lunes, 22 de junio de 2009

Slowloris: Apache DoS

El pasado miércoles día 17 de Junio vio la luz una nueva herramienta de DoS llamada Slowloris, escrita por RSnake, inspirado por el conocido (aunque aún oculto, por lo que yo sé) Sockstress, que consiste en una herramienta que aprovecha debilidades del protocolo TCP para realizar denegación de servicio contra todo tipo de servicios de red que utilicen dicho protocolo.

Sin embargo, aunque inspirado por Sockstress, Slowloris opera a nivel de aplicación, en lugar de en capa de red, por lo que no es aplicable a todo tipo de servicios, sino que aprovecha una debilidad en los protocolos a nivel de aplicación de los servicios web para provocar una denegación de servicio basada en agotar todos los recursos disponibles sin necesidad de grandes recursos como una BotNet o una conexión de gran ancho de banda.

Para descargar y probar la aplicación únicamente es necesario pinchar sobre este enlace y antes de ejecutarlo tener la precaución de instalar dos librerías que requiere para su ejecución:

# perl -MCPAN -e 'install IO::Socket::INET'
# perl -MCPAN -e 'install IO::Socket::SSL'


Yo lo he probado sobre la BackTrack 4 Beta en VMWare, para lo cual he arrancado el servicos Apache2 que viene con esta misma distribución y lo he lanzado utilizando el siguiente comando:

# perl slowloris.pl -dns 127.0.0.1


Obteniendo el siguiente resultado:



Como se puede observar (pinchar sobre la imagen para verla más grande), la aplicación lanza cerca de 1000 paquetes y luego espera durante 100 segundos para volver a lanzar, lo cual evidentemente no requiere disponer de un gran ancho de banda ni de realizar ningún ataque distribuido. Una vez lanzado el ataque, al intentar conectar por medio de un navegador al servicio web, nos encontramos con que se queda Waiting y nunca llega a conectar, por lo que el ataque DoS ha surtido total efecto, ha consumido todas las conexiones del servidor web y este no puede procesar más conexiones.

Una vez probada su efectividad y a pesar de que en el artículo original del autor comenta como funciona, reinicié mi servidor web, lance mi Wireshark y me dispuse a ver que hacía exactamente este script perl para realizar la denegación de servicio, obteniendo el siguiente resultado:



Como podeis ver, lanza conexiones HTTP aparentemente normales pero las deja a mitad, diciendo que la longitud es de 42 Bytes pero dejando el mensaje sin terminar de ser enviado y sin cerrar la conexión, por lo que el servidor web mantiene las conexiones establecidas hasta un determinado timeout, por lo que estas se acaban agotando.

La detección de este tipo de ataques mediante IDS no es tan trivial como buscar una cadena de texto, ya que este ejemplo de ataque puede ser variado con sencillez conservando sus resultados, por lo que este tipo de firmas no valdrían.

En Emerging Threads han publicado ya una regla para Snort para que detecte este tipo de ataques, observemosla:
#by Kevin Ross
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"ET DOS Possible Slowloris Tool HTTP/Proxy Denial
Of Service Attempt"; flow:to_server,established;
content:"GET /"; depth:5; content:"User-Agent\:
Mozilla/4.0 (compatible\; MSIE 7.0\; Windows NT 5.1\;
Trident/4.0"; offset:30; depth:90; threshold: type
threshold, track by_src, count 100, seconds 30;
classtype:attempted-dos;
reference:url,isc.sans.org/diary.html?storyid=6601;
reference:url,www.packetstormsecurity.com/filedesc/slowloris.pl.txt.html;
sid:2009413; rev:1;)
Como podemos observar, la regla detecta el contenido del UserAgent y unn "GET /", lo cual por lo que he podido observar no se corresponde con el ataque, y aunque lo hiciera está concretando mucho en la aparición de información que no está basada en la vulnerabilidad, sino en el exploit, algo altamente desaconsejado por Snort por motivos obvios (cojo el script, una pizca de sal, otra de pimienta, y ya tengo un nuevo script que hace el mismo ataque y que no es detectado).

Yo tiraría más al hecho de detectar muchas conexiones simultaneas desde la misma IP y bloquearla, aprovechando de que al requerir establecer una conexión la IP de origen es más difícilmente falseable, aunque todavía no me he podido poner a desarrollar una regla. Si lo hago ya la publicaré.

Por último, aparte de la detección, la protección contra este tipo de ataques es complicada, ya que no basta con aumentar el número de conexiones. Parece que la única opción de las opciones que Apache nos proporciona es configurar la directriva TimeOut para que las conexiones caduquen antes y el ataque sea menos efectivo. Otra opción sería utilizar algún otro módulo como mod_limitipconn, pero ya es poner algo externo al código original de Apache y... no sé, piropeadme, llamadme paranóico :)

Bromas aparte, parece una buena opción también para limitar el número de conexiones simultaneas para una IP, dejando que una sola IP sólo consuma una parte de nuestras conexiones totales, para de esta manera evitar que una sola IP nos pueda provocar una denegación de servicio.

