SNMPv3 et syslog : superviser les équipements réseau

SNMP (Simple Network Management Protocol) permet à un serveur de supervision d'interroger les équipements du réseau (switchs, routeurs, pare-feu, serveurs, onduleurs, imprimantes) sur leur état, et à ces équipements de lui signaler eux-mêmes un problème. SNMPv3, la seule version à utiliser aujourd'hui, authentifie et chiffre ces échanges. Syslog est le protocole avec lequel les équipements envoient leurs journaux à un serveur central. Ce chapitre explique le modèle de SNMP (gestionnaire, agent, MIB, OID), ses versions et leurs niveaux de sécurité, la configuration de SNMPv3 sous Debian et sur Cisco, puis la centralisation des journaux par syslog.

Gestionnaire, agent, MIB

L'arbre des OID est mondial. Sa branche la plus utilisée commence par 1.3.6.1 (iso.org.dod.internet), puis se sépare en .2.1 (mib-2, les informations standard, communes à tous les constructeurs) et .4.1 (enterprises, une branche par constructeur : 9 pour Cisco).

Le .0 final désigne l'unique valeur d'une information simple. Pour une information présente plusieurs fois (une ligne par interface), l'OID se termine par le numéro de l'interface : ifOperStatus.3.

Les opérations et les ports

La supervision combine les deux sens : le sondage (polling) régulier, toutes les minutes par exemple, pour les mesures (débit, charge), et les notifications pour être prévenu immédiatement d'un événement (une interface qui tombe, une alimentation en panne). La conception des tableaux de bord, des seuils et des alertes dans Zabbix et Grafana est le sujet du cours Supervision.

SNMPv1, v2c et v3

SNMPv3 définit trois niveaux de sécurité :

Pour l'authentification, préfère SHA-256 (ou SHA-512) quand les deux côtés le gèrent, sinon SHA-1 ; jamais MD5. Pour le chiffrement, AES (128 bits, la norme) ; jamais DES. Les deux phrases secrètes (authentification et chiffrement) font au moins 8 caractères, mais prends-les longues et différentes. Les droits de chaque utilisateur sont limités par des vues (VACM) : la liste des branches de l'arbre qu'il peut lire.

SNMPv3 sur un serveur Debian 13

Sur srv-intranet, l'agent Net-SNMP (version 5.9.4) :

sudo apt install snmpd snmp
sudo systemctl stop snmpd
# Créer l'utilisateur en lecture seule, SHA-256 et AES ; le script demande les deux phrases secrètes
sudo net-snmp-create-v3-user -ro -a SHA-256 -x AES zabbix

Le script écrit l'utilisateur dans le fichier persistant de l'agent (/var/lib/snmp/snmpd.conf) ; au démarrage, snmpd remplace les phrases secrètes par des clés dérivées. Dans /etc/snmp/snmpd.conf, il reste à :

# Écouter sur l'adresse du serveur (par défaut : 127.0.0.1 et [::1] seulement)
agentaddress  udp:127.0.0.1:161,udp:192.168.21.10:161

# Supprimer les accès par communauté fournis par défaut
#rocommunity  public default -V systemonly
#rocommunity6 public default -V systemonly

sudo systemctl start snmpd
# Depuis srv-journaux : interroger le nom de l'équipement, puis la table des interfaces
snmpget  -v3 -l authPriv -u zabbix -a SHA-256 -A 'PhraseAuth' -x AES -X 'PhrasePriv' 192.168.21.10 1.3.6.1.2.1.1.5.0
snmpwalk -v3 -l authPriv -u zabbix -a SHA-256 -A 'PhraseAuth' -x AES -X 'PhrasePriv' 192.168.21.10 1.3.6.1.2.1.2.2.1.2

La première commande doit renvoyer le nom de la machine (STRING: srv-intranet). Une erreur Authentication failure signale une mauvaise phrase d'authentification ou un mauvais algorithme ; un Timeout signale un agent qui n'écoute pas sur cette adresse, ou un pare-feu qui bloque UDP 161.

SNMPv3 sur un switch Cisco

