Diferencias

Muestra las diferencias entre dos versiones de la página.

--- informatica:certificaciones:lpic:lpic-2:207_domain_name_server:207.3 [2021/04/12 12:15] – tempwin
+++ informatica:certificaciones:lpic:lpic-2:207_domain_name_server:207.3 [2021/04/23 13:51] (actual) – [TSIG] tempwin
@@ Línea 16: / Línea 16: @@
     * ''/etc/passwd''
     * DNSSEC
-    * dnssec-keygen
+    * ''dnssec-keygen''
-    * dnssec-signzone
+    * ''dnssec-signzone''
 ===== Limitar los accesos al servidor ====
@@ Línea 36: / Línea 36: @@
 Para limitar los hosts o las redes a los que el servidor tiene permitido responder:
+<code>
+allow-query {
+    redes_autorizadas;
+}
+</code>
+Por ejemplo:
 <code>
@@ Línea 48: / Línea 56: @@
 ===== 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
+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.
@@ Línea 72: / Línea 82: @@
 ===== Bind en modo chroot =====
-El objetivo es hacer creer al proceso se está ejecutando en un sistema normal, mientras está enjaulado en una estructura de directorio paralela.
+El objetivo es hacer creer al proceso que se está ejecutando en un sistema normal, mientras está enjaulado en una estructura de directorio paralela.
-Lo primer es crear un directorio de chroot (''/var/named'').
+  * [[https://wiki.debian.org/Bind9|Bind9 en la Wiki de Debian]]
+<WRAP center round info 60%>
+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/''
+</WRAP>
+==== 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í:
@@ Línea 80: / Línea 97: @@
 {{ :informatica:certificaciones:lpic:lpic-2:207_domain_name_server:dns-estructura-ficheros-chroot.png?nolink |}}
-Copiar los archivos de configuración al directorio chroot (''/var/named'').
+<code bash>
+mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}
+</code>
-Ejecución del proceso en modo chroot:
+==== Copia de ficheros y permisos ====
+Copiar los archivos de configuración, zona y aplicación al directorio chroot (''/var/bind9/chroot''):
+<code bash>
+cp -r /etc/bind /var/bind9/chroot/etc
+</code>
+También aprovechamos para copiar ''/etc/localtime'' para que BIND registre el tiempo correcto en los registros:
+<code bash>
+cp /etc/localtime /var/bind9/chroot/etc/
+</code>
+En Debian 10 **bind** también requiere ''/usr/share/dns'' (contiene información de los servidores DNS raíz):
+<code bash>
+mkdir -p /var/bind9/chroot/usr/share/dns
+cp /usr/share/dns/* /var/bind9/chroot/usr/share/dns/
+</code>
+Configuración de permisos de la estructura chroot:
+<code bash>
+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}
+</code>
+Cremos los ficheros de dispositivo (''/dev'') necesarios:
+<code bash>
+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
+</code>
+  * [[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:
+<code bash>
+chmod 660 /var/bind9/chroot/dev/{null,random,urandom}
+</code>
+==== Ejecución del servicio en chroot ====
 <code bash>
@@ Línea 90: / Línea 154: @@
 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'':
+<code>
+OPTIONS="-u bind -t /var/bind9/chroot"
+</code>
+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:
+<code>
+/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,
+</code>
+Y descomentamos la siguiente línea de ''/etc/apparmor.d/usr.sbin.named'':
+<code>
+include <local/usr.sbin.named>
+</code>
+Recargamos AppArmor:
+<code bash>
+systemctl reload apparmor
+</code>
+Ya podríamos arracancarlo con:
+<code bash>
+systemctl start bind9
+</code>
+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.
-• Las Extensiones de seguridad para el Sistema de Nombres de
-Dominio (DNSSEC) intentan aumentar la seguridad.
+==== DNSSEC ====
-• DNSSEC fue diseñado para proteger a los resolvers de Internet
-(clientes) de datos de DNS falsificados, tales como los creados por
+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.
-envenenamiento de caché DNS.
-• Todas las respuestas en DNSSEC son firmadas digitalmente.
+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**.
-Securizando las conexiones:
-DNSSEC: firma los mensajes enviados por los servidores DNS utilizando una
+Todas las respuestas en DNSSEC son firmadas digitalmente.
-MAC (Message Authentication Code). Utilizan cifrado asimétrico
-dnssec-keygen: comando que genera las claves.
+  * DNSSEC: firma los mensajes enviados por los servidores DNS utilizando una MAC (//Message Authentication Code//). Utilizan cifrado asimétrico
-- a algoritmo Algoritmo de cifrado HMAC-MD5, DSA, RSA
--b size Tamaño de la clave
+''dnssec-keygen'' es el comando que genera las claves.
--n nametype ZONE|HOST|ENTITY|USER|OTHER
-#dnssec-keygen –a [ HMAC-MD5 ] –b 512 –n HOST dns1
+  * ''-a algoritmo'': Algoritmo de cifrado HMAC-MD5, DSA, RSA
-OUTPUT: Kdns1.+157+21526.key ZONE lpic2.org
+  * ''-b size'': Tamaño de la clave
-Kdns1.+157+21526.private
+  * ''-n nametype'': ''ZONE|HOST|ENTITY|USER|OTHER''
-Securizando las conexiones:
-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.example
-OUTPUT: db.example.com.signed
-Securizando las conexiones:
-TSIG (Transaction SIGnature, firma de transacciones):
-• Se basa en el uso de una clave compartido entre los
-servidores que intercambian datos.
-• Proporciona un canal seguro de comunicación entre los
-servidores DNS para la transferencia de zonas.
-Securizando las conexiones:
-.Generamos las claves:
 <code bash>
-dnssec-keygen -a HMAC-MD5 -b 512 -n HOST rndc-key
+dnssec-keygen –a [ HMAC-MD5 ] –b 512 –n HOST dns1 ZONE lpic2.org
 </code>
-Salida:
+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.
 <code>
-Krndc-key.+157+21526.key
+dnssec-sigzone –o example.com db.micasa.local
-Krndc-key.+157+21526.private
 </code>
-. Una vez tenemos la claves, debemos declararlas en el fichero ''named.conf'' directamente, o crear un fichero ''tsig.key'' e incluirla dentro junto a las IP de los dns esclavos:
+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'':
 <code>
-key "TRANSFER" {
+dnssec-keygen -a HMAC-MD5 -b tamaño_de_clave -n nametype nombreclave
-    algorith hmac-md5;
+</code>
-    secret "asdf89uas9dfuasikdf==";
+^ 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:
+<code bash>
+dnssec-keygen -a HMAC-MD5 -b 128 -n HOST supersecret
+</code>
+Salida:
+  * ''Ksupersecret.+157+26824.key''
+  * ''Ksupersecret.+157+26824.private''
+Una vez tenemos la claves, debemos declararlas en el fichero ''named.conf'':
+<code>
+key nombre_clave {
+    algorithm hmac-md5;
+    secret "yItYGlAQtGcM7VqGjZdJAg==";
 };
+</code>
+^ 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).  |
-#nameserver2 (slave)
+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 10.0.1.2 {
+<code>
-    key {
+server ip_dest {
-        TRANSFER;
+   keys { nombre_clave; };
-    };
 };
 </code>
+^ 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.  |
-Securizando las conexiones:
+Si generamos el fichero ''tsig.key'', debemos incluirlo en el fichero de configuración ''named.conf'':
-.Si generamos el fichero tsig.key, debemos incluirlo en el fichero de configuración ''named.conf'':
 <code>
 include "/var/named/tsig.key"
 </code>
 Recargamos la configuración:
@@ Línea 169: / Línea 300: @@
 </code>
-. En el servidor esclavo debemos realizar los mismos pasos, aunque cambiando la IP por la del master:
+En el servidor esclavo debemos realizar los mismos pasos, aunque cambiando la IP por la del master:
 <code>
@@ Línea 176: / Línea 307: @@
     secret "asdf89uas9dfuasikdf==";
 };
 #nameserver1 (master)
@@ Línea 187: / Línea 317: @@
 </code>
-PREGUNTA DE EXAMEN:
-DNSSEC is used for?
-A. Encrypted DNS queries between nameservers.
-B. Cryptographic authentication of DNS zones.
-C. Secondary DNS queries for local zones.
-D. Defining a secure DNS section.
-E. Querying a secure DNS section.
-•Localización de los ficheros de configuración y utilidades de
-sevidor BIND.
-•Tipos de servidores DNS (master, slave, cache).
-•Definición de zonas.
-•Creación y modificación de ficheros de zonas directa e inversa.
-•Uso de directivas allow-query/allow-transfer.
-•Configuración Bind en chroot.
-•Conocimiento de DNSSEC.
-•Configuración y uso de firmas de transacción (TSIG).
-</code>