Ataque HTTP Flood: qué es y cómo mitigar este DDoS de capa 7

Un ataque HTTP Flood es un tipo de DDoS de capa de aplicación (Layer 7) que satura un servidor web con una avalancha de peticiones HTTP aparentemente legítimas. A diferencia de los ataques volumétricos, consume poco ancho de banda e imita el comportamiento de usuarios reales, lo que lo convierte en una de las amenazas más difíciles de detectar y mitigar.

Qué es un ataque HTTP Flood

El HTTP Flood opera en la capa 7 del modelo OSI, la capa de aplicación. En lugar de inundar la red con paquetes malformados, el atacante envía solicitudes HTTP válidas (normalmente GET o POST) desde una botnet de miles de dispositivos comprometidos. Cada petición es, por sí sola, indistinguible del tráfico real: cabeceras correctas, user-agents de navegadores legítimos y rutas existentes. El objetivo no es saturar el enlace de red, sino agotar los recursos del servidor de aplicaciones: hilos, conexiones, CPU, memoria y, sobre todo, la base de datos. Según OWASP, los ataques de denegación de servicio a nivel de aplicación están entre los más eficientes por la asimetría de recursos que explotan.

HTTP Flood vs. ataques volumétricos

Un ataque volumétrico clásico (UDP flood, SYN flood) busca consumir el ancho de banda con fuerza bruta y genera picos de tráfico fáciles de identificar. El HTTP Flood es lo contrario: bajo volumen, alto impacto. Una sola petición a un endpoint costoso —una búsqueda, un login o un carrito de compras— puede disparar consultas pesadas a la base de datos. Multiplicado por miles de bots, el servidor colapsa sin que el tráfico parezca anómalo a simple vista. Esta asimetría —poco esfuerzo para el atacante, mucho para el servidor— es lo que hace al HTTP Flood tan rentable.

Tipos de HTTP Flood

HTTP GET Flood: el atacante solicita de forma repetida recursos pesados (imágenes, PDFs, páginas dinámicas) para forzar al servidor a procesarlos una y otra vez.

HTTP POST Flood: envía formularios o cargas que obligan al backend a escribir en disco o ejecutar lógica costosa. Suele ser más dañino porque cada petición consume más recursos del lado del servidor.

Low and slow (Slowloris): en lugar de muchas peticiones, mantiene abiertas cientos de conexiones enviando datos muy lentamente, agotando el pool de conexiones del servidor con un tráfico mínimo.

Cache-busting: añade parámetros aleatorios a la URL (?x=12345) para saltarse la caché del CDN y forzar que cada petición llegue al origen.

Los atacantes más sofisticados apuntan deliberadamente a los endpoints más caros de la aplicación, donde una petición legítima ya consume muchos recursos.

Por qué es tan difícil de detectar

El reto del HTTP Flood es que cada petición parece legítima. No hay paquetes malformados ni firmas evidentes. Cada bot puede enviar pocas solicitudes por segundo —por debajo de cualquier umbral simple de rate limiting— y aun así, en conjunto, tumbar el servicio. Distinguir un usuario real de un bot bien diseñado exige análisis de comportamiento, no solo conteo de peticiones.

Cómo mitigar un ataque HTTP Flood

1. Rate limiting granular. Limita las peticiones por IP y por endpoint, con especial atención a las rutas costosas. En Nginx, por ejemplo:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /login { limit_req zone=api burst=20 nodelay; }

Más detalles en la guía de rate limiting de Nginx.

2. WAF con análisis de comportamiento. Un Web Application Firewall moderno —como el OWASP Core Rule Set sobre ModSecurity, o el WAF de Cloudflare— perfila el tráfico y bloquea patrones anómalos antes de que lleguen a la aplicación.

3. Challenges y CAPTCHA. Retos de JavaScript o CAPTCHA (como Cloudflare Turnstile) filtran botnets sin fricción para los usuarios reales.

4. Gestión de bots y fingerprinting. Identifica clientes automatizados por su huella técnica (TLS, cabeceras, comportamiento), no solo por su IP.

5. CDN y caché. Servir contenido cacheado desde el borde absorbe gran parte de la carga antes de tocar el origen; combínalo con protección anti cache-busting.

6. fail2ban y bloqueo automático. Detecta patrones de abuso en los logs y banea de forma reactiva las IPs ofensivas.

Valida tus defensas antes de que lo haga un atacante

Tener estos controles configurados no garantiza que funcionen bajo presión real. La única forma de saberlo es probarlos con simulaciones de carga y ataques de capa 7 en un entorno autorizado. En SecPro simulamos ataques DDoS de aplicación contra tu infraestructura para verificar que tus controles resisten —no solo en el papel— y medir tu tiempo real de detección y respuesta.

Conclusión

El HTTP Flood demuestra que el volumen no lo es todo: un ataque de bajo ancho de banda, bien dirigido a la capa de aplicación, puede ser tan devastador como uno volumétrico y mucho más sigiloso. Protegerse exige defensas en capa 7 —rate limiting, WAF, gestión de bots y caché— y, sobre todo, ponerlas a prueba antes de que lo haga un atacante real.