IP de origen tras un CDN: cómo se filtra y cómo cerrarla

La puerta principal y la puerta trasera

Un CDN o un WAF en el cloud se sitúa delante del servidor y atiende el hostname. Apunte un escáner a ese hostname y la petición va al edge: el TLS del edge, las cabeceras del edge, los rate limits y las reglas del edge. Un informe en verde es un informe sobre el edge. El origen, el servidor real, no ha sido tocado por ese escaneo, y todo lo que exponga directamente sigue expuesto a cualquiera que lo alcance por dirección en lugar de por nombre.

Por dónde se filtra el origen

La dirección rara vez está bien escondida, porque el dominio la publica para otros fines. El registro SPF es el caso habitual. Una política SPF que usa el mecanismo a autoriza al propio registro A del dominio a enviar correo, y ese registro A es el origen tras el CDN. El mecanismo mx apunta a los hosts de correo, que a menudo están en el mismo rango. Un ip4: literal la escribe con todas sus letras.

$ dig +short TXT example.com
"v=spf1 a mx ip4:<address> include:_spf.<mail-provider> ~all"
$ dig +short MX example.com
$ dig +short A mail.example.com ftp.example.com staging.example.com origin.example.com

Más allá del SPF: subdominios que nunca se pusieron tras el CDN (mail, ftp, un panel de control, staging, un host de origen a secas), que resuelven directamente al servidor. Los certificate transparency logs, que registran cada certificado emitido para un nombre, incluido el del host de origen. Las bases de datos de passive DNS, que conservan el registro A de antes de introducir el CDN. Las cabeceras Received de cualquier correo que envíe el servidor web, que nombran el host del que salió. Y funciones de la aplicación que hacen que el servidor se conecte hacia fuera a petición, como pingbacks y pruebas de webhook, que muestran la dirección de conexión a quien recibe la llamada.

Fije el origen y escanee lo que escanea un atacante

Una vez conocida la dirección, haga que las herramientas ignoren el CDN. curl lo hace por petición. Los escáneres que no pueden reciben una entrada en el fichero hosts. Ejecútelo desde una máquina que no esté en su propia red ni en ninguna allowlist en la que confíe el origen, porque un escaneo desde una dirección de confianza informa de lo que ven las direcciones de confianza.

# per request, no hosts-file change
$ curl --resolve example.com:443:<address> -sI https://example.com/

# for tools without --resolve
$ echo "<address>  example.com" | sudo tee -a /etc/hosts

Mantenga dos columnas en el resultado. La columna de infraestructura: qué puertos responden, qué versiones de TLS se aceptan, si los banners ofrecen nombres de software. La columna de aplicación: endpoints sin autenticación que enumeran usuarios, ficheros de debug o logs legibles en el web root, rutas de administración accesibles sin segundo factor, componentes por detrás de su versión actual. Una máquina bastionada que sirve una aplicación abierta no es un sitio seguro, y las dos columnas no se promedian en un único veredicto.

Cierre el origen al CDN

La corrección estructural está en el origen, no en el edge. Los puertos web responden solo a los rangos de direcciones publicados del CDN, con todo lo demás denegado por defecto. En un host con firewalld:

# load the CDN's published ranges into an ipset, then allow only them on 443
$ firewall-cmd --permanent --new-ipset=cdn-v4 --type=hash:net
$ firewall-cmd --permanent --ipset=cdn-v4 --add-entries-from-file=cdn-ranges-v4.txt
$ firewall-cmd --permanent --zone=public --remove-service=http
$ firewall-cmd --permanent --zone=public --remove-service=https
$ firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="cdn-v4" port port="443" protocol="tcp" accept'
$ firewall-cmd --reload
$ firewall-cmd --ipset=cdn-v4 --get-entries

Dos detalles deciden si esto aguanta. Los rangos del CDN cambian, así que el fichero se refresca desde la lista publicada del CDN de forma programada y el ipset se recarga con él. Y cada prefijo de una allow list se vuelve a leer después de cargarlo: una longitud de prefijo con un carácter mal escrito deja pasar una gran parte de internet y parece normal dentro del fichero.

Los rangos de direcciones son el primer cerrojo, no el único. La mayoría de los CDN pueden autenticar sus pulls hacia el origen con un certificado de cliente. Exíjalo en el servidor web, de modo que una petición desde dentro de un rango del CDN que no presente el certificado siga siendo rechazada. Después elimine las filtraciones que queden: un registro SPF que nombre solo los hosts que envían correo, ningún subdominio sin proxy apuntando al origen y, donde sea práctico, una dirección de origen nueva una vez puesto el cerrojo, porque la antigua permanece en el passive DNS indefinidamente.

Verifique desde fuera

Vuelva a ejecutar el escaneo fijado desde el mismo punto no confiable. El origen rechaza la conexión en el 443, y el hostname sigue sirviéndose a través del CDN. Repítalo después de cada cambio en los rangos o en la configuración del servidor web. Cómo convertir esto en una comprobación permanente en lugar de una acción puntual es el tema de demuestre que está cerrado desde fuera.

$ curl --resolve example.com:443:<address> -m 5 -sI https://example.com/ ; echo "exit $?"
exit 28
# a timeout (28) or a refused connection (7) is the correct answer from the locked origin