Un ataque HTTP Flood es un ataque DDoS de capa 7 (aplicación) que inunda un servidor web o una API con un alto volumen de solicitudes HTTP GET o POST, o mediante vectores específicos del protocolo HTTP/2. A diferencia de los ataques volumétricos que saturan el ancho de banda, el HTTP Flood agota los recursos del servidor — hilos, conexiones, CPU y memoria — usando solicitudes que pueden parecer legítimas para los dispositivos de red que no inspeccionan el contenido.
Cómo funcionan los ataques HTTP Flood
El impacto de un HTTP Flood depende del coste por solicitud en el lado del servidor. Las solicitudes a endpoints que consultan bases de datos, ejecutan lógica de negocio, realizan llamadas a servicios externos o renderizan contenido dinámico pueden agotar recursos con un volumen relativamente bajo. El atacante no necesita generar terabits de tráfico — basta con concentrar solicitudes en rutas costosas.
El ataque puede usar una botnet con muchas IPs de origen o un conjunto menor de clientes que abren múltiples conexiones o streams. La detección requiere análisis de patrón, comportamiento, coste por ruta y baseline histórico — no solo volumen bruto.
Taxonomía: HTTP Flood en contexto con otros ataques
La clasificación por capas OSI es un modelo operacional útil, pero no es rígida. Un mismo ataque puede explotar un protocolo de aplicación, viajar sobre TCP y, al mismo tiempo, presionar CPU, colas de conexión y lógica de negocio. La tabla siguiente usa categorías operacionales para orientar la defensa.
| Categoría operacional | Ejemplos | Recursos frecuentemente presionados |
|---|---|---|
| HTTP Flood (L7) | GET Flood, POST Flood, cache bypass, Rapid Reset | CPU, hilos, memoria, base de datos, lógica de negocio |
| Low and slow (L7) | Slowloris, R.U.D.Y., Slow POST | Pool de conexiones TCP, workers |
| Estado y protocolo (L4) | SYN Flood, ACK Flood | Colas de handshake, tablas stateful, CPU |
| Reflexión/amplificación | DNS Amplification, NTP, SSDP | Ancho de banda, PPS, enlaces |
| Volumétrico puro (L3/L4) | UDP Flood, ICMP Flood | Banda, PPS, uplinks |
Los routers y controles de red normalmente actúan en las capas 3 y 4, aplicando políticas por IP, puerto, protocolo, volumen y comportamiento de flujo. Los firewalls modernos y los proxies pueden ofrecer capacidades adicionales de inspección, pero el análisis completo de solicitudes HTTP normalmente requiere un WAF, un proxy inverso u otro componente que termine TLS.
Tipos de HTTP Flood
GET Flood
Envía solicitudes HTTP GET en alto volumen contra una o varias URLs del servidor. Las URLs que activan consultas a bases de datos, renderizado dinámico de páginas o procesamiento pesado en el backend son objetivos preferidos — cada solicitud consume más recursos que una respuesta estática. El objetivo es ocupar todos los hilos de procesamiento disponibles hasta que el servidor deje de responder.
POST Flood
Combina el volumen de solicitudes con el coste de procesar cargas útiles. Los formularios de autenticación, endpoints de búsqueda y APIs de procesamiento de datos son objetivos comunes — cada solicitud POST obliga al servidor a analizar el cuerpo del mensaje antes de responder. Un POST Flood puede tener mayor impacto por solicitud que un GET Flood, lo que significa que volúmenes menores de RPS pueden producir un efecto similar.
Cache bypass
Un atacante puede intentar reducir la eficiencia de la caché usando parámetros aleatorios, rutas únicas o atributos que alteren la clave de caché — como ?cb=7f3a9 o ?ts=1687234561. El efecto depende de la política de caché: algunas CDNs incluyen query strings en la clave, mientras que otras pueden ignorar, normalizar o limitar determinados parámetros.
Cuando el ataque tiene éxito, los cache misses aumentan y más solicitudes llegan al origen, elevando su carga. Una caída abrupta en el cache hit rate es una señal relevante, pero debe correlacionarse con cambios de configuración, despliegues, campañas, cambios en el mix de contenido y métricas de origen antes de clasificarse como ataque.
HTTP/2 Rapid Reset
El HTTP/2 Rapid Reset explota el mecanismo de multiplexación de streams de HTTP/2. En HTTP/1.1, las conexiones persistentes pueden transportar múltiples solicitudes secuenciales, pero el protocolo no ofrece multiplexación simultánea nativa. HTTP/2 introdujo streams independientes que permiten múltiples solicitudes concurrentes sobre una única conexión TCP.
El ataque abre un stream con un frame HEADERS y lo cierra rápidamente con RST_STREAM. Dependiendo de la implementación, el servidor, el proxy o el balanceador de carga puede necesitar crear estado para el stream, procesar cabeceras, actualizar contadores, aplicar límites y gestionar la cancelación antes de liberar los recursos.
El impacto no requiere que toda solicitud llegue al backend. El coste de crear y cancelar streams a alta velocidad puede ser suficiente para presionar la CPU y las estructuras internas del stack HTTP/2. El problema central del CVE-2023-44487 era la posibilidad de eludir protecciones basadas únicamente en el límite máximo de streams concurrentes, abriendo y reseteando streams rápidamente para mantener bajo el recuento activo mientras se acumulaba trabajo en el servidor.
La detección requiere monitorear métricas específicas del protocolo HTTP/2: una alta proporción de frames RST_STREAM en relación a streams completados, combinada con alto consumo de CPU sin tráfico de respuesta proporcional, es el patrón característico de este vector.
Señales operativas: qué observar
La correlación de múltiples métricas es más fiable que cualquier indicador aislado. Los valores siguientes son ilustrativos — usa un baseline por aplicación, ruta, método HTTP, región y período. Una API autenticada puede tener un cache hit rate cercano a cero en operación normal; un servicio de contenido estático puede operar por encima del 95%.
| Indicador | Qué observar | Interpretación posible |
|---|---|---|
| RPS por ruta y método | Crecimiento por encima del baseline histórico | HTTP Flood, lanzamiento de campaña o crecimiento legítimo |
| Coste por endpoint | Aumento de CPU, base de datos, llamadas externas o latencia en rutas específicas | Ataque dirigido a ruta costosa, regresión de código o problema de dependencia |
| Cache hit rate por tipo de contenido | Caída respecto al baseline de la ruta o servicio | Cache bypass, cambio de caché, despliegue o cambio de mix de contenido |
| Errores 5xx y timeouts | Crecimiento correlacionado con presión de tráfico | Saturación del origen, fallo de backend o cambio de política |
| CPU del servidor de origen | Pico sin incremento proporcional de banda L3/L4 | HTTP Flood — no volumétrico |
| Proporción RST_STREAM / HEADERS | Crecimiento abrupto por conexión o cliente | Posible HTTP/2 Rapid Reset |
| Fingerprints TLS y comportamiento | Concentración o cambio inesperado de patrones | Automatización, cambio de cliente o tráfico legítimo concentrado |
| Sesiones, cookies y secuencia de navegación | Patrones inusuales para el endpoint | Bot, integración desconocida o fallo de cliente |
Ningún indicador aislado confirma un HTTP Flood. El análisis debe correlacionar telemetría de red, TLS, HTTP, caché, aplicación y comportamiento de usuarios.
Las alertas deben detectar cambios relevantes respecto al historial de ese flujo — no depender de porcentajes fijos universales.
Técnicas de mitigación
WAF con score-based detection
El WAF inspecciona solicitudes HTTP en la capa 7 y puede evaluar múltiples factores: anomalías en cabeceras, frecuencia de solicitudes por IP, coincidencia con firmas conocidas y reputación de origen.
Las cabeceras inusuales, ausentes o inconsistentes pueden usarse como señales adicionales, pero no deben bloquear tráfico de forma aislada. La evaluación debe considerar el tipo de endpoint, el contrato de la API, el perfil de clientes legítimos y la correlación con tasa, identidad, fingerprint, sesión y comportamiento. Clientes legítimos como APIs, aplicaciones móviles, health checks e integraciones backend-to-backend pueden omitir cabeceras como Accept-Language o Referer por razones válidas.
El WAF requiere ajuste continuo. Las reglas demasiado agresivas pueden bloquear tráfico legítimo; las reglas demasiado permisivas fallan en detectar ataques. El baseline de comportamiento por aplicación y endpoint es esencial para la calibración.
TLS fingerprinting JA3/JA4
JA3 y JA4 son señales de fingerprinting TLS basadas en características del Client Hello, como versiones, cipher suites y extensiones. Pueden ayudar a agrupar clientes con comportamientos similares e identificar automatización o herramientas conocidas cuando se correlacionan con otras señales.
Estos fingerprints no identifican de forma única a un usuario o bot. Los clientes legítimos pueden compartir la misma firma, y los atacantes sofisticados pueden imitar fingerprints de navegadores o usar navegadores reales. Los bots avanzados pueden usar Playwright, Puppeteer, Selenium o entornos móviles. Por ello, JA3/JA4 deben contribuir a un score de riesgo junto con reputación, tasa de solicitudes, cookies, comportamiento de navegación, identidad, ruta accedida y señales de aplicación.
JA4 es una familia más reciente de fingerprints, propuesta para reducir algunas limitaciones prácticas de JA3, como variaciones de ordenación en determinados campos. Su disponibilidad, formato y utilidad dependen de la herramienta de seguridad utilizada.
Rate limiting granular por endpoint
El rate limiting puede aplicarse por IP, prefijo, sesión, credencial, token, tenant, fingerprint, ruta y comportamiento. Los límites solo por IP pueden afectar a usuarios detrás de NAT o CGNAT y son menos efectivos contra botnets distribuidas. El objetivo es impedir que las solicitudes abusivas avancen hacia el origen, pero los controles de borde aún necesitan dimensionarse para absorber y clasificar el tráfico.
La granularidad por endpoint es esencial: un único umbral para toda la aplicación protege mal los endpoints costosos (autenticación, búsqueda, checkout) y puede bloquear tráfico legítimo en endpoints de alto volumen. Una respuesta HTTP 429 informa al cliente que debe esperar — y evita que la solicitud consuma recursos del origen, dependiendo de la arquitectura.
Browser challenge y CAPTCHA adaptativo
Los browser challenges y CAPTCHAs pueden elevar el coste de la automatización y reducir los ataques de bots simples. Sin embargo, los bots avanzados pueden ejecutar JavaScript o usar navegadores reales, y los challenges pueden afectar la accesibilidad, las APIs, las aplicaciones móviles, los WebViews y los usuarios con JavaScript bloqueado. Por ello, deben aplicarse de forma adaptativa, con monitoreo de falsos positivos y rutas de excepción para integraciones de confianza.
Protección en el edge — controles antes del origen
La mitigación más efectiva ocurre antes de que las solicitudes lleguen al servidor de origen. Cuando el tráfico HTTPS se termina en el edge, las políticas de WAF, limitación de tasa y protección de APIs pueden aplicarse antes de que las solicitudes seleccionadas se reenvíen al origen.
Una arquitectura distribuida de edge puede reducir la necesidad de desvío a un único centro de scrubbing y acercar la mitigación a las fuentes de tráfico. El impacto en la latencia depende de la topología, el enrutamiento, la ubicación de los puntos de presencia, la capacidad, la terminación de protocolos y las políticas aplicadas.
Errores comunes al mitigar HTTP Flood
Bloquear IPs individuales durante el ataque: los HTTP Floods modernos usan botnets distribuidas o múltiples IPs. El bloqueo solo por IP es lento y poco efectivo. Usa rate limiting basado en comportamiento, fingerprinting y análisis de patrones de acceso — que funcionan incluso cuando las IPs varían.
Aplicar el mismo rate limit a todos los endpoints: los endpoints críticos (autenticación, API, checkout) tienen menor tolerancia al volumen abusivo. Configura políticas granulares por URI con umbrales distintos según el coste de procesamiento.
Confiar solo en el firewall de red L3/L4: los firewalls de red no inspeccionan el contenido HTTP. Se necesita un WAF de capa 7 para detectar HTTP Flood, cache bypass y HTTP/2 Rapid Reset.
Usar umbrales fijos para el cache hit rate: una caída en el cache hit rate puede tener muchas causas además de un ataque — despliegue, expiración de TTL, cambio de mix de contenido, campañas. Calibra las alertas con el baseline histórico de la ruta y correla con otras métricas.
Ignorar las métricas del protocolo HTTP/2: la proporción de RST_STREAM es un indicador específico del Rapid Reset. Las herramientas de observabilidad de capa 7 deben incluir métricas de streams HTTP/2 además del RPS.
Preguntas frecuentes
¿HTTP Flood y DDoS de capa 7 son lo mismo? El HTTP Flood es una de las formas más frecuentes de DDoS de capa de aplicación, especialmente en servicios web y APIs. Otros ataques L7 incluyen los ataques low and slow (Slowloris, R.U.D.Y.), DNS Water Torture y exploits específicos de APIs. El HTTP Flood se distingue por el alto volumen de solicitudes o el alto coste por solicitud, mientras que los ataques low and slow operan con pocas conexiones mantenidas intencionalmente lentas. La prevalencia varía según la base observada por cada proveedor y el período analizado.
¿Cómo ayuda el TLS fingerprinting JA3/JA4 en la detección?
JA3/JA4 analiza el Client Hello de la negociación TLS — no las cabeceras HTTP. Cada implementación de biblioteca de red tiende a producir una combinación específica de cipher suites, extensiones TLS y curvas elípticas. Esto puede ayudar a identificar automatización o herramientas conocidas. Estos fingerprints no son identificadores únicos — muchos usuarios legítimos pueden compartir la misma firma — y los bots sofisticados pueden imitar navegadores. Deben usarse como parte de un score de riesgo, no como criterio aislado.
¿Qué hace peligroso al HTTP/2 Rapid Reset?
El cliente envía solo dos frames por intento (HEADERS + RST_STREAM). Dependiendo de la implementación, el servidor puede necesitar crear estado para el stream, procesar cabeceras, actualizar contadores y gestionar la cancelación antes de liberar los recursos — aunque el resultado se descarte poco después. El CVE-2023-44487 demostró que las implementaciones protegidas solo por el límite de streams concurrentes eran vulnerables a este patrón de apertura y reset rápido. El resultado puede ser saturación de CPU sin tráfico de respuesta proporcional.
¿Por qué HTTPS dificulta la mitigación? HTTPS cifra el contenido de las solicitudes. Los dispositivos de red sin terminación TLS no pueden inspeccionar las cabeceras HTTP, las URLs ni los payloads. La mitigación efectiva del HTTP Flood requiere terminación TLS en el edge, lo que permite al WAF inspeccionar el contenido completo de la solicitud. Esto es especialmente relevante para la detección de cache bypass y el análisis de comportamiento.
¿Un CDN protege automáticamente contra el HTTP Flood? Los CDNs absorben carga para el contenido cacheable. Los HTTP Floods que apuntan a endpoints dinámicos — APIs, autenticación, checkout — tienden a eludir la caché por definición o a usar técnicas de cache bypass. La protección efectiva requiere WAF y rate limiting integrados con el CDN para la inspección de capa 7 antes del reenvío al origen.
¿Cómo distingo un HTTP Flood de una prueba de carga legítima? Las pruebas de carga legítimas deben tener alcance, ventanas de tiempo, responsables, origen y métodos acordados previamente. La investigación debe correlacionar esos registros con la telemetría de tráfico, autenticación, origen, comportamiento, impacto de aplicación y cambios de configuración. Las señales de navegador, cookies y fingerprints pueden ayudar, pero no son prueba aislada de legitimidad o ataque.
¿Cuál es la diferencia operativa entre HTTP Flood y los ataques low and slow? El HTTP Flood tiende a generar alto volumen de solicitudes o alto coste por solicitud, y puede reutilizar conexiones persistentes, HTTP/2 o HTTP/3. Los ataques low and slow como Slowloris priorizan mantener conexiones o solicitudes incompletas abiertas durante largos períodos con baja tasa de datos — saturando el pool de conexiones sin generar alto RPS. Las defensas también difieren: el rate limiting y el WAF se centran en el HTTP Flood; los timeouts de conexión y los límites de sesiones simultáneas son más relevantes para los ataques low and slow.
Referencias técnicas
- RFC 9113 — HTTP/2
- RFC 9114 — HTTP/3
- CVE-2023-44487 — HTTP/2 Rapid Reset Attack
- Google Cloud: HTTP/2 Rapid Reset DDoS attack
Cómo implementar en Azion
Azion puede componer una estrategia de mitigación de HTTP Flood y abuso de aplicaciones web, conforme a los productos contratados, los protocolos publicados y las políticas configuradas.
-
Controles de capa 7 en el edge: cuando el tráfico HTTPS se termina en el edge, las políticas de WAF, limitación de tasa y protección de APIs pueden aplicarse antes de que las solicitudes seleccionadas se reenvíen al origen.
-
Rate limiting por ruta y comportamiento: los límites pueden configurarse por IP, URI, método, credencial, sesión, tenant u otros criterios disponibles en la política, considerando el coste y el perfil legítimo de cada endpoint.
-
Detección de automatización: señales de comportamiento, reputación, cabeceras, sesiones y fingerprints TLS — cuando estén disponibles — pueden ayudar a identificar tráfico automatizado. Estas señales deben usarse de forma combinada para reducir los falsos positivos.
-
Observabilidad: logs, métricas de solicitudes, errores, caché, latencia y políticas aplicadas pueden apoyar la detección de anomalías y el ajuste de controles durante un incidente.
La cobertura efectiva depende de la arquitectura de la aplicación, la terminación de TLS, los productos habilitados, las políticas configuradas y el perfil del tráfico y del ataque.
Aprende más en la documentación del WAF de Azion.