Cuando la mayoría de la gente piensa en un ataque de denegación de servicio, imagina miles de máquinas enviando tráfico masivo hasta colapsar un servidor. Mucho ruido, mucho ancho de banda, muchos recursos.
Slowloris no funciona así.
Slowloris es silencioso. Es paciente. Y con una sola máquina, puede dejar fuera de servicio a un servidor Apache sin apenas generar tráfico. Lo descubrí durante una auditoría de seguridad y desde entonces se ha convertido en uno de mis ejemplos favoritos para explicar por qué la ciberseguridad no es solo cuestión de volumen, sino de lógica.
Este ataque lo descubrí en un cliente con un servidor dedicado y que en horas puntuales. Al documentarme este fin de semana sobre este ataque, decidí escribir esta entrada. No pongo los datos del cliente por el ACUERDO DE CONFIDENCIALIDAD (NDA) que hemos firmado ambas partes así como mi equipo.
¿Qué es Slowloris?
Slowloris es un ataque de tipo DoS de capa 7 (capa de aplicación) creado en 2009 por el investigador Robert «RSnake» Hansen. Su nombre viene del slow loris, un primate de movimientos extremadamente lentos – y esa es exactamente su filosofía: moverse despacio para no ser detectado y mantener al servidor ocupado indefinidamente.
A diferencia de los ataques DDoS volumétricos (que saturan la red con tráfico), Slowloris explota una característica del protocolo HTTP: los servidores mantienen conexiones abiertas mientras esperan que el cliente complete su petición.
Cómo funciona: la lógica del ataque
Para entender Slowloris, necesitas saber cómo funciona una petición HTTP básica.
Cuando tu navegador pide una página web, envía algo así:
GET / HTTP/1.1
Host: victima.com
Connection: keep-alive
(línea en blanco = fin de la petición)Esa línea en blanco al final (\r\n\r\n) es la señal que le indica al servidor que la petición ha terminado. Sin ella, el servidor sigue esperando.
Y ahí está el truco.
Lo que hace Slowloris:
- Abre cientos de conexiones simultáneas al servidor objetivo.
- En cada conexión, envía una petición HTTP incompleta — sin la línea final.
- Cada pocos segundos, envía una cabecera adicional para que el servidor no cierre la conexión por timeout:
GET / HTTP/1.1
Host: victima.com
X-custom-header-1: valor
X-custom-header-2: valor ← se envía cada 5 segundos
X-custom-header-3: valor ← y así indefinidamente
… - El servidor espera pacientemente que llegue el fin de la petición… que nunca llega.
- Mientras tanto, su pool de conexiones disponibles se va llenando.
- Cuando no queda ninguna conexión libre, los usuarios legítimos reciben un error 503 Service Unavailable.
El servidor no ha sido bombardeado. Ha sido engañado.
¿Por qué afecta especialmente a Apache?
No todos los servidores son igual de vulnerables. La clave está en cómo gestionan las conexiones.
Apache (en su configuración por defecto) usa un modelo basado en hilos o procesos: cada conexión activa consume un worker. Tiene un número máximo de workers configurado (MaxRequestWorkers). Cuando Slowloris los ocupa todos, Apache no puede atender a nadie más.
Nginx, en cambio, usa un modelo event-driven (basado en eventos). Puede manejar miles de conexiones concurrentes con muy pocos recursos, lo que lo hace prácticamente inmune a Slowloris tal como está.
| Servidor | Vulnerabilidad | Motivo |
|---|---|---|
| Apache (config. por defecto) | Alta | Un worker por conexión |
| IIS 6.0 | Alta | Modelo similar |
| Nginx | Baja | Event-driven, sin limite práctico |
| Lighttpd | Baja | Event-driven |
| Apache + mod_reqtimeout | Mitigado | Corta conexiones lentas |
Lo que vi en el pentesting
Durante la auditoría, el servidor objetivo corría Apache 2.4 sin módulos de protección adicionales. Usé slowhttptest, una herramienta que permite lanzar este tipo de ataques de forma controlada y medir el impacto:
slowhttptest -c 500 -H -g -o reporte -i 10 -r 200 -t GET -u http://victima.com -x 24 -p 3
Los parámetros clave:- -c 500 – 500 conexiones simultáneas
- -H – modo Slowloris (cabeceras lentas)
- – i 10 – intervalo de 10 segundos entre cabeceras
- -r 200 – 200 conexiones nuevas por segundo
- -p 3 – tiempo de espera para confirmar que el servidor ha caído
En menos de 90 segundos, el servidor dejó de responder a peticiones legítimas. El ataque generó apenas unos kilobytes de tráfico por segundo — completamente invisible para sistemas de detección basados en volumen.
Cómo defenderse
1. Usa Nginx como reverse proxy
La defensa más efectiva. Nginx absorbe las conexiones lentas antes de que lleguen a Apache. Los usuarios legítimos siguen llegando, Slowloris no puede hacer nada.
2. Activa mod_reqtimeout en Apache
Este módulo de Apache establece un timeout para que las peticiones que no se completan en un tiempo determinado sean cortadas:
# En httpd.conf o apache2.conf
LoadModule reqtimeout_module modules/mod_reqtimeout.so
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
Esto le dice a Apache: "Si no recibes cabeceras completas en 20-40 segundos, cierra la conexión."3. Limita conexiones por IP con mod_qos
QS_SrvMaxConnPerIP 50Máximo 50 conexiones simultáneas por IP. Un atacante desde una sola máquina queda limitado.
4. Configura correctamente el firewall / WAF
Reglas de rate limiting por IP en el nivel de red, antes de que llegue al servidor web.
5. Usa servicios de protección perimetral
Cloudflare, AWS Shield, o cualquier CDN con protección DDoS detectan el patrón de conexiones lentas y lo bloquean automáticamente.
Conclusión: la importancia de los ataques de capa 7
Slowloris es un ejemplo perfecto de por qué la seguridad no puede limitarse a proteger el perímetro de red. Un ataque que genera prácticamente cero tráfico puede dejar fuera de servicio un servidor en minutos.
Si tienes un servidor Apache expuesto, revisa hoy mismo:
- ¿Está
mod_reqtimeoutactivado? - ¿Tienes un reverse proxy por delante?
- ¿Tu WAF está configurado para detectar conexiones de larga duración con pocas transferencias?
En pentesting, Slowloris es una prueba estándar precisamente porque revela si el servidor tiene las protecciones mínimas necesarias. Si cae, hay trabajo que hacer.
Este artículo es únicamente con fines educativos. Nunca realices pruebas en sistemas sin autorización expresa por escrito.
