Portada General Ataques DDoS con Servidores DNS Recursivos
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.
Ataque de Denegación de Servicio sería la traducción más acertada de Distributed Denial of Service, que son las siglas de DDoS.
El objetivo de un ataque DDos es, básicamente, que un servidor deje de funcionar para que no pueda seguir funcionando y en servicio.
Sin entrar en complejidades, la forma de actuar de un ataque DDos es muy sencilla. Se trata de enviar muchas peticiones, al mismo tiempo y repetidas veces a un servidor con la intención de que se sature y deje de funcionar.
Si nos imaginamos un campo de fútbol, un hipermercado, o cualquier otro sitio abarrotado de personas queriendo salir al mismo tiempo por la misma salida, podemos comprender, a grandes rasgos, que es un ataque DDos.
Esto, que en principio parece muy simple, es tremendamente efectivo, ya que no existe servidor capaz de aguantar un número descomunal de peticiones. Por muy potente que sea acabará, saturándose y dejando de funcionar.
Además, el funcionamiento básico de un ataque DDos puede ser muy sencillo. Si cientos de miles de personas entran al mismo sitio web y actualizan sin para la página principal del sitio, este acabará saturado por intentar atender tantas peticiones.
Obviamente este ejemplo es muy básico y un ataque DDos funciona de una manera más compleja, usando ordenadores zombies, ataques lentos usando una técnica llamada Slow Read, etc…
Como hemos comentado antes, los ataques DDoS no son complicados de realizar en concepto, pero al mismo tiempo, un ataque DDoS básico a cualquiera de los servidores de Hostinet sería fácilmente detectado y anulado.
La seguridad es algo que nos tomamos muy en serio en Hostinet y por ese motivo todos los alojamientos web que ofrecemos llevan incluidos una serie de protecciones para garantizar la seguridad del sitio web.
Estas medidas de seguridad son :
Además de esto, todos los servidores están monitorizados 24 horas al días, 7 días a la semana, durante todo el año para que, en caso de recibir un ataque masivo y organizado, poder reaccionar lo antes posible y neutralizarlo evitando mayores problemas.
¿Te ha resultado útil? Recibe artículos como este suscribiéndote GRATIS a