-->
42

Tag Archives: DNS poisoning

Cómo parchear BIND9 contra cache poisoning en Debian Etch

0
Filed under Uncategorized
Tagged as , , , , , , , ,

Ok, ya les conté cómo venía la mano del ataque descubierto por Dan Kaminsky, muchos links a diversas fuentes de exploits, y sitios donde verificar si sus DNS están seguros o son vulnerables.
Ahora les traigo desde HowtoForge.com un tutorial para parchear BIND9 y evitar este tipo de ataque.

Ante todo: el artículo original en ingles es de Falko Timme <ft [at] falkotimme [dot] com>.

[1] Verificar su nuestro BIND es vulnerable.

Ejecuten este comando contra sus servidores de nombres para ver si son vulnerables (reemplazar ns1.ejemplo.com por sus correspondientes servidores):

dig +short @ns1.ejemplo.com porttest.dns-oarc.net TXT

# dig +short @ns1.example.com porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“1.2.3.4 is POOR: 26 queries in 4.4 seconds from 1 ports with std dev 0.00″

Si les devuelve POOR, significa que BIND es vulnerable. Si es el caso, tienen que parchear BIND.

Si no reciben ninguna respuesta, significa que su server de DNS no resuelve recursivamente, lo que significa que no responde consultas para dominios para los que no es autoridad. En este caso no son vulnerables al cache poisoning, pero de todas formas les sugiero que realmente parcheen BIND.

[2] Parchear BIND.

Falsificación de DNS de Kaminsky (en Matasano)

0
Filed under Uncategorized
Tagged as , , , ,

Primero lo primero: Esto no es mío. Es solo una traduccción de este post en el blog de mi buen amigo Buanzo -a quien le robo noticias seguido, solo que las publico más tarde, en castellano, y con mayor porcenataje de errores ortográficos XD-.

Sacado de Barrapunto:

La idea básica del ataque, que puede considerarse a estas alturas de dominio público, es la combinación de DNS Forgery y DNS RRset poisoning. Se trata de conseguir, mediante la repetición de peticiones, que un servidor DNS acepte como respuesta legítima una respuesta ilegítima de nivel 3, y que ésta incluya información sobre la IP de otros dominios de nivel 3 del mismo dominio de nivel 2. En otras palabras, si se consigue que el servidor acepte como válido un paquete que le dice que xhstrn.google.com tiene como IP 1.2.3.4, aceptará como válida cualquier información adicional sobre google.com: www.google.com, mail.google.com, etc. Fascinante.

La explicación completa:

Falsificación efectiva de DNS en el 2008: Un descubrimiento de Kaminsky, en Matasano Chargen, escrito por ecopeland.

[0] El gato se escapó de la bolsa (nota de traducción: no me convence esta frase en castellano). Sí, Halvar Flake se dio cuenta de la falla que Dan Kaminsky va a anunciar en la Black Hat.