Análisis de un ataque DDoS con Amplificación DNS
Leonardo Pizarro
Universidad Técnica Federico Santa María [email protected]
July 11, 2013
I. Introducción
En el presente documento se desarrolla un es- tudio del ataque DDoS con Amplificación DNS, el cual combina conocimientos de las diver- sas capas de red, así como el funcionamiento detallado del protocolo DNS. Este ataque ha adquirido popularidad en el último tiempo debido a su eficiencia y a que provee de anon- imato al atacante. Esta investigación entrega una descripción del problema, define los prin- cipales causantes, así como el modus operandi del atacante, es decir, los pasos que debe seguir.
Luego, se presentan las contramedidas cono- cidas a la fecha, como el desarrollo y conclu- siones del trabajo práctico llevado a cabo, que busca generar un ambiente controlado en el que se pueda replicar el ataque con el fin de su estudio.
II. Descripción del Problema
Los Ataques de Denegación de Servicio o DoS por su sigla en ingles han existido durante años a través de internet. A lo largo del tiempo se han podido factores claves en este tipo de ame- nazas, como la constante búsqueda de factores de amplificación del ataque, teniendo como claro ejemplo el Smurf Attack y el Fraggle Attack a finales de la decada del 90, así como el ac- tual uso de BotNets por parte de los atacantes, dando pie al Distributed-Dos o DDos. Otro aspecto vislumbrado es el uso de IP Spoofing, el
cual es uno de los pilares de cualquier ataque debido a el ocultamiento de la identidad, y en los casos mencionados anteriormente, dificulta la forma en que se pueden mitigar, ya que esta modificación actua al nivel 3 del modelo OSI.
El modus operandi del ataque DDos a Spamhaus y finalmente mitigado por Cloudfare, se pudo observar el uso de las peticiones DNS.
Normalmente, un consulta DNS, específica- mente el paquete de respuesta, no podía pesar más de 512 bytes. Lo anterior se puede generar desde una petición de 60 bytes, logrando un factor de amplificación de 8.5. Con el uso de la extensión EDNS0 para DNS los paquetes de respuesta puede ser aumentados, permitiendo actualmente respuestas mayores a 4000 Bytes, generadas con la misma petición de 60 bytes, consiguiendo una amplificación de un factor 60, es decir, un paquete a lo menos 7 veces más grande, que al ser UDP (connectionless) puede generar un caudal importante en segundos. Lo anterior, en conjunto con servidores OpenDNS y un servidor DNS contaminado, permiten que el atacante genere un registro TXT de más de 4000 bytes, los que mediante las consultas falsi- ficadas a servidores OpenDNS, gatilla el tráfico hacia la victima[4].
II.1 Causas
Las causas del efecto amplificador de este ataque se fundamentan en 2 aspectos: En la re- cursióndel servidor DNS, lo que permite que
cualquier servidor o cliente fuera del dominio pueda realizar consultas. Por ejemplo, si el servidor OpenDNS responde por el dominio example.com, sólo debiese devolver una con- sulta a clientes o servidores dentro de aquel dominio, como sucede con masterdns.labcomp.cl, que es el servidor de nombres encargado del dominio labcomp.cl.
El otro aspecto es el mal uso del EDNS0, que fue diseôsado para permitir un una mayor comunicación debido a los datos adi- cionales que puede proporcionar un servidor de nombres, lo que ocasiona que se el máximo tamaôso de respuesta de un servidor de nom- bres pasase de 512 bytes, a más de 4 KiloBytes.
II.2 Modus Operandi del Atacante
El atacante busca dejar sin utilidad el ser- vicio de su victima utilizando la menor cantidad posible de recursos. Esto lo logra mediante los siguientes pasos:
Figure 1: Secuencia del Ataque
El lograr el paso 1 o 3 no es un acto trivial, además de que a diferencia de los demás pa- sos, no son automatizables y requieren de un conocimiento intermedio-avanzando de seguri-
dad como de redes.
II.3 Contramedidas conocidas
Actualmente la medida inmediata a tomar en este caso es la de bloquear la dirección IP de el o los servidores OpenDNS que estan de- volviendo las consultas realizadas. Sin em- bargo, esta defensa actua como un ataque DoS por sí mismo, ya que a cada servidor OpenDNS le aparecerá que la victima esta real- izando una serie de consultas de gran tamaôso, bloqueando las respuestas y por ende cau- sando un gran uso del ancho de banda de la red de los servidor OpenDNS. A su vez, cier- tos firewalls segmentan cualquier paquete de tamaôso mayor a 512 bytes, por lo que esto funciona como contramedida parcial, ya que independiente de la cantidad de paquetes que se segmenten, el fin último del atacante es co- lapsar la red.
III. Trabajo Práctico
En pos de lograr un entendimiento del prob- lema se procedió a montar un escenario sim- ilar, en el cual destacan aspectos más técni- cos y particulares del ataque, los que posibil- itan estudiar aspectos como que la conexión de los computadores atacantes debe ser de- trás de un modem (switch) o un router que permita la falsificación o Spoofeo de la IP de origen, lo cual aôsade un grado de dificultad al ataque, ya que no sólo se necesita controlar un computador de una botnet sino que tam- bién componentes de la red a la cual pertenece.
Otro aspecto que surge en el desarrollo de la parte práctica es que se uso el mismo servi- dor OpenDNS casero, es decir, que permite la recursión de una consulta perteneciente a otro dominio, para alojar la información del do- minio hackeado o falsificado, es decir el dominio que contiene un registro TXT y con EDNS0 activado, que permite el envío de paquetes de gran tamaño y cuyo servidor de nombres permite la transferencia a cualquiera que lo solicite. Finalmente, la creación del paquete con la herramienta Scapy permite la posterior automatización del ataque, el cual es monitore- ado con las herramientas wireshark y tshark en la máquina atacante (detectando los 60 bytes de la consulta del paquete de salida UDP), con tshark en el servidor victima (detectando la consulta no solicitada) y con munin en el servi- dor OpenDNS/Dominio falso para monitorear
la entrada y salida de datos. En el Anexo 3 se presenta el detalle de la puesta en marcha con todos los detalles técnicos remanentes.
IV. Conclusiones
La efectividad de este ataque presenta una to- tal dependencia a la topología de la red, tanto de la botnet atacante como la de la victima, ya que es común que servidores, aún teniendo redundancia y balanceo de carga, no tengan redundancia en cuanto al cableado de la red que les da acceso a internet. Aquello conlleva que el bloqueo de el único canal de comuni- cación mediante este ataque de nivel 3 sea muy efectivo. Como contramedida clásica surge el tener una red distribuida con múltiples accesos a internet. Sin embargo, como solución más cercana a un servidor con servicios críticos sin tanto presupuesto, es factible dividir los servi- cios imprescindibles en diferentes IPs públicas, de modo que ante un ataque sea posible rediri- gir la red interna o las peticiones de los clientes por estas direcciones.
En otro aspecto, este ataque al ser una mod- ificación de la lógica del Smurff Attack, permite extrapolar que aunque se logre palear la am- plificación DNS, otro servicio UDP podrá ser fuente de un mal uso, como lo podría ser una falsificación múltiple de paquetes NTP con el fin de desorientar a la victima o simplemente colapsar su red.
V. Anexos
V.1 DNS
El protocolo de búsqueda de dominio de nombres o DNS por su sigla en ingles, cumple la función de transformar una dirección url a una IP, con el fin de poder utilizar un denominador para distintos servidores más cercano que un conjunto de números. Este protocolo pertenece a la capa de aplicaciones o capa 7 según el modelo OSI
La forma en que opera una consulta DNS se puede apreciar en la Figura 1, siendo el desglose el siguiente:
Se puede apreciar que un cliente realiza la consulta a www.wikipedia.org, la cual es analizada
Figure 2: Búsqueda DNS
de derecha a izquerda, tomando inicialmente lo que se denomina como TLD, que en el caso sería org, a lo que uno de los servidores root le indica la dirección IP del servidor que maneja ese TLD.
Luego, el cliente le realiza al servidor de .org la consulta por wikipedia.org, obteniendo la respuesta del servidor de nombres encargado de esa dirección. Finalmente, el servidor de nombres de wikipedia.org le entraga una dirección IP del servidor que aloja la página, y puede acceder a esa IP para ver su contenido. Este procedimiento es conocido como búsqueda recursiva o recursión
Desde sus comienzos en 1983, DNS entrega paquetes de respuesta a las consultas como la anterior mediante el protocolo UDP, con un tamaño máximo de 512 bytes. Desde 1999 es posible transferir una respuesta más grande, siendo común el usar 4KB, debido a la mayor información disponible. Lo anterior es debido a la aprobaciín del RFC 2671 o EDNS0, el cual es un mecanismo de extension para DNS.
Entre las consultas posibles, existen distintos tipos, siendo los más comunes:
Tipo Descripción
A Indica la dirección IPv4 del servidor host con el contenido del dominio buscado AAAA Indica la dirección IPv6 del servidor host con el contenido del dominio buscado
NS Indica el servidor de nombres a cargo del dominio MX Indica el servidor de correo a cargo del dominio
TXT Contiene información adicional del dominio, como filtros de spam
CNAME Alias de un dominio
Table 1: Tipos de records DNS más comunes
A diferencia de una consulta de un cliente a un servidor DNS, los servidores DNS se comunican entre si mediante el protocolo TCP en el mismo puerto 53. Como buenas prácticas para un servidor DNS, se recomienda que permita recursión sólo para consultas realizadas dentro de su zona.
V.2 HowTo: DDos with DNS Amplification
Pasos para replicar un ataque en un ambiente controlado.
1. Servidor DNS: Se instala Debian 6 en su versión estable, cuyo nombre código es Squeeze con la función de servidor DNS seleccionada entre los paquetes básicos. Los cambios a realizar a la configuración del S.O. instalado son:
• Firewall: Iptables controla el firewall en Squeeze mediante el archivo iptables.rules en la carpeta /etc. En caso de no existir el archivo, es conveniente realizar el comando iptables-save > iptables.rules. Luego, se agregan 2 reglas:
-A INPUT -p udp -m udp --dport 53 -j ACCEPT -A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
Las que permiten la comunicación con los clientes y otros servidores DNS.
• DNS: La configuración por defecto para DNS en Debian esta en el archivo named.conf en la carpeta /etc/bind/, el cual inicialmente sólo incluye a 3 archivos, de los cuales nos interesa named.conf.options, que es aquel que filtra la recursión, la transferencia y a quienes se autoriza a realizar consultas al servidor. Se debe descomentar la sección forwardersy agregar las siguientes lineas al archivo:
allow-transfer { 0.0.0.0/0; };
allow-query { 0.0.0.0/0 };
allow-recursion { 0.0.0.0/0; };
Esto permite obtener un servidor OpenDNS (recursión para todos), además de actuar como el servidor del Dominio hackeado o falso, ya que permite la transferencia a todos..
A lo anterior, se debe agregar uno o más dominios, que deben ser configurados a modo de contener el registro TXT malicioso. Aquello se realiza de la siguiente manera[3]:
$ORIGIN template.cl.
$TTL 86400
@ IN SOA inti.inf.utfsm.cl. hostmaster.inf.utfsm.cl. ( 2010121301 ; Serial
10800 ; Refresh 1800 ; Retry 3600000 ; Expire 3600 ) ; Minimum
IN NS inti.inf.utfsm.cl.
IN NS secundario.nic.cl.
IN A 200.1.19.9
IN MX 10 crux.inf.utfsm.cl.
www IN A 200.1.19.9 mail IN A 200.1.19.9
Lo anterior debe guardarse con el nombre dominio.tld.zone, que en este caso es tem- plate.cl.zone en /etc/bind. Finalmente se debe agregar al archivo named.conf.default- zonesen /etc/bind, lo siguiente para cada dominio:
zone "template.cl" IN { type master;
file "/etc/bind/template.cl.zone";
notify yes;
also-notify { 200.1.123.7; }; # Notificando al servidor secundario allow-transfer { 0.0.0.0; }; # Permite la transferencia de zona a
# cualquiera que lo solicite };
Con lo anterior, al hacer una consulta del tipo dig any template.cl @<IP Servidor DNS>
se tendrá una respuesta normal.
2. Activar EDNS0: Se puede observar que viene activado en la instalación base.
3. Crear entrada TXT de 4000 Bytes: El registro TXT para DNS puede variar entre 0 y 4096 bytes (Con EDNS0 Activado), sin embargo, el registro debe estar compuesto de substrings que no superen los 255 bytes de largo cada uno[2], de lo contrario, el servidor DNS no iniciará. Un registro correcto es de la forma
IN TXT "Giant TXT record for DNS Amplification Testing, any questions, at leoxdxp on twitter or lepizar at inf dot utfsm dot cl Now Just more text text text text text DDoS text text text text text text more text text text text"
" text DDoS text text text text text text more text text text text text DDoS text text text text text text more text text " "text text text DDoS text text text text text text more text text text text text DDoS text text "
En donde se puede apreciar las comillas dobles entre substrings, lo cual permite la creacion de un string gigante. El string del ejemplo pesa 552 bytes.
4. Aplicar paquete UDP con IP Spoofeada: Utilizando la herramienta Scapy, mediante el uso del método IP(), se puede asignar tanto un origen como un destino. En este caso, el origen es la IP de la victima y el destino el o los servidor OpenDNS.
Además, Scapy permite elegir el protocolo mediante el cual será enviado el paquete, por lo que se utilizará el método UDP(). Finalmente, usando el método DNS(), se pasan los parámetros de la consulta como tal. La suma de lo anterior queda como:
#!/usr/bin/python import sys
from scapy.all import sr1,IP,DNS,UDP,DNSQR,send victimsIP = "54.232.215.XXX"
OpenDNSIP = "190.45.112.YY"
packet = IP(src=victimsIP, dst=OpenDNSIP)/UDP() /DNS(rd=1,qd=DNSQR(qname="example.com",qtype="TXT")) send(packet)
Para poder medir la salida como llegada del paquete, se recomienta dejar UDP( sport=53, dport=53 ), y con tcpdump o wireshark filtrar el puerto, el protocolo y medir el contenido de este.
References
[1] An Extensible Pattern-based Library and Taxonomy of Security Threats for Distributed Systems, Anton V. Uzunova, Eduardo B. Fernandez
[2] TXT Records Size
https://groups.google.com/forum/?fromgroups#!topic/comp.protocols.dns.bind/x4Vdl9xi7Xs [3] Template DNS ftp://ftp.inf.utfsm.cl/dnstemplate Todos los links activos al DD de MM del
2013
[4] Anatomy of a DNS DDoS Amplification Attack, David Piscitello, ICANN SSAC Fellow http://www.watchguard.com/infocenter/editorial/41649.asp
