Tabla de Contenidos

207.3 Securing a DNS server

Pertenece a Topic 207: Domain Name Server

Limitar los accesos al servidor

Para limitar los hosts o las redes que tienen acceso al servidor podemos definir acls (listas de control de acceso): 

acl "permitidos" {
    localhost;
    192.168.10.10;
    192.168.30.0/24;
};

El nombre que hemos usado (“permitidos”) nos servirá a continuación para establecer reglas, facilitando la administración.

Limitar las Consultas simples

Para limitar los hosts o las redes a los que el servidor tiene permitido responder: 

allow-query {
    redes_autorizadas;
}

Por ejemplo: 

allow-query { 
    10.0.0.34; # Servidor DNS
    permitidos;
};

Estas reglas las pondríamos en el fichero named.conf.options ya que son opciones de configuración.

Limitar Tranferencias de zonas

Una transferencia de zona es la solicitud de información sobre un dominio que utilizan los servidores secundarios para actualizar su propia base de dtos del dominio.

La transferencia siempre va desde el maestro a los esclavos. Las modificaciones se producen en el maestro. Los esclavos solo almacenan copias.

Para securizar e impedir que por otros mecanismos se solicite esa información, se debería limitar la solicitud de transferencias a los servidores secundarios que conocemos.

Para indicar los hosts a los que el servidor master tiene permitido las transferencia de las zonas: 

allow-transfer { … };

En la zona master, pondríamos una lista de direcciones IP de servidores esclavos. En nuestra zona esclava pondríamos None. De esta manera solo los esclavos harán transferencia de zona desde el maestro, pero desde los esclavos nadie podrá hacer transferencia de zona.

Ejecución del Servicio con un cuenta NO-ROOT

En los orígenes, era frecuente ejecutar un servidor bind con la cuenta de administración root.

La ejecución del servicio con el usuario named o bind evita que el proceso tenga privilegios de superusuario. Actualmente esto funciona así, pero si quisiéramos arrancar el servicio de bind con un usuario específico: 

named –u named –g named

Bind en modo chroot

El objetivo es hacer creer al proceso que se está ejecutando en un sistema normal, mientras está enjaulado en una estructura de directorio paralela.

En sistemas Red Hat (como CentOS) si instalamos el paquete bind-chroot hace que bind se ejecute en una jaula, con lo cual todo estaría en el directorio /var/named/chroot/

Estructura de directorios

Lo primer es crear un directorio de chroot (/var/bind9/chroot).

Creación de la estructura de directorios falsa / en el directorio chroot. Todos los directorios utilizados por el proceso named deben aparecer ahí: 

mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}

Copia de ficheros y permisos

Copiar los archivos de configuración, zona y aplicación al directorio chroot (/var/bind9/chroot): 

cp -r /etc/bind /var/bind9/chroot/etc

También aprovechamos para copiar /etc/localtime para que BIND registre el tiempo correcto en los registros: 

cp /etc/localtime /var/bind9/chroot/etc/

En Debian 10 bind también requiere /usr/share/dns (contiene información de los servidores DNS raíz): 

