SOBRE LA SEGURIDAD DE LOS SERVIDORES DNS Y LA TOPOLOGÍA DE LA RED

Jan 29th, 2010 | Posted by | Filed under Linux, Redes, Seguridad

Muchas veces, la seguridad no se obtiene teniendo la última versión de cada servicio corriendo en la DMZ, sino manteniendo una topología de red adecuada que minimize el impacto de cualquier 0-day que pueda surgir.

En concreto, vamos a fijarnos en este advisory del que es el DNS más usado, BIND:

BIND 9.5.2-P2 is a SECURITY PATCH for BIND 9.5.2. It addresses two potential cache poisoning vulnerabilities, both of which could allow a validating recursive nameserver to cache data which had not been authenticated or was invalid.

Como podéis leer, la vulnerabilidad es bastante importante (cahe poisoning, que significa que pueden sobreescribir registros del cache del servidor DNS) y requiere atención inmediata. Dicha vulnerabilidad, según explican, ha sido introducida en un parche que corrige vulnerabilidades anteriores.

En este artículo, vamos a repasar una posible forma de disponer los servidores DNS que minimiza el impacto de cualquier vulnerabilidad, en concreto la arriba mencionada.

Antes de empezar, notar que la instalación de un servidor DNS con BIND es totamente trivial. Puede hacerse en una máquina virtual que corra cualquier distribución linux en cuestión de segundos, y luego dicha VM puede copiarse/pegarse en otro servidor que corra, por ejemplo, VMware. El balanceo de las peticiones DNS puede hacerse en el firewall. Así pues, el trabajo para disponer de una buena infraestructura de resolución de nombres no es demasiado grande.

(1) Consultas DNS de la intranet

Todos los clientes de la intranet deben poder resolver peticiones no sólo de servidores internos sino también, por ejemplo en caso de que salgan por HTTP vía proxy, de direccones de internet, como pueda ser www.marca.com o www.elpais.es.

Deberemos tener un servidor DNS que salga a internet a hacer dichas peticiones, pero que no pueda consultarse desde internet. Es decir, nadie de internet debe poder hacer peticiones a este servidor.

(2) Consultas DNS desde la DMZ

Pueden usar el mismo servidor que la intranet. No hay necesidad de complicarlo más.

(3) Consulta desde internet de nuestras zonas.

Aquí es donde está el principal problema … Un servidor que responda a peticiones de internet para resolver nombres de nuestra empresa NO DEBE JAMÁS responder a ninguna otra cosa. No debe permitir consultas recursivas – en el caso de un ISP esto no puede ser, pero normalmente sí es posible. Y no debe usarse para salir a internet. Además, por supuesto, debe tener todas las transferencias de zona cerradas.

Un servidor que resuelve la zona miempresa.com desde internet debería hacer sólo eso y punto.
Replicación entre servidores
Es una práctica bastante común que para actualizar los servidores se disponga de uno que es el “master” y el resto se definan como “esclavos”. Los esclavos cada cierto tiempo consultan al master y se transfieren las zonas. Esto, que parece muy cómodo, puede ser un problema, ya que podrían enviarnos actualizaciones desde sitios maliciosos, impersonando al servidor master, e infectando la caché del servidor esclavo.
¿Y quién necesita esto?
La forma más fácil, rápida y segura de actualizar un servidor DNS con BIND es meter una tarea en el cron que haga un rsync del directorio /var/named y luego reinicie el servicio. Nada de definir esclavos, nada de transferencias de zona, ni de cache poisoing de este tipo … Se toca uno de los servidores y se hace un rsync a los demás. Tan fácil como eso.

Aparte, como no tenemos transferencias de zona, cerramos el puerto 53/TCP (el UDP es el de las consultas normales y el TCP para consultas muy grandes – innecesario – o transferencias de zona) desde todo salvo los admins y asunto liquidado.

A veces, la topología de red lo es todo.

Share
Comments are closed.