====== 207.3 Securing a DNS server ====== Pertenece a [[informatica:certificaciones:lpic:lpic-2:207_domain_name_server|Topic 207: Domain Name Server]] * **Weight**: 2 * **Description**: Candidates should be able to configure a DNS server to run as a non-root user and run in a chroot jail. This objective includes secure exchange of data between DNS servers. * **Key Knowledge Areas**: * BIND 9 configuration files * Configuring BIND to run in a chroot jail * Split configuration of BIND using the forwarders statement * Configuring and using transaction signatures (TSIG) * Awareness of DNSSEC and basic tools * Awareness of DANE and related records * **Terms and Utilities**: * ''/etc/named.conf'' * ''/etc/passwd'' * DNSSEC * ''dnssec-keygen'' * ''dnssec-signzone'' ===== 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. * [[https://wiki.debian.org/Bind9|Bind9 en la Wiki de Debian]] 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í: {{ :informatica:certificaciones:lpic:lpic-2:207_domain_name_server:dns-estructura-ficheros-chroot.png?nolink |}} 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 * [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/devices.txt|Lista de dipositivos con su nombre, tipo y números mayor y menor]]. 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 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: firma los mensajes enviados por los servidores DNS utilizando una MAC (//Message Authentication Code//). Utilizan cifrado asimétrico ''dnssec-keygen'' es el comando que genera las claves. * ''-a algoritmo'': Algoritmo de cifrado HMAC-MD5, DSA, RSA * ''-b size'': Tamaño de la clave * ''-n nametype'': ''ZONE|HOST|ENTITY|USER|OTHER'' dnssec-keygen –a [ HMAC-MD5 ] –b 512 –n HOST dns1 ZONE lpic2.org Genará dos ficheros: * ''Kdns1.+157+21526.key'' (clave pública) * ''Kdns1.+157+21526.private'' (clave privada) ''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 ==== **T**ransaction **SIG**nature, firma de transacciones. * Se basa en el uso de una clave compartida entre los servidores que intercambian datos. * Proporciona un canal seguro de comunicación entre los servidores DNS para la transferencia de zonas. 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: * ''Ksupersecret.+157+26824.key'' * ''Ksupersecret.+157+26824.private'' 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; }; };