Flooding. Román Castro Coedo roman.ccoedo

Transcripción

1 Flooding Román Castro Coedo roman.ccoedo

2 Í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

3 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

4 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. ( También podría ayudar a mitigar el problema configurar un sistema de caché HTTP. 4

5 Ilustración 1: La máquina atacante tiene 100 threads enviando peticiones TCP al puerto 80. 5

6 Ilustración 2: LOIC generó una gran cantidad de paquetes. 6

7 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: 7

8 Ilustración 3: En cada url introducida podemos configurar un booster diferente. 8

9 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

10 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

11 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. ( 11

12 Ilustración 7: Hulk en acción 12

13 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

14 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 , por lo que basta con actualizarlo para estar protegidos ante killapache. 14

15 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

16 Ilustración 10: En la imagen se puede apreciar el header range y su valor. En mis pruebas estoy corriendo la versión por lo que la vulnerabilidad ya estaba corregida. 16

17 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

18 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

19 Ilustración 12: Ataque en marcha con un timeout de

20 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

21 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

22 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

23 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 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

24 Ilustración 16: Tor's Hammer en acción 24

25 Ilustración 17: En la imagen se puede apreciar que Tor's Hammer está realizando POSTs de 1 byte de forma continuada. 25

26 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

27 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

28 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

29 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