¿Qué es un ataque HTTP Flood?
El HTTP Flood es un ataque DDoS de capa 7 (aplicación) que satura un servidor web con una avalancha de peticiones HTTP aparentemente legítimas (GET o POST). A diferencia de los ataques volumétricos, no busca saturar el ancho de banda sino agotar los recursos del servidor —CPU, memoria, conexiones a base de datos— con peticiones que parecen las de un usuario normal, lo que lo hace difícil de detectar.
GET Flood vs POST Flood
El GET Flood pide repetidamente recursos pesados (imágenes, páginas dinámicas) para forzar al servidor a procesarlos. El POST Flood envía formularios o cargas que obligan a procesar datos en el backend y consultar la base de datos, consumiendo más recursos por petición. Ambos suelen ejecutarse desde botnets para simular tráfico distribuido y realista.
¿Cómo mitigar un HTTP Flood?
Las defensas efectivas incluyen un WAF (Web Application Firewall), rate limiting por IP y por sesión, retos tipo CAPTCHA o JavaScript para filtrar bots, caché en el borde (CDN) y análisis de comportamiento para distinguir usuarios reales de peticiones automatizadas. Tratamos este ataque en profundidad en nuestro blog.
Por qué es más difícil de filtrar que un ataque volumétrico
Porque cada petición es, individualmente, legítima: un GET o un POST bien formado que cualquier navegador podría enviar. No hay paquetes malformados ni direcciones falsificadas que delaten el origen, porque el ataque necesita completar el saludo TCP y el cifrado TLS. Distinguirlo del tráfico real exige mirar el comportamiento —ritmo, orden de navegación, cabeceras, si se cargan los recursos asociados— y no el contenido de cada paquete.
Peticiones caras: el truco que multiplica el daño
Un atacante competente no pide la portada, que suele estar cacheada y es barata de servir. Busca lo que obliga al servidor a trabajar: búsquedas internas con términos poco frecuentes, filtros combinados en un catálogo, exportaciones, endpoints que consultan la base de datos sin caché. Así, unas pocas peticiones por segundo consumen más recursos que miles contra contenido estático, y el gráfico de ancho de banda ni se inmuta mientras el servicio se cae.
Qué defensa funciona de verdad
Limitación de tasa por sesión y por endpoint, no solo por IP, porque el tráfico viene distribuido. Cachear agresivamente lo que se pueda para que el grueso no llegue a la aplicación. Exigir una prueba de que hay un navegador real —un desafío ligero o un verificador— en las rutas caras. Y conocer la propia línea base: sin saber cuántas peticiones por minuto recibe normalmente cada endpoint, no hay forma de reconocer cuándo empieza el ataque.
