📡 SNMP – Monitoring, MIBs/OIDs & Protocoles v1/v2c/v3

Simple Network Management Protocol

SNMP est un protocole de la couche Application (Couche 7) conçu pour superviser (monitorer) et gérer des équipements sur un réseau IP (Routeurs, Switchs, Serveurs, Imprimantes, NAS...).

C'est le standard universel pour la collecte de métriques de performance (CPU, RAM, Bande Passante) et de statut (État des ports).

Architecture (Manager / Agent)

SNMP fonctionne sur un modèle "Manager-Agent" :

• Manager (NMS) : Le serveur de supervision (ex: Zabbix, Nagios). C'est lui qui "pose les questions" (Polling).
• Agent : Le logiciel qui tourne sur l'équipement supervisé (ex: le switch Cisco, le serveur Windows). Il "connaît les réponses" et les expose.
• MIB (Management Information Base) : (Voir 3.1) Le "dictionnaire" que le NMS utilise pour savoir quelles questions il peut poser à l'Agent.

[ NMS (Manager) ]
(ex: Zabbix)
      │
      │ Requête : "Quel est ton CPU ?" (GET)
      │ Alerte : "Port 1/1 Down !" (TRAP)
      │
      ▼
[ AGENT (Appareil) ]
(ex: Switch Cisco)

SNMP utilise UDP comme protocole de transport (Couche 4), car il est rapide, sans connexion (stateless) et a un faible overhead, ce qui est idéal pour des requêtes de monitoring répétitives (polling).

Il utilise deux ports "Well-Known" distincts :

SNMP définit plusieurs types de messages (PDU - Protocol Data Units) :

La version originale de SNMP (1988, RFC 1157). Statut : Totalement obsolète.

Sécurité : Community String (Chaîne de Communauté)

L'authentification (très faible) est gérée par une "chaîne de communauté", qui est un mot de passe partagé.

• public : (Défaut) Accès en Lecture Seule (Read-Only - RO). Permet les GET.
• private : (Défaut) Accès en Lecture/Écriture (Read-Write - RW). Permet les SET.

Faille Critique : Les community strings sont envoyées en Texte Clair (Clear Text) dans les paquets UDP. Un attaquant "sniffant" (écoutant) le réseau peut les capturer en quelques secondes.

Limitations

• Sécurité (texte clair).
• Ne supporte pas GETBULK (inefficace).
• Supporte uniquement des compteurs 32 bits (un compteur 32 bits pour le trafic d'une interface 1 Gbps "wrappe" (revient à zéro) en ~34 secondes, rendant le monitoring de bande passante inutilisable).

C'est la version la plus utilisée aujourd'hui dans les réseaux internes (LAN). (SNMPv2c = v2 avec "community strings").

Sécurité : Identique à v1

SNMPv2c utilise toujours des Community Strings en texte clair (public, private). Il n'est pas plus sécurisé que v1.

Son utilisation est acceptable uniquement sur un réseau de management "de confiance" (ex: un VLAN de supervision), protégé par des ACLs/Firewalls.

Améliorations Clés (par rapport à v1)

• GETBULK : L'ajout majeur. Permet à un NMS de demander plusieurs OIDs (ex: 10) en une seule requête GET, réduisant massivement la charge CPU et réseau du polling.
• Compteurs 64 bits (Counter64) : Ajoute des compteurs 64 bits (ifHCInOctets), essentiels pour monitorer la bande passante sur les interfaces modernes (1 Gbps, 10 Gbps) sans "wraparound" (retour à zéro) rapide.
• INFORM : Ajoute les TRAPs confirmés (avec ACK).

SNMPv3 est le standard moderne qui adresse toutes les failles de sécurité de v1/v2c. Il est complexe à configurer mais essentiel pour les réseaux non-fiables (WAN).

USM (User-based Security Model)

v3 n'utilise plus de "community strings". Il utilise un Nom d'Utilisateur et des Niveaux de Sécurité (Auth/Priv).

• authNoPriv (Recommandé) : Garantit l'Authenticité (l'expéditeur est bien le NMS) et l'Intégrité (le paquet n'a pas été modifié) grâce au hachage (HMAC-MD5/SHA).
• authPriv (Max Sécurité) : Garantit l'Authenticité, l'Intégrité ET la Confidentialité (le contenu du paquet est chiffré en AES).

Le "Dictionnaire" (Nom -> OID)

