TecnoWarp: DNS

Mostrando entradas con la etiqueta DNS. Mostrar todas las entradas

miércoles, 25 de febrero de 2015

DNSSEC

Todos sabemos que el DNS es un protocolo que resuelve los nombres de dominio en direcciones IP, pero ¿cómo sabemos la autenticidad de la dirección IP devuelta? Es posible que un atacante pueda alterar una respuesta DNS o envenenar la caché DNS y redirigir los usuarios a un sitio malicioso con el nombre de dominio legítimo en la barra de direcciones. Las extensiones de seguridad DNS (DNSSEC) son una especificación que tiene por objeto el mantenimiento de la integridad de los datos de las respuestas DNS. DNSSEC firma todos los registros de recursos DNS (A, MX, CNAME, etc.) de una zona mediante PKI (Public Key Infrastructure). Las resoluciones de DNS habilitando DNSSEC (como Google Public DNS) pueden verificar la autenticidad de una respuesta DNS (que contiene una dirección IP) utilizando el registro DNSKEY público.

Acerca de DNSSEC

Un registro de recursos (RR) contiene una información específica sobre el dominio. Entre los más comunes son un registro que contiene la dirección IP del dominio, registro AAAA que contiene la información de IPv6, y registro MX que tiene servidores de correo de un dominio. Una lista completa de DNS RR se puede encontrar aquí .Del mismo modo DNSSEC también requiere varios RR.

DNSSEC registros de recursos

DNSKEY Contiene la clave pública que resolutores de seguridad.
RRSIG existe para cada RR y contiene la firma digital de un registro.
DS - Delegación Firmante - existe este registro en los servidores de nombres del dominios de primer nivel. Así que si example.com era su nombre de dominio, el TLD es "com" y sus servidores de nombres son a.gtld-servers.net., -b.gtld-servers.net. hasta m.gtld-servers.net. El objetivo de este registro es para verificar la autenticidad de la misma DNSKEY.

Nombre de Dominio: ejemplo.gob.ve

Entorno de instalación

Nombre del servidor: DNS01

Dirección IP: 192.168.200.2 y 172.16.0.195 (Virtual) Nombre de host:

dns02.ejemplo.gob.ve SO: Debian 7

Nombre del servidor: DNS02

Dirección IP: 192.168.200.2 y 172.16.0.196 (virtual) Nombre de host:

dns02.ejemplo.gob.ve OS: Debian 7

Habilitar DNSSEC añadiendo las siguientes directivas de configuración dentro de /etc/bind/named.conf.options, Esto Puede variar dependiendo de como se configure el DNS y como se ordene la información.Configuración del maestro DNSSEC


dnssec-enable yes;

        dnssec-validation yes;
        dnssec-lookaside auto;

        //bindkeys-file "/etc/bind/bind.keys";

Luego colocar la clave de DLV ISC para bind9, para este caso podemos usar Webmin para la tarea de simplificar el prceso, sin embargo acá dejo la clave para ser pegada en la ruta /etc/bind/named.conf.


trusted-keys {

    dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URkY62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh";

    };

para hacerlo en webmin vamos a la configuración y abrimos el icono que dice:

Es este menú se puede configurar todo lo referente a la clave DLV, por defecto BIND crea la clave para la validación.

si se quiere crear una clave de zona, lo que se requiere es crear una clave ksk

martes, 24 de febrero de 2015

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

domingo, 25 de enero de 2015

CONFIGURACIÓN BIND9 ADS

Esta guía describirá cómo autenticar contra servidores de Active Directory utilizando BIND9 sin actualizaciones de DNS dinámico (DDNS).

Esta solución ES compatible con Windows Server 2000 y 2003 y server 2008 en los esquemas de Active Directory.

Idenfificación de IP requeridas y Host Name Información

Nombre de dominio completo (FQDN) de su dominio de Active Directory:
ex: eleyzam.com

IP de los servidores de Active Directory:
por ejemplo: 192.168.200.2
por ejemplo: 192.168.200.3

Nombre de servidores de Active Directory:
ex: ads01
ex: ads02

Nombre del Servidor DNS
ex: ads01
ex: ads02

IP del servidor DNS
192.168.200.14

Ver GUID de dominio

El GUID de dominio es un GUID estático para el directorio de nombres de dominio.

Para obtener el GUID de dominio, abra una ventana CMD en el servidor de Active Directory de Windows y escriba:

repadmin /showreps ServerName

al ejecutar este comando se imprimiran en pantalla los siguientes datos

Opciones de DSA: IS_GC

Opciones de sitio: (none)

GUID del objeto DSA: 5d4cf62e-0ba2-4259-b1ef-b2502a3867b6

Id. de invocación de DSA: 5a8bfb19-d996-45fb-b9cf-377d410cc729

==== VECINOS DE ENTRADA ======================================

DC=eleyzam,Dc=com

eleyzam\ADS02 vía RPC