{"id":1811,"date":"2006-04-03T21:33:00","date_gmt":"2006-04-03T21:33:00","guid":{"rendered":"http:\/\/cursos.hostinet.com\/general\/ataques-ddos-con-servidores-dns-recursivos\/"},"modified":"2026-03-30T13:48:04","modified_gmt":"2026-03-30T11:48:04","slug":"ataques-ddos-con-servidores-dns-recursivos","status":"publish","type":"post","link":"https:\/\/www.hostinet.com\/formacion\/general\/ataques-ddos-con-servidores-dns-recursivos\/","title":{"rendered":"Ataques DDoS con Servidores DNS Recursivos"},"content":{"rendered":"
<\/div>

\"Ataques<\/p>\n

 <\/p>\n

A TCP\/IP le pasan los a\u00f1os y eso se nota. Muchas veces se ha hablado del peligro de los servidores DNS recursivos<\/strong> que hay en Internet. Son servidores que aceptan consultas DNS de dominios de los que no son autoritativos. M\u00faltiples documentos han salido ya entorno al Pharmming<\/a><\/strong>.<\/p>\n

Hoy nos toca hablar sobre un nuevo tipo de ataque DDoS<\/a><\/strong> que ha salido a discusi\u00f3n en varias listas de seguridad<\/strong> hace un mes escaso. \u00c9ste ataque usa estos servidores DNS como intermediarios.<\/p>\n

Como es f\u00e1cil deducir, se aprovechan de la facilidad de poder enviar datagramas UDP spoofeados<\/a><\/strong> (Direcci\u00f3n IP de origen falseada) para saturar a la v\u00edctima con respuestas de consultas DNS.<\/p>\n

Usa un sistema parecido al antiguo ataque de DoS<\/a> Smurf<\/a><\/strong>. \u00c9ste lo que hac\u00eda era mandar un paquete ping (eco request ICMP) a una direcci\u00f3n broadcast<\/strong> con la direcci\u00f3n de origen falseada con la de la v\u00edctima. Al ser una solicitud a una direcci\u00f3n broadcast, varias m\u00e1quinas responder\u00edan a la v\u00edctima, si no todas, pudi\u00e9ndola dejar offline<\/strong>. En el ataque Smurf<\/strong> la v\u00edctima no pod\u00eda hacer gran cosa para protegerse. La soluci\u00f3n estaba en la correcta configuraci\u00f3n de la red. En el RFC2644<\/a> se explica la soluci\u00f3n a esto en los encaminadores<\/strong>.<\/p>\n

Pues bien, con el protocolo DNS<\/strong> pasa algo parecido, al poderse falsear la direcci\u00f3n de origen f\u00e1cilmente tambi\u00e9n en el protocolo UDP.<\/p>\n

El ataque b\u00e1sicamente se basa en usar un registro de recurso (RR)<\/strong> de tipo TXT<\/strong> lo suficientemente largo como para que se d\u00e9 la amplificaci\u00f3n, de unos 4000 bytes<\/strong> podr\u00eda ser m\u00e1s que suficiente. As\u00ed, para una consulta que puede ser de unos 60 bytes podemos obtener un factor de amplificaci\u00f3n de 66<\/strong>, suponiendo una respuesta de 4000 bytes.<\/p>\n

En el 2002 ya se coment\u00f3 en la lista de gnupg-users la posibilidad de utilizar los registros MX (mail)<\/strong> de algunos servicios de correo grandes. Utilizando este sistema, seg\u00fan m\u00e1s cerca est\u00e9 la respuesta de 512 bytes<\/strong>, sin sobrepasarlo, mayor amplificaci\u00f3n.<\/p>\n

Por ejemplo, con los servidores de hotmail.com<\/strong> se consigue una amplificaci\u00f3n de 9.5<\/strong>, con los de aol.com<\/strong> un factor de 10<\/strong> y con mci.com<\/strong> un 10.2<\/strong>. Aun as\u00ed, la diferencia del tama\u00f1o de la respuesta no es lo suficientemente alarmante.<\/p>\n

La limitaci\u00f3n de este ataque se manifestaba por el l\u00edmite de los 512 bytes del protocolo UDP. S\u00ed una respuesta superara este l\u00edmite se enviar\u00eda por el protocolo TCP, y no funcionar\u00eda.<\/p>\n

Sin embargo en el EDNS0<\/strong> [RFC2671]<\/a> se sugiere que el cliente pueda cambiar el tama\u00f1o m\u00e1ximo del paquete UDP mediante un registro de recurso (RR) llamado OPT<\/strong>. Por lo tanto, basta con buscar un servidor DNS<\/strong> que soporte la extensi\u00f3n EDNS<\/strong>. Bind 9<\/strong> lo soporta, con un l\u00edmite de 4096 bytes<\/strong> de respuesta m\u00e1ximo. Djbdns<\/strong>, sin embargo, no lo soporta<\/strong>. De todas formas, en Bind se puede configurar este tama\u00f1o con la opci\u00f3n edns-udp-size<\/strong>.<\/p>\n

Total, que con una lista de servidores que cumplan esas condiciones, y un registro TXT<\/strong> lo suficientemente grande, bastar\u00eda para poner en apuros a m\u00e1s de uno. Siendo bastante complicada la localizaci\u00f3n del verdadero atacante.<\/p>\n

Las consecuencias<\/strong> del ataque las sufrir\u00edan tanto el servidor DNS<\/strong> como la v\u00edctima<\/strong> del ataque. Para reducir el ataque en el servidor autoritativo del dominio tambi\u00e9n convendr\u00eda que el RR TXT<\/strong> en cuesti\u00f3n tuviera un TTL (Time To Live) alto<\/strong>, para que se cacheara la respuesta en los servidores recursivos utilizados para el ataque.<\/p>\n

Tambi\u00e9n se est\u00e1 discutiendo en las listas la idea de tratar a los \u00abopen resolvers\u00bb<\/strong> (los servidores DNS recursivos de acceso p\u00fablico) como a los \u00abopen relays\u00bb<\/strong>.<\/p>\n

Teniendo en cuenta la inseguridad del protocolo UDP<\/strong>, s\u00f3lo es cosa de tiempo que los atacantes encuentren diferentes protocolos y aplicaciones que utilizar para sus fechor\u00edas.<\/p>\n

A corto plazo no parece que tenga f\u00e1cil soluci\u00f3n. Ya veremos que sucede en el futuro.<\/p>\n

 <\/p>\n

—
\nZz.<\/p>\n

\u00bfQu\u00e9 es Exactamente un Ataque DDos?<\/h2>\n

\"\u00bfQu\u00e9<\/p>\n

Ataque de Denegaci\u00f3n de Servicio<\/strong> ser\u00eda la traducci\u00f3n m\u00e1s acertada de Distributed Denial of Service<\/em>, que son las siglas de DDoS<\/strong>.<\/p>\n

El objetivo de un ataque DDos es, b\u00e1sicamente, que un servidor deje de funcionar para que no pueda seguir funcionando y en servicio<\/em>.<\/p>\n

Sin entrar en complejidades, la forma de actuar de un ataque DDos es muy sencilla. Se trata de enviar muchas peticiones<\/strong>, al mismo tiempo y repetidas veces a un servidor con la intenci\u00f3n de que se sature<\/strong> y deje de funcionar.<\/p>\n

Si nos imaginamos un campo de f\u00fatbol, un hipermercado, o cualquier otro sitio abarrotado de personas queriendo salir al mismo tiempo por la misma salida<\/strong>, podemos comprender, a grandes rasgos, que es un ataque DDos.<\/p>\n

Esto, que en principio parece muy simple, es tremendamente efectivo, ya que no existe servidor capaz de aguantar un n\u00famero descomunal de peticiones<\/strong>. Por muy potente que sea acabar\u00e1, satur\u00e1ndose y dejando de funcionar.<\/p>\n

Adem\u00e1s, el funcionamiento b\u00e1sico 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\u00e1gina principal del sitio, este acabar\u00e1 saturado por intentar atender tantas peticiones.<\/p>\n

Obviamente este ejemplo es muy b\u00e1sico y un ataque DDos funciona de una manera m\u00e1s compleja, usando ordenadores zombies<\/em>, ataques lentos usando una t\u00e9cnica llamada Slow Read<\/em>, etc\u2026<\/p>\n

Hostinet y la Protecci\u00f3n Contra ataque DDoS<\/h2>\n

Como hemos comentado antes, los ataques DDoS no son complicados de realizar en concepto, pero al mismo tiempo, un ataque DDoS<\/strong> b\u00e1sico a cualquiera de los servidores de Hostinet ser\u00eda f\u00e1cilmente detectado y anulado<\/strong>.<\/p>\n

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.<\/p>\n

Estas medidas de seguridad son :<\/p>\n