DDoS Análisis de Ataques Coordinados

Este artículo DDoS Análisis de Ataques Coordinados, fue publicado originalmente en ingles para la revista Pentest Magazine y su autor Ramiro Caire con gusto lo comparto en español para La Comunidad DragonJAR.

En este post se cubrirán algunos conceptos acerca de un tipo de ataque conocido llamado “DDoS (Denegación de Servicio Distribuido, por sus siglas en ingles) con algunas demostraciones en laboratorio como “Prueba de Concepto” con algunas contramedidas. Aquí, nos enfocaremos en dos tipos de ataques: "SYN Flood"y "Slow HTTP DDoS Attack".

Entendiendo DDoS

Es muy probable que ud ya conozca el Ataque de Denegación de Servicio Distribuido (DDoS) el cual es una extensión del ya conocido DoS (Denial of Service) que sucede cuando el servidor objetivo se ve saturado de peticiones TCP o UDP a determinado servicio.

(Por lo general, servicio web al puerto 80, pero esto depende de las intenciones del atacante, cualquier servicio puede ser vulnerable) dejando de responder incluso a peticiones genuinas.

DDoS Análisis de Ataques Coordinados y el concepto de Distribuido

El concepto de “Distribuido” es concerniente a que estas peticiones son realizadas desde cientos, miles de máquinas infectadas (comúnmente llamadas “zombies” ) las cuales son gobernadas a través de “Botnets” (http://en.wikipedia.org/wiki/Botnet) de manera coordinada al mismo tiempo.

Esto supone una sumatoria de ancho de banda, uso de memoria y procesamiento en el objetivo que, por lo general, ningún servidor podría soportar, terminando en un colapso del servicio atacado por no poder responder cada petición.

DDoS Análisis de Ataques Coordinados los tipos

En este articulo haremos foco en dos tipos de ataques, los mismos son “SYN flood” y “Slow HTTP DDoS Attack”.

La clave del éxito para los ataques de DDoS es la cantidad de “zombies” con que cuenta cada Botnet. Podemos afirmar que mayor es el número de máquinas atacantes, mayor es la efectividad del ataque.

A modo de ejemplo, hagamos el siguiente cálculo rápido

Una “botnet” tiene 3000 máquinas zombies listas para atacar. Cada máquina utiliza una conexión hogareña (generalmente xDSL) con un promedio de 128 Kib/s de ancho de banda de subida (upstream):

3000 hosts * 128 KiB/s (upstream) = 384000 KiB/s = 375,00 MiB/s

Es decir, se genera un tráfico resultante de 375,00 MiB/s, el cual es un ancho de banda mas que suficiente para colapsar prácticamente cualquier sistema (aún estando protegido) ya que
los vínculos que los ISP le otorgan a los servidores target son claramente inferiores a este valor.

Pero este no es el único factor que influye en el éxito de un ataque DDoS, también podemos mencionar la variante de ataque que se realizará (descriptos anteriormente), la buena o mala configuración de los servidores target, la duración del ataque, etc...

SYN Flood Attack

Este es uno de los dos tipos de ataques de DDoS que analizaremos en este artículo.

Como lector de este Magazine, usted probablemente sepa que los headers de un paquete TCP/IP contiene banderas (flags), las cuales tienen diferentes funciones, como por ejemplo marcar inicio, prioridad y fin de la conexión, reiniciarla, etc y que el “diálogo” entre las partes se inicia con el “saludo de las tres vías”. En este último punto está la clave de esta técnica.

En que consiste el ataque “SYN Flood”

Pues bien, el ataque de “SYN Flood” consiste en enviarle paquetes manipulados a la maquina target, activando el bit SYN (S flag) en la conexión TCP y alterando la IP origen (mediante técnica de spoofing), la víctima responde con un SYN/ACK (SA flags) considerando que se trata de una conexión legítima y espera por un ACK (A flag) por parte del cliente. Al tratarse de direcciones falsas, la respuesta nunca llegará y la secuencia no llega a completarse ocasionando que la víctima se sature de conexiones no dejando lugar a conexiones genuinas.

En el siguiente gráfico, se aprecia una secuencia normal del “saludo de las tres vías”

En tanto que, modificando los headers, la conexión se realizará del siguiente modo:

Un ataque utilizado por el grupo “Anonymous”

Este es sin dudas uno de los ataques mas conocidos por su simplicidad-efectividad y famoso dado que es la técnica principal utilizada por el ya mundialmente conocido grupo hacktivista “Anonymous” que si bien ellos mismos lo emplean como herramienta de “protesta”, está quedando en evidencia que esto no siempre se aplica para el común de los ciberdelincuentes que, en su mayoría, lo emplean como herramienta de extorsión en perjuicio de empresas o gobiernos y en otras ocasiones para obtener ganancias económicas.

Herramientas

Existe gran cantidad de herramientas para efectuar un SYN Flood Attack, entre ellos las armas principales de “Anonymous”, llamadas LOIC (Low Orbit Ion Cannon) y HOIC (High Orbit Ion Cannon). Estas herramientas pueden ser manejadas por el usuario o bien utilizando el modo “Hivemind”, a través de u canal de IRC en un ataque distribuido y coordinado. Son herramientas muy potentes y deben ser utilizadas responsablemente.

Pero en este artículo utilizaré otra herramienta que no tiene el ataque como propósito de uso, estoy hablando de HPING3, que es una grandiosa herramienta de pruebas a reglas de firewall, stress testing, manipulación de paquetes, entre otras utilidades, muy necesaria para todo sysadmin y profesional de la seguridad informática.

¿Cómo este ataque puede ser demostrado?

A los efectos ilustrativos de complementar este artículo y teniendo en cuenta la complejidad de contar con una botnet real, he montado un escenario en mi laboratorio interno en el cual emplearé tres maquinas (corriendo Backtrack 5 R2) que simularán ser muchas mas para atacar un servidor vulnerable y desprotegido (corriendo Fedora release 15 (Lovelock)).

La idea es inundar de paquetes manipulados (utilizando el flag SYN) a la víctima, simulando un ataque desde cientos de hosts diferentes.

Graficando el escenario

El escenario podría ser graficado del siguiente modo:

Como ya dijimos, HPING3 es una excelente herramienta con la posibilidad de utilizarla en muchas situaciones, recomiendo ejecutar la ayuda (hping3 -h) para ver las diversas opciones.

Para el caso de esta demostración, desde cada una de las máquinas atacantes, ejecutamos HPING con los siguientes parámetros:

 

Parámetro	Función
-S	seteamos el flag SYN
--flood	Enviamos paquetes lo mas rápido posible. No se muestran respuestas.
--rand-source	Simulamos diferentes orígenes aleatoriamente al enviar los paquetes.
-d	Establecemos el tamaño del cuerpo del paquete (expresado en bytes). Este valor puede variar.
-p	Indicamos el puerto de destino

 

Es importante contar con privilegios de superusuario, es por eso que utilizamos “sudo” para correr el comando.

Teniendo en cuenta que el target entonces es 192.168.1.109, que utilizaremos el flag SYN, que lo haremos en modo “flooding”, con cada request con un origen diferente y al puerto HTTP, el comando quedaría conformado así:

sudo hping3 -S 192.168.1.109 --flood --rand-source -d 5000 -p 80

Otras variantes y valores

Se podrían utilizar otras variantes y valores, pero a los efectos de la prueba, con estos parámetros es mas que suficiente para causar un DDoS.

Y lanzamos el ataque simultáneamente en las 3 maquinas atacantes !

:~$ sudo hping3 -S 192.168.1.109 --flood --rand-source -d 5000 -p 80
HPING 192.168.1.109 (eth0 192.168.1.109): S set, 40 headers + 5000 data bytes
hping in flood mode, no replies will be shown


Mientras tanto, veamos que ocurre en el servidor target. Para ello utilizaré el analizador de tráfico “IPTRAF”, pero bien usted puede utilizar el que desee (wireshark o tcpdump por ejemplo).

El flujo de tráfico se ve mas o menos así:

Al cabo de unos pocos segundos, el sitio se volverá inaccesible dada la cantidad de requests que el servidor tiene que procesar.

Al intentar acceder al sitio atacado, en el puerto 80, se obtiene un timeout dado que el servidor no puede responder a peticiones genuinas por estar saturado de paquetes malformados:

Como hemos podido ver, un servidor que no está protegido adecuadamente puede ser fácilmente comprometido utilizando unos pocos recursos.

Sin embargo, esta prueba fue realizada en una red interna, simulando un ambiente similar a internet pero sin intermediarios (routers, proxies, etc) que puedan ayudar a mitigar el riesgo aplicando algunas contramedidas, pero si tenemos en cuenta lo mencionado en la primera parte (“Entendiendo DDoS”), ante un ataque masivo, coordinado a nivel mundial, sin dudas esos controles pueden verse desbordados o poco efectivos.

Slow HTTP DDoS Attacks

Este es el segundo ataque que desarrollaremos en este articulo y uno de mis predilectos en el sentido de admiración a como se logra comprometer un servidor web sin mayores recursos al alcance.

También es conocido como “Slowloris” por ser la primera herramienta liberada para explotar una falla de diseño en el manejo de conexiones concurrentes.

Se trata de una técnica que afecta a servidores web (en su mayoría Apache, pero otros también) que tiene la particularidad de provocar un gran impacto utilizando un mínimo de ancho de banda, incluso utilizando unas pocas conexiones hogareñas xDSL.

La idea principal esta basada en como Apache maneja los hilos de conexiones, y a diferencia de otros ataques (como por ejemplo el tratado anteriormente “SYN Flood”) en los cuales son necesarios cientos, miles de paquetes para saturar la víctima, se trata de mantener abiertas conexiones el mayor tiempo posible enviando una respuesta parcial al servidor.

Dado que el pool de hilos disponibles es finito, el colapso se produce cuando éste se ve saturado, ocasionando así una Denegación de Servicio.

Cabe aclarar que este ataque no afecta al servidor entero sino al servicio web solamente, y el servicio se restablece inmediatamente una vez finalizado el ataque.

Veamos en detalle el funcionamiento de este ataque

Un cliente realiza una petición GET con una cabecera manipulada, la cual no se enviará por completo al servidor, quien, por diseño del protocolo HTTP, se quedará esperando por el resto de los datos. Para ello se suprime el envío del CRLF (señal de finalización) de la cabecera.

Si se producen muchas conexiones al mismo tiempo, el servidor mantendrá esos recursos ocupados hasta dejar de responder a nuevos requests, algunos posiblemente legítimos.

Como comprobarlo?

Para esta demostración no precisé de muchas maquinas atacantes, ya que, como explicamos antes, la clave está es comprometer a un servidor con pocos recursos al alcance.
Por lo tanto, utilizaré el siguiente escenario, suficiente para la prueba de concepto:

VICTIMA:
IP: 192.168.1.109
HTTP SERVER: Apache/2.2.22


ATACANTE:
IP: 192.168.1.104
SOFTWARE: slowhttptest-1.4


Existen algunas herramientas para hacer una prueba de concepto de este ataque.
Yo utilizaré una herramienta de capa siete desarrollada por Sergey Shekyan, llamada “Slowhttptest”, la cual es útil para simular (y hacer efectivos) ataques Slow HTTP DoS.
Recomiendo fuertemente esta herramienta dada su flexibilidad para realizar otros tipos de pruebas (como por ejemplo “Apache Range Header Attacks”), la posibilidad de generar gráficos y por ser la mas actualizada de las herramientas disponibles para ataques/tests de Slow HTTP DoS.
Queda fuera de este artículo el procedimiento de instalación, pero no se preocupen que está muy bien documentado en la página oficial del proyecto.

Utilizaré el módulo de monitoreo de Apache (server-status) en el servidor target para monitorear la actividad antes y durante un ataque.

En un estado normal, el servidor luce del siguiente modo:

En la máquina atacante, ejecutamos el siguiente comando (debajo explico las opciones y modificadores):

$ slowhttptest -c 1000 -H -g -o attack_stats -i 10 -r 200 -t GET -u http://192.168.1.109 -x 30 -p 3

• -c number of connections (limited to 65539)
• -H tipo de ataque que realizaremos (en este caso Slow Down en Headers)
• -g generate statistics in CSV and HTML formats
• -o output file
• -i Seconds. Interval between follow up data in seconds, per connection
• -r connections per second
• -t header/verb to use
• -u target URL, the same format you type in browser, e.g https://host[:port]/
• -x max length of follow up data
• -p timeout to wait for HTTP response on probe connection, after which server is
  considered inaccesible

Lanzamiento del ataque tipo “Slow Down Headers”

Con este seteo, lanzaré un ataque de tipo “Slow Down Headers”, es decir, haremos los requests al servidor pero no completaremos los mismos, forzando al servidor mantener esas conexiones en estado de lectura generando hasta 1000 conexiones concurrentes.
Como se observa en las opciones, puse como opción generar un archivo HTML para posterior análisis del ataque.

Ahora, lancemos el ataque:

Using:
test type: SLOW HEADERS
number of connections: 1000
URL: http://192.168.1.109/
verb: GET
Content-Length header value: 4096
follow up data max size: 604
interval between follow up data: 10 seconds
connections per seconds: 200
probe connection timeout: 3 seconds
test duration: 240 seconds
Sat Jul 28 08:58:47 2012:slow HTTP test status on 0th second:
initializing: 0
pending: 1
connected: 0
error: 0
closed: 0
service available: YES
Sat Jul 28 08:58:52 2012:slow HTTP test status on 5th second:
initializing: 0
pending: 586
connected: 252
error: 0
closed: 0
service available: NO
Sat Jul 28 08:58:58 2012:slow HTTP test status on 10th second:
initializing: 0
pending: 573
connected: 427
error: 0
closed: 0
service available: NO

Desde el servidor target, capturé el estado de las conexiones:

Como podemos observar en el proceso de ataque de slowhttptest, luego de 5 segundos de lanzado el mismo, el servicio ya no estaba mas disponible, lo cual es fácilmente comprobable al intentar navegar el sitio atacado y luego de unos minutos sin lograr acceder se obtendrá un timeout. (Ver PIC-03).

Luego de finalizado el ataque, la herramienta slowhttptest nos entrega el reporte del ataque:

Como se puede observar, es una herramienta muy potente la cual debe usarse con mucha responsabilidad. También es muy útil para realizar “Stress Testings” contra servidores propios y poder así testear la carga que soportan los mismos.

Como ya mencionamos antes, en este caso las pruebas son contra un servidor desprotegido, pero en un escenario real, de grandes infraestructuras protegidas, estos tipos de ataques mantienen su efectividad, mas aún si lo pensamos como una posibilidad de ataque distribuido.

Contramedidas en DDoS Análisis de Ataques Coordinados

Ojalá pudiese escribir en esta sección una fórmula mágica para protegerse contra los DDoS, pero desafortunadamente no existe una manera de defenderse completamente contra miles y miles de máquinas atacando, lo que si puedo hacer es brindar algunos consejos para mitigar el riesgo y no estar tan expuestos.

Para no entrar en demasiados tecnicismos, ya que hay muchos productos y variedad de sistemas operativos, etc, daré algunos tips generalizados que los administradores de sistemas deberán tener en cuenta para defenderse de ataques DDoS.

Los tips que se muestran a continuación aplican para los dos tipos de ataque planteados en este artículo, y para otros mas también.

A tener en cuenta en DDoS Análisis de Ataques Coordinados

• Desde ya, estar al día con las actualizaciones de software en uso que esté expuesto a internet.
• Sin dudas una de las técnicas mas recomendadas es la implementación mixta de
  • Firewall
  • Balanceo de carga
  • Proxy reverso
• Limitar la cantidad de conexiones permitidas por cada IP individual (100 estaría bien, una vez superado ese límite, las conexiones se rechazan)
• Acortar el número de conexiones por segundo.
• Reducir el tiempo en que cada cliente permanece conectado.
• Teniendo que el servidor web Apache es uno de los mas usados en internet, seguir las recomendaciones de la documentación oficial: http://httpd.apache.org/docs/trunk/misc/security_tips.html
• Si su aplicación tiene una audiencia específica, por ejemplo, si el servicio es solamente para personas residentes en Ecuador, las peticiones provenientes desde Rusia o China podrían ser blockeadas mediante uso de blacklists de rangos.

Para quienes quieren el articulo DDoS Análisis de Ataques Coordinados en ingles les dejo el pdf en linea:

<

DDoS Análisis de Ataques Coordinados, articulo escrito por Ramiro Caire para La Comunidad DragonJAR

Ramiro Caire creador del post, DDoS Análisis de Ataques Coordinados es un profesional de TI y Consultor de Seguridad. Sus áreas de interés principal van desde consultoría a pentest, incluyendo evaluación de la vulnerabilidad, Diseño de Redes e Infraestructuras. Actualmente está centrado en la evaluación de seguridad, estrategias de planificación y de investigación de Seguridad Cibernética. (ramiro.caire (arroba) gmail.com); Twitter: @rcaire