Análisis de un ataque DDoS con Amplificación DNS

Transcripción

1 Análisis de un ataque DDoS con Amplificación DNS Leonardo Pizarro Universidad Técnica Federico Santa María September 8, 2013 Abstract El ataque DDoS con amplificación DNS ha adquirido gran relevancia debido a su poder para dejar sin acceso a un servicio. Este poder se basa en 3 pilares, uno de los cuales depende exclusivamente de los administradores de los servidores OpenDNS. En este trabajo se realiza un análisis de los pasos necesarios para llevar acabo este ataque, además de analizar las medidas existentes. I. Introducción En la era de la computación, los ataques de denegación de servicio, DoS(Denial of-service Attack) por su sigla en ingles, han marcado momentos importantes, debido a ser el mecanismo más simple[7] para inhabilitar parcial o totalmente un servicio, como por ejemplo una página web de una organización, sin necesitar mayor conocimiento de redes y/o informática. Este ataque, y sus variaciones, se caracteriza por respetar el paradigma de que el costo de enviar un mensaje es menor al costo de procesamiento que debe enfrentar el servidor que responde, ya sea por un costo de procesamiento, de ancho de banda o de memoria[8]. En sus origenes, la práctica inicial consistía en enviar paquetes SYN desde una dirección falsa, causando que los paquetes ACK nunca lleguen a la víctima, ya que la dirección que fue falsificada no responde ante los paquetes SYN, desechando los SYNACK enviados por la víctima, dejando la conexión abierta. Esta versión de un ataque DoS explota un mal uso de TCP. Para la versión UDP, se realizan envíos de peticiones no solicitads a un puerto con el fin de colapsar la red. Con el tiempo, diversas nuevas maneras fueron apareciendo, ya sea por mal uso de protocolos, o por la explotación de vulnerabilidades presentes en los mecanismos de defensas creados para los ataques originales, como por ejemplo, ataques de seguridad que atacan la CPU debido a la carga que realiza un login en el sistema[12]. Sin embargo, a pesar de la explotación de nuevas vulnerabilidades, con el pasar del tiempo, la capacidad de los sistemas fue aumentando, siendo capaces de resistir por defecto ataques. Esto creo la necesidad de buscar un factor de amplificación que pudiese respetar el paradigma de que cada mensaje enviado fuese menos costoso que el procesamiento de este en la víctima. Así, en conjunto con la masificación del correo electrónico,nacen las botnets[13], que son conjuntos de computadores infectados por un virus o troyano, permitiendo su manipulación remota por un atacante, las cuales representan una amplificación del poder de ataque. Por otra parte, el uso de protocolos para la amplificación alcanza un punto a destacar en 1997, con el SMURF attack[14] y su pivote a UDP, el Fraggle Attack[15], llamado así por el nom- 1

2 bre del código que les dio su creador. Estos ataques explotaban la vulnerabilidad en la que al enviar un mensaje ICMP al broadcast de la red, con la dirección de origen como si fuese la de la víctima, causaban una respuesta no solicitada en masa hacia la víctima, como lo ilustra la figura 1. de denegación de servicio más potente en la historia de internet[9] y es el tópico central a analizar en este trabajo. Esta investigación entrega una descripción del problema, define los principales causantes, así como el modus operandi del atacante, es decir, los pasos que debe seguir. Luego, se presentan las contramedidas conocidas a la fecha, como el desarrollo y conclusiones 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 Figure 1: Ataque Smurf amplificando via Broadcast Los métodos de amplificación como el anterior o mediante el uso de Botnets, permite escalar el ataque DoS a su forma actual, el Distributed Denial of-service Attack o DDoS por su sigla en ingles, el cual es la distribución del origen del ataque, habiendo simultaneamente varios agentes atacantes. Esto, en conjunto con el desarrollo de nuevas herramientas como Scapy[11] o Mausezahn[10], los cuales facilitaban uno de los aspectos cruciales que se ha mantenido con el tiempo de este ataque, la falsificación y ocultamiento de la dirección IP del atacante, han permitido que los ataques de este tipo sean frecuentes en internet[16], aunque con mayor énfasis en atacar páginas mediante caudales de peticiones gigantes, que el hecho de esconder la IP del atacante a través del Spoofing, usando herramientas como LOIC[17]. Luego, en un entorno de internet cada vez más acostumbrado a estos sucesos, nace bajo la lógica del Smurf Attack, la amplificación DNS, la que en conjunto a DDoS crean un poderoso ataque aún sin una solución clara. Un ejemplo de este ataque fue el ataque a Spamhaus, organización encargada de combatir el SPAM a nivel mundial mediante blacklists, la que fue víctima de lo que se denomina el ataque El ataque DDoS con Amplificación DNS explota un aspecto clave del protocolo DNS (Explicado con mayor detalle en el Anexo 1), el cual, desde la implementación y puesta en marcha de la especificación EDNS0, permite la expansión del tamaño máximo estandar de algunos parámetros de DNS, definido por defecto en 512 Bytes, sin marcar un limite. Teniendo en cuenta que una consulta DNS realizada por un cliente, es decir, una consulta de resolución de nombre, puede pesar a lo más 60 Bytes, implica que sin la extensión EDNS0, la amplificación es de hasta 8 veces. Ahora, con EDNS0, la respuesta a una consulta DNS puede pesar más de 4 KiloBytes, por lo que la amplificación es de 68 veces o más. Lo anterior, es sólo uno de los pilares de este ataque, el que al igual que cualquier otro DDoS, se apoya en la falsificación de su origen y al mismo tiempo, en el uso de BotNets. Sin embargo, un tercer factor amplificador en esta situación, son los servidores OpenDNS, los cuales, son servidores DNS normales, que responden consultas mediante el puerto 53 UDP, pero que no discriminan sobre quien realiza la consulta. Un servidor DNS normal sigue las normas de buenas prácticas[18][19][20] permitiendo consultas y respondiendo sólo a una red o subred de la que es parte o en la que confía. Un servidor OpenDNS responde las consultas 2

