Configuración

• Configure qué zonas NSEC3 deben crearse modificando el archivo config.json (ver Config)

• Generar claves: $ ./gen_keys.py

  Para cada zona, se generan una KSK y una ZSK. Las claves se reutilizan al cambiar la configuración siempre que los nombres de las zonas permanezcan sin cambios en la configuración.

• Generar zonefiles: $ ./gen_zones.py -c

  La opción -c habilita la exportación de archivos de configuración (actualmente solo para BIND9)

Use --help para más opciones.

Config

La estructura de configuración contiene dos elementos:

• default: Parámetros por defecto para las zonas (no todos están soportados hasta ahora)
• zones: Lista de todas las zonas a exportar

Zona

Una zona contiene:

• name (obligatorio): El nombre usado al referenciar la zona y como nombre de archivo durante la exportación
• origin (obligatorio): El nombre de dominio canónico del origin de la zona
• parent: El nombre de la zona padre (no el origin), al cual se añaden los registros NS, A, DS y NSEC3PARAM de esta zona
• keysize (obligatorio): El tamaño de la clave RSA (solo RSA hasta ahora)
• nsec3: Los parámetros NSEC3:
  • iterations: por defecto 0
  • salt: por defecto ''
  • algorithm: Valor entero; por ahora, solo se soporta SHA-1 (1)
  • tight: Un booleano especial que controla si deben añadirse registros NSEC3 inmediatamente después del origin y antes y después de *.origin. Por ejemplo, si *.origin tiene un registro NSEC3 1d..ua.origin., entonces los registros para 1d..u0.origin. y 1d..ub.origin. también se añaden al zonefile. Esto asegura que cada prueba NXDOMAIN en un subdominio de origin (por ejemplo, a.origin.) requiera tres registros NSEC3, ya que los registros NSEC3 que cubren el origin y el comodín tienen un rango muy pequeño hasta next_hash
• ns: El/los nameserver(s) de esta zona. Un valor único o una lista de:
  • ns: El nombre de dominio de un nameserver, por defecto ns1.origin
  • ip: El dominio IPv4 (IPv6 actualmente no soportado), por defecto 172.0.0.1
• soa: El RDATA SOA
• rrsets: Una lista de RRsets adicionales, dada como la tupla de 5 elementos [domain name, ttl, class, type, rdata] donde todos los valores (excepto, opcionalmente, ttl) se dan como cadenas

Reproduciendo el Ataque

Para reproducir el ataque NSEC3, esta sección ilustra una posible configuración personalizada que consiste en un servidor DNS autoritativo y un resolver víctima. Antes de continuar, asegúrese de que el entorno del sistema tenga un firewall suficientemente configurado para no exponer servidores públicos a los zonefiles del ataque.

1. Instale el nameserver NSD (versión actual)

   Navegue al sitio web de NLNetlabs (https://nsd.docs.nlnetlabs.nl/en/latest/installation.html) para las instrucciones de instalación.

   Se recomienda desplegar el nameserver en una VM o contenedor. Como punto de partida, hay un pequeño Dockerfile en docker/nsd.

   Construya el contenedor con docker build -t <tag> <path_to_dockerfile>, por ejemplo: cd docker/nsd && docker build -t nsd .

   Ejecute el contenedor con docker run -it --name <name> nsd bash para abrir una consola en el contenedor.

   A continuación, el nameserver debe configurarse para alojar los zonefiles del atacante. Esto requiere una configuración correcta de los zonefiles a generar (lo más importante, la dirección IP dada en los registros NS debe coincidir con la dirección IP del contenedor). Si no se ha configurado ninguna red, la dirección IP del contenedor puede verse con: docker container inspect <name> | grep IPAddress

   Genere las zonas con salida de configuración (./gen_zones.py -c, ver arriba) y copie la carpeta de salida de zonas desde el directorio del repositorio al interior del contenedor docker: docker cp ./zones <name>:/etc/nsd

   En la consola del contenedor, el archivo de configuración de NSD /etc/nsd/nsd.conf en el contenedor debe modificarse añadiendo las siguientes líneas:

   root@kitploit:~

   verify:
       enable: no
   remote-control:
       control-enable: no
   
   include: "/etc/nsd/zones/nsd.conf"
   

   Finalmente, ejecute NSD desde la shell del contenedor con el comando /usr/sbin/nsd -d -c /etc/nsd/nsd.conf

   Habilite la salida de logs con la opción -V 4.

   Ahora, si no han ocurrido problemas, el nameserver autoritativo debería estar ejecutándose. Puede verificarlo ejecutando una consulta de uno de los dominios de las zonas desde el sistema anfitrión usando dig: dig @<ip-addr-of-nsd-container> <domain>

2. Instale un resolver. En esta demostración, mostramos un posible enfoque para Unbound 1.17.1.

   Un dockerfile oficial puede encontrarse aquí: https://github.com/NLnetLabs/pythonunbound

   Hemos incluido una versión modificada de este Dockerfile en docker/unbound con una versión actualizada de Ubuntu y preconfigurada para Unbound 1.17.1.

   Clone el repositorio, cambie a su directorio y construya el contenedor de Unbound: docker build -t <tag> .

   Ejecute el contenedor con: docker run --name <name> -it <tag> bash

   A continuación, Unbound debe configurarse de modo que pueda localizar el nameserver autoritativo NSD. Esto se hace modificando el archivo unbound.conf en el directorio de trabajo del contenedor. Para ello, asegúrese de que la entrada server.module-config se elimina de la configuración.

   Para habilitar la validación DNSSEC, los registros DNSKEY de la zona padre del atacante deben configurarse manualmente. Esta debe ser la misma clave que se ha utilizado para generar las firmas, por ejemplo:

   root@kitploit:~

   server:
       chroot: ""
       do-ip6: no
       trust-anchor: "attack.er. DNSKEY 257 3 7 AwEAAdqDN3rJYlmGP3jJs5lCZq5NYrCn pCVlV0ko17JnbfYfLCroEF4reO/Xy0MK C9AVvSRTk83MHDuzMYXogm7m/gcn3Mh0 MwB2InP8jkPw5not+TMH/Wrbs31xkT2n RIBJJ+1lPF+e2AvwWvgREcEVTRbdhIqQ iM1StWXoTVudry4V"
   

   Además, debe configurarse una stub-zone para permitir que el resolver Unbound encuentre el nameserver autoritativo NSD. Esto se logra añadiendo lo siguiente al archivo unbound.conf:

Si tiene algún problema con esta guía, no dude en contactarnos para obtener más orientación.

Inicie unbound en el contenedor con: unbound -vvv (use -dd para evitar la demonización)

Ahora debería poder consultar unbound con dig y observar el tiempo de respuesta: dig @127.0.0.1 attack.er