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

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

Un ataque DDoS en la capa de aplicación, también llamado ataque de capa 7 o L7, inunda una aplicación web o una API con peticiones que parecen de usuarios normales. En lugar de saturar la red, agota lo que la aplicación necesita para responder: hilos de trabajo, CPU, conexiones a la base de datos y memoria. Cada petición es pequeña, así que el volumen de tráfico por sí solo apenas delata el ataque.

Es el primo discreto de los ataques volumétricos, que saturan el ancho de banda en las capas 3 y 4. Consulta la visión general de DDoS y la entrada sobre el HTTP flood, la forma L7 más habitual.

Cómo funcionan los ataques a la capa de aplicación

El atacante controla una botnet de dispositivos comprometidos o de máquinas en la nube alquiladas. Cada bot envía peticiones baratas de enviar y caras de responder. Patrones habituales:

• HTTP flood: una tasa alta de peticiones GET o POST a endpoints costosos como la búsqueda, el inicio de sesión o una página de inicio dinámica.
• Slowloris: muchas conexiones que se mantienen abiertas enviando las cabeceras muy despacio, hasta que el servidor se queda sin huecos libres.
• RUDY (R-U-Dead-Yet): la misma idea con el cuerpo de peticiones POST, enviado a cuentagotas.
• Cache busting: una cadena de consulta distinta en cada petición (?x=8841) para que una CDN no pueda responder desde caché y todas lleguen a tu origen.
• Abuso de API: llamadas repetidas a endpoints caros, como informes, exportaciones o agregaciones, que ningún usuario real invocaría tantas veces.

Ejemplo: un endpoint de búsqueda

Supón que /search?q=... ejecuta una consulta sin caché de 200 ms y que tu app tiene 20 workers. Eso son, como mucho, unas 100 búsquedas por segundo (cifras ilustrativas). Una botnet que envía 150 búsquedas por segundo nunca toca tu límite de ancho de banda, pero el pool de workers se llena, la cola crece y los visitantes reales ven timeouts y errores 503. La gráfica de tráfico parece normal; la de latencia, no.

Por qué la capa 7 es más difícil de defender que la 3/4

• Todas las peticiones son válidas. No hay nada malformado que descartar en el borde de la red.
• Los bots parecen navegadores. Con user agents realistas, bloquear por UA sirve de poco.
• Las fuentes están repartidas. Las botnets usan muchas direcciones y bloquear IP una a una es un juego del gato y el ratón.
• Lo normal depende de tu app. Necesitas conocer tu tasa habitual de peticiones por sesión y por endpoint para detectar lo anómalo.

Cómo defenderse

• Limita la tasa en el borde y en la app. Un firewall de aplicaciones web (WAF) puede limitar por IP, sesión y endpoint. Mantén también un límite en la aplicación por si el tráfico esquiva el borde. Responde con 429 Too Many Requests y una cabecera Retry-After. La guía de limitación de tasa en APIs explica causas y soluciones.
• Desafía a los clientes sospechosos. Un CAPTCHA o un desafío de JavaScript filtra bots sencillos antes de que lleguen al código costoso.
• Cachea lo que puedas. Cachea las respuestas GET anónimas y deja las cookies fuera de la clave de caché en páginas no personalizadas.
• Abarata los endpoints costosos. Índices, límites de paginación y timeouts evitan que una petición retenga un worker mucho tiempo.
• Vigila la latencia, no solo el tráfico. Crea alertas sobre latencia p95, tasa de errores y saturación de workers. La lista completa está en cómo detener ataques DDoS.

Errores habituales

• Confiar solo en el bloqueo de IP frente a una botnet distribuida.
• Limitar solo la página de inicio de sesión y dejar abiertas la búsqueda, la exportación y las rutas de API.
• Limitar detrás de un proxy o CDN por la dirección del proxy y no la del cliente real, de modo que todos comparten un único contador.
• No tener una referencia del tráfico normal, así que nadie sabe cómo es lo anómalo.
• Suponer que la CDN lo absorbe todo mientras los endpoints no cacheables llegan directos al origen.

Qué papel tienen las pruebas de carga y la monitorización

Una prueba de carga no es una simulación de DDoS, y LoadFocus no simula ataques DDoS. Lo que hace una prueba de carga es mostrar cómo se comporta tu propia aplicación con un nivel de tráfico que tú eliges, desde regiones cloud conocidas y solo contra sistemas que estás autorizado a probar. Eso sirve para defenderse: sabes cuántas peticiones por segundo aguantan tus endpoints costosos y si tus límites responden con 429 en lugar de timeouts. Lee pruebas de carga frente a pruebas de estrés para planificarlo y ejecútalo con las pruebas de carga de LoadFocus. Combínalo con la monitorización de API para recibir una alerta si un endpoint se vuelve lento o falla (los checks gratuitos se ejecutan cada 5 minutos).

Preguntas frecuentes: DDoS en la capa de aplicación

¿Qué tamaño necesita un ataque L7?

Menos del que mucha gente cree. El límite es el trabajo que hace tu app por petición, no el ancho de banda. Un endpoint con una consulta pesada a la base de datos se puede agotar con una tasa de peticiones moderada.

¿En qué se diferencia un DDoS L7 de un HTTP flood?

El HTTP flood es un tipo de DDoS L7 y el más común. Slowloris, RUDY, el cache busting y el abuso de API son otros tipos en la misma capa.

¿Una CDN detiene los ataques a la capa de aplicación?

Ayuda con las páginas cacheables y a menudo incluye limitación de tasa y reglas contra bots. No ayuda con peticiones no cacheables como inicios de sesión, búsquedas o llamadas a la API, que siguen llegando a tu origen si no se limitan.

¿Limito por IP, por sesión o por ambas?

Por ambas. Los límites por IP frenan bots simples. Los límites por sesión o cuenta frenan ataques distribuidos en los que cada dirección envía pocas peticiones.

¿Cómo distingo un ataque de un pico de tráfico?

Compara con tu referencia habitual: qué endpoints reciben las peticiones, desde qué regiones, con qué user agents y cómo evolucionan los errores. Los ataques suelen ser uniformes (mismas rutas, mismo user agent), mientras que los picos reales son variados y responden a una causa, como una campaña o un lanzamiento.