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

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

Script para crear Repositorios de DEBIAN

Como se podrá observar y se habrá visto en la información anterior de instalar debmirror en CENTOS, no existe soporte nativo de ese paquete, y a menos que se tenga un repositorio por rsync no se podrá descargar repositorios Debian para ser hosteados en CENTOS sin la necesidad de este. Por ello al usar esta herramienta hay que tener cuidado de poner las carpetas a sincronizar en diferentes subdirectorios, para evitar que por algún motivo el debmirror borre las carpetas fuera del ámbito del script en el mismo nivel del árbol.

También se recomienda usar el método http. pues el método debmirror y rsync ha arrojado errores con los archivos sources. Los scripts para sincronizar son los siguientes.

Debian MAIN 6,7,8

/usr/local/bin/debmirror --debug \
--progress \
--verbose \
--diff=none \
--host=mirrors.kernel.org \
--root=debian \
--method=http \
--dist=squeeze,wheezy,jessie,wheezy-updates,squeeze-updates,wheezy-backports \
--arch=i386,amd64 \
--nosource \
--section=main,contrib,non-free \
--i18n \
--getcontents \
--ignore-release-gpg \
--ignore-missing-release \
/repo/debian/main > /repo/rsync.log
echo "Culminada la Sincronizacion del repositorio debian arquitetura amd64." 
exit

Debian Security

/usr/local/bin/debmirror --debug \
--progress \
--verbose \
--diff=none \
--host=security.debian.org \
--root=:debian-security \
--method=http \
--dist=squeeze/updates,wheezy/updates,jessie/updates \
--arch=i386,amd64 \
--nosource \
--section=main,contrib,non-free \
--getcontents \
--ignore-release-gpg \
--ignore-missing-release \
--rsync-options=-aIL \
/repo/debian/security > /repo/rsync.log
echo "Culminada la Sincronizacion del repositorio debian security arquitetura amd64."
exit

Sepan disculpar la simpleza, pero espero igual les sea de utilidad.

Script para crear Repositorios de Centos

Los siguentes scrips permiten hacer un Rsync  de cualquier mirror de Centos que cuente con soporte de dicho protocolo, los archivos son los siguientes:

Antes de declarar los scripts debo comentar que creé un LVM aparte para repositorios, en este caso recomiendo por lo menos 500gb pues si se va a instalar paquetes centos y debian, se llenará rápidamente. Solo los de centos ocupan entre centos 6.5 y 7 que en mi caso son los que tengo habilitado junto a sus epel ocupa unos 150GB, así que tomen las previsiones del caso.

Script Centos 6.5

#!/bin/bash
#Test IF
VAR=`ps -ef | grep "rsync --progress --stats -av --delete --delete-excluded --exclude "isos" --exclude "i386" rsync://mirrors.kernel.org/centos/6.5/" | wc -l`
    echo $VAR
    if [ $VAR == 1 ]; then 
        echo "Sincronizando Repositorio Centos 6.5" 
        rsync --progress --stats -av --delete --delete-excluded --exclude "isos" --exclude "i386" rsync://mirrors.kernel.org/centos/6.5/ /repo/centos/6/ > /repo/rsync.log
    elif [ $VAR > 1  ]; then 
        echo "Servicio Operativo"
        exit
    fi

Script Centos 7

#!/bin/bash
#Test IF
VAR=`ps -ef | grep "rsync --progress --stats -av --delete --delete-excluded --exclude "isos" --exclude "i386" rsync://mirrors.kernel.org/centos/7.0.1406/" | wc -l`
echo $VAR
if [ $VAR == 1 ]; then 
echo "Sincronizando Repositorio Centos7" 
 rsync --progress --stats -av --delete --delete-excluded --exclude "isos" --exclude "i386" rsync://mirrors.kernel.org/centos/7/ /repo/centos/7/ > /repo/rsync.log
elif [ $VAR > 1  ]; then 
echo "Servicio Operativo"
exit
fi

Script EPEL Centos 6