Une MIB (Management Information Base) est un fichier texte (structuré) qui sert de "dictionnaire" ou de "carte" pour les données SNMP. Il traduit les noms numériques (OID) en noms lisibles par l'homme, et vice-versa.

Les NMS (Nagios, Zabbix) doivent charger les fichiers MIB (fournis par le constructeur, ex: CISCO-PROCESS-MIB.mib) pour comprendre les OIDs spécifiques à cet équipement.

Sans la MIB, le NMS demande :
  "Donne-moi .1.3.6.1.2.1.1.1.0"
  Réponse : "Cisco Router 2901"

Avec la MIB (chargée), l'admin configure :
  Check : "sysDescr.0" (Human-readable)
  (Le NMS traduit "sysDescr.0" en .1.3.6.1.2.1.1.1.0)

L'"Adresse" de la Donnée

Un OID (Object Identifier) est l'adresse numérique unique qui identifie une variable (un "objet") spécifique dans la MIB.

C'est une structure arborescente (hiérarchique) où chaque chiffre représente un "nœud".

# Le nom lisible (MIB) : sysUpTime
# L'OID : .1.3.6.1.2.1.1.3
# L'instance (Scalaire) : .0

OID complet : .1.3.6.1.2.1.1.3.0

# Le nom lisible (MIB) : ifDescr (Description d'interface)
# L'OID (Table) : .1.3.6.1.2.1.2.2.1.2

# Les instances (Tabulaire) :
OID: .1.3.6.1.2.1.2.2.1.2.1 (Interface 1) -> "FastEthernet0/1"
OID: .1.3.6.1.2.1.2.2.1.2.2 (Interface 2) -> "FastEthernet0/2"
OID: .1.3.6.1.2.1.2.2.1.2.3 (Interface 3) -> "Vlan1"

Tous les OIDs sont organisés dans une structure hiérarchique (arborescente) globale.

. (Root)
 └ 1 (iso)
   └ 3 (org)
     └ 6 (dod)
       └ 1 (internet)
         ├─ 2 (mgmt)
         │  └ 1 (mib-2)
         │    ├─ 1 (system)
         │    │  ├─ 1 (sysDescr)  -> .1.3.6.1.2.1.1.1
         │    │  └─ 3 (sysUpTime) -> .1.3.6.1.2.1.1.3
         │    ├─ 2 (interfaces)
         │    │  └ 2 (ifTable)
         │    │    └ 1 (ifEntry)
         │    │      ├─ 2 (ifDescr)   -> .1.3.6.1.2.1.2.2.1.2
         │    │      └─ 10 (ifInOctets) -> .1.3.6.1.2.1.2.2.1.10
         │    ...
         └─ 4 (private)
            └ 1 (enterprise)
              ├─ 9 (cisco)
              │  └ ... (MIBs propriétaires Cisco)
              ├─ 2021 (ucd-snmp)
              └─ ... (Autres constructeurs)

C'est le mode de supervision Pull (Tirer), initié par le NMS. C'est le mode utilisé pour la supervision de performance (métriques qui changent constamment).

Processus (Polling)

1. Le NMS (Manager) est configuré pour interroger (Poll) un Agent (ex: 192.168.1.1) toutes les 5 minutes.
2. Toutes les 5 minutes, le NMS envoie une série de requêtes GET (ou GETBULK) à l'Agent sur le port UDP 161.
3. Requêtes : "OID 1.3.6...1.3.0 (sysUpTime) ?", "OID ...2.2.1.10.1 (ifInOctets.1) ?", "OID ...2.2.1.16.1 (ifOutOctets.1) ?".
4. L'Agent répond (RESPONSE) avec les valeurs actuelles (ex: Uptime=12345, In=50000, Out=20000).
5. Le NMS stocke ces valeurs (horodatées) dans sa base de données (RRDtool, TSDB) et trace le graphique.

C'est le mode de supervision Push (Pousser), initié par l'Agent. C'est le mode utilisé pour la supervision d'événements (Faults).

1. Une alimentation (PSU) sur un Switch tombe en panne.
2. L'Agent (Switch) génère immédiatement une TRAP
   (ex: "linkDown", "configChanged", "psuFailed").
3. Il l'envoie (PUSH) au NMS (UDP 162).
4. Le NMS reçoit la TRAP et génère une Alerte CRITICAL.

(Permet une alerte instantanée, sans attendre
 le prochain cycle de polling de 5 min).

