Diferencias

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

--- informatica:certificaciones:lpic:lpic-2:207_domain_name_server:207.3 [2021/04/13 15:59] – [Bind en modo chroot] tempwin
+++ informatica:certificaciones:lpic:lpic-2:207_domain_name_server:207.3 [2021/04/23 13:51] (actual) – [TSIG] tempwin
@@ 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 74: / Línea 84: @@
 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]]
+<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 ====
@@ Línea 85: / Línea 100: @@
 mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}
 </code>
+==== Copia de ficheros y permisos ====
 Copiar los archivos de configuración, zona y aplicación al directorio chroot (''/var/bind9/chroot''):
@@ Línea 96: / Línea 113: @@
 <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>
@@ Línea 113: / Línea 137: @@
 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:
@@ Línea 120: / Línea 146: @@
 </code>
-==== Ejecución del proceso en chroot ====
+==== Ejecución del servicio en chroot ====
 <code bash>
@@ Línea 128: / 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 =====
@@ Línea 169: / Línea 230: @@
 **T**ransaction **SIG**nature, firma de transacciones.
-  * Se basa en el uso de una clave compartido entre los servidores que intercambian datos.
+  * 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.
-Primera se generan las claves:
+Primero se generan las claves con el comando ''dnssec-keygen'':
+<code>
+dnssec-keygen -a HMAC-MD5 -b tamaño_de_clave -n nametype nombreclave
+</code>
+^ 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 512 -n HOST rndc-key
+dnssec-keygen -a HMAC-MD5 -b 128 -n HOST supersecret
 </code>
 Salida:
-  * ''Krndc-key.+157+21526.key''
+  * ''Ksupersecret.+157+26824.key''
-  * ''Krndc-key.+157+21526.private''
+  * ''Ksupersecret.+157+26824.private''
-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:
+Una vez tenemos la claves, debemos declararlas en el fichero ''named.conf'':
 <code>
-key "TRANSFER" {
+key nombre_clave {
-    algorith hmac-md5;
+    algorithm hmac-md5;
-    secret "asdf89uas9dfuasikdf==";
+    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.  |
 Si generamos el fichero ''tsig.key'', debemos incluirlo en el fichero de configuración ''named.conf'':