En la entrada anterior de Denegación de Servicio realizamos una Prueba de Concepto explicando el Ataque DNS Amplificado, en esta ocasión seguimos con los ataques en la capa 7 de la torre OSI (Aplicación), concretamente contra Servidores Web.
Vamos a centrar la atención en el ataque Slow Headers que popularizó la herramienta Slowloris en el año 2009. A pesar de los años y como veremos a continuación, este ataque sigue siendo efectivo contra cualquier servidor que haga uso de hilos para atender a las peticiones, como por ejemplo los servidores Apache. Vamos al lío.
¿Cómo funciona?
El diseño del protocolo HTTP/S requiere que una petición sea recibida de forma completa antes de que el servidor pueda procesarla, si una petición esta incompleta o tiene una velocidad de transferencia baja el servidor web reserva recursos esperando que llegue el resto de la petición para que esta pueda ser atendida. Es por este motivo por el que los servidores multihilo asignan un número máximo de conexiones para evitar que un atacante pueda afectar al funcionamiento del servidor.
El objetivo de este Slow Headers es abrir un gran número de conexiones y evitar que el servidor web las cierre para que este no sea capaz de responder al resto de peticiones y crear una denegación de servicio. Es importante recalcar que este ataque únicamente afecta al servicio web no vamos a afectar al resto de servicios y por lo tanto es un ataque más dirigido y difícil de mitigar.
Para esto el atacante envía una petición GET con el header incompleto y un Content-Length grande, el servidor recibe la petición y ocupa una conexión para recibir el resto de la solicitud, para evitar que este la cierre el atacante envía de forma constante más datos en la cabecera de forma que nunca se alcance el timeout que tiene configurado el servidor para cerrar una conexión.
Prueba de Concepto
Para llevar a cabo la Prueba de Concepto utilizamos el siguiente escenario:
- Víctima: Servidor Web LAMP (Apache 2.4.18)
- Atacante: Kali Linux con SlowHTTPTest
Es importante tener en cuenta que estamos utilizando la configuración por defecto de Apache, la cual incluye el módulo mpm_prefork que protege el sistema de ataques de denegación de servicio orientados a consumir los recursos del sistema. Para ello utiliza MaxRequestWorkers que son el número máximo de trabajadores o procesos simultáneos permitidos (hilos) por el servidor, por defecto 150.
Como ya hemos comentado, el ataque se basa en crear los procesos suficientes como para que el servidor web no sea capaz de crear más procesos y atender las peticiones.
Para monitorizar el ataque hacemos uso del módulo mod_status de Apache con la opción ExtendedStatus activada. Comenzamos abriendo una conexión desde el atacante hacia la víctima.
Comprobamos la reacción del Servidor, donde visualizamos la conexión abierta por la máquina atacante (10.0.2.15) y el número de peticiones que están siendo procesadas (la atacante y la propia de server-status en localhost)
Además de esto también echaremos el ojo al consumo de memoria en el Servidor (comando free) durante los ataques, en reposo este es su estado.
Con esto tendríamos el servidor preparado y monitorizado para analizar los ataques.
SlowHTTPTest
Para llevar acabo los ataques utilizaremos la herramienta SlowHTTPTest la cual podéis descargar desde el Github de su creador: https://github.com/shekyan/slowhttptest o bien ejecutando un simple «apt-get install slowhttptest». Esta herramienta incluye cuatro modalidades de Ataque: Slow Headers (Slowloris), Slow Body (R-U-Dead-Yet), Range Attack (Apache Killer) y Slow Read.
Para realizar el Ataque superaremos el límite de conexiones del servidor (por defecto 150), ante la duda mejor que sobren conexiones, podéis crear tantas como permita vuestro ancho de banda.
Con la opción -H seleccionamos el ataque Slow Headers, -g para generar estadísticas del ataque, -c será el número de conexiones que queremos generar (en servidores basados en hilos como Apache, cada conexión generará un proceso), -l para la duración del ataque en segundos, con -s definimos el valor del Content-length que irá en el header de la petición (este tiene que ser grande), -t para el tipo de petición (GET, POST, FAKEVERB), -u para la URI a atacar y -p para el tiempo en segundos que esperará para recibir una respuesta del servidor antes de considerar su caída.
Lanzamos el ataque y vemos como a los pocos segundos el servidor web deja de atender las solicitudes.
La herramienta ya nos avisa de que el servicio no está disponible.
El servicio vuelve a levantarse una vez han pasado los 120 segundos que definimos en el ataque. Podemos analizar lo sucedido en el servidor web después del mismo, ya que durante el ataque no podremos acceder a server-status.
Conexiones abiertas (máximo definido en MaxRequestWorkers), las conexion se generan en modo lectura para que el servidor las mantenga abiertas, las 10 peticiones sobrantes no son atendidas (DoS).
Consumo de memoria. Al enviar más peticiones de las permitidas (150) el consumo de memoría no aumenta por lo que la denegación unicamente se causa sobre el servicio web, recordemos que esto es gracias a la protección MaxRequestWorkers.
Error.log del servidor Apache: «server reached MaxRequestWorkers setting»
En la máquina atacante la herramienta SlowHTTPTest genera un archivo html con el resultado del ataque, donde se aprecia el punto exacto en el cual el servidor dejó de dar servicio.
Contramedidas
Algunas de las contramedidas que ayudan a mitigar estos ataques consisten en limitar el número de conexiones máximas que puede establecer una única IP, establecer restricciones respecto al número mínimo de bytes transferidos o la cantidad de tiempo que un único usuario puede mantener activa la misma conexión.
Desde Apache 2.2.15 se propone el uso del módulo mod_reqtimeout para establecer la configuración adecuada a tu servidor y evitar el daño que estos ataques son capaces de provocar. Además de todo esto es recomendable utilizar proxys y balanceadores de carga para dificultar todo lo posible la acción del atacante.
Para finalizar, os dejo por aquí el resultado del ataque contra mi router doméstico, ¡hasta la próxima!
Metalex