Debian : Utiliser Unbound avec DNSSEC + dnssec-trigger

Article publié, le 1 Septembre 2016 et modifié le 20 Avril 2020
9 minutes de lecture

Cet article contient 1804 mots.
Source brute de l'article :
Commit version : 03259cc

Description

Le but d’utiliser Unbound est d’avoir localement sur sa station son propre serveur DNS Cache (enregistrant la relation noms de domaine et adresses IP déjà visités, afin de ne pas aller interroger les serveurs DNS Root, sauf à changement de ladite information). Et, utiliser Unbound avec la gestion sécurisée des informations DNS, par le biais de la technologie DNSSEC, est un plus indéniable (cela évite d’avoir à obtenir des informations DNS faussées, par une action pirate).

Cette dernière est assumée, en partie, par l’outil dnssec-trigger !

Versions utilisées

OS : Debian Stable / Sid
unbound : selon la version de Debian utilisée
dnssec-trigger : selon la version de Debian utilisée

Installation

Avec Debian, comme d’habitude, rien de bien compliqué !

# apt install unbound unbound-host dnssec-trigger

Les fichiers de configuration principaux :

d’unbound sont dans /etc/unbound/ ;
ceux de dnssec-trigger dans /etc/dnssec-trigger/

Info

Préférez utiliser la version des backports !

dnssec-trigger

Testez que l’installation de dnssec-trigger est correcte à l’aide de la commande de contrôle dnssec-trigger-control-setup :

Code : shell

# dnssec-trigger-control-setup 
setup in directory /etc/dnssec-trigger 
dnssec_trigger_server.key exists 
dnssec_trigger_control.key exists 
create dnssec_trigger_server.pem (self signed certificate) 
create dnssec_trigger_control.pem (signed client certificate) 
Signature ok 
subject=/CN=dnssec-trigger-control 
Getting CA Private Key 
Setup success. Certificates created. 

run this script again with -i to: 
	- enable remote-control in unbound.conf 
	- start unbound-control-setup 
	- add root trust anchor to unbound.conf 
if you have not done this already

Si c’est votre cas, c’est une bonne chose ! :p

Pensez à redémarrer le service lié à unbound !

Configuration

Unbound

La configuration d’unbound ne pose pas de gros problème, en soit, il faut veiller à l’écriture correcte des informations !

Toutes les variables et leur impact sont expliquées dans la documentation officielle anglaise : https://unbound.net/documentation/unbound.conf.html

Voyons quelques détails dits de sécurité à paramétrer absolument dans votre propre fichier de configuration, que l’on nommera ainsi, pour l’exemple : /etc/unbound/unbound.conf.d/perso.conf

Pour tester la configuration de vos fichiers, utilisez la commande unbound-checkconf !

Gestion des réseaux autorisés

access-control: 127.0.0.0/8 allow ## j’autorise l’interface de bouclage local sur la couche IPv4 access-control: 192.168.1.0/24 allow ## j’autorise le réseau local access-control: 0.0.0.0/0 refuse ## j’interdis tout le reste de l’Internet !

Le segment réseau peut-être de type IPv4 ou IPv6. L’action à allouer peut-être :

allow permet l’accès
allow_snoop permet l’accès, en utilisant une technique de “cache snopping”, qui donne le droit d’examiner le contenu en cache.
deny refuse l’accès - option par défaut, si non spécifiée
deny_non_local,
refuse refuse l’accès, tout en envoyant un message d’erreur adéquat.
ou refuse_non_local

Pour les autres options, ou afin de mieux saisir les subtilités, merci de lire la page officielle anglaise !

Durcir et cacher certaines informations

Code : unbound

harden-algo-downgrade: no 
harden-glue: yes
    
hide-identity: yes
hide-version: yes
    
private-address: 192.168.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
    
use-caps-for-id: no
    
val-clean-additional: yes

Explications

harden-algo-downgrade empêche ou non de choisir l’algorithme le plus faible .
- Si no est choisi, ce sera l’algorithme le plus faible qui sera élu…
- Si les zones DNS ne sont pas configurées pour fonctionner correctement avec cette option, cela peut entraîner des échecs de validation ; dans ce cas, il faut la mettre sur no. Cette option n’est pas reconnue avec la version Jessie, utilisez la version backports !
Les variables private-address renforcent l’aspect privé de ces réseaux. Cela empêche l’inclusion de ces segments réseaux dans les réponses DNS, et protège de la technique des “Relais DNS” (qui utilise, par exemple, un navigateur internet comme relais ou proxy réseau).
La variable use-caps-for-id est expérimentale et peut créer des bogues, ou résultats incorrects - ne pas l’utiliser à moins d’être sûr de ce que vous faites…
La variable val-clean-additional assure de nettoyer toutes les données DNS non sécurisées

Optimisation

Code : unbound

num-threads: 4
    
