--- categories: ['OpenBSD','Réseau','Serveur'] date: 2018-10-23T15:08:43+02:00 description: "Comment contrôler son service unbound, sous OpenBSD, avec la commande `unbound-control`" draft: false tags: ['OpenBSD','unbound','supervision'] title: "OpenBSD : Unbound control" translationKey: 'openbsd-unbound-control' --- ## Description Le but de cet article est de montrer comment obtenir les différentes informations qu'unbound permet de surveiller, et se base sur l'outil `unbound-control`. ## Configuration Pour rappel : * le fichier de configuration est normalement : `/var/unbound/etc/unbound.conf` * la commande pour tester la configuration est : `unbound-checkconf` Je ne rappellerai pas comment configurer pleinement Unbound, lisez cet article **{{< inside "sys:openbsd:unbound" >}}** et celui-ci pour plus de "sécurité" autour des communications DNS **{{< inside "sys:openbsd:unbound-dnssec-dns-over-tls" >}}** ;-) ### unbound-control-setup La première chose, à faire sur votre serveur, est l'usage de l'outil `unbound-control-setup`, afin de générer les clés et certificats nécessaires pour gérer le service : {{< code "unbound-control-setup" shell >}} Les clés et certificats étant générés, il ne reste plus qu'à retoucher le fichier de configuration pour activer le service de gestion de contrôle, qui permet de le gérer aussi à distance ! ### unbound-control Ouvrons le fichier de configuration d'unbound, pour le modifier de manière adéquate - par défaut, il se présente ainsi : {{< code "unbound-remote-control-default" shell >}} Pour pouvoir l'administrer localement, il est nécessaire de commenter la déclaration `control-interface` et d'ajouter celles-ci : {{< code "unbound-remote-control-interface-localhost" shell >}} Il est bien sûr possible de spécifier l'adresse IPv4 ou IPv6 du serveur, celles de votre LAN, ou celles accessibles sur Internet.
Lire les règles de {{< anchor "pare-feu" "pf" >}} envisageables pour sécuriser la connexion. ---- Maintenant, après avoir vérifié le fichier de configuration et recharger/relancer le service unbound, il est possible au moins localement d'utiliser l'outil `unbound-control`. Lisez ABSOLUMENT le manpage pour savoir quelles sont les différentes options, voici les plus utiles : * `-c` : spécifier un fichier de configuration alternatif * `-h` : obtenir l'aide * `-s` : cibler le serveur à interroger ; *fonctionne sur IPv4 et IPv6* : `server[@port]` : * si le port n'est pas spécifié, ce sera celui par défaut `8953`,
* sinon modifiez-le dans le fichier de configuration. Ensuite, il est possible d'envoyer des commandes qui interagiront avec le serveur, de telle manière :
`$ unbound-control -s 127.0.0.1 command_name` Il y a beaucoup de commande possibles, voici certaines : * `start` : démarrer le serveur * `stop` : arrêter le serveur * `reload` : purge le cache et recharge la configuration * `stats` : affiche les statistiques et remets à zéro les compteurs internes * `stats_noreset` : affiche les statistiques sans remettre à zéro les compteurs internes * `status` : affiche le status du serveur * `0`, s'il fonctionne * `1`, s'il y a une erreur * `3`, soit s'il ne fonctionne pas, soit si la connexion est refusée. * `dump_cache` permet d'afficher/imprimer le contenu du cache ; il est ainsi possible de le rediriger vers un fichier pour enregistrer ces données. * `load_cache` charge le contenu d'un cache depuis stdin… aide au débogage. * `get_option //option//` pour obtenir la valeur d'une option, où `option` est le nom de l'option * `set_option //option:valeur//` permet de définir la valeur d'une option… où `option` est le nom de l'option, et `valeur`, sa valeur adéquate. Les options paramétrables sont : * `add-holddown`, * `cache-max-ttl`, `cache-max-negative-ttl`, `cache-min-ttl` * `del-holddown`, `do-not-query-localhost`, * `harden-below-nxdomain`, `harden-dnssec-stripped`, `harden-glue`, `harden-large-queries`, `harden-referral-path`, `harden-short-bufsize`, * `hide-identity`, `hide-version`, * `identity`, `ignore-cd-flag`, `ip-ratelimit`, * `keep-missing`, * `log-queries`, `val-log-level`, `val-log-squelch`, * `max-udp-size`, * `prefetch`, `prefetch-key`, * `ratelimit`, * `statistics-cumulative`, `statistics-interval`, * `ssl-upstream`, `tcp-upstream`, * `version`, Ensuite, il est possible de gèrer : * les zones locales `local-zone` * et leurs données `local-data`, * toutes les options `auth_*`, `dump_*`, `flush_*`, `forward_*`, `insecure_*`, `list_*`, `*ratelimit_*`, `stub_*`, `view_*` mais là, encore une fois, je vous invite à relire le manpage. ;) #### Exemples * `status` :
{{< code "unbound-control-status-example" shell >}} * `get_option` :
`$ unbound-control -s ::1 get_option harden-glue`
`yes` * `dump_cache` :
`$ unbound-control -s ::1 dump_cache > dump.unbound`
il ne vous reste plus qu'à lire le fichier `dump.unbound` ; *bien sûr, il peut porter tout autre nom que vous désirez*. ### PF Voici quelques règles - d'exemples - pour le pare-feu {{< abbr PF "Packet-Filter" >}} : #### PF : côté serveur Si vous utilisez l'option `control-interface` en permettant que ce soit l'IP publique sur Internet ou sur votre LAN qui soit consultable, il est fortement recommandé de modifier vos règles PF, afin de n'autoriser que le flux venant d'une machine autorisée, telle que : {{< code "sys-openbsd-unbound-pf-rules-server-example" PF >}} Autrement dit, on autorise le flux entrant sur l'interface `egress` depuis les adresses IPv4|6 intégrées dans la table `` vers le serveur `$myhost` sur le port `$unbound_ctlr`. #### PF : côté station Pour votre station autorisée ayant, par exemple, l'adresse IPv4 `192.168.1.3` : {{< code "sys-openbsd-unbound-pf-rules-station-example" PF >}} On autorise le flux sortant de votre machine autorisée vers le serveur sur le port adéquate… Bien-sûr, faites de même pour IPv6. ## Documentations * {{< inside "sys:openbsd:unbound" >}} * {{< inside "sys:openbsd:unbound-dnssec-dns-over-tls" >}} ### Manpage * {{< man unbound-control 8 >}} ---- ***Enjoy-ID!
Enjoy-IT!*** ---