#!/bin/bash
#Test IF
VAR=`ps -ef | grep "rsync --progress --stats" | wc -l`
if [ $VAR == 1 ]; then 
echo $VAR
echo "Sincronizando Repositorio EPEL Centos6" 
 rsync --progress --stats -av --delete --delete-excluded --exclude 'ppc64' --exclude 'i386' rsync://mirrors.kernel.org/fedora-epel/6/ /repo/epel/6/ > /repo/rsync.log
elif [ $VAR > 1  ]; then 
echo "Servicio en funcionamiento, para ver la salida utilice el comando "tail -f /repo/rsync.log" "
exit
fi

Script EPEL Centos 7

#!/bin/bash
#Test IF
VAR=`ps -ef | grep "rsync --progress --stats" | wc -l`
if [ $VAR == 1 ]; then 
echo $VAR
echo "Sincronizando Repositorio EPEL Centos7" 
 rsync --progress --stats -av --delete --delete-excluded --exclude 'ppc64' rsync://mirrors.kernel.org/fedora-epel/7/ /repo/epel/7/ > /repo/rsync.log
#rsync --progress --stats -av --delete --delete-excluded rsync://mirrors.neterra.net/epel/7/x86_64/ /repo/epel/7/x86_64/ > /repo/rsync.log
elif [ $VAR > 1  ]; then 
echo "Servicio en funcionamiento, para ver la salida utilice el comando "tail -f /repo/rsync.log" "
exit
fi

como puede apreciarse se está usando los repositorios de mirrors.kernel.org, debido a el gran ancho de banda que posee dicho repositorio, y la facilidad con que puede descargarse. 

HTTP/2 ha sido finalizado, la mayor actualización de HTTP en 16 años se acerca

Hace apenas unas horas, Mark Nottingham de la IETF ha publicado en su blog que el nuevo estándar HTTP/2 ha sido finalizado, y que ha sido enviado al RFC Editor para comenzar el proceso de publicación de la que será la mayor actualización del protocolo de transferencia de hipertexto desde que se implementó la versión HTTP 1.1 hace ya dieciséis años.

Esta actualización del protocolo que permite que los servidores web y los navegadores se comuniquen entre sí para que el usuario final pueda acceder al contenido de la red, traerá consigouna mayor velocidad en la carga de las páginas, una reducción de los errores de conexión y una menor carga en los servidores de las redes.

Esta versión 2.0 del HTTP está basada en SPDY el protocolo de comunicaciones que Googlepresentó hace algo más de cinco años para conseguir una mayor velocidad de carga de las webs, manipulando el tráfico para mejorar la latencia y la seguridad. Pero aunque la reducción de los tiempos de carga va a ser uno de los grandes alicientes del HTTP/2, no será el único.

Las novedades del nuevo protocolo

Además de la ya mencionada velocidad de carga, el nuevo estándar HTTP también innovará con una nueva función de multiplexación que permitirá que un servidor pueda responder a varias peticiones al mismo tiempo, de manera que no haya problemas de eficiencia y carga que provoquen bloqueos de las páginas.

HTTP/2 también usará bastantes menos conexiones, lo que debería dar como resultadouna menor carga en los servidores y páginas web. Además, también traerá buenas noticias para los desarrolladores, pues será compatible con el código escrito hasta ahora al mantener la misma API HTTP que se ha estado actualizando hasta hoy, haciendo simplemente que todas las mejoras sean opcionales.

Aunque hace unos meses saltó el rumor de que HTTP/2 podría funcionar únicamente a través de conexiones cifradas, de momento no se han tomado medidas tan drásticas para mejorar la seguridad, aunque en las FAQ del proyecto sí que vemos que se están debatiendo posibilidades como la utilización del cifrado oportunista por http:// URI sin autenticación del servidor.

Google ya anunció hace unos días que Chrome empezaría a utilizar HTTP/2 en cuanto estuviese listo, por lo que algunas de sus funciones ya pueden ser probadas tanto en su navegador como en Firefox. Además, seguramente el resto de empresas empiece a adoptar también el protocolo en sus navegadores en cuanto este sea publicado de forma oficial, lo cual no debería tardar demasiado.

Fuente: http://www.genbeta.com/