Flooding

Flooding
Román Castro Coedo
roman.ccoedo
Índice de contenido
Introducción..........................................................................................................................................3
Tipos de ataques...................................................................................................................................3
HTTP Flood.....................................................................................................................................3
SYN Flood.......................................................................................................................................3
SSL Flood y Renegociación SSL.....................................................................................................3
UDP Flood.......................................................................................................................................3
Herramientas.........................................................................................................................................4
L.O.I.C.............................................................................................................................................4
H.O.I.C.............................................................................................................................................7
Hulk DDoS....................................................................................................................................10
Killapache......................................................................................................................................14
Qslowloris......................................................................................................................................17
Slowloris........................................................................................................................................17
THC SSL DoS................................................................................................................................21
Tor's hammer..................................................................................................................................23
UDPFlood......................................................................................................................................27
Introducción
Los ataques por inundación (flooding) son ataques que están diseñados para tirar abajo una
red o servicio saturándolos con grandes cantidades de tráfico. El objetivo principal es que la red o
servicio esté tan cargada con peticiones de conexión generadas por el atacante que no pueda
procesar las peticiones de conexión reales. El resultado final es una denegación de servicio (DoS).
A menudo, estos ataques se realizan de forma distribuida (Distributed Denial of Service, o
DDoS). La idea es utilizar múltiples conexiones a internet y distribuidas globalmente (por ejemplo a
través de una botnet). Debido a la dispersión geográfica de las máquinas que componen una botnet
es mucho más difícil encontrar un patrón con el que realizar un filtrado de paquetes.
Tipos de ataques
En este apartado explicaré el funcionamiento de los principales ataques por inundación. En
la práctica existen muchas más variantes de estos ataques.
HTTP Flood
Consiste en realizar múltiples peticiones HTTP (ya sean GET o POST) a un servidor.
Cuanto más compleja de procesar sea la petición para el servidor, más fácil será tirarlo. Si
las peticiones siguen algún tipo de patrón, no resulta complicado definir reglas en el firewall
que bloqueen las peticiones maliciosas.
SYN Flood
SYN Flood consiste en realizar un ataque de denegación de servicio tratando de
mantener conexiones abiertas en el servidor.
En una conexión TCP normal, el usuario envía un paquete TCP SYN al servidor, el
cual le contesta con un SYN-ACK. El usuario cuando recibe este paquete confirma que lo ha
recibido con un ACK.
En un ataque SYN Flood el usuario ignora el SYN-ACK que le envía el servidor, por
lo que este queda a la espera de confirmación.
SSL Flood y Renegociación SSL
Pedir una conexión segura es una tarea sencilla para el cliente, pero muy costosa para
el servidor. Aprovechando esta característica de SSL, se pueden realizar ataques que saturen
servidores realizando peticiones de conexión y renegociando el método de cifrado de forma
continua.
UDP Flood
Los ataques por inundación UDP son de ataques de denegación de servicio sobre
UDP. Como UDP es no orientado a conexión, si inundamos la víctima con paquetes UDP
enviados a puertos aleatorios ésta tendrá que responder a todos ellos con paquetes ICMP
Destination Unreachable.
3
Herramientas
A continuación explicaré el funcionamiento y las opciones de las principales herramientas
de flooding. Algunas de estas herramientas son de uso genérico, también existen herramientas
orientadas a explotar vulnerabilidades de algunas aplicaciones en concreto.
También realizaré un pequeño test para el que usaré dos máquinas virtuales, una actuará
como servidor (con un apache v2.2.22) y la otra de atacante.
L.O.I.C.
¿Qué es?
LOIC es una herramienta para realizar un ataque de denegación de servicio. Está
programada en C#. También existe una versión programada en C++ con una interfaz gráfica
programada en Qt, que será la que utilicemos en nuestras pruebas.
LOIC es una herramienta muy básica, pero puede ser peligrosa si existen múltiples atacantes
haciendo uso de ella.
¿Cómo funciona?
LOIC inunda a nuestra víctima con paquetes HTTP, UDP o TCP. Además, LOIC nos permite
realizar un ataque delegando el control a un canal de IRC, de modo que el ataque sería distribuido.
¿Qué parámetros podemos configurar?
Podemos configurar la ip/url de nuestra víctima, el tipo de paquete que queremos enviar, el
puerto y el número de procesos que queremos que lancen las peticiones. También podemos
configurar el canal IRC al que queremos delegar el control, si es que queremos.
¿Cómo podemos defendernos de él?
Podemos proteger nuestros servidores de un ataque de este tipo mediante reglas de filtrado
en el firewall. Por ejemplo, se podría realizar un script que, periódicamente, compruebe si estamos
bajo ataque, analizando el trafico y las peticiones de una ip. Si éstas se realizan en intervalos de
tiempo iguales, bloqueamos dicha ip. (http://panivinux.wordpress.com/category/loic/). También
podría ayudar a mitigar el problema configurar un sistema de caché HTTP.
4
Ilustración 1: La máquina atacante tiene 100 threads enviando peticiones TCP al puerto
80.
5
Ilustración 2: LOIC generó una gran cantidad de paquetes.
6
H.O.I.C.
¿Qué es?
HOIC es una herramienta de denegación de servicio similar a LOIC. HOIC permite atacar
más de una página web a la vez, de este modo podemos realizar peticiones a diferentes partes de un
mismo sitio web. Si nuestra víctima alojase múltiples sitios web, también podríamos atacarlos todos
a la vez para intentar tirar la máquina.
¿Cómo funciona?
Al igual que LOIC, HOIC inunda a nuestra víctima con peticiones. La principal diferencia
es que HOIC sólo permite realizar floods HTTP. La mayor ventaja de HOIC es la posibilidad de
utilizar booster scripts. Con estos scripts podemos randomizar algunos de los parámetros de las
peticiones, de este modo son mucho más complicadas de filtrar. HOIC trae unos cuantos booster
scripts, pero también podemos crear nuestros propios scripts.
¿Qué parámetros podemos configurar?
Podemos configurar el número de threads que se ejecutarán y añadir objetivos. Cada
objetivo es una url, y podremos seleccionar un booster script para cada uno de ellos.
¿Cómo podemos defendernos de él?
Aunque HOIC permite randomizar las peticiones al servidor, hay algunos patrones mediante
los cuales podemos detectar el ataque y filtrarlo. Una forma de detectar que la petición no es
legitima, por ejemplo, es analizando el orden de las cabeceras o los espacios extra que existen en
determinadas peticiones. (Fuente: http://blog.spiderlabs.com/2012/01/hoic-ddos-analysis-anddetection.html).
7
Ilustración 3: En cada url introducida podemos configurar un booster diferente.
8
Ilustración 4: Con el comando top se puede ver como apache2 es el proceso que más cpu está
utilizando en el momento del ataque.
9
Ilustración 5: Ejemplo de petición de HOIC randomizado con GenericBooster
Ilustración 6: Otro ejemplo de petición randomizada generada por HOIC.
Hulk DDoS
¿Qué es?
Hulk es una herramienta de denegación de servicio escrita con la finalidad de exponer las
debilidades comunes de los servidores con configuraciones por defecto. Hulk es un script python
realmente simple, ya que sólo tiene 155 líneas de código. Debido a su sencillez, es muy fácil abrir el
código y ver cómo funciona.
¿Cómo funciona?
El script en cuestión crea peticiones get a la url que le pasemos como parámetro, tratando de
que sean lo más realistas posible. Para ello, monta unos vectores con distintos valores para el useragent y el referer, asigna un keep-alive aleatorio, y pide una uri diferente cada vez.
10
¿Qué parámetros podemos configurar?
Hulk sólo toma por parámetro la url de la víctima. A diferencia de otras herramientas que
hemos analizado, no podemos configurar el número de threads que se van a ejecutar (aunque sí es
bastante sencillo modificar el código para que ejecute los threads que nosotros queremos). Por
defecto, se ejecutarán 500 threads.
¿Cómo podemos defendernos de él?
Como las peticiones que realiza hulk son tan diferentes, es capaz de saltarse las cachés http.
Además como todo el tráfico generado es aleatorio, es mucho más difícil distinguir el tráfico
generado por esta herramienta del real. Una forma de distinguir a hulk de un cliente web real es el
orden de los headers, de este modo podemos filtrar las peticiones de hulk y finalizar sus conexiones.
(http://blog.spiderlabs.com/2012/05/hulk-vs-thor-application-dos-smackdown.html).
11
Ilustración 7: Hulk en acción
12
Ilustración 8: Los picos de cpu de apache han llegado a más del 25% de uso de cpu. También
podemos ver la petición http que realizó Hulk.
13
Killapache
¿Qué es?
Killapache es una herramienta de denegación de servicio orientada a explotar una
vulnerabilidad de apache. La herramienta en cuestión es un script escrito en perl para demostrar
dicha vulnerabilidad.
¿Cómo funciona?
Para tumbar el servidor apache, killapache hace uso del header HTTP “range”. Dicho header
está diseñado para reducir los requisitos de ancho de banda, y permiten a un navegador cargar sólo
algunas partes de un documento (por ejemplo, para reanudar una descarga). Pedir múltiples rangos
creando una cabecera mal formada causa en apache un comportamiento erróneo, que acaba con el
servidor completamente saturado.
¿Qué parámetros podemos configurar?
Killapache toma dos parámetros. El host y el número de threads que queremos utilizar.
¿Cómo podemos defendernos de él?
La vulnerabilidad de Apache fué corregida en su versión 2.2.20, por lo que basta con
actualizarlo para estar protegidos ante killapache.
14
Ilustración 9: killapache en funcionamiento. Debemos pasarle por parámetro la URL y el número
de threads con los que queremos atacar.
15
Ilustración 10: En la imagen se puede apreciar el header range y su valor. En mis pruebas estoy
corriendo la versión 2.2.22 por lo que la vulnerabilidad ya estaba corregida.
16
Qslowloris
Qslowloris es una interfaz gráfica qt para Slowloris. Como la única diferencia entre
Qslowloris y Slowloris es la interfaz, y me parecen más útiles las herramientas en línea de
comandos (es más sencillo crear scripts que las utilicen), me centraré en Slowloris.
Slowloris
¿Qué es?
Slowloris es una herramienta escrita en perl para realizar denegaciones de servicio de tipo
SYN Flood sobre HTTP.
¿Cómo funciona?
Funciona enviando peticiones HTTP parciales, la idea es mantener muchas conexiones
abiertas a la vez, enviando headers en intervalos regulares para conseguir que los sockets no se
cierren. La principal ventaja de este enfoque es que no necesitamos tanto ancho de banda para tirar
el servidor, ya que en lugar de inundar la red, nos dedicaremos a adueñarnos de todos los sockets
posibles.
A medida que los usuarios legítimos liberen sus conexiones, slowloris continuará
compitiendo por las nuevas conexiones. Por este motivo puede pasar algún tiempo hasta que
consiga tener todos los sockets colapsados.
Otra ventaja de slowloris es que los ficheros de log no van a ser escritos hasta que las
peticiones se hayan completado. Gracias a cómo funciona slowloris podemos tirar un servidor sin
que se escriba ni una sola línea en el log del servidor, consiguiendo así que no salte ninguna alarma.
¿Qué parámetros podemos configurar?
Con la opción -dns podemos especificar la url de la víctima y con -port el puerto. Podemos
utilizar la opción -test con la que encontraremos un timeout adecuado con el que realizar el ataque
(de forma que el servidor no cierre nuestras conexiones). Una vez encontrado el timeout adecuado
podemos hacer uso de las opciones -timeout, -num (número de sockets) y -tcpto. También podemos
evitar cachés http con -caché o https con -https.
¿Cómo podemos defendernos de él?
Existen diversas técnicas para miticar los ataques de slowloris. Una opción sería limitar el
número de peticiones que el servidor acepta de una sola ip. Debido a la naturaleza de slowloris, si el
timeout de nuestro servidor es muy elevado esta solución no es válida por si misma, por lo que
deberíamos considerar reducir el tiempo de conexión de un cliente.
Otra solución podría ser aumentar la tasa de transferencia mínima de una conexión, para que
las peticiones tengan que completarse más rápido.
17
Ilustración 11: La opción -test de slowloris nos permite realizar un test con el que buscar qué margen
de tiempo es el correcto para que no se cierren las conexiones. Una vez encontrado el timeout podemos
configurar el ataque con los parámetros -timeout, -num (número de sockets) y -tcpto (timeout de TCP)
18
Ilustración 12: Ataque en marcha con un timeout de 30.
19
Ilustración 13: It DOESN'T work! Slowloris colapsó el servidor al momento, ya que no había
usuarios con la conexión abierta en el momento del ataque.
20
Ilustración 14: Pese a que el servidor estaba bajo ataque, slowloris no hizo saltar ninguna alarma.
el % de cpu y de memoria era normal para el proceso de apache2.
THC SSL DoS
¿Qué es?
THC SSL DoS es una herramienta para realizar denegaciones de servicio mediante SSL.
¿Cómo funciona?
Establecer una conexión SSL requiere mucho más procesamiento en el servidor que en el
cliente, y esta herramienta trata de colapsar el servidor aprovechándose de ésto.
La ventaja de este ataque es que se puede montar desde una sola conexión, ya que no
necesitamos tanto ancho de banda como en un HTTP Flood. Según la documentación, un portátil en
una línea DSL podría competir con un servidor en un enlace 30Gbit.
Los servidores no están preparados para procesar grandes cantidades de handshakes SSL.
Además, no existen soluciones reales a este problema, aunque desabilitar las renegociaciones SSL
podría ayudar a reducir el impacto. El peor escenario posible sería un ataque desde múltiples nodos,
(un DDoS SSL).
¿Qué parámetros podemos configurar?
Los parámetros que toma thc-ssl-dos son la dirección ip y el puerto de la víctima. También
debemos pasar el parámetro –accept para confirmar que estamos autorizados a realizar el ataque
sobre dicho objetivo.
21
¿Cómo podemos defendernos de él?
Existen dos formas de mitigar el problema. Podemos intentar acelerar el cifrado en el
servidor, de modo que establecer la conexión no requiera tanto esfuerzo. También podemos
deshabilitar las renegociaciones SSL iniciadas por el cliente, aunque esta es una solución parcial ya
que la herramienta se puede modificar para que establezca una nueva conexión TCP para cada
handshake.
Para probar el funcionamiento de esta herramienta, lo primero que he hecho ha sido activar ssl en
apache2 (a2enmod ssl). Después he activado el sitio https por defecto (a2ensite default-ssl).
Ilustración 15: Parece que apache (v2.2.22), por defecto, desactiva las renegociaciones iniciadas
por el cliente, por lo que el ataque no funciona. No obstante la herramienta se puede modificar
para que establezca una nueva conexión TCP para cada handshake.
22
Tor's hammer
¿Qué es?
Tor's Hammer es una herramienta de denegación de servicio mediante HTTP POST.
¿Cómo funciona?
Tor's Hammer realiza una petición POST pasando los campos lentamente (entre 0.5 y 3
segundos) en la misma sesión. La herramienta va enviando byte por byte con un tiempo de espera
entre cada envío, lo que causa que los threads del servidor tengan que estar ocupados con estos
fragmentos.
Con los ataques de denegación de servicio tradicionales necesitamos una gran cantidad de
máquinas inyectando tráfico de forma simultánea, pero con esta técnica, al igual que ocurría con
slowloris, basta una sola máquina para tumbar un servidor vulnerable porque el ataque se realiza
inyectando lentamente byte por byte.
Una funcionalidad de Tor's Hammer es la de poder pasar los ataques DoS a través de la red
TOR, lo que permite lanzar el ataque desde direcciones IP aleatorias, por lo que, teóricamente, no se
pueden rastrear.
¿Qué parámetros podemos configurar?
Tor's hammer puede tomar como parámetros el target, el número de threads que ejecutarán
las peticiones y el puerto al que será dirigido. Además podemos utilizar el parámetro -tor
PROXY:PUERTO para utilizar un proxy tor.
¿Cómo podemos defendernos de él?
Una solución parcial a este problema sería mantener una lista con las diferentes urls que
requieren POST, y solo permitir los post para estas urls. No es una buena solución porque el
atacante podría modificar la herramienta para realizar el post en una de las urls legítimas. Además
no es muy cómodo tener que mantener una lista con las urls que pueden hacer post, ya que si la
aplicación web cambia también tendríamos que cambiar la lista.
En apache una solución sería hacer uso de mod_reqtimeout. mod_reqtimeout está incluído
por defecto desde la versión 2.2.15. Con este módulo, si el cliente no envía el mensaje en el tiempo
configurado, la conexión caduca.
Otro módulo que es útil en este escenario es mod_qos. mod_qos implementa mecanismos de
control de calidad de servicio. mod_qos permite configurar parámetros como el número de
conexiones máximo del servidor, el número de conexiones máximo por IP, la velocidad mínima por
conexión (de modo que si es lenta, caduca), y además permite cambiar el comportamiento de la
configuración en función de la carga del servidor.
Con mod_security también podríamos configurar reglas para que cada vez que apache
devuelva un 408 (request timeout) cuente cuántas veces ha ocurrido para una ip concreta, y si
excede el máximo bloquea esa IP durante un periodo determinado de tiempo.
23
Ilustración 16: Tor's Hammer en acción
24
Ilustración 17: En la imagen se puede apreciar que Tor's Hammer está realizando POSTs de 1 byte
de forma continuada.
25
Ilustración 18: El proceso de apache2 está trabajando más que si estuviese en reposo, pero no se
acerca a la carga que tuvo con LOIC, HOIC o Hulk. Esto es debido a que Tor's Hammer realiza el
ataque lentamente (slow-rate DoS), y es especialmente útil para que el ataque sea menos
detectable. Aunque el ataque no tumbó el servidor, tras unos minutos ya le costaba responder a las
peticiones legítimas.
26
UDPFlood
¿Qué es?
UDPFlood es una herramienta sencilla para realizar ataques de inundación UDP.
¿Cómo funciona?
UDPFlood crea paquetes UDP con datos aleatorios e inunda con ellos a la víctima.
¿Qué parámetros podemos configurar?
Entre los parámetros que podemos configurar se encuentran, al igual que otras herramientas
comentadas anteriormente, la dirección de la víctima (que puede ser una dirección ipv4 o ipv6), el
número de threads que queremos crear y el puerto. Además podemos configurar el tamaño del
buffer.
¿Cómo podemos defendernos de él?
Los ataques por inundación UDP se pueden agrupar en dos categorías, aquellos que se
realizan con paquetes pequeños y que intentan saturar la aplicación (un servidor web por ejemplo) y
aquellos que se realizan con paquetes más grandes y que intentan consumir el ancho de banda de la
conexión. Estos últimos podrían llegar a inutilizar la red donde se encuentre la víctima.
En el primer caso, la solución sería filtrar los paquetes en un firewall, de modo que éstos no
lleguen nunca a la víctima. En el segundo caso la solución es más compleja, y deberíamos contactar
con nuestro proveedor para que sea él quien bloquee el ataque.
27
Ilustración 19: Ataque en marcha con 10 threads. Los paquetes están siendo dirigidios al puerto 9
(puerto en el que se descartan los paquetes entrantes)
28
Ilustración 20: Wireshark está saturado capturando los paquetes entrantes, aunque son
descartados por la máquina ya que están dirigidos al puerto 9.
29