¿Qué es un ataque DDoS de capa de aplicación?

¿Qué es un ataque DDoS de capa de aplicación?

Un ataque DDoS de capa de aplicación — también llamado ataque Layer-7 (L7) — sobrecarga una aplicación web inundándola con peticiones que parecen tráfico legítimo de usuarios. A diferencia de los ataques volumétricos que saturan el ancho de banda de red (Layer 3/4), los ataques L7 atacan la lógica de la aplicación misma: solicitan endpoints caros, martillean formularios de búsqueda, abusan de páginas de login, o simplemente solicitan la homepage más rápido de lo que el servidor puede renderizar. El ancho de banda consumido es pequeño; la carga de CPU y base de datos es enorme.

Los ataques L7 son peligrosos precisamente porque parecen reales. Una avalancha de peticiones HTTP GET a /search?q=anything puede tirar un sitio sin exceder el ancho de banda que un solo usuario de banda ancha consumiría. Las protecciones DDoS genéricas que filtran por volumen de tráfico dejan pasar estos ataques.

Cómo funcionan los ataques DDoS de capa de aplicación

El atacante controla una botnet — típicamente miles de navegadores comprometidos, dispositivos IoT o instancias cloud alquiladas. Cada bot envía una petición pequeña pero costosa en recursos al objetivo. Patrones de ataque comunes:

• HTTP flood: Volumen masivo de peticiones GET o POST a endpoints caros (búsqueda, homepage dinámica, login). Cada petición puede tomar 100-500 ms de tiempo de servidor; miles por segundo saturan el pool de workers.
• Slowloris: Abrir muchas conexiones TCP al servidor, enviar headers lentamente (un byte cada pocos segundos), nunca terminar la petición. Las conexiones permanecen abiertas consumiendo slots de servidor; los usuarios legítimos no pueden conectarse porque el pool está agotado.
• RUDY (R-U-Dead-Yet): Como Slowloris pero para peticiones POST — enviar headers POST, luego gotear el body en chunks diminutos durante horas.
• Cache-busting: Añadir parámetros de query únicos (?id=12345) para que cada petición falle el caché del CDN y golpee el origen. Efectivo contra sitios que dependen de la absorción del CDN.
• Abuso de endpoint API: Llamar repetidamente endpoints caros (búsqueda, recomendaciones, agregaciones complejas) que ningún usuario normal llamaría miles de veces por segundo.

Por qué los ataques L7 son más difíciles de defender que L3/L4

Los ataques volumétricos (Layer 3/4) se anuncian con volúmenes de tráfico absurdos — tu CDN ve 100 Gbps entrantes y descarta la basura obvia antes de que llegue al origen. Los ataques L7 envían peticiones HTTP pequeñas, individualmente-legítimas-en-apariencia a volumen agregado moderado. El reto defensivo:

• Cada petición parece válida. Filtrar solo por volumen no caza nada — el ancho de banda parece normal.
• Spoofing de user-agent. Los bots modernos envían user-agents de navegador realistas. Bloquear por UA solo caza bots obvios.
• Origen distribuido. Las botnets abarcan miles de IPs residenciales. Bloquear por IP es whack-a-mole.
• La detección comportamental requiere contexto. La protección real necesita entender qué es normal para tu app — tasa de peticiones por sesión, patrones de navegación, distribuciones de tiempo-en-página. Eso es caro de construir bien.

Cómo defenderse contra DDoS de capa de aplicación

Web Application Firewall (WAF) con rate limiting

Una WAF (Cloudflare, AWS WAF, Akamai) se sienta delante del origen y aplica reglas: rate-limit por IP, por sesión, por endpoint. Las WAFs modernas incluyen managed rule sets que reconocen patrones de ataque comunes (Slowloris, RUDY, fingerprints de bots comunes) automáticamente.

CAPTCHAs y páginas de challenge

Cuando la WAF detecta patrones sospechosos (ej. 50 req/seg desde una sola IP), sirve un CAPTCHA o challenge JavaScript. Los bots fallan el challenge; los usuarios reales lo completan. El modo "Under Attack" de Cloudflare hace esto automáticamente.

Rate limit a nivel de aplicación

Incluso con una WAF, la defensa en profundidad importa. El rate-limiting a nivel de aplicación por usuario/sesión/IP atrapa ataques que pasan el perímetro. Express/Nginx/Envoy lo soportan todos.

Cachear agresivamente

Los ataques de cache-busting fallan contra endpoints bien cacheados. Configura Cache-Control en todos los endpoints GET. Varía en headers mínimos (no incluyas cookies en la clave de caché para páginas no personalizadas).

Monitorizar y alertar

La detección precede a la mitigación. Monitoriza tasa de peticiones, tasa de errores, latencia p95. Cuando la WAF se activa, ya deberías saberlo — alertas proactivas en umbrales más bajos atrapan el ataque antes de que cascade.

FAQ: DDoS de capa de aplicación

¿Cómo de grande necesita ser un ataque L7 para tirar un sitio?

Más pequeño de lo que la gente cree. Una botnet de 5.000-10.000 nodos golpeando endpoints caros a tasas moderadas puede sobrepasar el pool de workers de una app SaaS típica de tamaño medio. Ancho de banda: trivial. CPU/BD: catastrófico.

¿Protegerá la capa gratis de Cloudflare contra ataques L7?

Parcialmente. Cloudflare gratis proporciona rate limiting básico y modo "Under Attack", lo que ayuda con ataques no sofisticados. Los ataques L7 persistentes o a gran escala necesitan el tier Pro/Business con reglas WAF gestionadas y rate limits custom.

¿Cuál es la diferencia entre un L7 DDoS y un HTTP flood?

El HTTP flood es un tipo de L7 DDoS — el más común. Otras categorías de ataque L7 (Slowloris, RUDY, cache-busting, abuso de API) todas se sientan en Layer 7 pero usan técnicas distintas.

¿Pueden las pruebas de carga simular un L7 DDoS?

Sí — eso es exactamente lo que hacen las pruebas de stress y soak. LoadFocus ejecuta scripts JMeter o k6 a alta concurrencia desde infraestructura cloud para validar que tu app permanece responsiva bajo carga. La diferencia con un ataque real: las pruebas de carga respetan rate limits y paran a la señal; los atacantes no.

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

Ambos. El rate-limiting por IP atrapa bots obvios desde IPs únicas. El rate-limiting por sesión/usuario atrapa ataques distribuidos que vienen de miles de IPs pero coordinados contra el mismo objetivo. Apílalos.

¿Cómo sé si me están atacando vs experimentando tráfico orgánico?

Compara la forma actual del tráfico con tu baseline normal: distribución de peticiones entre endpoints, tasas de error, distribución geográfica, diversidad de user-agent. Un ataque típicamente muestra uniformidad (mismos endpoints, mismo user-agent, mismas regiones) mientras el tráfico orgánico es desordenado.

Cómo LoadFocus ayuda a prepararse para L7 DDoS

LoadFocus ejecuta pruebas de carga JMeter y k6 scriptables contra tus endpoints a escalas que imitan patrones de ataque L7 — alta concurrencia, targeting de endpoints caros, variaciones de cache-busting. Úsalo para validar que tus rate limits funcionan antes de que un atacante los pruebe. Ejecuta una prueba de patrón de ataque desde loadfocus.com/es-es/free-load-test o combina con monitorización de API en loadfocus.com/es-es/api-monitoring para validación continua.