OpenBSD : Unbound control

Article publié, le
5 minute(s) de lecture

Cet article contient 912 mots.
Source brute de l'article : MD

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 OpenBSD : utiliser Unbound et celui-ci pour plus de “sécurité” autour des communications DNS OpenBSD : Unbound en mode DNSSEC + DNS/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 : shell

# unbound-control-setup                                                                                                 
setup in directory /var/unbound/etc
generating unbound_server.key
Generating RSA private key, 3072 bit long modulus
...............................................................................................................++
............................................................++
e is 65537 (0x10001)
generating unbound_control.key
Generating RSA private key, 3072 bit long modulus
........................................................................++
..................++
e is 65537 (0x10001)
create unbound_server.pem (self signed certificate)
create unbound_control.pem (signed client certificate)
Signature ok
subject=/CN=unbound-control
Getting CA Private Key
Setup success. Certificates created. Enable in unbound.conf file to use

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 : shell

remote-control:
        control-enable: yes
        control-use-cert: no
        control-interface: /var/run/unbound.sock

Pour pouvoir l’administrer localement, il est nécessaire de commenter la déclaration control-interface et d’ajouter celles-ci :

Code : shell

        #control-interface: /var/run/unbound.sock
        control-interface: 127.0.0.1
        control-interface: ::1

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 pare-feu 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 : shell

    $ unbound-control -s ::1 status                                                                                                          
    version: 1.8.1
    verbosity: 1
    threads: 2
    modules: 2 [ validator iterator ]
    uptime: 49932 seconds
    options: reuseport control
    unbound (pid 99951) is running…
    
  • 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 PF :

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 : PF

(…)
myhost = "192.168.1.1"
unbound_ctlr = "8953"
(…)
table <t_adm> const { 192.168.1.3, fd0::3 }
(…)
blog log
pass out
(…)

pass in quick on egress  proto tcp from <t_adm>  to $myhost port $unbound_ctlr flags S/SA modulate state

Autrement dit, on autorise le flux entrant sur l’interface egress depuis les adresses IPv4|6 intégrées dans la table <t_adm> 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 : PF

(…)
myhost = "192.168.1.3"
server    = "192.168.1.1"
unbound_ctlr = "8953"
(…)
blog log
pass out
(…)
pass out quick on egress inet  proto tcp from $myhost  to $server  port $unbound_ctlr flags S/SA modulate state

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

Manpage


Enjoy-ID!
Enjoy-IT!