3 de cualquier origen, sean estas consultas recursivas o consultas directas, lo cual permite a un cliente realizar consultas genuinas o malignas. El proyecto OpenResolver[21] es una instancia que recolecta información de los servidores OpenDNS, creando conciencia y haciendo un llamado a sus administradores a realizar recursión sólo a su red. Luego los 3 componentes del ataque causan una amplificación de proporciones[3]., causando un cuello de botella inmediato, saturando la red de la víctima. A continuación se listan las amplificaciones, con : X : Amplificación DNS (TXT) Y :Cantidad de Atacantes (Botnet) Z : Número de Servidores OpenDNS (i) 1 Paquete Falso = Bytes 1 servidor OpenDNS Víctima recibe X Bytes por petición. (ii) Y * 1 Paquete Falso 1 servidor OpenDNS Víctima recibe Y X Bytes por petición. (iii) Y * 1 Paquete Falso Z * 1 servidor OpenDNS Víctima recibe Z Y X Bytes por petición. Lo anterior quedo demostrado en la práctica en el ataque iniciado el 18 de Marzo del 2013 en contra de Spamhaus, organización que monitorea el spam enviado en internet, creando y actualizando listas negras que permiten a miles de servidores de correo bloquear estos correos no deseados. Dado que la industria del SPAM mueve millones de dolares[22], es facil para Spamhaus ser una víctima habitual de este tipo de ataques, adaptando medidas paliativas. Sin embargo, la magnitud de este ataque llevo a Spamhaus a verse en la obligación de recurrir a Cloudfare, una empresa proveedora de contenido, que mediante la distribución de sus datacenters y el balanceo de carga otorgado por el protocolo Anycast, lo que permitió a Spamhaus volver a operar con normalidad. La cantidad de tráfico generada oscilaba entre los 75 y los 120 Gbps, por lo que cualquier intento de respuesta que no fuese vía infraestructura era infructuoso. De este punto, es donde Anycast, que se puede tomar como la combinación entre Unicast y Multicast, ya que de un origen hay un destinatario, que sin embargo pertenece a un set de destinatarios posibles, es decir, funciona como Multicast pero en vez de replicar a todos los destinatarios, selecciona uno. En el caso de Cloudfare, ellos lo configuran de modo que nodo destinatario seleccionado, sea el que tiene la menor distancia o número de hops entre medio. Como medidas paleativas existen los firewalls que bloquean cualquier paquete UDP mayor a 512 bytes, así como existe Literatura[23] que sugiere que al aumentar sospechosamente la cantidad de paquetes tipo Response, sin haber realizado solicitudes, es decir, paquetes tipo Request, se puede sospechar el que se esta en el inicio de uno de estos ataques. La figura 2 ilustra los pasos que debe realizar un atacante desde la planificación a la ejecucción del ataque, y se listan a continuación: 1. El atacante debe crear o ganar acceso a un servidor DNS, de forma de manipular un archivo DNS que contenga la información de uno o más sitios web, con el fin, de agregar o modificar registros como el TXT, para así lograr la primera amplificación. 2. A su vez, el atacante debe obtener un listado de Servidores OpenDNS, para conseguir la mayor amplificación posible en este aspecto, así como diversificar los origenes de las peticiones falsas. 3. Se debe crear el código generador del mensaje falso, en el cual es de suma importancia esconder la dirección original 3

