En líneas generales, para generar un DoS (o DDoS) en un sitio con suficientes recursos, es necesario hacer uso de una botnet, un montón de ordenadores zombies a nuestro servicio, que efectúan peticiones de forma simultánea contra un objetivo común, configurable en tiempo y en lugar por el atacante. Al final, la denegación de servicio del objetivo se puede hacer efectiva por varias causas:
- Porque el servidor o los servidores, son incapaces de contestar a tantas peticiones de forma simultánea
- Alguno de los mecanismos intermedios (routers, switches, firewalls, balanceadores...) que atraviesan dichas peticiones se satura de peticiones y se ve incapaz de gestionar la marabunta
- El ancho de banda disponible de dicha organización se ve desbordado y el tráfico lícito se pierde en un gran porcentaje o se degrada el servicio.
Hace ya una semana que se ha dado a conocer una nueva herramienta que ha puesto los pelos de punta a la comunidad: Slowloris. El autor de la criatura, Robert Hansen, publicó en http://ha.ckers.org/ el código fuente y el funcionamiento básico.
Este "sencillo" script hecho en Perl implementa una potente e inteligente manera de generar una denegación de servicio sobre un servidor web Apache. Para ello, se basa en la cantidad de peticiones que es capaz de mantener un servidor web de forma concurrente. La forma de saturar el pool de servicios es mediante la creación de "requests" HTTP (con HTTPS también funciona) de manera que se empiezan a enviar cabeceras y más cabeceras al servidor de manera que así se fuerza a mantener abierta las conexiones por parte del servidor. Los servidores web tienen determinado un número máximo global de sockets permitidos (configurados en los ficheros correspondientes).
Se trata de un DoS localizado al servicio web en concreto, manteniendo el resto de los servicios de la máquina accesibles.
Madre mía, qué buena pregunta. La verdad es que tiene una respuesta complicada.
He encontrado en Internet multitud de módulos Apache que se pueden incluir en el servidor web para efectuar diferente tipo de restricciones. Describo un poco los que más me han llamado la atención:
- mod_evasive: Este módulo sirve para gestionar el número de peticiones por IP hacia una misma página en concreto o hacia el servidor en general. Se configuran los umbrales que permitimos así como diferentes sistemas de notificación (bloqueo dinámico con IPTables, correo de notificación de detección de intento de DoS, Syslog, etc,...)
- mod_limitipconn: Mediante este simple módulo, podemos restringir el número de peticiones origen desde una única IP hacia un servidor. Permite configurar diferentes políticas según el Location, el tipo de fichero a descargar, etc,... para "abrir la mano" y no provocar una autodenegación de servicio.
- mod_ip_count: Aún más simple que los anteriores, comprueba si el número de peticiones HTTP desde una única IP excede un tamaño máximo definido durante un periodo de tiempo.
Otra posible solución para paliar un ataque hecho mediante Slowloris es modificar, en el propio servidor web, el valor del parámetro TimeOut así como KeepAliveTimeOut. Para el primero por defecto son 300 segundos (o sea 5 minutos), lo cual puede hacer que efectivamente nuestro Apache sea carne de DoS en un corto espacio de tiempo. Si lo modificamos a un valor inferior (sin pasarse, puesto que una vez más, peticiones legítimas dejarían de funcionar), obligaríamos a que el atacante con slowloris hiciera uso de más y más máquinas para consumirnos muchas conexiones en muy poco tiempo. El segundo valor es el tiempo que espera para más peticiones bajo una misma conexión persistente. Por defecto viene a 15 segundos; un valor inferior liberará antes los recursos de esas conexiones persistentes.
Dentro de la propia máquina que alberga Apache (si es un *NIX) se pueden utilizar las herramientas propias del kernel de la máquina o del cortafuegos integrado para establecer políticas de conexión por cada IP.
Asimismo, utilizar las opciones de configuración provistas por los dispositivos intermedios (como firewalls o IPSs) podrían ser de utilidad también, para mitigar el flujo de tráfico que permitimos hacia el servidor web.
13 comments :
Interesante la herramienta...
habrá que probar.
según comenta el propio autor (y es que menudo chorreo que ha generado el "slowloris") mejorar la configuración básica del apache solo complica "ligeramente" el ataque, es decir, que no te libras. Realmente ha generado un buen problema nuestro amigo RSnake...
Por lo visto aparte de apache otros servidores web de importancia como son IIS o lighttpd o se ven afectados. La verdad es que hace tiempo que yo personalmente quiero migrar a lighttpd porque apache se está convirtiendo en un mastodonte con demasiados errores.
Hola Lorenzo,
Hasta ahora, ninguna de las soluciones que he visto publicadas me parece viable ...
Y es que en caso de dar servicio a "internet", así en general, y de tener una web complicada, donde los usuarios pueden consultar sus históricos, todas esas limitaciones causarían un auto-DoS.
Por ejemplo, supongamos que un usuario consulta todos sus movimientos de cuenta de este año ... ¿qué timeout tiene en fin de mes, con un montón de tráfico? ¿Y si lo consulta media market y no un usuario "normal"?
En fin, que no queda otra mas que comerse el ataque y paliarlo sobre la marcha ...
Ah!, probé la herramienta y FUNCIONA, pero muy bien xD
Saludos,
Eduardo.
@Delfi -> Te recomendamos que pruebes en un entorno controlado y solo con fines académicos
@Miguel -> He intentado expresar lo mismo en el artículo. Hardenizar el apache solo puede ayudar a evitar algunos ataques, pero si te atizan desde una botnet o desde más de un sitio, pueden complicarte la existencia igualmente.
@Dragón de Rozán-> Hasta donde tengo entendido, tanto IIS como LightHTTPD, no son vulnerables a Slowloris. Por favor, si tienes la fuente donde has leido que IIS también es vulnerable, compártela con nosotros.
@Eduardo Abril-> Estoy completamente de acuerdo contigo, aunque en tu blog indicas que si se modifica el timeout a 60 en el httpd.conf, un apache debidamente balanceado, es imposible de generar el DoS. Ví en su momento que, utilizando determinado tipo de balanceadores, el ataque se mitigaba puesto que la petición nunca llegaba al apache final. Se supone que estos balanceadores no efectúan la petición al servidor web de backend hasta que no les ha llegado completa (a modo de proxy inverso) y como nunca termina de llegar, no pasan más allá. Sin embargo, el socket sigue estando abierto para el balanceador, y puede que una sola máquina no se lo lleve por delante, pero si eres el objetivo de una botnet, al final terminas comiéndotelo.
En las pruebas que he hecho, a pelo (sin módulos para apache), un IPS hand-made casero que tengo (basado en los logs de mod_security), bloqueaba la IP a nivel IPTables y ya está. Sin embargo, tiene un pequeño retardo que me lleva a estar DoSed un par de minutos
Gracias a todos por vuestras aportaciones :D
Lorenzo, me falto la ene en "Por lo visto aparte de apache otros servidores web de importancia como son IIS o lighttpd No se ven afectados", así se entiende mejor, XD.
@Dragón de Rozán -> perdona, lo leí con demasiada prisa e interpreté lo contrario ;D
Interesantísima herramienta, pero a mi me parece que estas cosas no deberían hacerse "públicas", y entiendase por públicas como que se entere cualquier niñato gilipollas con mucho tiempo libre...
Tela la herramienta... tela... tela.. xDD
Hasta encontrar una solucion definitiva, seria interesante contar con herramientas de monitoreo como Cacti, Nagios que disparen alarmas cuando se pasa cierto consumo de CPU, Memoria o nro de sessiones abiertas desde una misma IP.
slds
@lorenzo: sí, efectivamente, digo que si se baja el timeout se mitiga mucho. Entre lo que mitigas y lo que balanceas la cosa debería arreglarse.
Lo malo es que luego me tocó que hablar con los de desarrollo web, porque si no haces esto puedes tener sorpresas desagradables, y se negaron a adoptar esa solución porque les estaríamos haciendo un DOS en toda regla a algunos clientes. Y es que es difícil preveer qué va a pasar cuando tienes cientos de clientes online, unos pidiendo datos de un día y otros de un año ...
Traducido: ¿quién se hace responsable? Yo, por mí, lo pondría, pero si falla un día algo me va a tocar que demostrar que NO es culpa mía (lo de la presunción de inocencia no se lleva mucho).
Así, si pasa algo diré "veís como tenía razón?".
Política, que asco ...
Y en eso ha quedado la cosa.
Sinceramente, no sé cómo vamos a afrontar este problema en el futuro. Instalar proxy's o similares no se hace en dos días.
@Julio Jaime: lo normal es tener algún tipo de control de tráfico de red, carga de CPU, disco usado, etc ... Lo tiene todo el mundo ... Lo malo es que te llamen un sábado a las 3 de la mañana por un ataque distribuído (porque los operadores verán que falla todo en el nagios/cacti) y tengas que comerte un mega-marrón de dimensiones impresionantes.
Saludos,
Eduardo.
Interesante artículo de Daniel Robbins sobre como defenderse de un ataque con slowloris.
http://www.funtoo.org/en/security/slowloris/
Hola , para frenar los ataques de Slowloris usé mod_qos siguiendo la guia de howtoforge y lo probé en varios servidores con un muy buen resultado. Así que lo recomiendo. Almenos soportó el ataque de 8 maquinas simultaneas sin ningun problemas,en primera instanacia desde una sola maquina atacando había logrado el DOS.
Dejo los links que usé y algunos más
Guia de implementación
http://www.howtoforge.com/how-to-defend-slowloris-ddos-with-mod_qos-apache2-on-debian-lenny
Pagina del proyecto
http://mod-qos.sourceforge.net/
Slowloris para windows (no la probé)
http://cyberwar4iran.blogspot.com/
Otro modulo que recomiendan
http://dominia.org/djao/limitipconn.html
Saludos y sigan con el blog que es barbaro!
Encontre los binarios de esta herramienta compilados para windows, asi no hace falta disponer de perl.
http://slowloris.clanteam.com/
Publicar un comentario