L'opération SET est une requête d'écriture (Write), initiée par le NMS (Manager) vers l'Agent (Switch).

Elle permet de modifier la configuration de l'équipement à distance via SNMP.

Exemple d'Usage

L'OID ifAdminStatus (.1.3.6.1.2.1.2.2.1.7) contrôle l'état d'une interface (1=up, 2=down).

# Commande pour ÉTEINDRE l'interface 1 (Fa0/1)

$ snmpset -v2c -c [RW_COMMUNITY] 192.168.1.1 \
    .1.3.6.1.2.1.2.2.1.7.1 i 2

(Où "i" = integer et "2" = down)

Risque de Sécurité Majeur :

Cette opération nécessite la Community Read-Write (RW) (ex: "private") ou un utilisateur v3 avec droits d'écriture.

Si un attaquant obtient cette community, il a un contrôle total sur l'équipement (shutdown de tous les ports, modification de la config...). C'est pourquoi la sécurité (SNMPv3, ACLs) est vitale.

snmpwalk (inclus dans net-snmp sur Linux) est l'outil de diagnostic n°1. Il effectue une série de requêtes GETNEXT (ou GETBULK) pour "marcher" (walk) le long d'un arbre OID et afficher toutes les valeurs qu'il trouve.

Syntaxe (v2c)

snmpwalk -v [version] -c [community] [IP] [OID_de_départ (optionnel)]

Exemples

# "Walk" tout l'arbre (très verbeux)
$ snmpwalk -v2c -c public 192.168.1.1

# "Walk" uniquement la branche "system" (1.3.6.1.2.1.1)
$ snmpwalk -v2c -c public 192.168.1.1 system
iso.3.6.1.2.1.1.1.0 = STRING: "Cisco IOS..." (sysDescr)
iso.3.6.1.2.1.1.3.0 = Timeticks: (1234567) 1 day... (sysUpTime)
iso.3.6.1.2.1.1.5.0 = STRING: "Switch-Core-1" (sysName)
...

# "Walk" la table des interfaces (ifDescr)
$ snmpwalk -v2c -c public 192.168.1.1 .1.3.6.1.2.1.2.2.1.2
iso.3.6.1.2.1.2.2.1.2.1 = STRING: "FastEthernet0/1"
iso.3.6.1.2.1.2.2.1.2.2 = STRING: "FastEthernet0/2"
iso.3.6.1.2.1.2.2.1.2.25 = STRING: "Vlan1"

snmpget effectue une seule requête GET pour récupérer la valeur d'un ou plusieurs OIDs spécifiques.

C'est l'outil utilisé par les scripts de supervision (ex: Nagios check_snmp) pour vérifier une métrique précise.

Syntaxe (v2c)

snmpget -v [version] -c [community] [IP] [OID 1] [OID 2] ...

Exemples

# Récupérer le sysUpTime
$ snmpget -v2c -c public 192.168.1.1 .1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timeticks: (1234567) 1 day, 10:17:36.7

# Récupérer le nom (sysName) ET la description (sysDescr)
$ snmpget -v2c -c public 192.168.1.1 sysName.0 sysDescr.0
iso.3.6.1.2.1.1.5.0 = STRING: "Switch-Core-1"
iso.3.6.1.2.1.1.1.0 = STRING: "Cisco IOS..."

snmpwalk/get sont pour le diagnostic. Un NMS est la plateforme (le "Manager") qui automatise la collecte (Polling, Traps) et fournit une interface web (Graphiques, Alertes).

Ce sont les OIDs les plus couramment supervisés (standard MIB-2, .1.3.6.1.2.1...).

snmpget (Lire 1 OID)

# v2c (non-sécurisé)
snmpget -v2c -c public 192.168.1.1 .1.3.6.1.2.1.1.3.0

# v3 (sécurisé, Auth/Priv)
snmpget -v3 -l authPriv -u [USER] -a [SHA|MD5] -A [AUTH_PASS] -x [AES|DES] -X [PRIV_PASS] [IP] [OID]

snmpwalk (Lire un arbre)

# v2c
snmpwalk -v2c -c public 192.168.1.1 .1.3.6.1.2.1.2.2.1.2

# v3
snmpwalk -v3 -l authPriv -u [USER] ... [IP] [OID]

snmpset (Écrire 1 OID)

# v2c (Éteindre l'interface 1)
# i = integer, 2 = down
snmpset -v2c -c private 192.168.1.1 .1.3.6.1.2.1.2.2.1.7.1 i 2