11 comentarios :

eduardo abril dijo...

Hola,

Respecto de esto que comentáis:

"Yo tiraría más al hecho de detectar muchas conexiones simultaneas desde la misma IP y bloquearla, aprovechando de que al requerir establecer una conexión la IP de origen es más difícilmente falseable, aunque todavía no me he podido poner a desarrollar una regla. Si lo hago ya la publicaré."

Sí, estoy totalmente de acuerdo. Nosotros hemos puesto en uno de nuestros clientes una regla para snort que hace eso: cuenta conexiones desde una misma IP.

El problema que nos hemos encontrado es que no es tan fácil ajustarlo porque, al fin y al cabo, una web con imágenes son ya bastantes conexiones per-se, y es difícil poner un límite que de una buena relación de falsos positivos si la web es compleja y tiene muchas cosas.

El problema es que, en nuestro caso, al ser clientes de banca electrónica, corres un riesgo muy alto si los banneas por un falso positivo. No es fácil ajustarlo, y al subir mucho el número de conexiones lo que pasa es que no detectas nada.

Saludos,
Eduardo.

Jose Selvi dijo...

Hola Eduardo, gracias por tu comentario :)

Efectivamente, había pensado en esa posibilidad, ¿cómo podemos diferenciar si la conexión es legítima o es una de estas que intentan una denegación de servicio? Pues a mi se me ocurre por observación que las conexiones legítimas tienen un GET o un POST, y el resto no, deja las conexiones abiertas.

Quizá el motor de Snort no nos ofrezca la posibilidad de realizar algo como esto directamente, no estoy seguro, pero al menos creo que sería posible utilizar la integración entre un sistema IDS como Snort y un HIDS como OSSEC o similar que monitorice el log del servidor web. Este ataque se podría correlar como muchas conexiones iniciadas en Snort que no se traducen en el mismo número de conexiones GET o POST en el servidor web.

Qué te parece?
Es sólo una idea, seguro que se le puede sacar punta.

Saludos!

OzX dijo...

Hi ¡
Uno de los problemas mas grandes que e tenido en el foro son los d.o.s, aunque creamos una regla que obtiene los datos de las dos fuentes.

- Conexiones Via netstat.
- Conexiones basadas en sesiones.

En las conexiones basadas en sessiones, calculamos la cantidad de veces que una IP ingresaba al Sitio en relacion al Tiempo. Por lo Tanto Teniamos una Relacion Ip-Tiempo. En general una Ip se conecta un Max de 70 Veces al Servidores (como extremo), luego de eso ya es un ataque. Ni con Los aceleradores para FF obtenía tantas conexiones.

Seria una Buena medida Desarrollar mas a fondo un analizador de Ip-Tiempo basadas en Sessiones. Incluso ¡, si el Bot o Ataque no Soporta Sessiones Este es Redirecionado Automaticamente.

Saludos¡
Oz¡

Jose Selvi dijo...

El problema de que venga de una sola IP yo creo que es algo que no es muy común en ataques DoS, salvo que se publiquen vulnerabilidades como las descritas en el post.

Lo más común en DoS son los SYN Flood desde alguna BOTNet, que además como todas las IPs de origen son spoofeadas, se hace muy complicado filtrarlo o trazarlo, de hecho imposible sin la colaboración de los ISP's.

Yago Jesus dijo...

Al hilo del affaire Slowloris http://isc.sans.org/diary.html?storyid=6622&rss

Saludos :)

Nikitux dijo...

Soy un novato en esto de la seguridad pero en www.howtoforge.net salió un articulo de como defenderse de Slowloris
mediante el mod_qos de Apache. Dejo el link ya que me pareció interesante. Seguramente ustedes podran analizar si es realmente efectivo este modulo.

http://www.howtoforge.net/how-to-defend-slowloris-ddos-with-mod_qos-apache2-on-debian-lenny

Saludos desde argentina Nikitux..

Jose Selvi dijo...

Tiene buena pinta, lo que hace con eso es establecer unas restricciones de conexiones por IP y además establece una especie de ventana temporal para esperar la petición GET (algo que no hace Slowloris).

Yo creo que es una buena manera de pararlo, aunque todo sería cuestión de montar una maquetita y probarlo, el programa lo tienes disponible para probarlo.

Gracias por el comentario!

Nikitux dijo...

Hola , pude implementar el mod_qos siguiendo la guia que le pasé anteriormente y lo probé en 2 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 nuevamente 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

Jose Selvi dijo...

Hola Nikitux, muchas gracias por compartir con nosotros los resultados de tus pruebas con mod_qos! :D

Jameson dijo...

Encontre los binarios compilados para windows, asi no es necesario disponer de perl para comprobar si su hosting o housing web es vulnerable.

http://slowloris.clanteam.com/

Anónimo dijo...

La versión en python de slowloris algunas cosillas extras

http://motomastyle.com/pyloris/