OBSD4* : wiki

Forum -

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, par une action “étatique” …).

Sous OpenBSD, unbound(8) est intégré nativement !

  • Pour activer unbound, tapez :
    # rcctl enable unbound
  • Pour le démarrer :
    # rcctl start unbound

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 ou dans la page de manuel unbound.conf(5) relative !

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

Fichier root.hints

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/etc/root.hints ftp://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/etc/root.hints"

Gestion DNSSEC

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"

Pour générer le fichier de clé :

# unbound-anchor -u _unbound -a "/var/unbound/db/root.key" 

Note : l'option '-u' utilise ici le nom utilisateur, par défaut lié au projet unbound, sous OpenBSD, à savoir '_unbound'.

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
  • 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 !

Gestion des réseaux autorisés

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è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'

Durcir et cacher certaines informations

      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'.
  • Les variables '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).
  • 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

Optimisations

      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
      
      # Uncomment to enable qname minimisation.
      # https://tools.ietf.org/html/draft-ietf-dnsop-qname-minimisation-08
      #
      qname-minimisation: 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 :
$ sysctl hw.ncpu                                                                                                                           
hw.ncpu=4
$ sysctl hw.ncpufound
hw.ncpufound=4
  • 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
  • Lisez la documentation officielle anglaise pour les options 'so-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 !
  • L'option 'qname-minimisation' a pour propos d'améliorer les informations privées liées à l'usage de DNS.

Gestion des caches

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

Gestion des journaux

      unwanted-reply-threshold: 10000000
      logfile: /var/unbound/etc/unbound.log
      val-log-level: 2
      verbosity: 1
  • 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 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.
  • 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.

Gestion des statistiques

      statistics-interval: 0
      extended-statistics: yes
      statistics-cumulative: no
  • L'option 'statistics-cumulative' est à paramétrer sur 'yes' si vous utilisez un outil d'affichage graphique des rapports, tel que Munin …

Bloquer certains sites

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 !

PGL YOYO

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' !

Projet BlockZones

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 :

  • pour Unbound - *.
  • pour Bind - *.
  • pour le fichier /etc/hosts - Vous pouvez activer toutes les urls du fichier 'domains'.

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 !

Fichier cron

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 …

Vérification

Dig test DNSSEC

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

Unbound-host test DNSSEC

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)

Test visuel graphique

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”

Documentations

Outre les pages de manuels OpenBSD :