4 y reemplazarla con la IP de la víctima, realizando lo que se denomina Spoofing. 4-7 Se ejecuta el paso 3, enviando las peticiones falsas a los servidores encontrados en el paso 2, los cuales consultan al servidor contaminado del paso 1, generando en la víctima el ataque. representan 2 sitios web atacados, los que se denominaron zona1.cl y zona2.cl, cada una configurada de manera estandar como se indica en el anexo, teniendo zona1.cl un registro TXT 1152 Bytes y zona2.cl con un registro TXT de 512 Bytes. De forma de lo anterior funcione se debe editar el archivo named.conf.defaultzones en /etc/bind, e iniciar o reiniciar el servicio bind (service bind restart). III. Figure 2: Secuencia del Ataque Implementación En esta sección se indican los pasos realizados para lograr un módelo a escala de un escenario real, permitiendo generar replicas en un ambiente controlado, con el fin de estudiar las posibles soluciones. Las explicaciones siguientes se complementan con los aspectos técnicos explicitados en el anexo. Como lo indica la figura 2, son necesarios el desarrollo técnico de los 3 primeros pasos, ya que la base de esta construcción determina la solidez del ataque. Para el primer y el segundo paso, se utilizo una máquina en la cual se instalo Debian 6, conocido como Wheezy, con la opción de instalar BIND[24], que es la implementación del protocolo DNS para linux. Una vez instalado, se crearon 2 zonas, las cuales Para replicar el sistema de OpenDNS, es necesario realizar unas modificaciones a la instalación por defecto de BIND, por lo que en el archivo named.conf.options en /etc/bind, permitiendo la recursión y las consultas desde cualquier origen. Tanto el servidor OpenDNS y las zonas modificadas con registros TXT malignos se alojan en el mismo servidor, al cual nos referiremos como ODNS. El tercer paso consiste en la creación de un script que permitiese enviar un paquete DNS (Capa 7), mediante UDP (Capa 4), falsificando la dirección IP de origen (Capa 3). Lo anterior, se logra utilizando Scapy[11], una herramienta de seguridad escrita en python que permite lo anterior, estando presente en los repositorios de múltiples sistemas operativos. packet = IP(src=victimsIP, dst=opendnsip)/udp()/ 4

5 DNS(rd=1,qd=DNSQR(qname="zona1.cl",qtype="TXT")) El desglose del paquete presenta en primer lugar la manipulación de IP, donde se puede dejar en los campos src (Origen) y dst (Destino), las IPs que el atacante estime conveniente siendo la IP de destino la de un servidor OpenDNS. A su vez, es necesario que el medio por donde salga el paquete a internet, es decir, el primer router o modem, no verifique la legitimidad de este. Luego, se indica mediante UDP, el protocolo a utilizar en la capa de transporte. Finalmente esta la petición DNS, una petición normal con rd= 1, lo que permite la recursividad de la consulta y con qd como el tipo comando DNS que se realiza, el que es una consulta (DNS Query, DNSQR), la que consulta por el nombre de dominio zona1.cl, en específico al registro TXT. Se utilizarón dos computadores víctimas, uno fue una instancia micro de Amazon Web Services (AWS), con 512 Mb de Ram y su IPv4 pública , mientras que la otra era una máquina virtual (DI) alojada en el sistema de virtualización Ovirt del LabComp, la cual contaba con una IPv4 pública del segmento /26. En ambas los firewalls estaban configurados para permitir el paso de datos por el puerto 53 en UDP y TCP. IV. Experimentación El primer elemento a registrar fue en envío y correcta recepción de una paquete con origen falso en los servidores de destino. Esto se puede comprobar usando wireshark o tshark en las máquinas respectivas, teniendo que haber un registro de paquete enviado en el computador atacante y un registro de un paquete recibido en la máquina víctima. El tamaño de cada uno de estos paquetes debe ser congruente, lo cual se comprueba parcialmente con la evidencia registrada en la máquina AWS. [root@atacante ~]# tshark -r SpoofDNSProof > DNS 68 Standard query TXT lpspa.cl [root@victima ~]# tshark -r SpoofDNSProofReceived > DNS Standard query response TXT A pesar de haber llegado el paquete falso, este no llego en el tamaño deseado. Al utilizar la herramienta dig en la víctima AWS, consultando por el registro TXT de zona1.cl se obtiene que el paquete es demasiado grande por lo que reintenta el envío mediante TCP, fracasando el ataque por el resto del mensaje que se intenta reenviar, lo que deja un factor de amplificación de sólo 7 veces. Esto es causado por una política de algún firewall existente entre el atacante y la máquina AWS, lo cual es conocido como una medida paliativa existente. Al realizar el envío falso a la máquina DI el paquete llega completo, por lo que por la claridad del experimento se elige esta víctima. Una vez comprobado el funcionamiento del ataque, se procede a realizar este contra la máquina DI, con un atacante y un servidor OpenDNS, el servidor creado para la experiencia, llamado ODNS. Durante el ataque, se monitorea con wireshark la capacidad de enviar paquetes por minuto, lo cual arroja un resultado de 2000, los que multiplicados por el tamaño de un paquete, indican que el gasto que se genera en el ancho de banda del atacante bordea los 120Kb por minuto. A su vez, en la víctima DI, con la zona1.cl se genera un daño teórico de 2.1 Mb por minuto. La zona2.cl causa un daño teórico de 1 Mb por minuto. Cada ataque no tuvo una duración de más de 4 minutos, oscilando los diversos intentos entre los 2 y los 3 minutos. IV.1 Resultados La práctica del ataque entrega los siguientes gráficos, los que fueron obtenidos con la herramienta ntop[6], instalada en las víctimas. 5