key-cache-slabs: 8
infra-cache-slabs: 8
msg-cache-slabs: 8
rrset-cache-slabs: 8

key-cache-size: 16m
msg-cache-size: 4m
rrset-cache-size: 8m

outgoing-range: 206

qname-minimisation: yes

so-rcvbuf: 1m
so-sndbuf: 1m

so-reuseport: yes

Explications

La variable num-thread correspond au nombre de cœurs CPU dont dispose votre station, soit pour 4 CPU ayant chacun deux cœurs, on lui attribuera le chiffre 8. Une manière d’être sûr du nombre de cœurs utilisés dans votre machine est d’utiliser la commande suivante : $ cat /proc/cpuinfo | grep processor | wc -l
Les variables terminant par le mot *-cache-slabs doivent être paramétrées au double de la variable num-thread. Ces variables gèrent les conflits de verrouillage en les diminuant.
La gestion des variables *-cache-size est sensible et doit être ainsi paramétrée : la variable rrset-cache-size doit être le double de la variable msg-cache-size ; quant à la variable key-cache-size, elle doit être elle-même le double de la variable rrset.
La variable outgoing-range qui gère le nombre de connexions par cœurs CPU doit être ainsi calculée : 1024 / nb_coeurs_CPU - 50
La variable so-reuseport permet d’améliorer significativement les performances de l’usage du protocole UDP !
La variable qname-minimisation envoie un minimum d’information DNS pour améliorer l’aspect privé de celles-ci : Cette option n’est pas reconnue avec la version Jessie, utilisez la version backports !
Lisez la documentation officielle anglaise pour les options so-rcvbuf, et so-sndbuf qui doivent être augmentées dans le cas de serveur surchargé. Autrement, laissez la valeur 0 par défaut - cela utilise les valeurs systèmes !

Gestion des caches

Code : unbound

# garde en cache les bons résultats
prefetch: yes
  
cache-min-ttl: 3600
cache-max-ttl: 86400

Gestion des journaux

Code : unbound

# gestion logs
logfile: /var/log/unbound/unbound.log
use-syslog: yes
unwanted-reply-threshold: 10000000
val-log-level: 2
verbosity: 1

Explications

Si l’option unwanted-reply-threshold est définie, le nombre paramétré total de réponses indésirables est gardé dans chacun des processus. Ce nombre paramétré atteint déclenche une action défensive de nettoyage des caches rrset et autres messages, un avertissement est affiché dans les journaux. Il est recommandé de positionner ce nombre à une valeur de 10 Millions !
L’option verbosity est le degré de verbosité des journaux :
- 0 signifie que seules les erreurs seront affichées ;
- 1 que ce sont des informations opérationnelles - valeur par défaut - ;
- 2 que celles-ci seront plus détaillées ;
- 3 définit les informations par niveau de requêtes et leurs sorties ;
- 4 restitue l’information du niveau d’algorithme utilisé ;
- 5, quant à lui, enregistre l’identification des clients en cas d’erreurs de cache.

Bloquer certains sites

Code : unbound

# bloque certaines pubs
local-zone: "doubleclick.net" redirect
local-data: "doubleclick.net A 127.0.0.1"
local-zone: "googlesyndication.com" redirect
local-data: "googlesyndication.com A 127.0.0.1"
local-zone: "googleadservices.com" redirect
local-data: "googleadservices.com A 127.0.0.1"
local-zone: "google-analytics.com" redirect
local-data: "google-analytics.com A 127.0.0.1"
local-zone: "ads.youtube.com" redirect
local-data: "ads.youtube.com A 127.0.0.1"
local-zone: "adserver.yahoo.com" redirect
local-data: "adserver.yahoo.com A 127.0.0.1"
local-zone: "ask.com" redirect
local-data: "ask.com A 127.0.0.1"

Info

Pour info, il existe des projets de listes, tels que :

PGL-Yoyo
l’excellent unbound-badhosts

Dans le cas d’usage de listes, il faut les inclure en utilisant la déclaration : include: /var/lib/unbound/nom-fichier-liste

Gérer des statistiques

Code : unbound

statistics-interval: 0
extended-statistics: yes
statistics-cumulative: no

Explications

L’option statistics-cumulative est à paramétrer sur yes - si vous utilisez un outil d’affichage graphique des rapports, tel que Munin…

Fichier root.hints

Le fichier root.hints est une liste des serveurs de noms faisant autorité, les premiers serveurs DNS, dits roots.

Pour le récupèrer : # curl ftp://FTP.INTERNIC.NET/domain/named.cache -o /var/lib/unbound/root.hints

Puis, modifiez le fichier de configuration, pour ajouter : root-hints: "var/lib/unbound/root.hints

Astuce

Pensez à créer un fichier cron pour mettre-à-jour régulièrement ce fichier… normalement, une période de 6 mois suffit.

