¿Qué es un ataque HTTP Flood DDoS?

¿Qué es un ataque HTTP flood DDoS?

Un HTTP flood es un ataque DDoS Layer-7 (capa de aplicación) donde el atacante envía volúmenes masivos de peticiones HTTP GET o POST a un servidor web objetivo. Cada petición individual parece legítima — HTTP bien formado, header user-agent realista, URL plausible — lo que hace los HTTP floods difíciles de filtrar sin bloquear usuarios reales en el proceso. Los HTTP floods son el patrón de ataque DDoS L7 más común: fáciles de ejecutar, difíciles de defender y desproporcionadamente destructivos relativos al ancho de banda consumido.

A diferencia de los ataques volumétricos (Layer 3/4) que saturan el ancho de banda de red con floods de paquetes brutos, los HTTP floods agotan recursos del lado servidor: pools de workers de servidor web, conexiones de base de datos, memoria de aplicación y cuotas de API downstream. Una botnet de 5.000-10.000 nodos golpeando un endpoint caro a 5 peticiones/segundo por nodo — 25.000-50.000 RPS agregadas — puede tirar una aplicación SaaS típica de tamaño medio sin exceder el ancho de banda que un solo usuario residencial de banda ancha usaría.

Cómo funcionan los ataques HTTP flood

El atacante controla una botnet — una red de dispositivos comprometidos: navegadores hackeados, dispositivos IoT (cámaras, routers, electrodomésticos smart) o instancias cloud alquiladas compradas en foros darkweb por 5-50 $/hora para ataques cortos. Cada bot en la red envía peticiones HTTP al objetivo con estas características:

• HTTP bien formado. Peticiones HTTP/1.1 o HTTP/2 reales con headers válidos — Host, User-Agent (a menudo spoofed para parecer Chrome/Safari/Firefox), Accept, etc. Lo que falla parsing HTTP básico se descarta en la WAF de todos modos.
• IPs de origen distribuidas. Las peticiones vienen de miles de IPs geográficamente dispersas — típicamente espacio IP residencial alquilado de dispositivos comprometidos, pools CGNAT de ISP o rangos IP transitorios de proveedores cloud.
• Selección de endpoint dirigida. Los atacantes inteligentes apuntan a los endpoints más caros: /search?q=..., /api/recommendations, la homepage dinámica sin caché, formularios de login que golpean la base de datos de auth. Cada petición dispara trabajo significativo de CPU y base de datos.
• Variación cache-busting. Añadir parámetros de query únicos o aleatorizar fragmentos para forzar cada petición a través del CDN al origen: /search?q=test&_cb=12345, /search?q=test&_cb=12346, etc. El caching de CDN se vuelve inútil.

HTTP flood vs otros patrones de ataque L7

El HTTP flood es el ataque L7 más común pero existen varias variantes y patrones adyacentes:

• HTTP flood (esta entrada): Alto volumen de peticiones HTTP totalmente formadas. Puede ser GET-flood (endpoints read-heavy) o POST-flood (endpoints write-heavy — a menudo más dañinos porque las escrituras golpean la base de datos).
• Slowloris: Abre muchas conexiones TCP, envía headers HTTP parciales lentamente, nunca termina. Las conexiones permanecen abiertas consumiendo slots del servidor; los usuarios legítimos no pueden conectarse porque el pool de conexiones está agotado.
• RUDY (R-U-Dead-Yet): Ataque slow POST — envía headers POST válidos, luego gotea el body en chunks diminutos durante horas. El servidor web mantiene la conexión viva esperando que el body se complete.
• GET recursivo: Martillea endpoints recursivos caros (búsqueda-con-filtros, agregaciones complejas) que tocan muchos servicios backing por petición.
• Flood spam de formulario: POST-floods a formularios (login, signup, contacto) que disparan efectos secundarios downstream: emails enviados, nuevos registros de usuario, entradas de log.

Por qué los HTTP floods son peligrosos

• Difíciles de distinguir de usuarios reales. Un pico de GETs a homepage desde miles de IPs distintas se ve como un hit viral O un HTTP flood. Los defensores tienen que elegir: bloquear agresivamente y perder usuarios reales, o ser permisivos y quedarse vulnerables.
• Amplificación de recursos. Una petición HTTP de 1 KB puede disparar una query de base de datos de 100 ms más una llamada de recomendación de 200 ms más un hit de API downstream de 50 ms. Cada byte de input de ataque se convierte en 100+ bytes de trabajo del lado servidor.
• Amplificación de costes. Si autoscalas en tráfico, un HTTP flood escala tu factura de infraestructura hacia arriba. El atacante paga por una botnet; tú pagas a AWS por los workers sirviendo al atacante.
• Fallos en cascada. Cuando el pool de workers está saturado, los usuarios reales empiezan a hacer timeout. Sus navegadores reintentan, aumentando la carga aún más. La aplicación puede caer antes de que el ataque alcance "saturación" en cualquier sentido tradicional.

Cómo defenderse contra HTTP floods

WAF con rate limiting