6 Figure 3: Registro del 2do ataque existoso Figure 4: Zoom del registro del 2do ataque existoso Figure 5: Costo Atacante 6

7 Los gráficos 3 y 4 muestran que se logra un ataque no menor considerando que no se utilizó un tamaño de registro TXT demasiado grande y que se dejo el factor de amplificación por cantidad de atacantes en 1 y por servidores OpenDNS en 1. El gráfico 5 comprueba el bajo costo de ancho de banda de un atacante. El gráfico 6 es el reflejo de un ataque no exitoso. La gráfica 7 muestra la serie de ataques realizados, resaltandose el ataque exitoso por sobre los demás intentos. Figure 6: Ataque no exitoso Figure 7: Registro de diversos intentos 7

8 V. Conclusiones La efectividad del ataque queda demostrada dado su bajo costo de red del atacante, así como el efecto que surge tras cada ataque, el que deja un cuello de botella que perdura en el tiempo, en el servidor OpenDNS queda una cola de peticiones, las que aún cuando finaliza el ataque, siguen llegando a la víctima. No se logra en todos los casos dejar inhabilitado el acceso a la máquina, sin embargo es constante el resultado de dificultar el acceso a esta, en especial la carga de los gráficos obtenidos en las víctimas en tiempo real. En otro aspecto, este ataque al ser una modificación de la lógica del Smurff Attack, permite extrapolar que aunque se logre palear la amplificació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 víctima o simplemente colapsar su red. La única contramedida conocidas y efectiva es el balancear la carga entre diversos servidores repartidos en distintas ubicaciones geográficas, lo que lo hace una medida inaccesible para la gran mayoría de las potenciales víctimas. A su vez, mientras existan servidores OpenDNS, en la cantidad que existen hoy día, sólo se puede esperar que los records en cuanto a la magnitud del ataque se sigan superando. Es sabido que al bloquear las peticiones no solicitadas se refleja el ataque en el servidor OpenDNS, sin embargo, si existiese una blacklist de este tipo de servidores, la cual podría nacer de un refinamiento del listado que genera el Open Resolver Proyect, se podría discriminar entre una reflexión a un servidor mal configurado y uno que no, lo cual hace que se tenga un nuevo discriminante para tomar esta decisión. References [1] TXT Records Size forum/?fromgroups#!topic/ comp.protocols.dns.bind/x4vdl9xi7xs [2] Template DNS [3] Anatomy of a DNS DDoS Amplification Attack, David Piscitello, ICANN SSAC Fellow [4] Block Iptables port [5] TCPDump HowTo [6] Ntop Monitoring Tool [7] The Anonymous WikiLeaks protests are a mass demo against control /dec/17/anonymous-wikileaks-protest-amazon-mastercard [8] Columbia, CS, Network Security - COMS W smb/classes/f06/l22.pdf [9] Largest DDoS Attack [10] Mausezahn traffic Generator [11] Scapy, packet manipulation tool [12] Ming Luo; Tao Peng; Leckie, C., "CPU-based DoS attacks against SIP servers," Network Operations and Management Symposium, NOMS IEEE, vol., no., pp.41,48, 7-11 April stamp.jsp?tp=&arnumber= &isnumber= [13] Botnet definition 8

