Los Servidores de DNS de Arnet y Personal estan fallando…

Hace un momento (17/09/08 15:00hs) estaba intentando entrar a la página de Personal, y encuentro que OpenDNS me dice que hay un problema, y al tratar de ver más detalles del tema, me encuentro con esto:

Nameserver trace for www.personal.com.ar:

* Looking for who is responsible for root zone and followed k.root-servers.net.
* Looking for who is responsible for ar and followed ns-ar.ripe.net.
* Looking for who is responsible for com.ar and followed relay1.mecon.gov.ar.
* Looking for who is responsible for personal.com.ar and followed oktubre.arnet.com.ar.

Nameservers for www.personal.com.ar:

* gulp.arnet.com.ar returned (SERVFAIL)
* oktubre.arnet.com.ar returned (SERVFAIL)

Al ver que son los sevidores de DNS de Arnet, intenté con Arnet y obtuve el mismo resultado:

Nameserver trace for www.arnet.com.ar:

* Looking for who is responsible for root zone and followed m.root-servers.net.
* Looking for who is responsible for ar and followed uucp-gw-1.pa.dec.com.
* Looking for who is responsible for com.ar and followed athea.ar.
* Looking for who is responsible for arnet.com.ar and followed oktubre.arnet.com.ar.

Nameservers for www.arnet.com.ar:

* oktubre.arnet.com.ar returned (SERVFAIL)
* gulp.arnet.com.ar returned (SERVFAIL)

Solo para curiosear, decidí desconectarme y reconectarme con los servidores de DNS de Arnet (normalmente uso los de OpenDNS) y al hacerlo, ya nada funciona, bueno, en realidad no se puede es resolver ningún nombre de DNS, por lo que no se puede navegar. Obviamente volví a conectarme con los servidores de OpenDNS y todo anda bien, pero evidentemente Arnet esta teniendo problemas con sus servidores de DNS en este momento, ¿alguien sabe algo al respecto?

Probando un poco más me encuentro con esto:

root@fire01:~ # host www.arnet.com.ar
www.arnet.com.ar has address 67.215.66.132
;; connection timed out; no servers could be reached
;; Warning: ID mismatch: expected ID 36494, got 44158
;; connection timed out; no servers could be reached

Por lo que veo hay problemas con el ID del pedido al server DNS. ¿Estarán cambiando el software de DNS por el famoso problema que hay con los servidores de DNS? (Para saber más del tema, los invito a escuchar mis podcasts 22 y 23 sobre esto), ¿o será que han tenido algún ataque y están corriendo para solucionarlo?.

Estaría bueno que den algo de información y que esto no quede como que “acá no pasó nada”.

PD: Me imagino que las lineas de soporte técnico de Arnet deben estar al rojo vivo en este momento.

ACTUALIZACION: Parece que ya se arregló.

el podcast de pablot – Episodio 23 – El problema del DNS (parte 2)

Vamos a retomar el tema del último podcast y ahondaremos un poco más en el problema, pero a su vez vamos a tratar de explicar brevemente que es lo que esta vulnerabilidad permite hacer a un atacante. Pero esta vez lo haremos en forma mucho más simple y sencilla, sin entrar en los aspectos técnicos del problema, para permitir que quienes no sean técnicos puedan comprenderlo sin quedar a mitad de camino.

Descargar: el podcast de pablot – Episodio 23 – El problema del DNS (parte 2)

Links adicionales: DNS, DNS Cache poisoning, Dan Kaminsky, OpenDNS, Blog de Dan Kaminsky donde se puede chequear el DNS, Otro sitio para chequear el DNS, Excelente explicación sobre la vulnerabilidad del DNS

el podcast de pablot – Episodio 22 – HOUSTON: Tenemos un problema con el DNS

A estas alturas nadie que se mueva en un ambiente técnico esta ajeno al gran problema que se ha presentado con el servicio de DNS, por lo que en este episodio del podcast, vamos a tratar de explicar de que se trata este problema

Es sin duda uno de los episodios más técnicos que hemos tenido hasta ahora, por lo que también es probable que sea el que más errores tenga. Más allá de los errores técnicos que pueda haber cometido en la explicación (hay una suerte de fe de erratas sobre el final), la idea no es que sea una clase magistral y detallada del problema, sino una explicación los más entendible posible sobre el tema.

Vamos a ver que es el servicio de DNS, que protocolo IP usa y porque, y en que consiste el ataque del que todos hablan.

No debemos perder de vista el real problema, ya que más allá del problema técnico en si con el DNS, lo más serio es que una vez suplantado o envenenado un servidor de DNS, todos los servicios de Internet que lo utilicen (web, email, ftp, etc.), pueden ser redireccionados a servidores falsos.

Descargar: el podcast de pablot – Episodio 22 – HOUSTON: Tenemos un problema con el DNS

Links adicionales: DNS, DNS Cache poisoning, Dan Kaminsky, OpenDNS, Blog de Dan Kaminsky donde se puede chequear el DNS, Otro sitio para chequear el DNS, Excelente explicación sobre la vulnerabilidad del DNS

Servidores de DNS de OpenDNS:

• 208.67.222.222

• 208.67.220.220

DNS en terapia intensiva

A estas alturas no va a ser novedad para nadie que este más o menos en tema, el serio problema que se ha detectado en el servicio de DNS.

Haciendo un breve resumen, el tema es que existe una vulnerabilidad que ya se conocía desde hace mucho tiempo, pero que desde hace unos meses un investigador y experto en seguridad, Dan Kaminsky, detectó que el problema es más serio de lo que parecía.

En pocas palabras, el problema esta dado porque se pueden hacer ataques de envenenamiento de cache de DNS (DNS cache poisoning) de forma mucho más rápida (por lo tanto más efectiva) de lo que se pensaba. Es por esto que Dan junto a varias empresas ha estado trabajando en un parche para minimizar el problema, ya que no se puede resolver directamente porque esta derivado de un problema de diseño del sistema de DNS y no de un simple bug que pueda ser corregido.

El descubrimiento de Dan ha demostrado que se puede tomar el control de un servidor de DNS en un tiempo que va de unos 30 segundos a 2 minutos. Para decirlo en términos simples el parche que ha desarrollado Dan junto a varias empresas, consiste en evitar que el ataque pueda ser realizado rápidamente para evitar que sea tan efectivo; evitando que el ataque pueda ser perpetrado en solo dos minutos. Pero el problema es serio y de ninguna manera el parche logra eliminar el riesgo.

Otro investigador, Evgeniy Polyakov, ha demostrado que esta lentificación que lograba el parche no lo ha lentificado tanto como creían, ya que fue posible tomar el control de un servidor de DNS en unas 10 horas (pero contando con cierta ventaja, como una red de Gb y una máquina con un troyano).

Ahora bien, debido a esto se han comenzado a ver titulares que dicen que el parche no sirve. Esto no es cierto, el parche si sirve, ya que aunque el ataque tarda 10 horas en ser efectivo, es mucho mejor eso a tan solo dos minutos.

El trabajo de Evgenly es muy bueno, pero de ninguna manera invalida la efectividad del parche desarrollado por Dan y su equipo, tan solo demuestra que no tiene toda la efectividad que se pensaba, pero no me parece que se pueda afirmar que el parche no resuelve el problema, ya que eso lo dijo el mismo Dan.

Si quieren saber más sobre el problema en cuestión, esperen a la próxima edición del podcast, ya que nos vamos a meter de lleno en el problema para tratar de explicarlo de la forma más sencilla posible. Espero que se entienda, ya que seguramente va ser el episodio más técnico que hayamos tenido hasta el momento.