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.
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, lo cual 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.
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.
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:
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.
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 un 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 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.
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
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 mal formados:
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.
¿Cómo 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 genera estadistias en formato CSV y HTML
- -o archivo de salida
- -i Segundos. Interval between follow up data in seconds, per connection
- -r Conexiones por segundo
- -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
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
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:
- 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)
- Limitar el número de conexiones por segundo.
- Limitar 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.
Fuente: http://www.dragonjar.org/