9 [14] Preventing Smurf Attacks [15] Fraggle Attack [16] DDoS Attacks are Increasing in Frequency and Severity âăş Study [17] Low Orbit Ion Cannon [18] Recursive DNS, Why it s not recommended? /whatis-recursive-dns-and-why-is-it-not-recommended [19] Internet Engineering Task Force [20] Pro DNS and Bind Book, 1ra Edición, 24/03/ [21] Open Resolver Proyect [22] Infographic - FastCompany - [23] A Fair Solution to DNS Amplification Attacks -Kambourakis, Georgios, et al. Digital Forensics and Incident Analysis, WDFIA Second International Workshop on. IEEE, [24] Berkeley Internet Name Domain- Todos los links activos al 6 de Septiembre del 2013 VI. Anexos VI.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. Figure 8: Búsqueda DNS 9

10 La forma en que opera una consulta DNS se puede apreciar en la Figura 8, siendo el desglose el siguiente: Se puede apreciar que un cliente realiza la consulta por el nombre a su servidor DNS, que puede ser el que provee su compañia proveedora de internet o alguno disponible como el de Google. El servidor DNS realiza la consulta internamente, de manera recursiva,, la cual es analizada de derecha a izquerda, tomando inicialmente lo que se denomina como TLD, que en el caso sería org, a uno de los servidores root, el cual le indica la dirección IP del servidor que maneja ese TLD. Luego, el servidor DNS le realiza la consulta al servidor de.org sobre wikipedia.org, obteniendo la respuesta del servidor de nombres encargado de esa dirección. Finalmente, el servidor de nombres de wikipedia.org le entrega una dirección IP del servidor que aloja la página, dirección que le entrega al realizador original de la consulta para que este pueda acceder a esa IP para ver su contenido. Este procedimiento es conocido como búsqueda recursiva o recursión. Esta recursión es correcta si y sólo si el servidor DNS le responde a clientes que esten dentro de su red, subred o sea de confianza. De lo contrario, al responder cualquier petición son denominados servidores OpenDNS. 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 A AAAA NS MX TXT CNAME Descripción Indica la dirección IPv4 del servidor host con el contenido del dominio buscado Indica la dirección IPv6 del servidor host con el contenido del dominio buscado Indica el servidor de nombres a cargo del dominio Indica el servidor de correo a cargo del dominio Contiene información adicional del dominio, como filtros de spam 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. VI.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: 10

11 -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 forwarders y agregar las siguientes lineas al archivo: allow-transfer { /0; }; allow-query { /0 }; allow-recursion { /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 puede realizar teniendo como ejemplo el siguiente archivo[2]: $ORIGIN zona1.cl. $TTL IN SOA ns1.zona1.cl. hostmaster.zona1.cl. ( ; Serial ; Refresh 1800 ; Retry ; Expire 3600 ) ; Minimum IN NS ns1.zona1.cl. IN NS secundario.nic.cl. IN A IN MX 10 mail.zona1.cl. IN TXT "Contenido de 18 Bytes" www IN A mail IN A Lo anterior debe guardarse con el nombre dominio.tld.zone, que en este caso es template.cl.zone en /etc/bind. Finalmente se debe agregar al archivo named.conf.defaultzones en /etc/bind, lo siguiente para cada dominio: zone "zona1.cl" IN { type master; 11

12 }; file "/etc/bind/zona1.cl.zone"; notify yes; also-notify { ; }; # Notificando al servidor secundario allow-transfer { ; }; # Permite la transferencia de zona a # cualquiera que lo solicite Con lo anterior, al hacer una consulta del tipo dig any 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[1], 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 víctima 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,sr victimsip = " " OpenDNSIP = " " packet = IP(src=victimsIP, dst=opendnsip)/udp( )/ DNS(rd=1,qd=DNSQR(qname="zona1.cl",qtype="TXT")) 12

13 while(1): send(packet) Para poder medir la salida como llegada del paquete, se recomienta dejar UDP( sport=53, dport=53 ), y con tcpdump[5] o wireshark filtrar el puerto, el protocolo y medir el contenido de este. Con ntop[6] se pueden tener gráficos en tiempo casi real para monitorear tamaño del tráfico generado. 13