Vulnerabilidad y Solución de BIND 9 - Parchear BIND Para Evitar el Envenenamiento de Caché (Fedora/CentOS)

Estoy bastante seguro de que la mayoría de ustedes han oído hablar de la vulnerabilidad en BIND. Dan Kaminsky, a principios de este mes, anunció un problema masivo y multivendor con DNS que podría permitir a los atacantes comprometer cualquier servidor de nombres, incluidos los clientes.

Pensé que compartiría con todos ustedes una de las soluciones más rápidas que los administradores de sistemas que ejecutan BIND 9 pueden usar para ayudar a resolver esta vulnerabilidad en caso de que sus sistemas sean vulnerables.

Después de 3 días de pruebas y experimentando con mis servidores DNS, descubrí algo que parecía resolver mi problema, por lo que decidí compartirlo con todos ustedes.

No estoy seguro de si esto realmente resolvió el problema, aunque ha funcionado para mí ya que los resultados de las pruebas son excelentes. Pero sus sugerencias y comentarios son bienvenidos.

Mi hallazgo, por simple que parezca, solo se aplica a aquellos que ejecutan BIND 9 en CentOS 4 o 5 y sistemas Fedora Core y superiores… probé en todas estas máquinas en mi oficina.

Comencemos… ¿de acuerdo?

Requisitos Previos y Suposiciones

Su firewall (iptables NAT/PAT o PIX) debe tener el puerto 53 abierto de tal manera que permita la selección de puertos aleatorios.
Debe estar ejecutando BIND 9 en CentOS 4 o 5 o en cualquier sistema Fedora Core.
BIND debe estar ejecutándose en modo chroot, aunque no es un requisito previo, sino una buena práctica.
En sus archivos /etc/named/named.conf O /etc/named.conf…. Se debe deshabilitar la consulta recursiva y también agregar un acl para permitir solo a sus redes realizar solicitudes recursivas. Con esto, el administrador del sistema habrá reducido las posibilidades de envenenamiento de caché a sus propias redes conocidas.

acl "mynetworks" {
         127/8;  172.16.0.0/12;  10.0.0.0/8;  192.168.0.0/16

view "internal" {
         match-clients { mynetwork; };
         allow-query { mynetwork; };
         allow-recursion { mynetwork; };
         match-recursive-only yes;

view "external" {
         match-clients { any; };
         allow-query { any; };
         allow-recursion { none; };
         match-recursive-only no;

Y Ahora Para Arreglar La Vulnerabilidad de BIND

El primer paso es que uno verifique si su sistema es vulnerable… ejecutando los comandos a continuación, reemplazando ns1.youdomain.co.tz con el TLD o ccTLD de su organización.

dig +short @ns1.youdomain.co.tz 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.
“192.168.1.3 es POBRE: 26 consultas en 20.0 segundos desde 1 puertos con desviación estándar 0.00”

POBRE —–> definitivamente indica que el servidor de nombres o sistema en cuestión es vulnerable y, por supuesto, el software BIND que se está ejecutando también es antiguo y necesita ser PARCHEADO …

Solución

Para aquellos que ejecutan sistemas CentOS O Fedora….. se puede usar yum para parchear los sistemas. Los desarrolladores de CentOS 5 ya han lanzado un parche para el software BIND y el actual es: bind-9.3.4-6.0.2.P1.el5_2. P1 indica que el paquete está parcheado.

En mis sistemas, después de parchear, obtuve este resultado..

rpm -q bind

bind-9.3.4-6.0.2.P1.el5_2 —-> si su versión de bind no está parcheada… entonces páchelo.

Uno debe hacer esto para obtener el software más reciente y el parche.

yum update bind bind-chroot -y

Uno debe editar su archivo named.conf y agregar lo siguiente. Guarde y recargue BIND.

 vi /etc/named.conf

options {
         directory "/var/named";
         allow-transfer {192.168.1.4 ;};
         query-source   address * port 53; ##COMENTAR o ELIMINAR ESTA LÍNEA.

Esto permitirá la selección de puertos aleatorios. Solo haga esto si este parámetro está habilitado en las opciones de su archivo named.conf.

         dnssec-enable yes;                        ## AÑADA ESTA OPCIÓN PARA HABILITAR DNS-SEC.

La línea anterior, cuando se agrega a su archivo named.conf, habilitará DNS-SEC. Adelante, configure DNS-SEC, pero recuerde que DNS-SEC no es una solución definitiva para esta vulnerabilidad. **

Recargue o reinicie BIND.

/etc/init.d/named reload

Luego pruebe nuevamente para ver si obtiene un mejor resultado.

dig +short @ns1.youdomain.co.tz porttest.dns-oarc.net TXT

Solo para confirmar… :-)

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.
“192.168.1.3 es BUENO: 26 consultas en 19.6 segundos desde 26 puertos con desviación estándar 16515.27”

BUENO indica que el servidor de nombres en cuestión en 192.168.1.3 parece estar seguro, pero uno debe asegurarse de que los puertos listados no sigan un patrón obvio. es decir, los puertos con desviación estándar.. 16515.27… Pero si su prueba marca (10000.00 desviación estándar) entonces su servidor DNS es más seguro y sus clientes o usuarios no deberían preocuparse.

El mismo procedimiento debe llevarse a cabo en todos los servidores DNS de su organización.