BIND9 TSIG

TSIG

TSIG (Transaction SIGnature, RFC 2845) es un método para firmar las transacciones y mensajes de DNS mediante el uso de claves simétricas (secretas) compartidas. Esto incluye los mensajes de consulta recursiva, notificación o consultas dig, aunque TSIG suele utilizarse sobre todo para proteger la transferencia de zonas de un dominio entre un servidor de DNS primario y su(s) secundario(s). TSIG opera con cifrado simétrico, es decir, los servidores implicados en la transacción comparten una misma clave. Esto nos permitirá restringir quién puede transferir las zonas DNS entre servidores. Es el caso que aplicaremos en este documento.Estrictamente hablando, TSIG no es parte de DNSSEC, pero asegurar la comunicación entre los DNS autoritativos suele ser un paso previo a asegurar las zonas con DNSSEC. Conviene saber que TSIG no cifra los datos en tránsito. Su firma digital preserva la integridad de las comunicaciones maestro-esclavo, no la confidencialidad, ya que los datos de una zona son esencialmente públicos pero, si se requiere confidencialidad, se debe configurar una VPN.

Configuración de TSIG

Para configurar TSIG es recomendable crear una clave por cada servidor esclavo. De esa forma, si un servidor esclavo se ve comprometido, solo será necesario reemplazar la clave almacenada en ese host.

Creación de la clave

Para crear la clave TSIG usaremos dnssec-keygen, una utilidad incluida con bind9 para generar claves DNSSEC:

dnssec-keygen -a HMAC-SHA256 -b 112 -n HOST keyname

• HMAC-SHA256 es el algoritmo utilizado para el cifrado.
• 112 es la longitud de la clave (o el número de bits). La actual recomendación de NIST es usar HMAC-SHA256, con 112 bits.
• HOST: HOST es la palabra clave utilizada para generar una clave para un cifrado de clave simétrico. Por convención, se suele usar como nombre de clave el nombre de host de ambos servidores ('dns01' y 'dns02' en este ejemplo), finalizado en un punto.

En nuestro caso:

$ dnssec-keygen -a HMAC-SHA256 -b 112 -n HOST dns01-dns02.dns01-dns02.+163+14005

163 identifica el algoritmo utilizado (HMAC_SHA256) y 14005 es la huella (útil en DNNSEC porque se permiten varias claves por zona).Si recibimos un error al usar el algoritmo HMAC-SHA256 (private key is invalid) deberemos actualizar nuestra versión de bind9, evitando así tener que usar algoritmos débiles como HMAC-MD5.El comando anterior nos creará dos pequeños ficheros de texto, uno con extensión .key y otro .private:

dns01-dns02.+163+14005.key  dns01-dns02.+163+14005.private

El fichero .key contiene un registro DNS KEY que puede usarse en un fichero de zona. El fichero con extensión -.private es el que nos interesa para nuestro caso: incluye información del algoritmo y la clave que necesitamos (aunque el fichero key contendrá igualmente la clave secreta). Este es su contenido:

$ cat dns01-dns02.+163+14005.private

Private-key-format: v1.3

Algorithm: 163 (HMAC_SHA256)

Key: 6f5p3ntxg81bTgkpeX4=Bits: 
AAA=Created: 20130514083805

​Activate: 20130514083805

Publish: 20130514083805

La línea Key contiene la clave secreta (”6f5p3ntxg81bTgkpeX4=” en este ejemplo), que por supuesto deberemos proteger y guardar a buen recaudo y que usaremos para configurar bind9, nsd o el servidor DNS de nuestra elección con soporte TSIG. No es necesario copiar el fichero completo, basta con copiar la línea con la clave a nuestro fichero de configuración en nuestro servidor primario y secundario, como se explica a continuación.

Configurar servidor DNS primario

Ahora que ya tenemos la clave, debemos incluirla tanto en la configuración del servidor DNS primario como en el secundario. Empezamos con el primario, editamos named.conf:

//TSIGkey===============================================================

 dns01-dns02. { algorithm hmac-sha256; secret "6f5p3ntxg81bTgkpeX4="; };

Ahora debemos especificar que nuestro secundario (192.168.200.79 y 172.16.0.195) usará la clave dns01-dns02.:

server 192.168.200.79 {
keys {

        };
dns01-dns02.;
    };

        dns01-dns02.;
server 172.16.0.196 {
    keys {
        };

    };

Por ejemplo:

zone "example.com" {

    type            master;

    file            "master/db.example.com";
allow-transfer {

​};
key dns01-dns02.;

    };

Es una doble seguridad: no basta con conocer la clave, sino que debe proceder de la IP declarada para el secundario.

nota: Se puede cambiar el nombre de este ejemplo por el que se requiera, el nombre descriptivo que se le da a la clave no tiene nada que ver son esta, solo es una asociación, pues cuando el ve que existe la clave en el servidor DNS secundario es que procede a la trasferencia, así que esto es solo con el fin de que se pueda identificar fácilmente la clave y cambiarla de ser necesario. por este motivo también se debe colocar la misma nomenclatura en el servidor secundario.

Configurar servidor DNS secundario

La configuración del servidor secundario también deberemos modificarla.  tendremos que editar named.conf, como hicimos con el primario, y añadir lo siguiente:

//TSIG ====================================================================
key dns01-dns02. { algorithm hmac-sha256; secret "6f5p3ntxg81bTgkpeX4="; };

server 172.16.0.195 {
server 192.168.200.14 {
    keys {
        dns01-dns02.;
        };
    };
    keys {

    };
dns01-dns02.;

        };

Para comprobar que la conexión TSIG funciona, modificamos un registro de zona en el primario (por ejemplo, cambiamos su número de serie). Al recargar el servidor, el maestro debería notificar al secundario que ha habido cambios e inmediatamente el esclavo debe intentar transferir la zona. Tambien puede optar por recargar el esclavo y este buscará recargar las zonas. Si TSIG está correctamente configurado deberíamos ver en los logs del primario algo parecido a esto:

Comprobación

May 14 10:48:26 foo named18123: zone example.com/IN: loaded serial 2013051401

May 14 10:48:26 foo named18123: zone example.com/IN: sending notifies (serial 2013051401)

May 14 10:48:26 foo named18123: client 1.2.3.4#57028: transfer of 'example.com/IN': AXFR-style IXFR   started: TSIG dns01-dns02.

​May 14 10:48:26 foo named18123: client 1.2.3.4#57028: transfer of 'example.com/IN': AXFR-style IXFR ended

Y en el secundario:

<a class="wiki" href="1368521223" rel="">1368521223</a> nsd<a class="wiki" href="3508" rel="">3508</a>: info: Zone example.com serial 2013051301 is updated to 2013051401.

Si algo ha ido mal, obtendremos mensajes ”denied” en los logs. Deberemos revisar los ficheros de configuración (named.conf ), pues lo más probable es que hayamos cometido alguna errata.

para mas fuente de consulta visite http://doc.flossystems.com/es/security/dns/tsig