Una protección que se podía rodear
El sitio y la plataforma del cliente estaban detrás de una CDN con WAF. Pero el load balancer de origen, en la nube, seguía aceptando tráfico directo desde internet. Quien descubriera la IP del origen pasaba por fuera de toda la protección.
Cerrar esa puerta parecía cosa de una regla de firewall: bloquear todo lo que no viniera de la CDN. En la práctica, había tres piezas que tenían que cambiar juntas y en el orden correcto. El dominio raíz no acepta CNAME, por una regla del propio DNS, y el DNS del cliente no soportaba registros ALIAS. Por eso, el dominio raíz apuntaba a una IP fija de la CDN, configurada a mano: si la CDN cambiaba esa IP, el sitio se caía. El orden también importaba, porque bloquear el origen antes de que el DNS apuntara a la CDN tiraría el sitio. Y la recolección de métricas de los servidores pasaba justamente por el camino que se iba a cerrar.
Ensayar antes
Validé todo el flujo en una prueba de concepto antes de tocar producción, y fue ahí donde aparecieron los errores 403 al activar el bloqueo en el firewall del load balancer. Corregidos esos, restringí el origen: el firewall pasó a aceptar solo las IPs de la CDN.
Automatizar lo que depende de terceros
El punto frágil seguía siendo depender de IPs que no eran nuestras. Escribí dos scripts en Python. El primero sincroniza las IPs actuales de la CDN en los registros DNS de los dominios que no aceptan CNAME. Refactoricé la lógica en una función genérica, lo que permitió incluir un subdominio que todavía apuntaba directo al origen, y corregí un bug en el modo de simulación: en Python, el string "false" es verdadero. El segundo script mantiene las IPs de la CDN actualizadas en la lista de permitidos del firewall.
Para que el monitoreo sobreviviera al bloqueo, ajusté la recolección de métricas para descubrir las IPs de las instancias de autoscaling por la API de la nube, sin pasar por el camino cerrado. También apoyé la prueba de concepto de APM, con proxy reverso y certificados TLS, incluido un wildcard, para el colector.
Un redirect que rompía imágenes
En medio del trabajo, un redirect empezó a romper imágenes, y el primer sospechoso era el DNS. Mostré con pruebas que el DNS estaba bien y que el problema era la regla de redirect de la CDN, que descartaba la ruta de la URL. El servidor de origen, en comparación, la preservaba. Separar lo que era DNS de lo que era CDN evitó un cambio equivocado.
Qué cambió
El origen dejó de ser accesible directamente: todo el tráfico pasó a entrar por la CDN y el WAF. El riesgo de la IP fija quedó automatizado, y si la CDN cambia sus IPs, el DNS y el firewall se actualizan solos. El monitoreo de los servidores siguió funcionando después del bloqueo.
Lo que me llevo
La seguridad del borde no es una regla de firewall, es un cambio coordinado entre DNS, CDN, firewall y monitoreo. Y todo lo que depende de una IP que no controlas tiene que estar automatizado, o se vuelve una caída esperando su momento.