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.