Snmpd : Monitorer OpenBSD

Article publié, le 20 Novembre 2019 et modifié le 21 Novembre 2019
6 minutes de lecture

Cet article contient 1144 mots.
Source brute de l'article :
Commit version : 5b7612d

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 :

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

# chown root:_snmpd /etc/snmpd.conf
# chmod 0600 /etc/snmpd.conf

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 fichier de configuration , il faudra relancer le service ad hoc.

SNMP v2

Pour débuter, commençons par :

Code :

listen on 192.168.1.3 udp
read-only community macompub
read-write community macompriv

À 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 : sh

$ snmp walk -v 2c -c macompub $(hostname) sysDescr
sysDescr.0 = STRING: OpenBSD omv.huc.fr.eu.org 6.6 GENERIC.MP#2 amd64

$ snmp walk -v 2c -c macompub $(hostname) ifName
ifName.1 = STRING: em0
ifName.2 = STRING: enc0
ifName.3 = STRING: lo0
ifName.4 = STRING: pflog0

Ce sont des exemples d’interrogation et réponses.

SNMP v3

Sans sécurité

Commençons avec un exemple sans sécurité :

Code :

seclevel none
user "test"

Après le rédémarrage du service :

Code : sh

$ snmp walk -u "test" -v 3 $(hostname) sysDescr
sysDescr.0 = STRING: OpenBSD omv.huc.fr.eu.org 6.6 GENERIC.MP#2 amd64

$ snmp walk -u "test" -v 3 $(hostname) ifName
ifName.1 = STRING: em0
ifName.2 = STRING: enc0
ifName.3 = STRING: lo0
ifName.4 = STRING: pflog0

Utilisateur authentifié

Code :

seclevel auth
user "uauth" authkey "secret007"

Après le rédémarrage du service :

Code : sh

$ snmp walk -A "secret007" -a SHA -l authNoPriv -u "uauth" -v 3 192.168.47.3 sysdescr
sysDescr.0 = STRING: OpenBSD omv.huc.fr.eu.org 6.6 GENERIC.MP#2 amd64

Authentification forte

Configurons le serveur par un exemple fort :

Code :

listen on 192.168.1.3 tcp
seclevel enc
user "uenc" authkey "zx4pyrfyeu5x5c3kxqirhtsxksbmawju" auth hmac-sha512 enckey "XHVBzYUpP8dKns75BaSwq6t7SUgF6oMz" enc aes

Après le redémarrage du service :

Code : sh

$ snmp walk -A "zx4pyrfyeu5x5c3kxqirhtsxksbmawju" -a SHA-512 -l authPriv -u "uenc" -v 3 -X "XHVBzYUpP8dKns75BaSwq6t7SUgF6oMz" -x aes $(hostname) sysdescr
sysDescr.0 = STRING: OpenBSD omv.huc.fr.eu.org 6.6 GENERIC.MP#2 amd64

$ snmp walk -A "zx4pyrfyeu5x5c3kxqirhtsxksbmawju" -a SHA-512 -l authPriv -u "uenc" -v 3 -X "XHVBzYUpP8dKns75BaSwq6t7SUgF6oMz" -x aes  $(hostname)  ifname
ifName.1 = STRING: em0
ifName.2 = STRING: enc0
ifName.3 = STRING: lo0
ifName.4 = STRING: pflog0

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

$ ps aux | grep snmpd
_snmpd   41593  0.0  0.1   772  3124 ??  SU     10:32PM    0:00.07 snmpd: snmpe (snmpd)
root     55283  0.0  0.0   820  1492 ??  Ip     10:32PM    0:00.01 /usr/sbin/snmpd
_snmpd   42220  0.0  0.1   752  2756 ??  Ip     10:32PM    0:00.02 snmpd: traphandler (snmpd)
root     80301  0.0  0.0   332  1256 p0  S+p    10:33PM    0:00.01 grep snmpd

$ netstat -ant | grep snmp
0xfffffd8105572100 stream      0      0 0xfffffd810e7e70e8                0x0                0x0                0x0 /var/run/snmpd.sock

Voilà, pour la partie serveur !

Et les clients ?

Les clients

Depuis OpenBSD 6.6, le client natif est 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 : sh

$ ls -al /usr/share/snmp/mibs/
total 184
drwxr-xr-x  2 root  wheel    512 Oct 12 18:34 ./
drwxr-xr-x  3 root  wheel    512 Oct 12 18:34 ../
-r--r--r--  1 root  wheel   2331 Oct 12 18:34 OPENBSD-BASE-MIB.txt
-r--r--r--  1 root  wheel   8805 Oct 12 18:34 OPENBSD-CARP-MIB.txt
-r--r--r--  1 root  wheel   3283 Oct 12 18:34 OPENBSD-MEM-MIB.txt
-r--r--r--  1 root  wheel  39486 Oct 12 18:34 OPENBSD-PF-MIB.txt
-r--r--r--  1 root  wheel  18559 Oct 12 18:34 OPENBSD-RELAYD-MIB.txt
-r--r--r--  1 root  wheel   4635 Oct 12 18:34 OPENBSD-SENSORS-MIB.txt
-r--r--r--  1 root  wheel   2547 Oct 12 18:34 OPENBSD-SNMPD-CONF.txt

Il peut être utile de les “donner à manger” aux différents clients des autres systèmes de surveillance/métrologie/monitoring, tel Nagios , Munin , etc…