Cómo parchear BIND9 contra el envenenamiento de caché DNS en Debian Etch

Versión 1.0
Autor: Falko Timme

Este artículo explica cómo puedes arreglar un servidor de nombres BIND9 en un sistema Debian Etch para que ya no sea vulnerable al envenenamiento de caché DNS.

¡Este documento se proporciona sin garantía de ningún tipo! ¡No emito ninguna garantía de que esto funcione para ti!

1 Comprobando si BIND es vulnerable

Ejecuta el siguiente comando contra tu servidor de nombres para averiguar si es vulnerable (reemplaza ns1.example.com con la dirección de tu propio servidor de nombres):

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

mh1:~# 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 es POBRE: 26 consultas en 4.4 segundos desde 1 puertos con desviación estándar 0.00”
mh1:~#

POBRE indica que BIND es vulnerable. En este caso, debes parchear BIND.

Si no obtienes ninguna respuesta, esto significa que tu servidor DNS no es un resolvedor recursivo, lo que significa que no responde consultas para dominios para los que no es autoritativo. En este caso, no eres vulnerable al envenenamiento de caché, pero aún así te aconsejo encarecidamente que actualices BIND.

2 Parcheando BIND

Esto no es tanto un parche, sino una actualización. Simplemente ejecuta

apt-get install bind9 bind9-host

Esto instalará los paquetes BIND actualizados desde los repositorios de Debian.

Después, abre /etc/bind/named.conf y modifica la sección de opciones. Si no necesitas un resolvedor recursivo (es decir, si tu servidor de nombres solo debe responder consultas para dominios de los que es responsable), agrega allow-recursion { none; };. De esa manera desactivas la caché para otros dominios. La segunda línea que debes agregar es dnssec-enable yes; - esto hace que BIND responda consultas en puertos aleatorios que son más difíciles de adivinar para los hackers (recuerda la respuesta a nuestro comando dig en el capítulo 1: […]26 consultas en 4.4 segundos desde 1 puertos[…] - BIND estaba respondiendo solo en un puerto…).

Corrección: Acabo de recibir el siguiente correo electrónico de Alan Clegg:

¡Buen día! Acabo de leer tu artículo en: https://www.howtoforge.com/how-to-patch-bind-to-avoid-cache-poisoning-debian-etch y tengo un par de comentarios. Primero, gracias por escribir esto. Necesitamos que tantas personas como sea posible solucionen este problema. En segundo lugar, hay un error menor que debe corregirse. Dices: “La segunda línea que debes agregar es dnssec-enable yes; - esto hace que BIND responda consultas en puertos aleatorios que son más difíciles de adivinar para los hackers” En realidad, esta línea habilita al servidor para responder con registros DNSSEC cuando el bit “DO” (DNSSEC OK) está establecido en la pregunta que se está haciendo. Lo que quieres que la gente busque es una declaración como: query-source […] port XX; Donde el XX es un número de puerto fijo en el que se enviarán las consultas desde este sistema. Esto deshace todo lo que las nuevas versiones de BIND hacen para aleatorizar el puerto de origen UDP. Si tienes alguna pregunta, no dudes en enviar un correo electrónico. Alan Clegg
Internet Systems Consortium (ISC)
Capacitación y Soporte

vi /etc/bind/named.conf

| [...] options { pid-file "/var/run/bind/run/named.pid"; directory "/etc/bind"; auth-nxdomain no; allow-recursion { none; }; dnssec-enable yes; /* * Si hay un firewall entre tú y los servidores de nombres con los que deseas * hablar, es posible que necesites descomentar la directiva query-source * a continuación. Las versiones anteriores de BIND siempre hacían * preguntas usando el puerto 53, pero BIND 8.1 usa un puerto no privilegiado * por defecto. */ // query-source address * port 53; }; [...] |

Reinicia BIND después:

/etc/init.d/bind9 restart

(Si estás usando ISPConfig, tus cambios serán sobrescritos por ISPConfig. Para evitar esto, tomamos el archivo de plantilla named.conf /root/ispconfig/isp/conf/named.conf.master, lo modificamos como se muestra arriba y guardamos la plantilla modificada en el directorio /root/ispconfig/isp/conf/customized_templates => /root/ispconfig/isp/conf/customized_templates/named.conf.master. También debes modificar /etc/bind/named.conf como se muestra arriba además de eso.)

3 Comprobando BIND de nuevo

Ahora ejecutamos la consulta del capítulo 1 nuevamente:

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

Si todo salió bien, ahora debería mostrar BUENO en lugar de POBRE, y debería usar más de un puerto:

mh1:~# 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 es BUENO: 26 consultas en 4.4 segundos desde 26 puertos con desviación estándar 20195.32”
mh1:~#

¡Felicidades, acabas de arreglar BIND!

También puedes ejecutar el comando dig contra los servidores de nombres de tu ISP para averiguar si sus servidores de nombres aún son vulnerables. Si lo son, ¡deberías instar a tu ISP a actualizar sus servidores de nombres!