¿Qué es un ataque DDoS por inundación HTTP?

¿Qué es un ataque DDoS por inundación HTTP?

Una inundación HTTP (HTTP flood) es un ataque DDoS en la capa de aplicación (capa 7). Muchas máquinas envían peticiones HTTP GET o POST de apariencia normal a un servidor web o a una API hasta que ya no queda capacidad para los usuarios reales. Cada petición es HTTP válido, así que no hay ningún paquete malformado que descartar. El daño viene del trabajo que cada petición provoca en el servidor, no del ancho de banda que consume.

Es una forma de ataque DDoS en la capa de aplicación y forma parte de la familia más amplia de la denegación de servicio distribuida (DDoS). Esta entrada explica cómo funcionan las inundaciones y cómo defenderse. No es una guía para lanzar una: atacar sistemas que no son tuyos es ilegal.

Cómo funciona una inundación HTTP

• Una botnet envía el tráfico. Las peticiones llegan desde un gran número de dispositivos comprometidos o máquinas alquiladas, por lo que ninguna IP destaca.
• Las peticiones parecen normales. Las cabeceras, los métodos y las URL son válidos, y el user-agent suele copiarse de un navegador real.
• El objetivo son los endpoints costosos. La búsqueda, los listados con filtros, el inicio de sesión y las recomendaciones cuestan al servidor mucho más que un archivo estático, así que una tasa de peticiones moderada puede agotar los procesos de trabajo o las conexiones a la base de datos.
• Se evita la caché. Añadir un parámetro aleatorio a cada URL (por ejemplo ?q=zapatos&_=83721) hace que cada petición parezca nueva, atraviesa la CDN y llega a tu servidor de origen.

Una inundación GET golpea endpoints de lectura. Una inundación POST golpea endpoints de escritura, como registros o formularios de contacto, y suele castigar más a la base de datos. Los ataques lentos como Slowloris y RUDY están relacionados, pero funcionan de otra forma: mantienen conexiones abiertas con muy poco tráfico en lugar de generar muchas peticiones por segundo.

Ejemplo: una inundación sobre una página de búsqueda

Imagina una tienda cuyo endpoint /search ejecuta una consulta a la base de datos sin caché. Un día normal atiende unas pocas peticiones por segundo. Durante una inundación, miles de clientes piden /search con un término aleatorio distinto cada vez. Todas las peticiones fallan la caché, el pool de conexiones de la base de datos se llena y las llamadas del pago empiezan a agotar el tiempo de espera. Los navegadores y las apps reintentan, lo que añade más carga. Nada aquí fue "hackeado": el sitio simplemente se quedó sin capacidad, por eso la primera señal suele ser respuestas lentas y una tasa de errores creciente.

Por qué cuesta tanto frenar una inundación HTTP

• Se parece a un pico de tráfico. Una ráfaga de peticiones desde muchas IP puede ser una campaña o una inundación. Bloquear demasiado hace perder clientes, bloquear poco deja el sitio caído.
• El coste es desigual. Una petición pequeña puede desencadenar una consulta a la base de datos y varias llamadas posteriores.
• El autoescalado puede subir la factura. Si escalas por número de peticiones, puede que pagues por atender el tráfico del ataque. Fija un máximo.

Cómo defenderse de una inundación HTTP

• Poner un borde delante del origen. Una CDN sirve el contenido cacheable y absorbe las ráfagas antes de que lleguen a tus servidores.
• Usar límites de tasa en el WAF. Un firewall de aplicaciones web cuenta las peticiones por origen y limita las que llegan demasiado rápido. Por ejemplo, las reglas basadas en tasa de AWS WAF agrupan las peticiones según los criterios que elijas y aplican una acción cuando se supera un límite.
• Desafiar a los clientes sospechosos. Un desafío de JavaScript o un CAPTCHA filtra los bots que no ejecutan un navegador.
• Cachear y normalizar las URL. Ignora los parámetros que no cambian la respuesta para que el cache busting deje de funcionar.
• Limitar por sesión y por cuenta, no solo por IP, porque una botnet rota las direcciones.
• Proteger los endpoints costosos. Los timeouts, un circuit breaker o una respuesta en caché de reserva evitan que una dependencia lenta tumbe todo el sitio.

El plan paso a paso está en cómo detener los ataques DDoS.

Errores comunes

• Limitar la tasa solo por dirección IP.
• Fijar un límite por debajo del pico real, de modo que un lanzamiento de producto lo active.
• Cachear los archivos estáticos pero no las páginas costosas que hay detrás.
• No tener una línea base, así que nadie sabe cómo se ve "el doble de la tasa normal de peticiones".
• Esperar a que los clientes avisen de la caída.

Inundaciones HTTP, pruebas de carga y monitorización

Una prueba de carga no es una simulación de ataque y no sustituye a un WAF ni a una protección DDoS. Lo que sí puede hacer es mostrar dónde se queda sin capacidad tu propia aplicación con tráfico alto pero legítimo: qué endpoint se ralentiza primero y si los límites y la caché se comportan como esperabas. Prueba solo sistemas que sean tuyos o para los que tengas permiso por escrito, y mejor en staging. LoadFocus ejecuta pruebas de carga con JMeter y k6 desde regiones en la nube, y el plan gratuito permite hasta 10 usuarios virtuales. La diferencia entre ambos tipos de prueba está en pruebas de carga frente a pruebas de estrés.

La monitorización detecta una inundación pronto. Configura alertas sobre la tasa de peticiones, la tasa de errores y la latencia p95 frente a una línea base, y vigila tus endpoints públicos con la monitorización de API. Si un límite bloquea a clientes reales, esta guía sobre límites de tasa en APIs te ayuda a interpretar las respuestas 429. Los proveedores de nube tienen sus propias reglas para simular DDoS: AWS solo las permite a través de socios aprobados o con aprobación previa.

Preguntas frecuentes: ataques DDoS por inundación HTTP

¿Qué diferencia hay entre una inundación HTTP y un ataque volumétrico?

Un ataque volumétrico intenta llenar el ancho de banda de tu red con tráfico bruto. Una inundación HTTP envía peticiones válidas y agota recursos del servidor, como procesos de trabajo, conexiones a la base de datos y cuotas de APIs posteriores, a menudo con mucho menos ancho de banda.

¿Cómo distingo una inundación HTTP de un pico de tráfico viral?

Fíjate en la forma del tráfico. Los picos orgánicos suelen concentrarse en pocas páginas, con referrers, navegadores y regiones variados, y visitantes que navegan y compran. Las inundaciones tienden a ser uniformes: user-agents parecidos, URL raras con parámetros aleatorios, sin referrers y sin conversiones.

¿Una CDN detiene una inundación HTTP?

Ayuda con el contenido cacheable, pero los parámetros de cache busting y los endpoints dinámicos siguen llegando a tu origen. Combina la CDN con límites de tasa en el WAF, desafíos y límites en la propia aplicación.

¿Debo limitar la tasa por IP o por sesión?

Por ambas. Los límites por IP detienen orígenes individuales, y los límites por sesión o cuenta detienen a una botnet que reparte las peticiones entre muchas direcciones.

¿Puedo probar mi sitio frente a una inundación HTTP?

Puedes hacer una prueba de carga de tu propia aplicación para encontrar sus límites de capacidad, con autorización y a ser posible en staging. Una simulación real de DDoS es un servicio aparte que los proveedores restringen, así que consulta con tu proveedor antes de ejecutar nada que imite un ataque.