SW-COEUR(config)# ip access-list standard ACL-SUPERV
SW-COEUR(config-std-nacl)# permit host 192.168.10.180
SW-COEUR(config)# snmp-server view VUE-LECTURE iso included
SW-COEUR(config)# snmp-server group GRP-SUPERV v3 priv read VUE-LECTURE access ACL-SUPERV
SW-COEUR(config)# snmp-server user zabbix GRP-SUPERV v3 auth sha PhraseAuth priv aes 128 PhrasePriv
SW-COEUR(config)# snmp-server host 192.168.10.180 version 3 priv zabbix
SW-COEUR(config)# snmp-server enable traps snmp linkdown linkup

Le groupe fixe le niveau de sécurité (priv = authPriv), la vue en lecture et l'ACL des adresses autorisées ; l'utilisateur porte les phrases secrètes. La commande snmp-server host envoie les traps à Zabbix. Attention : auth sha désigne SHA-1. Sur les versions d'IOS XE qui proposent SHA-2 pour SNMPv3, choisis-le (l'aide ? après auth liste les algorithmes de ton modèle). Les utilisateurs SNMPv3 n'apparaissent pas dans la configuration affichée par show running-config : show snmp user les liste. La sécurisation complète de l'administration des équipements Cisco est dans le cours Routage et commutation.

Et les autres équipements ?

Syslog : centraliser les journaux

Syslog est le format et le protocole d'envoi des journaux des équipements réseau et des systèmes Unix. Chaque message porte une origine (facility : noyau, authentification, messagerie, ou local0 à local7 pour les équipements), une gravité (severity) de 0 à 7, un horodatage, le nom de l'équipement et le texte.

Un niveau de journalisation inclut tous les niveaux plus graves : régler un équipement sur informational (6) envoie les messages de 0 à 6, sans le débogage.

Chez Sorbier, srv-journaux (192.168.10.180) reçoit les journaux des switchs, du pare-feu et des serveurs Linux. Sur un switch Cisco :

SW-COEUR(config)# service timestamps log datetime msec localtime
SW-COEUR(config)# logging source-interface Vlan99
SW-COEUR(config)# logging host 192.168.10.180
SW-COEUR(config)# logging trap informational

Sur pfSense, Status > System Logs > Settings, rubrique Remote Logging Options : coche Enable Remote Logging et indique 192.168.10.180:514 dans Remote log servers (le cours pfSense montre la suite côté Wazuh : superviser pfSense et envoyer ses journaux).

Sous Debian 13, les journaux sont gérés par journald ; pour les envoyer à un serveur syslog, installe rsyslog :

# /etc/rsyslog.d/90-central.conf, sur les serveurs qui envoient
*.* action(type="omfwd" target="192.168.10.180" port="514" protocol="tcp"
           queue.type="LinkedList" queue.filename="central" action.resumeRetryCount="-1")

# /etc/rsyslog.d/10-reception.conf, sur srv-journaux
# Les switchs et pfSense envoient en UDP 514 par défaut, les serveurs Linux en TCP 514
module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")
template(name="ParHote" type="string" string="/var/log/central/%HOSTNAME%/%PROGRAMNAME%.log")
if $fromhost-ip != "127.0.0.1" then {
    action(type="omfile" dynaFile="ParHote")
    stop
}

La file d'attente sur disque (queue.filename) garde les messages si srv-journaux est injoignable, et action.resumeRetryCount="-1" fait réessayer indéfiniment. Vérifie la syntaxe avec rsyslogd -N1 avant de redémarrer le service. Pour les flux qui traversent le pare-feu, comme ceux de la DMZ, Sorbier utilise syslog sur TLS, en TCP 6514 (matrice des flux du cours Cybersécurité des infrastructures).

Les journaux de Windows ne sont pas au format syslog : on les centralise par le transfert d'événements Windows (cours Windows Server) ou par l'agent d'un SIEM. L'analyse des journaux, la détection et la corrélation des événements de sécurité relèvent d'un SIEM comme Wazuh : voir le cours Wazuh, de la collecte des journaux à la lecture d'une alerte. Et rien de tout cela n'a de valeur si les horloges ne sont pas synchronisées (chapitre 7).

Exercices

.1.3.6.1.2.1.1.5.0 = STRING: SW-COEUR
.1.3.6.1.2.1.1.3.0 = Timeticks: (864000) 2:24:00.00
.1.3.6.1.2.1.2.2.1.8.10101 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.10102 = INTEGER: down(2)