« Utiliser Unbound avec DNSSEC » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 22 : | Ligne 22 : | ||
La configuration d'Unbound ne pose pas de gros problème, en soit, il faut veiller à l'écriture correcte des informations ! | La configuration d'Unbound ne pose pas de gros problème, en soit, il faut veiller à l'écriture correcte des informations ! | ||
{{Note2|Text=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 | 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 |
Version du 1 septembre 2016 à 22:37
Utiliser Unbound avec DNSSEC
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 !
Installation de Unbound et de l'outil dnssec-trigger
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/
Configuration de Unbound
La configuration d'Unbound ne pose pas de gros problème, en soit, il faut veiller à l'écriture correcte des informations !
NOTE : 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
Gestion des réseaux autorisés
access-control: 127.0.0.0/8 allow ## j'autorise mon serveur 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 !
Durcir et cacher certaines informations
harden-algo-downgrade: no # créer de faux positifs avec les zones DNS mal configurées, si actif harden-below-nxdomain: yes harden-dnssec-stripped: yes harden-glue: yes harden-referral-path: yes hide-identity: yes hide-version: yes use-caps-for-id: no # créer des erreurs de requêtes DNS si actif
Optimisation
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
so-rcvbuf: 4m so-sndbuf: 4m
so-reuseport: yes
Explications :
- La variable '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 :
$ cat /proc/cpuinfo | grep processor | wc -l
- Les variables terminant par le mot '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 - n'est fonctionnelle que sous Linux !
Gestion des caches
# garde en cache les bons résultats prefetch: yes cache-min-ttl: 3600 cache-max-ttl: 86400
Gestion des journaux
# gestion logs logfile: /var/log/unbound/unbound.log use-syslog: yes val-clean-additional: yes val-log-level: 2 verbosity: 3
Bloque certains sites
# bloque cetaines 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"
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.
# 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 personnelle, 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"
ATTENTION : Veillez à redémarrer le service unbound si vous l'avez configuré après l'installation et le démarrage post-install !
Dig test DNSSEC
Un premier test à faire est l'usage de la commande 'dig', telle que :
$ 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
Unbound-host test DNSSEC
L'autre commande à utiliser est la commande 'unbound-host' qui permet de s'assurer du même résultat, telle que :
$ 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)
Test visuel
Un moyen visuel est d'ouvrir votre navigateur internet favori, puis d'aller sur les sites suivants :
- 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"
Documentation à finir !!!