2. Configuración DNSSEC
u Configuración común:
u Archivo de configuración
u Generación de claves KSK y ZSK
u Configuración manual
u Firmado
u Configuración automática
u Parámetros de automatización DNSSEC
u NSEC3
u DS
u Key rollover
2
3. Como funciona
u Dos claves asimétricas: KSK y ZSK. Valores recomendados KSK 4096,
ZSK 1024 con rollovers para KSK de 1 a 3 años y de 1 a 3 meses para
ZSK
u Aligeramos la extensión de la zona manteniendo un cifrado suficiente
u Publicamos ambas claves públicas en la zona: DNSKEY
u Utilizamos KSK para firmar el DNSKEY
u Evitamos firmar el DNSKEY con ZSK para aligerar la zona
u Update-check-ksk y dnssec-dnskey-kskonly establecidos a yes
u Utilizamos KSK para generar el DS y lo subimos al delegante
u Utilizamos ZSK para firmar el resto de registros: RRSIG
3
10. Configuración común:
Opciones de BIND
u Opciones necesarias en named.conf.options
u dnssec-enable tiene que encontrarse establecido a yes
u dnssec-validation tiene que encontrarse establecido a yes o auto
u Establecido a yes debemos indicar el enlace de confianza con los
parámetros managed-keys (Señalamos la correspondecia del DS) o trusted-
keys (No utilizamos los DS pero conocemos las claves de confianza)
u dnssec-lookaside tiene que encontrarse establecido a yes o auto
u Igual que managed-key para el dominio dlv.isoc.org
u update-check-ksk y dnssec-dnskey-kskonly establecidos a yes para
evitar cargar más la zona sin necesidad
10
12. Configuración común:
Generación de claves
u Veamos que hemos hecho:
u dnssec-keygen –a NSEC3RSASHA1 –b 2048 –n ZONE example.com
u -a algoritmos posibles a utilizar. Por defecto RSASHA1. Optamos por
NSEC3RSASHA1 para añadir posteriormente NSEC3
u Hay múltiples algoritmos en BIND aunque algunos aun no implementados y
otros enfocados a la generación de claves TSIG/TKEY
u -b tamaño de la clave. Por defecto 2048 para la KSK y 1024 para el
resto. La recomendación es hacer fuerte KSK y rollover de ZSK
u -n ZONE [Dominio] para poder implementar DNSKEY
u Más opciones que posteriormente veremos
12
13. Configuración común:
Generación de claves
u Desde la carpeta creada para almacenar las claves generamos el
KSK de la misma forma que el anterior. Sólo añadimos la opción –f
KSK para indicarle a dnssec-keygen el tipo de clave
13
14. Configuración común:
Generación de claves
u La clave pública nos indica los tiempos de válidez que
gestionaremos en el rollover y la DNSKEY que posteriormente
publicaremos
u La clave privada ZSK es la que vamos a utilizar para la firma de los
recursos
14
15. Introducción de los períodos de
validez de las claves
u O en la generación de claves o en cualquier momento posterior con dnssec-
settime
u Genera los metadatos necesarios para realizar el rollover de claves tanto de
manera manual como automática
u Períodos de la clave
u Creación. Es la única que no se puede modificar. Se establece en el momento de
generación de la clave.
u Publicación (-P) Establece el momento en que la clave se publicará por el servidor
u Activación (-A) Establece el momento en que la clave comenzará a firmar registros
de la Zona
u Inactivación (-I) Establece el momento en que la clave dejará de firmar resgistros de
la zona
u Borrado (-D) Establece el momento en que la clave será borrada
u Revocación (-R) Establece el momento en que la clave será revocada. Opcional y no
debería usarse salvo compromiso de la clave
15
16. Períodos de validez de la clave
u Formato AAAAMMDDHHMMSS
u La hora que introduzcamos tomara en consideración el timezone
del ordenador y se guardará en formato UTC. ( ¡Si escribimos las 12
de la noche en horario de verano español se guardará como las 2
de la mañana! )
u - i especifica el intervalo de pre-publicación de la clave. Si se
establece las fechas de publicación y activación se encontrarán
separadas al menos por el intervalo señalado en esta opción
u +/- Establece valores relativos a partir de una fecha dada
16
17. Generadas las claves
u A partir de aquí tenemos dos opciones:
A. Hacerlo todo de forma manual
B. Automatizar en diferentes grados menos la generación de claves
(auto-dnssec allow/maintain) para rollover
C. Automatizar todo incluso la generación de claves (inline-signing) para
rollover
D. En cualquier caso la gestión del DS nunca es automática
17
18. Configuración manual
u Incluir las claves en la zona. Ejemplo en bash
u For key in `ls Kexample.com*.key`
u do
u echo “$INCLUDE $key “>> db.example.com
u done
18
19. Configuración manual
u Preparando la firma de la zona. Generamos un SALT suficientemente aleatorio
u head -c 1000 /dev/random | sha1sum | cut -b 1-16
u Cuanto más fuerte sea el SALT mas dificultad para hacer Zone Walking en NSEC3
u Una vez obtenido procedemos a la firma
19
20. Configuración manual
u Una vez firmado se nos han generado dos ficheros:
u El fichero de zona firmado con el mismo nombre que el original más la extensión
.signed
u El fichero de las claves DS con la sintaxis dsset-[dominio] para registrarlo en el dominio
superior
20
22. Configuración automática
u BIND9.9 ofrece herramientas suficientes para automatizar toda la
gestión incluyendo los rollovers
u Debemos decirle dónde se van a almacenar la claves
u /etc/bind/keys o similar. Lo introducimos en named.conf mediante una
opción de modo global o en el archivo local para cada una de las zonas.
u Directiva: key-directory "/etc/bind/keys";
u La automatización se realiza mediante la directiva auto-dnssec allow
maintain en cada zona
u Establecida en allow la automatización requerirá lanzarse desde el
comando rndc sign [zone] por el administrador
u Establecida en maintain la automatización es total excepto para
generación de claves y generación y publicación del DS en el dominio
superior
u Solo tenemos que generar un nuevo DS cuando hagamos rollover de KSK
22
24. Configuración automática
u Después de reiniciar el
servicio la firma es
automática… aunque
tardará un tiempo en
aparecer en el fichero
24
25. Configuración automática
u Después de reiniciar el
servicio la firma es
automática aunque tardará
un tiempo en aparecer en el
fichero
u Al contrario que en el modo
manual aquí no se genera
un nuevo fichero de zona
sino que se produce la firma
sobre el original
25
26. Automatizar rollover
u Si se encuentra las nuevas claves en el directorio señalado
procederá a realizar el rollover conforme los tiempos señalados
u Si no se señalan tiempos conforme a los establecidos por defecto
u Si se señalan tiempos de desactivación o borrado de claves pero no se
generan las siguientes se procederá a su desactivación y borrado
dejando la zona con firmas de los recursos pero sin claves públicas
u Establecer un correcto procedimiento de rollover y seguirlo
u Entender porqué existen dos claves y establecer los tiempos
correctos de rollover de cada una
u La KSK requiere nueva generación y publicación del DS
u Opción para automatización total inline-signing
26
27. Generación de claves automática
u Con la opción inline-signing BIND se encargará de generar las
claves cuando sea necesario a partir de las claves existentes y
atendiendo a los tiempos señalados en sus metadatos y al valor de
sig-validity-interval x y (Por defecto 30 días – 7,5 días)
u sig-validity-interval primer valor indica el número de días en que la
clave automaticamente generada expirará (Por defecto 30 días)
u Este valor tiene que ser siempre un múltiplo al menos de 2 del TTL de
expiración del SOA
u sig-validity-interval segundo valor opcional indica el número de días
previo a la expiración en que la firma se regenerará (Por defecto 7,5
días)
u Ambos valores se expresan en días salvo que el primero sea menor de 7
en cuyo caso el segundo se expresa en horas
27
29. NSEC3
u DNSSEC contesta con un hash firmado la no-existencia de recurso (NSEC)
u Realiza la comprobación de la no-existencia basándose en el ordenamiento
canónico de los recursos existentes
u Si hago sucesivas búsquedas alfabéticas de recursos al azar podré obtener
todos los datos de la zona con NSEC al usar la información en claro
u NSEC3 mitiga el problema al almacenar los recursos existentes como hashes
u Cuantas más iteracciones más coste de cálculo
u Cuanto más aleatorio el SALT más dificultad en el uso del diccionario
u De ahí la importancia de evitar secuencias propias y usar algo lo más aleatorio
posible
u head -c 1000 /dev/random | sha1sum | cut -b 1-16
u Para hacer efectivo NSEC3 en modo automático el parámetro debe estar
configurado. auto-dnssec maintain lo aplicará o en la firma inicial o en la
reconfiguración de claves
29
30. NSEC3
u DNSSEC contesta con un hash firmado la no-existencia de recurso
u Realiza la comprobación de la no-existencia basándose en el ordenamiento
canónico de los recursos existentes
u Si hago sucesivas búsquedas alfabéticas de recursos al azar podré obtener
todos los datos de la zona
u NSEC3 mitiga el problema al no responder el recurso existente sino un hash de
este.
u Cuantas más iteracciones más coste de cálculo
u Cuanto más aleatorio el SALT más dificultad en el uso del diccionario
u De ahí la importancia de evitar secuencias propias y usar
u head -c 1000 /dev/random | sha1sum | cut -b 1-16
u Para hacer efectivo NSEC3 en modo automático el parámetro debe estar
configurado. auto-dnssec maintain lo aplicará o en la firma inicial o en la
reconfiguración de claves
30
31. Delegation Signer (DS)
u Hash del KSK que se contiene en el dominio delegante para mantener la
cadena de confianza:
u El dominio delegante señala los NS del delegado
u Mediante el DS señala si está firmado y valida la clave de firma
u Para obtener el DS utilizamos el comando dnssec-dsfromkey y lo
suministramos a la autoridad del dominio superior
u Si la autoridad del dominio superior somos nosotros mismos lo insertamos
mediante nsupdate
31
32. Pasar la zona firmada a normal
u Para quitar la firma automática de la zona dos pasos:
u auto-dnssec allow y establecer la directiva dnssec-secure-to-insecure
yes en las opciones
u Borrar las DNSKEYS de la zona mediante nsupdate
u > update delete example.com DNSKEY
32