Firmado autom‡tico en l’nea (INLINE) con BIND --------------------------------------------- Recuerde que si ve un '#' antes de un comando, significa que debe ejecutar dicho comando como root, por medio de una de estas alternativas: a) sudo -s b) sudo command Continuaremos sobre el trabajo realizado en los ejercicios anteriores para habilitar firmado en l’nea con BIND (9.9+) Con el firmado en l’nea, la zona original nunca se modifica: esto permite al administrador, por ejemplo, hacer un vaciado "dump" desde una base de datos que contenga la zona, y hacer que BIND simplemente la firme. Cuando se actualiza la zona original, BIND detecta los cambios, y re-firma. *** EN SU SERVIDOR MAESTRO *** 1. Vamos a agregar un par de comandos al fichero de configuraci—n named.conf de BIND para habilitar firmado de DNSSEC en l’nea Primero, edite named.conf bajo /etc/namedb/ y haga los siguientes cambios: zone "MITLD" { file "/etc/namedb/master/MITLD"; // <--- Quite ".signed" (si est‡) type master; key-directory "/etc/namedb/keys"; // <--- Agregue esto (si no est‡) auto-dnssec maintain; // <--- Agregue esto (si no est‡) inline-signing yes; // <--- Agregue esto // update-policy local; // <--- Quite, si est‡ }; Grabe y salga. 2. Prepare las claves Si ha hecho el ejercicio de firmado manual antes, ya ha generado las claves, y podemos reusar las mismas. De lo contrario, vamos a generar un par de claves nuevas. a) Si no tiene las claves todav’a (si ya tiene claves, vaya al paso b): # mkdir -p /etc/namedb/keys # chown -R bind /etc/namedb/keys # cd /etc/namedb/keys - Genere el primer par de claves (ZSK) # dnssec-keygen MITLD ( saldr‡ algo como: Generating key pair......................+++++ + .... KMITLD.+005+43116) - Genere el segundo par (KSK) # dnssec-keygen -f KSK MITLD KMITLD.+005+52159 Compruebe que las claves est‡n ah’: # ls -l KMITLD* F’jese que no especificamos ningunos par‡metros como algoritmo, tama–o de la clave, etcÉ Usaremos los valores por defecto ahora. b) Si ya tiene las claves: Debemos asegurarnos de que el directorio tiene los permisos correctos, ya que BIND necesitar‡ gestionarlo y necesitar‡ acceso a los ficheros y el directorio: # chown -R bind /etc/namedb/keys Veamos las claves: # cd /etc/namedb/keys/ # ls -l KMITLD* -rw-r--r-- 1 bind wheel 591 Feb 18 15:52 KMITLD.+005+32044.key -rw------- 1 bind wheel 1774 Feb 18 15:52 KMITLD.+005+32044.private -rw-r--r-- 1 bind wheel 417 Feb 18 15:52 KMITLD.+005+64860.key -rw------- 1 bind wheel 1010 Feb 18 15:52 KMITLD.+005+64860.private 3. Ahora echemos un vistazo al fichero de zona Si hab’a hecho un backup de su zona, vamos a restaurarla, para empezar desde cero. # cd /etc/namedb/master # cp MITLD.backup MITLD Elimine el fichero .signed de la zona - BIND lo crear‡ autom‡ticamente! # rm MITLD.signed De nuevo, recuerde revisar que en named.conf est‡ cargando "MITLD", y no "MITLD.signed". Adem‡s debemos comprobar que BIND puede escribir en el directorio master: # chown bind /etc/namedb/master 4. Ahora recargue la configuraci—n en el servidor # rndc reconfig En este paso deber’a tener ficheros nuevos en el directorio master/: # cd /etc/namedb/master # ls -l ... -rw-r--r-- 1 root wheel 497 Sep 13 14:56 MITLD -rw-r--r-- 1 root wheel 497 Sep 12 09:49 MITLD.backup -rw-r--r-- 1 bind wheel 512 Sep 13 15:04 MITLD.jbk -rw-r--r-- 1 bind wheel 1331 Sep 13 15:04 MITLD.signed -rw-r--r-- 1 bind wheel 3581 Sep 13 15:04 MITLD.signed.jnl ... A ver si el firmado funcion— correctamente: # rndc signing -list MITLD Done signing with key 22603/RSASHA1 Done signing with key 39978/RSASHA1 TambiŽn revise los logs: # less /etc/namedb/logs/general 13-Sep-2012 15:04:27.444 reloading configuration succeeded 13-Sep-2012 15:04:27.450 zone MITLD/IN (unsigned): loaded serial 2012022301 13-Sep-2012 15:04:27.451 any newly configured zones are now loaded 13-Sep-2012 15:04:27.471 zone MITLD/IN (signed): loaded serial 2012022301 13-Sep-2012 15:04:27.493 zone MITLD/IN (signed): receive_secure_serial: unchanged 13-Sep-2012 15:04:27.501 zone MITLD/IN (signed): reconfiguring zone keys 13-Sep-2012 15:04:27.544 zone MITLD/IN (signed): next key event: 13-Sep-2012 16:04:27.501 # dig @localhost MITLD NS Note que la zona firmada no est‡ en un formato legible. Para ver los contenidos de la zona firmada, se puede hacer una transferencia de zona (axfr) o tambiŽn: # named-checkzone -D -f raw -o - MITLD MITLD.signed | less 5. Cambios en la zona Entonces, c—mo actualizo la zona y la vuelvo a firmar? Simple! Vamos a modificar la zona y agregar un record llamado "mail" con la direcci—n IP del servidor auth1: mail A 10.10.XX.1 ; X is your group Entonces, edite el fichero de zona "MITLD" y agregue la l’nea de arriba. TambiŽn recuerde cambiar el serial. Ahora, recargue la zona. BIND firmar‡ autom‡ticamente: # rndc reload MITLD Espere unos segundos, y luego: # tail /etc/namedb/log/general QuŽ puede observar ? # dig @localhost mail.MITLD a # dig @localhost MITLD soa F’jese en el serial 6. Si no ha subido sus records DS a la ra’z en un ejercicio anterior, o si ha generado claves KSK nuevas, ahora debe enviar estos records DS a la ra’z. De lo contrario, puede ignorar el resto de este ejercicio! (DS = una huella digital criptogr‡fica (digest fingerprint) de la KSK). Genere records "DS" a partir de su clave KSK: Busque cu‡l es la clave KSK: # cd /etc/namedb/keys # more KMITLD*key Busque la que tenga "IN DNSKEY 257". Anote el "keyid" y sustituya la cadena "+005+32044" m‡s abajo con "+005+keyid" donde keyid es el nśmero en cuesti—n. # dnssec-dsfromkey KMITLD.+005+32044 >dsset-MITLD. No olvide el punto! 7. Suba el dsset de su zona (conteniendo la huella de su clave) al servidor ra’z: # scp dsset-MITLD. adm@a.root-servers.net: El password es el mismo que en clase 8. Avise al instructor de que lo ha hecho! El instructor incluir‡ el DS-set en la ra’z y firmar‡ la zona. 8. Verifique: # dig @a.root-servers.net DS MITLD.