mkdir -p /var/bind9/chroot/usr/share/dns
cp /usr/share/dns/* /var/bind9/chroot/usr/share/dns/

Configuración de permisos de la estructura chroot: 

chown bind:bind /var/bind9/chroot/etc/bind/rndc.key
chmod 775 /var/bind9/chroot/var/{cache/bind,run/named}
chgrp bind /var/bind9/chroot/var/{cache/bind,run/named}

Cremos los ficheros de dispositivo (/dev) necesarios: 

mknod /var/bind9/chroot/dev/null c 1 3
mknod /var/bind9/chroot/dev/random c 1 8
mknod /var/bind9/chroot/dev/urandom c 1 9

Modificamos los permisos de estos ficheros recién creados: 

chmod 660 /var/bind9/chroot/dev/{null,random,urandom}

Ejecución del servicio en chroot

named –c /var/named/etc/named.conf –u named –d /var/named

De esta manera, si alguien lograse tomar el control de este bind, no podría acceder al resto del sistema, solo en esta jaula.

En sistemas con systemd, por ejemplo Debian 10, editamos el fichero /etc/default/bind9: 

OPTIONS="-u bind -t /var/bind9/chroot"

En Debian 10 se incluye AppArmor, así que necesitamos indicarle que nos deje acceder a ciertos directorios. Creamos el fichero /etc/apparmor.d/local/usr.sbin.named con el contenido: 

/var/bind9/chroot/etc/bind/** r,
/var/bind9/chroot/var/** rw,
/var/bind9/chroot/dev/** rw,
/var/bind9/chroot/run/** rw,
/var/bind9/chroot/usr/** r,

Y descomentamos la siguiente línea de /etc/apparmor.d/usr.sbin.named: 

include <local/usr.sbin.named>

Recargamos AppArmor: 

systemctl reload apparmor

Ya podríamos arracancarlo con: 

systemctl start bind9

Y se ejecutará en la jaula creada.

Securizando las conexiones

El diseño original del Domain Name System (DNS) no incluía la seguridad, sino que fue diseñado para ser un sistema distribuido escalable.

DNSSEC

Las Extensiones de seguridad para el Sistema de Nombres de Dominio (DNSSEC) intentan aumentar la seguridad. Usamos cifrado asimétrico (claves privadas y públicas) con las que firmaremos las peticiones y las respuestas del DNS para saber que vienen de donde deben venir.

DNSSEC fue diseñado para proteger a los resolvers de Internet (clientes) de datos de DNS falsificados, tales como los creados por envenenamiento de caché DNS.

Todas las respuestas en DNSSEC son firmadas digitalmente.

dnssec-keygen es el comando que genera las claves. 

dnssec-keygen –a [ HMAC-MD5 ] –b 512 –n HOST dns1 ZONE lpic2.org

Genará dos ficheros:

dnssec-sigzone: Realiza el firmado de una zona. Genera los registros NSEC y RRSIG, y crea una versión firmada de la zona. 

dnssec-sigzone –o example.com db.micasa.local

Obtenemos un fichero db.micasa.local.signed

TSIG

Transaction SIGnature, firma de transacciones.

Maestro y esclavo intercambian unas claves para confirmar que la transferencia de zonas es correcta.

Primero se generan las claves con el comando dnssec-keygen: 

dnssec-keygen -a HMAC-MD5 -b tamaño_de_clave -n nametype nombreclave
Parámetros Descripción
-a HMAC-MD5 -a define el algoritmo de cifrado. HMAC-MD5 es el único valor soportado para TSIG.
-b tamaño_de_clave -b define el tamaño de la clave usada. Para HMAC-MD5, tamaño_de_clave tiene que estar comprendido entre 1 y 512. 128 es un valor corriente generalmente satisfactorio.
-n nametype -n define la propiedad de la clave. En su uso para TSIG, generalmente nametype tiene el valor HOST para indicar que la seguridad va de máquina a máquina.
nombreclave El nombre de la clave. Puede ser cualquier cadena alfanumérica.

Ejemplo: 

dnssec-keygen -a HMAC-MD5 -b 128 -n HOST supersecret

Salida:

Una vez tenemos la claves, debemos declararlas en el fichero named.conf: 

key nombre_clave {
    algorithm hmac-md5;
    secret "yItYGlAQtGcM7VqGjZdJAg==";
};
Elemento Descripción
key Inicia la declaración de la clave.
nombre_clave El nombre de la clave utilizada en la generación.
algorithm Tiene como parámetro el tipo de algoritmo usado.
hmac-md5 Obligatorio para TSIG.
secret Tiene como parámetro la clave generada en el archivo Knombreclave.+xxx.yyyyy.key (la cadena de caracteres entre comillas dobles).

La clave compartida se declara en ambos servidores. Ahora hay que hacer que sepan que tienen que utilizarla para garantizar la seguridad de ciertas comunicaciones. Por lo tanto, habrá que añadir un nuevo comando en named.conf: 

server ip_dest {
   keys { nombre_clave; };
};
Elemento Descripción
server Anuncia un modo de comportamiento para un servidor determinado.
ip_dest La dirección IP del servidor para el que se aplica esta directiva.
keys Establece la clave utilizada para asegurar los intercambios.
nombre_clave El nombre de la clave utilizada en la generación.

Si generamos el fichero tsig.key, debemos incluirlo en el fichero de configuración named.conf: 

include "/var/named/tsig.key"

Recargamos la configuración: 

rndc reload

En el servidor esclavo debemos realizar los mismos pasos, aunque cambiando la IP por la del master: 

key "TRANSFER" {
    algorith hmac-md5;
    secret "asdf89uas9dfuasikdf==";
};

#nameserver1 (master)

server 10.0.1.1 {
    key { 
        TRANSFER;
    };
};