En arquitecturas con WAF/CDN, el diseño implícito es simple: todo el tráfico “de verdad” debe entrar por la capa perimetral, ser inspeccionado y recién después llegar al origen (ALB, API Gateway, App Service, etc.). El Origin IP Bypass rompe ese contrato cuando la IP pública del origen queda expuesta y puede ser alcanzada desde Internet. En ese momento, el WAF puede seguir “funcionando” y facturando, pero el atacante ya no está obligado a pasar por él.
Lo delicado es que no suele fallar por una vulnerabilidad sofisticada, sino por pequeñas decisiones operativas: un subdominio olvidado, un cambio de DNS apresurado, una cabecera que delata, o un Security Group/NSG demasiado permisivo. El impacto no es teórico: bots y atacantes automatizados buscan justo estos huecos porque convierten una defensa cara en una opción.
Qué salió mal: el bypass no ataca el WAF, rodea la arquitectura
El escenario típico es este: publicas una aplicación detrás de CloudFront/Azure Front Door/Cloudflare con WAF y reglas trabajadas. El equipo confía en que el origen solo recibirá tráfico “filtrado”. Sin embargo, el origen (un Application Load Balancer, un API Gateway o un endpoint HTTP directo) sigue teniendo una IP pública o un nombre resoluble y, peor, es accesible desde 0.0.0.0/0. El atacante no “rompe” el WAF: simplemente deja de usarlo.
En producción esto se manifiesta con consecuencias concretas: picos de CPU en el backend mientras el panel del WAF se ve tranquilo; rate limiting que parece no hacer efecto; y un aumento de errores 5xx que no correlaciona con el tráfico observado en el CDN. En incidentes reales, el primer síntoma suele ser un “misterioso” DDoS de capa 7 o un scraping agresivo que, supuestamente, tu WAF ya bloqueaba.
Hay un detalle operativo que agrava el problema: muchos equipos validan la seguridad mirando solo el flujo “correcto” (cliente → CDN → origen). Pero el bypass se valida atacando el flujo “prohibido” (cliente → origen directo). Si esa ruta existe, el resto de controles son parciales por definición.
Cómo se descubre la IP del origen en entornos corporativos (y por qué pasa)
Descubrir la IP real del origen no requiere magia; requiere paciencia y señales laterales. En organizaciones grandes es habitual que existan restos: subdominios de pruebas, endpoints heredados de migraciones, o registros DNS antiguos en caches y proveedores externos. En un pentest interno, suele bastar con enumeración de DNS y revisión de certificados para encontrar una puerta trasera involuntaria.
Los vectores más frecuentes encajan con el día a día de una empresa:
- Subdominios olvidados o paralelos: un
api-old.empresa.comque apunta directo al ALB o a un backend “temporal” que terminó siendo permanente. - Historial de DNS: cambios de proveedor (de ALB directo a CloudFront, por ejemplo) dejan rastros; atacantes consultan fuentes de histórico o resuelven nombres que antes apuntaban al origen.
- Fugas en cabeceras o respuestas: respuestas que delatan infraestructura o rutas internas; a veces un backend devuelve redirecciones, hostnames o valores inconsistentes que ayudan a triangulación.
Cada uno de estos puntos suele aparecer por fricción real: prisas de un go-live, equipos distintos gestionando DNS y red, y la falsa sensación de que “si el dominio principal está detrás del CDN, ya está”. En incidentes, a menudo el bypass entra por un subdominio que ni siquiera está en el inventario de aplicaciones.
Una consecuencia muy concreta: si el atacante descubre el origen, puede lanzar fuerza bruta, explotación de endpoints pesados o abusos de API directamente contra el ALB/API Gateway. Es habitual que el WAF tenga reglas para path traversal, SQLi o bots, pero el origen directo no las verá jamás.
El error de configuración más caro: reglas abiertas hacia el origen
El patrón clásico es un Security Group/NSG que permite HTTP/HTTPS desde cualquier lugar porque “ya lo protege el WAF/CDN”. Eso es exactamente lo que habilita el Origin IP Bypass. En AWS, por ejemplo, un ALB internet-facing con un security group que permite 443 desde 0.0.0.0/0 seguirá siendo accesible aunque CloudFront esté delante. En Azure, un backend detrás de Front Door sin restricciones equivalentes acaba en la misma situación.
En empresas esto aparece por motivos prácticos: se habilita temporalmente para una prueba, para un partner externo, para monitorización, o porque nadie quiere mantener allowlists de rangos IP. El problema es que la “temporalidad” se vuelve permanente, y el atacante solo necesita una ventana de exposición. Además, cuando el origen recibe tráfico directo, tu observabilidad se fragmenta: parte del tráfico se ve en logs del CDN/WAF y parte solo en logs del backend, complicando respuesta a incidentes.
Señales tempranas que suelen pasar desapercibidas:
- Tráfico en el origen con Host inesperado: peticiones que no llevan el
Hostdel dominio público, o que usan el DNS name del ALB/API. Esto suele indicar acceso directo o escaneo. - Distribución de IPs cliente “imposible”: si esperas ver solo IPs del CDN llegando al origen, pero aparecen IPs residenciales o de cloud providers aleatorios, hay un bypass o un camino paralelo.
Operativamente, cada bullet se traduce en acciones claras: revisar logs del ALB/API para Host, SNI y patrones de UA; y comparar la lista de IPs origen con los rangos permitidos del proveedor CDN. Si esa comparación no cierra, el bypass ya no es una hipótesis: es un hecho.
Cómo hacerlo en la práctica: cerrar el bypass con controles verificables
La mitigación efectiva no es “poner más reglas en el WAF”, porque el bypass lo evita. La mitigación es eliminar la alcanzabilidad pública del origen o restringirla estrictamente para que solo el CDN pueda hablar con él. La decisión dependerá de tu plataforma y de si puedes operar sin IP pública.
Acciones concretas que funcionan en entornos reales:
- Restringir el origen a rangos IP del CDN: en AWS, ajustar el Security Group del ALB para permitir 443 solo desde los rangos de CloudFront (si aplica en tu diseño) o desde componentes controlados; en Azure, lo equivalente con NSG/Firewall para que el backend solo acepte tráfico esperado.
- Integración nativa de WAF en el balanceador: si tu origen es un ALB, asociar AWS WAF al ALB reduce el “punto único” del CDN; si alguien llega al ALB, sigue habiendo inspección. En Azure, el patrón equivalente es llevar el control a la capa que realmente recibe tráfico.
- Eliminar IP pública del origen con PrivateLink: usar AWS PrivateLink/Azure Private Link para que el backend sea privado y el tránsito hacia el origen no dependa de una IP pública alcanzable desde Internet.
La clave está en la verificación, no en la intención. Valida con pruebas directas: intenta conectar a la IP/DNS del origen desde una red externa. Si responde, el bypass sigue abierto. En AWS, además, revisa que el ALB no esté expuesto por error (scheme internet-facing) y que el Security Group no tenga inbound amplio. En Azure, verifica que el backend no tenga exposición pública alternativa por endpoints heredados o reglas demasiado generales.
Un control adicional que ayuda a detectar fallos de allowlist: instrumenta alertas cuando el origen reciba tráfico desde IPs fuera del conjunto esperado (rangos del CDN, NATs corporativos, etc.). En incidentes reales, esta alerta reduce el tiempo de detección de días a minutos.
Recomendaciones para entornos corporativos
El Origin IP Bypass aparece cuando el origen mantiene una ruta pública paralela al CDN/WAF. No necesitas que el WAF “falle”; basta con que el atacante encuentre la IP real del ALB/API Gateway mediante subdominios olvidados, histórico de DNS o señales en cabeceras, y pueda conectarse porque los Security Groups/NSGs permiten 0.0.0.0/0.
Las medidas que realmente cierran el problema son arquitectónicas y de red: restringir el origen para que solo sea alcanzable por el perímetro esperado, llevar controles (WAF) a la capa que recibe tráfico si hay exposición inevitable, y preferir diseños sin IP pública usando PrivateLink cuando la plataforma lo permite. Operativamente, la disciplina es verificar: probar acceso directo al origen desde fuera y monitorear cualquier IP de origen que no corresponda al CDN.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.