--- aliases: [/fr/sys/openbsd/snmpd/] date: 2019-11-20T22:43:39+01:00 description: "Comment mettre en place le service de monitoring SNMPd sous OpenBSD" draft: false include_toc: true lastmod: 2019-11-21T16:00:00+01:00 show_comments: false tags: ["OpenBSD","snmpd","snmp","serveur","supervision"] title: "Snmpd : Monitorer OpenBSD" --- ## Description **OpenBSD** intègre par défaut dans le système de base **snmpd** qui est le démon du service SNMP. * OpenBSD : 6.6 * Service : snmpd ## Documentation La documentation se fait au-travers des différents manpages, tels que : * {{< man snmpd 8 >}} * {{< man "snmpd.conf" 5 >}} ## Configuration La configuration du serveur **snmpd** se fait, *à minima*, au-travers d'un seul fichier de configuration, à créer : `/etc/snmpd.conf`. Il existe trois versions du protocol ; la v1 est l'historique à ne plus utiliser ; la v2 apporte des prémices de sécurité ; la v3 est la plus sécurisante, néanmoins, il faut utiliser les niveaux de sécurité et de chiffrement les plus forts. *(Pour info, dans certaines conditions, la v3 est aussi faillible et sujette à vulnérabilités)*. Après avoir écrit le fichier de configuration, il faut donner les droits d'exécution adéquates et utilisateur au fichier de configuration : {{< code "openbsd-snmpd-rights" sh >}} ### Configuration Globale Plusieurs options peuvent être paramétrées : * `filter-routes` (**yes**|**no**): permet au noyau de filter les messages de mise à jour des routes dans le socket. * `listen on` *address* [**tcp**|**udp**]: spécifie l'adresse locale qui doit écouter les messages SNMP entrants. *Il est possible de la spécifier plusieurs fois*. Les deux protocoles **TCP** et **UDP** sont gérés. * `read-only` : spécifie la communauté autorisée en lecture seule. Par défaut, la valeur est `public` * `read-write` (**community** *string* | **disabled**) : Soit spécifie la communauté autorisée en lecture et écriture, soit désactive l'écrite définitivement. Par défaut, la valeur est `private` * `seclevel` : spécifie le niveau le plus bas de sécurité que snmpd(8) accepte. Par défault, la valeur est `none`. Si l'une des deux autres options `auth` ou `enc` est choisie, snmpd(8) n'acceptera que les requêtes SNMPv3. `enc` oblige à ce que les messages soient chiffrés et une authentification valide, autrement ils seront supprimés. * Il existe aussi l'option `socket`, les différentes options `system` et celles relatives à `trap`. Je renvoie au manpage ;) Les deux options `read_*` ne servent QUE pour une configuration SNMP v2. ### Macros Des macros peuvent être définies. Considérez-les comme des variables. On ne peut utiliser des mots clés réservés. Elles commencent forcément par une lettre, un chiffre ou le symbole '`_` ' suivi de tout autre caractère. ### Configuration des utilisateurs Avec SNMPv3, Il est possible de définir plusieurs utilisateurs par le biais de l'option `user`, tel que : * `user` *name* **authkey** *key* **auth** *hmac* **enckey** *key* **enc** *cipher* * `authkey` est requis pour authentifier les messages en spécifiant une clé. Si la clé est omise, pas d'authentification. * `auth` *hmac* permet de cibler l'algorithme HMAC à utiliser. Par défaut, la valeur est `hmac-sha1`. La valeur la plus forte est `hmac-sha512`. * `enckey` *key* est la clé de chiffrement utilisé pour chiffrer et déchiffrer les messages dans un soucis de confidentialité. Sans, le compte utilisateur n'acceptera jamais l'entrée des messages ou ne chiffrera pas les messages sortants. * `enc` *cipher* est l'algorithme utilisé. Par défaut, sa valeur est `des`. Sa valeur la plus forte est `aes`. Il faut bien comprendre que le nom de l'utilisateur, les caractères donnant la valeur des clés `key` sont des choix purement arbitraires. À vous de les spécifier… ### Configuration des OID Les **OID** sont les identifiants des objets. Je renvoie au manpage, si besoin de les gérer. ## Utilisation * Le service se nomme logiquement : `snmpd` * L'option de test de configuration : `-n` Ainsi la commande `snmpd -n` permettra de s'assurer de la validité de l'ensemble de la configuration, à tout moment. À chaque modification du {{< anchor "fichier de configuration" "configuration" >}}, il faudra relancer le service ad hoc. ### SNMP v2 Pour débuter, commençons par : {{< code "openbsd-snmpd-snmpv2-example" >}} À minima, nous n'avons besoin de rien de plus. C'est très basique et permet de tester/s'assurer du bon fonctionnement, de la bonne compréhension. Testons la réponse : {{< code "openbsd-snmpd-snmpv2-test" sh >}} Ce sont des exemples d'interrogation et réponses. ### SNMP v3 #### Sans sécurité Commençons avec un exemple sans sécurité : {{< code "openbsd-snmpd-snmpv3-none-example" >}} Après le rédémarrage du service : {{< code "openbsd-snmpd-snmpv3-none-test" sh >}} #### Utilisateur authentifié {{< code "openbsd-snmpd-snmpv3-auth-example" >}} Après le rédémarrage du service : {{< code "openbsd-snmpd-snmpv3-auth-test" sh >}} #### Authentification forte Configurons le serveur par un exemple fort : {{< code "openbsd-snmpd-snmpv3-enc-example" >}} Après le redémarrage du service : {{< code "openbsd-snmpd-snmpv3-enc-test" sh >}} ### Gestion du service * activation : `rcctl enable snmpd` * démarrage : `rcctl start snmpd` Après avoir activé et démarré le service, il est possible de vérifier le fonctionnement du service, tel que : {{< code "openbsd-snmpd-check-service" sh >}} Voilà, pour la partie serveur ! Et les clients ? ### Les clients Depuis OpenBSD 6.6, le client natif est {{< man snmp >}} Pour information, il y a sur chaque système OpenBSD, dans le répertoire `/usr/share/snmp/mibs/` l'ensemble de fichiers MIB qui renferment toutes informations utiles : {{< code "openbsd-ls-snmp-mibs" sh >}} Il peut être utile de les "donner à manger" aux différents clients des autres systèmes de surveillance/métrologie/monitoring, tel {{< tag Nagios >}}, {{< tag Munin >}}, etc... -----