Gestion DNSSEC

La gestion DNSSEC se fait par l’usage de l’outil unbound-anchor qui crée un fichier de clé nécessaire et l’ajout de la variable auto-trust-anchor-file qui pointe vers ledit fichier de clés.

Exécutez : # unbound-anchor -a "/var/lib/unbound/root.key"

La variable auto-trust-anchor-file est normalement déclarée dans le fichier /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf. Si ce fichier n’existe pas, vous pouvez l’ajouter à votre fichier de configuration personnel, ou créer ledit fichier qui sera pris en charge lors du (re)démarrage lié au service unbound.

Elle a cette teneur : auto-trust-anchor-file: "/var/lib/unbound/root.key"

De même, il faut ajouter les variables suivantes à votre propre fichier de configuration :

Code : unbound

harden-below-nxdomain: yes
harden-dnssec-stripped: yes
harden-referral-path: yes

Explications

L’option harden-referral-path renforce la validation DNSSEC - c’est une option expérimentale, sans norme RFC, et peut poser des problèmes de performances !

Attention

Veillez à redémarrer le service unbound si vous l’avez configuré après l’installation et le démarrage post-install !

Tests DNSSEC

Dig

Un premier test à faire est l’usage de la commande dig, telle que :

Code : shell

$ dig com. SOA +dnssec 

; <<>> DiG 9.10.3-P4-Debian <<>> com. SOA +dnssec 
;; global options: +cmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60764 
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 1 

(…)

Ce qu’il faut repérer dans la sortie complète de la commande dig est sur la ligne flags: : il faut la présence du drapeau ad - si celui-ci figure bien, c’est bon signe ! :D

$ dig com. SOA +dnssec | grep ";; flags" ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Unbound-host

L’autre commande à utiliser est la commande unbound-host qui permet de s’assurer du même résultat, telle que :

Code : shell

$ unbound-host com. -f /var/lib/unbound/root.key -v 
com. has no address (secure) 
com. has no IPv6 address (secure) 
com. has no mail handler record (secure)

$ unbound-host dnssec.cz -f /var/lib/unbound/root.key -v 
dnssec.cz has address 217.31.205.51 (secure) 
dnssec.cz has IPv6 address 2001:1488:0:3::5 (secure) 
dnssec.cz mail is handled by 10 mail.nic.cz. (secure) 
dnssec.cz mail is handled by 15 mx.nic.cz. (secure) 
dnssec.cz mail is handled by 20 bh.nic.cz. (secure)

# unbound-host dnssec.cz -C /etc/unbound/unbound.conf -v 
[1472755792] libunbound[44222:0] debug: switching log to /var/log/unbound/unbound.log 
dnssec.cz has address 217.31.205.51 (secure) 
dnssec.cz has IPv6 address 2001:1488:0:3::5 (secure) 
dnssec.cz mail is handled by 10 mail.nic.cz. (secure) 
dnssec.cz mail is handled by 15 mx.nic.cz. (secure) 
dnssec.cz mail is handled by 20 bh.nic.cz. (secure)

dnssec-trigger

Utilisez l’outil dnssec-trigger est trivial :

Code : shell

# dnssec-trigger-control status  
at 2016-09-01 08:41:22 
authority 192.33.4.12: OK 
http ster.nlnetlabs.nl (185.49.140.10): OK 
state: auth secure

Navigateur internet

Un moyen visuel est d’ouvrir votre navigateur internet favori, puis d’aller sur les sites suivants :

http://www.dnssec.cz : si, sur la partie droite, vous voyez une clé verte, c’est tout autant bon signe !
https://en.internet.nl : cliquez sur le lien titré “Test my internet connection”

Cron

Pensez à créer un fichier cron mensuel /etc/crond.monthly/unbound, pour mettre-à-jour les fichiers root.hints, et ads server :

Code : shell

#!/bin/sh
    
# update  file named.cache
curl ftp://FTP.INTERNIC.NET/domain/named.cache -o /var/lib/unbound/root.hints
    
# update file ads servers
curl -sS -L --compressed "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&mimetype=plaintext" > /var/lib/unbound/unbound_ad_servers
chown unbound:unbound /var/lib/unbound/unbound_ad_servers

Dépannage

fatal error: SSL handshake

Si vous avez l’erreur ci-dessous :

# dnssec-trigger-control status Mar 20 15:08:13 dnssec-trigger-control[2016] fatal error: SSL handshake failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

redémarrez d’abord le service unbound !

Documentations

Pour en savoir un peu plus sur l’outil, les raisons de son existence et de son usage, lisez l’article de Stéphane Bortzmeyer : dnssec-trigger, un outil pour mettre DNSSEC à la disposition de M. Toutlemonde…

J’ai écrit pour la première fois cet article pour le wiki de la communauté de Debian-fr.xyz !