Una WAF moderna (Cloudflare, AWS WAF, Akamai, Fastly) se sienta delante del origen y aplica rate limits por IP, por sesión, por endpoint. La mayoría de managed rule sets WAF reconocen fingerprints de bots comunes y patrones de HTTP flood automáticamente. Sintoniza el rate limit a tu pico de tráfico normal más 50% de margen — cualquier cosa por encima dispara la WAF.

Challenges JavaScript y CAPTCHAs

Cuando la WAF detecta un patrón flood, sirve un challenge JavaScript o CAPTCHA. La mayoría de botnets no ejecutan JavaScript ni resuelven CAPTCHAs a escala; los navegadores reales sí. El modo "Under Attack" de Cloudflare automatiza esto. Los challenges modernos son invisibles para la mayoría de usuarios legítimos.

Caching agresivo

Los ataques cache-busting fallan contra endpoints bien cacheados. Configura Cache-Control: max-age en todos los endpoints GET. Usa una CDN con altos ratios de cache hit. Para endpoints dinámicos, considera stale-while-revalidate para servir contenido cacheado mientras el origen se recupera.

Rate limiting a nivel de aplicación

Defensa en profundidad. Incluso con una WAF, tu aplicación debería rate-limitar a nivel de sesión/usuario. Una WAF atrapa floods basados en IP; los rate limits de aplicación atrapan atacantes que rotan a través de IPs residenciales pero coordinan contra las mismas cuentas.

Prepárate para failover

Identifica tus endpoints más caros y ten un plan de circuit-breaker. Si /api/recommendations es el cuello de botella durante ataques, configúralo para devolver un fallback cacheado o una respuesta de error simple cuando la carga exceda X peticiones/segundo. Mejor degradar una feature que colapsar todo el sitio.

Monitoriza y alerta proactivamente

Deberías saber de un HTTP flood antes que tus clientes. Alerta sobre: tasa de peticiones por encima de 2x la baseline rolling, tasa de error por encima del 1%, latencia p95 por encima del SLO. La mitigación automatizada (auto-activación de WAF) cierra el gap de "detectado" a "mitigado" pero el monitoreo proactivo atrapa ataques que la WAF no atrapa.

FAQ: Ataques HTTP Flood DDoS

¿Cómo de grande necesita ser un HTTP flood para tirar un sitio?

Más pequeño de lo que la gente cree. 25.000-50.000 RPS apuntando a endpoints caros pueden sobrepasar el pool de workers de una aplicación SaaS típica de tamaño medio. Los atacantes no necesitan millones de peticiones por segundo — solo lo suficiente para saturar tus endpoints más caros más rápido de lo que el autoscale puede reaccionar.

¿Detendrá el plan gratis de Cloudflare HTTP floods?

Parcialmente. El plan gratis proporciona protección DDoS básica (mayormente Layer 3/4) y modo "Under Attack" para ataques L7. Los HTTP floods persistentes o sofisticados necesitan el plan Pro/Business con reglas WAF gestionadas, controles de rate-limiting y gestión de bots.

¿Cómo distingo un HTTP flood de un pico de tráfico viral?

Mira la forma del tráfico: los picos virales se concentran en una o pocas URLs (la página que se hizo viral) con user-agents, geografía y referers diversos. Los floods son uniformes: las mismas URLs golpeadas por los mismos user-agents desde las mismas regiones, sin referers orgánicos. La tasa de conversión también ayuda — el tráfico viral convierte; el tráfico flood no.

¿Puedo ejecutar una prueba de carga que imite un HTTP flood?

Sí — eso es exactamente lo que hace stress testing. Usa LoadFocus para ejecutar scripts JMeter o k6 a alta concurrencia desde regiones cloud, golpeando tus endpoints caros con formas de petición realistas. Valida que tus rate limits, CDN y autoscale funcionan ANTES de que un atacante los pruebe. La diferencia: las pruebas de carga respetan rate limits y paran a la señal; los atacantes no.

¿Debería rate-limitar por IP o por sesión?

Ambos. El rate-limiting por IP atrapa ataques desde fuentes únicas. El rate-limiting por sesión/usuario atrapa ataques distribuidos que vienen de miles de IPs pero coordinados contra tus endpoints. Apílalos — ninguno solo es suficiente.

¿Cuál es el coste de no estar preparado para un HTTP flood?

Tres cubos: directo (coste de downtime — transacciones perdidas, penalizaciones SLA), indirecto (coste de autoscale — tu factura de infraestructura multiplicada mientras se sirve tráfico de ataque), reputacional (churn de clientes tras outages públicos, caídas de ranking si Googlebot no puede crawlear durante ataques). Para un sitio e-commerce típico, un outage de 4 horas durante el tráfico pico cuesta cinco cifras como mínimo.

Cómo LoadFocus te ayuda a prepararte para HTTP floods

LoadFocus ejecuta pruebas de carga JMeter y k6 scriptables a escalas que imitan patrones de ataque HTTP flood: alta RPS, targeting de endpoints caros, variaciones cache-busting. Ejecuta un stress test desde loadfocus.com/es-es/free-load-test contra tu entorno staging para validar que tus rate limits, caching CDN y autoscale funcionan antes de que un atacante los stress-teste por ti. Combina con monitorización de API desde 25+ regiones para atrapar ataques reales temprano.