Debian : Utiliser Unbound avec DNSSEC + dnssec-trigger

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

Cet article contient 1413 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

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

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

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

Gestion des journaux

Code : unbound

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

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

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

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

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

dnssec-trigger

Utilisez l’outil dnssec-trigger est trivial :

Code : shell

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

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 !