Le but d'utiliser Unbound est d'avoir localement sur sa station son propre serveur DNS en mode Cache (enregistrant la relation entre noms de domaine, déjà visités et adresses IP correspondantes, afin de ne pas aller interroger les serveurs DNS, à chaque fois… sauf à changement de ladite information).
Utiliser Unbound avec la gestion sécurisée des informations DNS, par le biais de la technologie DNSSEC, est un plus indéniable, car cela permet de s'assurer de la qualité des informations DNS, que celles-ci soient fiables. Ce n'est pas le sujet de cet article de parler du chiffrement et des algorythmes liés.
Utiliser Unbound, en plus en mode protocolaire DNS-over-TLS, permet d'assurer que les communications entre le serveur unbound et les serveurs DNS soient “chiffrées”. Ce n'est pas le sujet de cet article de parler du chiffrement du protocole de communication.
Sous OpenBSD, unbound(8) est intégré nativement !
# rcctl enable unbound
# rcctl start unbound
La configuration d'Unbound ne pose pas de gros problème, en soit, il faut veiller à l'écriture correcte des informations !
NOTE : Ne pas hésiter à lire la documentation officielle et le manpage. Retrouvez les liens adéquats dans le chapitre “Documentation” !
Voyons quelques détails dits de sécurité à paramétrer absolument dans votre propre fichier de configuration : /var/unbound/etc/unbound.conf
ATTENTION : Pour tester la configuration de vos fichiers, utilisez la commande unbound-checkconf(8)
!
Quand vous avez terminé votre configuration, pensez à redémarrer le service lié à unbound :
# rcctl restart unbound
Le fichier root.hints
est une liste des serveurs de noms faisant autorités, les premiers serveurs DNS, dits 'roots'.
Bien qu'OpenBSD semble avoir une liste intégrée, il est intéressant de récupérer ladite liste tous les 6 mois environ.
# ftp -o /var/unbound/db/root.hints http://FTP.INTERNIC.NET/domain/named.cache
Note : Pensez à créer un cron(8) pour aller le récupérer automatiquement !
Puis, modifiez le fichier de configuration, pour ajouter :
root-hints: "/var/unbound/db/root.hints"
La gestion DNSSEC se fait par l'usage de l'outil unbound-anchor(8)
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, dans votre fichier de configuration, tel quel :
# Uncomment to enable DNSSEC validation. # auto-trust-anchor-file: "/var/unbound/db/root.key" # add validation module-config: "validator iterator"
Le mot-clé “validator” doit être présent avant “iterator”.
Pour générer le fichier de clé :
# unbound-anchor -u _unbound -a "/var/unbound/db/root.key"
NB : Il semble que le démarrage d'Unbound via rcctl
utilise cette commande, vous ne devriez donc ne pas avoir à la lancer manuellement sauf en cas de problème.
Note : l'option -u
utilise ici le nom utilisateur, par défaut lié au projet unbound, sous OpenBSD, à savoir _unbound
.
Prenez la peine de vérifier que l'utilisateur système _unbound
a bien le droit d'écrire dans ce dossier. En effet, si c'est le cas, il mettra à jour le fichier de clés racines suivant les règles du RFC 5011 (cf article de Bortzmeyer).
De même, il faut ajouter les variables suivantes à votre propre fichier de configuration :
harden-below-nxdomain: yes harden-dnssec-stripped: yes harden-referral-path: yes
harden-referral-path
renforce la validation DNSSEC - c'est une option expérimentale, sans norme RFC, et peut poser des problèmes de performances !
Depuis la version 1.7.0 d'unbound, une nouvelle option agressive-nsec
qui gère le cache des enregistrements NSSEC est apparue. OpenBSD 6.4 embarque la version 1.8.1. Veillez à l'activer :
aggressive-nsec: yes
Oui, unbound est capable de communiquer aussi avec les serveurs DNS, en mode protocolaire DNS-over-TLS !
Il est nécessaire de bien comprendre l'impact de l'usage de ce mode de communication. Du fait d'utiliser TLS, la communication semble “ralentie”, donner la sensation de lenteur… cela est plus ou moins sensible selon la puissance de votre machine et des serveurs interrogés, de la qualité du réseau, etc…
Il faut configurer unbound ainsi, dans un premier temps :
do-tcp: yes tcp-upstream: yes
Explications :
do-tcp
indique de communiquer sur le protocole TCPssl-upstream
ou tls-upstream
oblige à communiquer sur le protocole TLS.
Ensuite, il est nécessaire de décommenter - si ce n'est pas déjà fait - la partie forward-zone
, pour indiquer le(s) serveur(s) à interroger sur le port adéquat, par défaut le : 853, tel(s) que :
forward-zone: name: "." # use for ALL queries forward-addr: 9.9.9.9@853 # Quad9 forward-addr: 1.1.1.1@853 # Cloudflare forward-addr: 149.112.112.112@853 # Quad9 secondaire forward-addr: 1.0.0.1@853 # Cloudflare secondaire forward-addr: 2620:fe::fe@853 # Quad9 / IPv6 forward-addr: 2606:4700:4700::1111@853 # Cloudflare / IPv6 forward-addr: 2606:4700:4700::1001@853 # Cloudflare secondaire / IPv6
Les serveurs DNS indiqués le sont à titre d'exemples et fonctionnels… mais vous pouvez très bien en ajouter, supprimer d'autres, ne le faire que sur une des deux couches réseaux (soit pour IPv4, soit pour IPv6)… etc…
Le fichier de configuration par défaut contient les déclarations suivantes :
access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow access-control: ::0/0 refuse access-control: ::1 allow
À moins de savoir quoi modifier, laissez tel quel !
Le segment réseau peut-être de type IPv4 ou IPv6. L'action à allouer peut-être :
allow
permet l'accèsallow_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éedeny_non_local
,refuse
refuse l'accès, tout en envoyant un message d'erreur adéquat.refuse_non_local
hide-identity: yes hide-version: yes
harden-algo-downgrade: no harden-glue: 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'.private-address
renforce 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).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 …val-clean-additional
assure de nettoyer toutes les données DNS non sécuriséesnum-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 # Uncomment to enable qname minimisation. # https://tools.ietf.org/html/draft-ietf-dnsop-qname-minimisation-08 # qname-minimisation: yes
Explications :
num-thread
correspond au nombre de cœurs CPU dont disposent 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 : $ sysctl hw.ncpu hw.ncpu=4 $ sysctl hw.ncpufound hw.ncpufound=4
slabs
doivent être paramétrées au double de la variable num-thread
. Ces variables gèrent les conflits de verrouillage en les diminuant.*-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'.outgoing-range
qui gère le nombre de connexions par cœurs CPU doit être ainsi calculée : 1024 / nb_coeurs_CPU - 50so-rcvbuf
, et sondbuf
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 !qname-minimisation
a pour propos d'améliorer les informations privées liées à l'usage de DNS.# garde en cache les bons résultats prefetch: yes cache-min-ttl: 3600 cache-max-ttl: 86400
unwanted-reply-threshold: 10000000 logfile: /var/unbound/etc/unbound.log val-log-level: 2 verbosity: 1
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 nettoyages 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 ! Pour info, l'excellente documentation de Calomel recommande 10000.verbosity
est le degré de verbosité des journaux. statistics-interval: 0 extended-statistics: yes statistics-cumulative: no
statistics-cumulative
est à paramétrer sur 'yes' si vous utilisez un outil d'affichage graphique des rapports, tel que Munin …Il suffit de télécharger une liste de noms de domaines de sites publicitaires, par exemple, puis de l'inclure dans le fichier de configuration de la façon suivante :
include: /var/unbound/etc/listes
Note : le nom de la liste n'importe pas ou prou, si ce n'est de restituer correctement le nom que vous lui avez donnée dans le fichier de configuration !
Le site “https://pgl.yoyo.org/adservers/” met à jour, régulièrement une liste de noms de domaines, que vous pouvez utiliser, pour bloquer ces sites !
# ftp -o /var/unbound/etc/unbound_ad_servers "http://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&mimetype=plaintext"
Dans le cas de cette liste, le nom donné est bien /var/unbound/etc/unbound_ad_servers
!
Le projet “BlockZones” a pour but de créer une liste unique combinée, à partir de plusieurs sites connus (dont celui de PGL YOYO, ci-dessus) pour fournir des listes de noms de domaines ayant une activité suspecte, en les formatant pour différents usages, ou services.
Il fournit des listes pour différents services serveurs :
Ces listes sont mises-à-jours, tous les jours … sur le site de PengouinPdt où vous trouverez les listes correspondants aux services ci-dessus, et les fichiers de sommes de contrôle sha512 !
Note : Pour les services, comme 'unbound', ne pas choisir d'activer toutes les urls du fichier 'domains', autrement vous aurez le droit à des dépassement de mémoire, signifiant que le service ne peut gérer l'ensemble de la liste - la configuration proposée par défaut est suffisamment gérable !
Vous pouvez utiliser le script suivant pour installer facilement le fichier /etc/hosts
proposé ci-dessus ainsi que le filtre pour unbound, proposé sur le git du projet !
Note : Le script ci-dessus a pour objectif de créer un cron(8) pour aller récupérer automatiquement, une fois par mois, les listes pour le service 'unbound' et le fichier '/etc/hosts' ; vous pouvez vous-même éditez le fichier /etc/monthly.local puis ajouter la commande de récupération, ci-dessus …
Pour utiliser unbound
, avec une connexion obtenue via dhcp, modifiez le fichier /etc/dhclient.conf
tel que :
prepend domain-name-servers 127.0.0.1;
Un premier test à faire est l'usage de la commande dig(1)
, telle que :
$ dig com. SOA +dnssec ; <<>> DiG 9.4.2-P2 <<>> com. SOA +dnssec ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45121 ;; 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
L'autre commande à utiliser est la commande 'unbound-host(1)' qui permet de s'assurer du même résultat, telle que :
$ unbound-host -v -f /var/unbound/db/root.key com. com. has no address (secure) com. has no IPv6 address (secure) com. has no mail handler record (secure)
$ unbound-host -v -f /var/unbound/db/root.key www.ripe.net www.ripe.net has address 193.0.6.139 (secure) www.ripe.net has IPv6 address 2001:67c:2e8:22::c100:68b (secure) www.ripe.net has no mail handler record (secure) $ unbound-host -v -f /var/unbound/db/root.key www.afnic.fr www.afnic.fr is an alias for lb01-1.nic.fr. (secure) lb01-1.nic.fr has address 192.134.5.24 (secure) lb01-1.nic.fr has IPv6 address 2001:67c:2218:30::24 (secure) lb01-1.nic.fr has no mail handler record (secure) $ unbound-host -v -f /var/unbound/db/root.key dnssec.cz 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 -v -C /var/unbound/etc/unbound.conf dnssec.cz 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)
Un moyen visuel est d'ouvrir votre navigateur internet favori, puis d'aller sur les sites suivants :