cd ~/blog

~/vulns/dos-ddos-low-and-slow-attack.md

Low and Slow DoS

webautor: Jordy Pérez Osorio aviso legal
DoSLow-and-SlowHTTP

~2 min de lectura


1. Descripción técnica

Low and Slow DoS mantiene recursos del servidor ocupados mediante conexiones o solicitudes que progresan lo bastante despacio para no terminar, pero con actividad suficiente para evitar ciertos timeouts. Su rasgo distintivo es el bajo throughput por conexión, no una herramienta concreta.

La técnica puede enviarse desde una sola fuente o distribuirse. Slowloris retiene solicitudes enviando cabeceras incompletas; R.U.D.Y. mantiene un cuerpo POST pendiente; Slow Read anuncia una ventana de recepción pequeña para ralentizar la respuesta del servidor.

1.1. Mecanismo

// renderizando diagrama…

2. Impacto

El ataque puede agotar sockets, workers, memoria asociada a peticiones o capacidad de lectura de cuerpos. El ancho de banda total puede permanecer bajo mientras aumentan la latencia y el número de conexiones activas.

Los servidores event-driven y HTTP/2 cambian el recurso crítico, pero no eliminan automáticamente el riesgo. El impacto depende del servidor, el proxy, los timeouts, la multiplexación y la forma en que la aplicación consume la petición.

3. Condiciones necesarias

  1. El servicio mantiene estado mientras espera más cabeceras, cuerpo o lectura del cliente.
  2. Los timeouts o tasas mínimas permiten conservar ese estado durante demasiado tiempo.
  3. El atacante puede abrir suficientes conexiones o streams para aproximarse al límite disponible.
  4. Un proxy anterior no completa, rechaza o amortigua las solicitudes lentas.

4. Validación y detección

Se deben observar simultáneamente duración, progreso y consumo de recursos. Indicadores útiles:

  • muchas conexiones de larga duración con pocos bytes transferidos;
  • cabeceras o cuerpos que permanecen incompletos;
  • Content-Length elevado con una tasa de recepción mínima;
  • crecimiento de workers, sockets o memoria sin un aumento proporcional del ancho de banda;
  • códigos 408, 499 o timeouts del proxy, interpretados según la arquitectura real.

Una conexión lenta individual puede corresponder a un cliente legítimo. La evidencia surge del patrón agregado y de su efecto sobre la capacidad del servicio.

5. Mitigación

  • Configurar timeouts separados para cabeceras, cuerpo y respuesta.
  • Exigir una tasa mínima razonable de transferencia después de un periodo inicial.
  • Limitar conexiones concurrentes y streams por identidad u origen.
  • Colocar un reverse proxy capaz de absorber y normalizar clientes lentos.
  • Procesar cuerpos por streaming y establecer límites de tamaño y memoria.
  • Ajustar los umbrales con telemetría para no excluir clientes legítimos lentos.

6. Clasificación

7. Referencias y conexiones

// relacionados