Ataques DDoS con Servidores DNS Recursivos

Categorias: General

  A TCP/IP le pasan los años y eso se nota. Muchas veces se ha hablado del peligro de los servidores DNS recursivos que hay en Internet. Son servidores que aceptan consultas DNS de dominios de los que no son autoritativos. Múltiples documentos han salido ya entorno al Pharmming.

  Hoy nos toca hablar sobre un nuevo tipo de ataque DDoS que ha salido a discusión en varias listas de seguridad hace un mes escaso. Éste ataque usa estos servidores DNS como intermediarios.

  Como es fácil deducir, se aprovechan de la facilidad de poder enviar datagramas UDP spoofeados (Dirección IP de origen falseada) para saturar a la víctima con respuestas de consultas DNS.

  Usa un sistema parecido al antiguo ataque de DoS Smurf. Éste lo que hacía era mandar un paquete ping (eco request ICMP) a una dirección broadcast con la dirección de origen falseada con la de la víctima. Al ser una solicitud a una dirección broadcast, varias máquinas responderían a la víctima, si no todas, pudiéndola dejar offline. En el ataque Smurf la víctima no podía hacer gran cosa para protegerse. La solución estaba en la correcta configuración de la red. En el RFC2644 se explica la solución a esto en los encaminadores.

  Pues bien, con el protocolo DNS pasa algo parecido, al poderse falsear la dirección de origen fácilmente también en el protocolo UDP.

  El ataque básicamente se basa en usar un registro de recurso (RR) de tipo TXT lo suficientemente largo como para que se dé la amplificación, de unos 4000 bytes podría ser más que suficiente. Así, para una consulta que puede ser de unos 60 bytes podemos obtener un factor de amplificación de 66, suponiendo una respuesta de 4000 bytes.

  En el 2002 ya se comentó en la lista de gnupg-users la posibilidad de utilizar los registros MX (mail) de algunos servicios de correo grandes. Utilizando este sistema, según más cerca esté la respuesta de 512 bytes, sin sobrepasarlo, mayor amplificación.

  Por ejemplo, con los servidores de hotmail.com se consigue una amplificación de 9.5, con los de aol.com un factor de 10 y con mci.com un 10.2. Aun así, la diferencia del tamaño de la respuesta no es lo suficientemente alarmante.

  La limitación de este ataque se manifestaba por el límite de los 512 bytes del protocolo UDP. Sí una respuesta superara este límite se enviaría por el protocolo TCP, y no funcionaría.

  Sin embargo en el EDNS0 [RFC2671] se sugiere que el cliente pueda cambiar el tamaño máximo del paquete UDP mediante un registro de recurso (RR) llamado OPT. Por lo tanto, basta con buscar un servidor DNS que soporte la extensión EDNS. Bind 9 lo soporta, con un límite de 4096 bytes de respuesta máximo. Djbdns, sin embargo, no lo soporta. De todas formas, en Bind se puede configurar este tamaño con la opción edns-udp-size.

  Total, que con una lista de servidores que cumplan esas condiciones, y un registro TXT lo suficientemente grande, bastaría para poner en apuros a más de uno. Siendo bastante complicada la localización del verdadero atacante.

  Las consecuencias del ataque las sufrirían tanto el servidor DNS como la víctima del ataque. Para reducir el ataque en el servidor autoritativo del dominio también convendría que el RR TXT en cuestión tuviera un TTL (Time To Live) alto, para que se cacheara la respuesta en los servidores recursivos utilizados para el ataque.

  También se está discutiendo en las listas la idea de tratar a los "open resolvers" (los servidores DNS recursivos de acceso público) como a los "open relays".

  Teniendo en cuenta la inseguridad del protocolo UDP, sólo es cosa de tiempo que los atacantes encuentren diferentes protocolos y aplicaciones que utilizar para sus fechorías.

  A corto plazo no parece que tenga fácil solución. Ya veremos que sucede en el futuro.

  Referencias y enlaces:

    http://www.isotf.org/news/DNS-Amplification-Attacks.pdf
    http://www.securityfocus.com/archive/1/428240/30/210/threaded
    http://www.securityfocus.com/archive/1/426368/30/0/threaded
    http://lists.oarci.net/pipermail/dns-operations/
    http://merit.edu/mail.archives/nanog/2006-02/msg00579.html


Zz.

VN:F [1.9.22_1171]
Rating: 4.0/5 (Votos: 1)

¿NECESITAS AYUDA? Llama a nuestro soporte técnico 946 545 762 / 902 011 590

De Lunes a Viernes de 08:00 a 20:00 horas.


¡¡SOLO PARA TI!! Aprovéchate Ahora ...

¡¡Descubre los Mejores Artículos de Expertos en Tecnología!!

-

¡¡Descubre los mejores Artículos de Tecnología con Hostinet!!
Todos realizados por Expertos.