Qu'est-ce que le SNMP ? MIB, OID, traps et SNMPv3

Peu de phrases reviennent aussi souvent sur un réseau, et aident aussi peu, que « Internet est lent ». Quel site, quelle heure, à quel point : sans ces trois réponses, la lenteur n’est pas un signalement de panne, c’est une opinion. Le SNMP (Simple Network Management Protocol) est le protocole qui pose exactement ces questions aux équipements réseau à intervalles réguliers et transforme les réponses en mesures.

Le plus rapide pour le comprendre est un système de détection incendie adressable. La centrale interroge un à un les détecteurs de sa boucle, par leur adresse, et pose chaque fois la même question : « numéro trois, votre état ? » Le détecteur répond, la centrale note, passe au suivant. En cas de vraie fumée, le détecteur n’attend pas son tour : il déclenche lui-même. Ces deux comportements, l’interrogation régulière et l’alerte spontanée, expliquent toute l’architecture de SNMP.

C’est le deuxième article du guide supervision et alertes, après Qu’est-ce que le syslog ? Le syslog donne des phrases, SNMP des nombres. Commandes, captures et sorties proviennent du laboratoire de l’auteur et sont inchangées.

Qu’est-ce que le SNMP, et quel problème résout-il ?

SNMP est un protocole de la couche application qui sert à collecter l’état des équipements réseau. Combien de paquets un switch a jetés, à quel point une liaison est pleine, quelle est la charge d’un processeur : c’est avec ce protocole que vous le demandez. La réponse n’est pas une phrase mais un nombre, et parce que c’est un nombre, on peut le conserver, le comparer et en faire un graphique. Le vrai problème est de langage : « Internet est lent » est une opinion, pas une mesure. SNMP transforme l’opinion en nombre.

Une distinction d’emblée : SNMP mesure à quel point une liaison est pleine, pas si un équipement est joignable. Pour cela, les outils de supervision utilisent le ping. Des utilisateurs dont le signal faiblit parce qu’un point d’accès est tombé diront aussi « Internet est lent », alors que la liaison n’est pas pleine du tout. SNMP donne l’occupation, le ping l’accessibilité ; avec les deux, la plainte cesse d’être un débat.

SNMP existe parce que les humains ne passent pas à l’échelle. Dix sites avec chacun un routeur, un pare-feu et deux switchs font 40 équipements ; relever à la main quatre valeurs sur chacun une fois par jour, c’est 160 relevés. L’essentiel n’est pas l’effort mais la continuité : les pannes surviennent quand personne ne regarde. Quand n’en avez-vous pas besoin ? Avec un switch et quelques postes, serveur, logiciel et tableau de bord coûtent plus qu’ils ne rapportent. Le seuil est franchi avec plusieurs sites, une liaison payée à la capacité, ou quand vous apprenez les pannes par les utilisateurs.

Comment fonctionne SNMP : gestionnaire, agent et interrogation

SNMP a deux côtés : le gestionnaire (manager) interroge, l’agent répond. Le gestionnaire produit les requêtes ; en pratique, un serveur de supervision. L’agent est le logiciel qui tourne sur l’équipement supervisé : switch, routeur, pare-feu, serveur, imprimante ou onduleur. La relation est volontairement asymétrique : l’agent n’ouvre pas de connexion, il écoute. Cela réduit la surface d’attaque, mais a un prix que le mécanisme décrit plus bas vient payer.

Les requêtes passent par UDP, par nécessité plus que par goût. Une interrogation d’état est un coup unique : sans réponse, redemander coûte moins cher que récupérer un paquet perdu. Et il faut interroger des centaines d’équipements en quelques secondes.

L’interrogation de l’agent par le gestionnaire s’appelle le polling et vise le port UDP 161. Le serveur pose les mêmes questions à chaque équipement à l’intervalle choisi, typiquement toutes les cinq minutes. Une mesure donne un nombre ; deux mesures successives donnent une différence. Le compteur d’octets d’une interface ne fait que croître et ne dit rien seul ; la différence entre deux valeurs à cinq minutes d’écart, divisée par le temps, donne le débit par seconde. C’est ainsi qu’est apparu, dans l’anecdote ci-dessus, le pic récurrent entre 9 h et 10 h.

Qu’est-ce qu’un trap SNMP ? L’équipement prend la parole

Le polling est régulier, et c’est aussi sa faiblesse. Avec une interrogation toutes les cinq minutes, une liaison qui tombe juste après une interrogation n’est remarquée qu’environ cinq minutes plus tard. Un trap est une notification que l’équipement envoie sans qu’on la lui demande, et elle arrive sur le port 162. Sur le système incendie, c’est le détecteur qui déclenche de lui-même à la première fumée.

• Poll : gestionnaire → agent, port de destination 161. Le gestionnaire demande.
• Trap : agent → gestionnaire, port de destination 162. L’équipement signale.

161 et 162 ne sont donc pas « deux ports SNMP », mais deux sens de conversation. Si votre serveur n’écoute pas le 162, vos équipements peuvent envoyer des notifications pendant des années sans qu’aucune ne vous parvienne.

Pour voir ce qu’un trap transporte sur le câble, j’ai interrogé le switch du laboratoire avec une community volontairement fausse en écoutant le 162. Les trois tentatives ont produit une notification ; en voici une, 67 octets :

0000  30 41 02 01 01 04 06 70 75 62 6c 69 63 a7 34 02  0A.....public.4.
0010  01 02 02 01 00 02 01 00 30 29 30 0e 06 08 2b 06  ........0)0...+.
0020  01 02 01 01 03 00 43 02 5e ad 30 17 06 0a 2b 06  ......C.^.0...+.
0030  01 06 03 01 01 04 01 00 06 09 2b 06 01 06 03 01  ..........+.....
0040  01 05 05                                         ...

D’abord, le a7 du quatorzième octet. Dans la requête plus bas, cet octet vaut a0, dans la réponse a2. Le sens de la conversation n’est pas un champ à part : il est codé dans le type du paquet. Ensuite, les deux valeurs. La première, 1.3.6.1.2.1.1.3.0, est le temps de fonctionnement de l’équipement : quand l’événement a eu lieu. La seconde, 1.3.6.1.6.3.1.1.4.1.0, a pour valeur une autre adresse : 1.3.6.1.6.3.1.1.5.5, « échec d’authentification ». Le type d’événement n’est pas une phrase, c’est un numéro. Le serveur le cherche dans son catalogue au lieu d’analyser du texte. Les temps de fonctionnement des trois notifications, 24237, 24438 et 24637, sont espacés d’environ deux secondes : l’équipement a signalé chaque tentative séparément. Enfin, et c’est le plus gênant, le septième octet : public est là aussi. La community circule en clair non seulement dans vos requêtes, mais aussi dans les notifications que l’équipement envoie de lui-même.

Une installation correcte combine les deux : le polling donne les tendances, les traps donnent les événements.

Laboratoire : pourquoi le récepteur de traps n’entendait rien au début

Cette section ne figure pas dans l’original turc. Avant que la capture ci-dessus ne réussisse, les notifications quittaient le switch et n’atteignaient jamais le programme qui écoutait sur le poste Windows. Le switch n’y était pour rien ; le pare-feu Windows, si, et la solution évidente n’a rien donné.

Windows fournit une règle entrante préconfigurée pour les traps SNMP. L’activer semble être la réponse. Voici ses filtres réels, lus avec PowerShell :

foreach ($n in 'SNMPTRAP-In-UDP','SNMPTRAP-In-UDP-NoScope') {
  $r = Get-NetFirewallRule -Name $n
  $a = $r | Get-NetFirewallApplicationFilter
  $s = $r | Get-NetFirewallServiceFilter
  $p = $r | Get-NetFirewallPortFilter
  "{0} | prog={1} | svc={2} | {3}/{4} | enabled={5}" -f $n, $a.Program, $s.Service, $p.Protocol, $p.LocalPort, $r.Enabled
}

SNMPTRAP-In-UDP | prog=%SystemRoot%\system32\snmptrap.exe | svc=SNMPTRAP | UDP/162 | enabled=False
SNMPTRAP-In-UDP-NoScope | prog=%SystemRoot%\system32\snmptrap.exe | svc=SNMPTRAP | UDP/162 | enabled=False

Lisez le milieu de chaque ligne. La règle n’ouvre pas l’UDP 162 : elle l’ouvre pour un programme et un service, le snmptrap.exe de Windows qui tourne comme service SNMPTRAP. Tout autre récepteur de traps est un autre programme, et la règle ne s’applique jamais à son trafic. Les deux règles sont en outre désactivées d’usine.

Le second obstacle était plus discret. Il existait sur cette machine des règles entrantes de blocage visant l’interpréteur sur lequel tournait le récepteur, et sous Windows une règle Block l’emporte sur une règle Allow, quel que soit leur ordre de création. Même une règle Allow correcte n’a rien changé tant que les règles Block n’étaient pas désactivées.

La liste de vérification quand un récepteur de traps Windows reste muet :

1. Vérifier que les traps quittent l’équipement, par une capture sur l’interface du récepteur.
2. Ne pas compter sur la règle préconfigurée, sauf si vous utilisez le service de traps de Windows. Créez une règle Allow entrante pour l’UDP 162 liée au programme de votre récepteur.
3. Chercher les règles Block qui visent ce programme ou ce port ; elles annulent en silence votre règle Allow.
4. Revenir en arrière ensuite s’il s’agissait d’un test. La première fois, je ne l’ai pas fait : les règles sont restées ouvertes après la mesure et ont dû être refermées plus tard.

Qu’est-ce qu’une MIB ? Le catalogue de ce que sait un équipement

Comment le serveur sait-il que 1.3.6.1.6.3.1.1.5.5 signifie « échec d’authentification » ? Plus largement : comment le gestionnaire sait-il quoi demander, et l’agent ce qu’on lui demande ? Il leur faut un dictionnaire commun : la MIB.

Une MIB (Management Information Base) est le catalogue normalisé des informations qu’on peut demander à un équipement. Elle ne contient pas de données : elle dit où elles se trouvent, leur type et leur sens. Pour le système incendie, c’est la liste des détecteurs établie à la mise en service : quel étage, quelle pièce, fumée ou chaleur. La liste des détecteurs correspond à la MIB, le numéro d’une ligne à l’OID. L’essentiel est que la MIB soit convenue à l’avance ; c’est pourquoi un serveur peut poser la même question à des équipements de constructeurs différents.

Qu’est-ce qu’un OID ? Une adresse dans le catalogue

Un OID (Object Identifier) est l’adresse d’une information dans la MIB, une suite hiérarchique de nombres séparés par des points. L’adresse normalisée de la description du système est 1.3.6.1.2.1.1.1.0 : 1.3.6.1 est la racine de l’arbre Internet, 2.1 la branche de gestion standard, le 1 suivant le groupe système, le 1 d’après l’objet description, et le 0 final son unique instance.

1.3.6.1.2.1.1.1.0    description du système
1.3.6.1.2.1.1.3.0    temps de fonctionnement
1.3.6.1.2.1.1.5.0    nom du système
1.3.6.1.2.1.1.6.0    emplacement
1.3.6.1.2.1.2.1.0    nombre d'interfaces

En interrogeant quatre de ces adresses sur le switch du laboratoire, deux résultats sont apparus, qui devraient figurer dans toute explication des MIB. Le nombre d’interfaces valait 119. L’équipement a 48 ports ; la différence vient des interfaces VLAN, des liens de pile et des interfaces logiques. Le chiffre est juste, mais ce n’est pas « le nombre de ports » : c’est la définition du catalogue qui fixe son sens, pas votre intuition. Et nom du système et emplacement sont revenus vides. Les adresses existent, l’équipement comprend la question, mais personne ne les a remplies. C’est très courant, et le résultat est un tableau de bord rempli de boîtes anonymes.

Où l’image du système incendie se brise

À deux endroits. La liste des détecteurs d’un bâtiment est propre à ce bâtiment, la MIB est universelle. Et la boucle d’un système incendie est physiquement séparée, alors que SNMP partage le réseau avec vos données. Pour écouter une boucle incendie, il faut entrer dans le bâtiment ; pour écouter SNMP, il suffit d’être sur le réseau. C’est tout le sujet de la section suivante.

Les versions de SNMP : v1, v2c et v3

Il existe trois versions, et leur différence n’est pas une liste de fonctions, mais la réponse à la question : qui a le droit de demander ? v1 est l’originale, que rien ne justifie aujourd’hui. v2c est la plus répandue, avec de meilleurs types de données et des requêtes groupées, mais elle en reste au même point que v1 pour l’authentification. v3 ajoute la couche de sécurité.

Une community est le texte d’accès de v1 et v2c, et contrairement à une idée répandue, elle ne se comporte pas comme un mot de passe. Seul point commun : sans elle, pas de réponse. Tout le reste manque : elle est envoyée non chiffrée, renvoyée à chaque requête, et revient dans chaque réponse. Et sur le terrain, c’est généralement une valeur unique partagée par tous les équipements.

Laboratoire : voir la community dans le paquet

La réponse habituelle sur le terrain : « une community en lecture seule est inoffensive, elle ne fait que lire ». J’ai défini une community en lecture seule sur un switch administrable et construit la requête à la main, parce que l’enjeu n’est pas la réponse mais les octets du paquet. La requête du nombre d’interfaces, 43 octets sans en-têtes :

0000  30 29 02 01 01 04 06 70 75 62 6c 69 63 a0 1c 02  0).....public...
0010  04 64 c8 5a 35 02 01 00 02 01 00 30 0e 30 0c 06  .d.Z5......0.0..
0020  08 2b 06 01 02 01 02 01 00 05 00                 .+.........

À partir du septième octet, public s’affiche en clair ; la suite 2b 06 01 02 01 02 01 00 au milieu est l’adresse demandée. La réponse de l’équipement :

0000  30 2a 02 01 01 04 06 70 75 62 6c 69 63 a2 1d 02  0*.....public...
0010  04 64 c8 5a 35 02 01 00 02 01 00 30 0f 30 0d 06  .d.Z5......0.0..
0020  08 2b 06 01 02 01 02 01 00 02 01 77              .+.........w

Le 02 01 77 final est l’entier attendu, 0x77, soit 119. Encore une fois, c’est le septième octet qui instruit : public figure en clair dans la réponse aussi. Celui qui écoute n’a même pas besoin de guetter une requête. Une autre mesure était plus gênante : interrogé sur sa description, l’équipement a renvoyé son nom de modèle complet et sa version de firmware en clair. Je les masque ici, pour la raison qui devrait aussi vous préoccuper : pour un attaquant, modèle et version sont la première donnée pour choisir la vulnérabilité qui fonctionnera. Une community ouverte ne donne pas seulement « la lecture » ; elle livre l’identité de l’équipement.

La même requête en SNMPv3

SNMPv3 supprime la community et la remplace par un nom d’utilisateur, une authentification et un chiffrement. J’ai créé un utilisateur v3 sur le même switch et posé la même question. Le mécanisme va plus loin que « chiffrement activé » :

1. Découverte. Le client envoie d’abord une requête non authentifiée ; l’équipement annonce son identifiant de moteur, son compteur de démarrages et son temps de fonctionnement. Honnêtement, c’est le point faible de v3 : un observateur apprend au moins que l’équipement existe et depuis quand il tourne.
2. Dérivation de clé. Le mot de passe n’est pas utilisé directement : il est étendu, haché, combiné à l’identifiant de moteur de l’équipement puis haché de nouveau. Résultat : une clé valable uniquement pour cet équipement.
3. Signature et chiffrement. Le contenu est chiffré avec une clé dérivée, le message signé avec une autre.

La clé d’authentification dérivée par mon client :

99e4f6a753f99ab77f6784608e28d89dbab58731

La valeur que le switch conservait pour cet utilisateur dans sa configuration était identique. Les deux côtés sont arrivés indépendamment à la même clé. C’est la conception en une ligne : le mot de passe ne traverse jamais le réseau et n’est pas stocké sur l’équipement. La requête v3, 131 octets, partie essentielle :

0030  0b 73 65 72 63 65 69 7a 6c 65 6d 65 04 0c 4e ed  .serceizleme..N.
0040  aa 9d d8 f1 f4 a2 c9 96 73 c9 04 08 c0 f2 fa ed  ........s.......
0050  c9 bc a5 0a 04 2d a8 8b 18 0e 55 9e 7d 09 14 3f  .....-....U.}..?
0060  a2 38 38 c6 b2 21 1f 96 b0 4d a4 fd 3b 4a 3e 86  .88..!...M..;J>.

Le nom d’utilisateur est en clair, serceizleme, et c’est voulu : l’autre côté doit savoir avec quelle clé vérifier. v3 ne cache pas le nom d’utilisateur, il cache le mot de passe ; j’ai vérifié par programme qu’aucun des deux mots de passe n’apparaît sous quelque forme que ce soit dans le paquet. Tout ce qui suit l’offset 0x50 est du contenu chiffré ; l’adresse lisible dans la requête v2c n’y est pas. La réponse est arrivée de la même façon, 173 octets sans champ lisible.

La différence entre v2c et v3 n’est pas « on a ajouté du chiffrement », c’est que ce qui fait office d’identité a changé. En v2c, l’identité est un texte, donc copiable. En v3, c’est une clé liée à l’équipement ; copiée, elle ne fonctionne nulle part ailleurs.

Syslog et SNMP : mesurer ou raconter

v3 règle la sécurité. Mais une catégorie de questions échappe toujours à SNMP : un nombre ne raconte pas l’histoire d’un événement. SNMP dit que le CPU est à 80 % ; il ne dit pas quelle connexion a échoué. Une ligne syslog du même switch :

<189> Aug 18 12:09:19 192.168.1.2-1 TRAPMGR[trapTask]: traputil.c(735) 221 %% Link Down: Vl1

Le <189> est le champ de priorité expliqué dans Qu’est-ce que le syslog ? ; ce qui compte ici, c’est que le reste est une phrase. Les traps sont exploitables par les machines : déclencher une action sur un OID précis est simple. Le syslog est lisible par les humains : quelle interface, quand, dans quel processus, tout est dans la phrase. Une bonne installation collecte les deux. L’erreur la plus courante : installer les deux et les laisser sans responsable. Les notifications partent à tout le monde, personne ne regarde, et un an plus tard l’alerte n’est plus qu’un bruit de fond.

SNMP sur le terrain : ordre de déploiement et dépannage

1. Restreindre l’accès d’abord, activer le protocole ensuite. SNMP ne doit être joignable que depuis le réseau d’administration ; la bonne place pour cela est la conception réseau (voir Qu’est-ce qu’un VLAN ?). Vérifiez aussi que 161 et 162 sont fermés vers l’extérieur.
2. Utiliser v3, garder v2c pour la transition seulement.
3. Rester en lecture seule. Ne donnez pas de droits d’écriture via SNMP ; configurez les équipements par une session d’administration chiffrée.
4. Remplir nom du système et emplacement.
5. Vérifier l’horloge de l’équipement. Un graphique ne vaut que par son axe du temps.

Pour vérifier que tout fonctionne, trois étapes : envoyer une seule requête (l’important est qu’une réponse arrive), vérifier que la réponse est plausible (119 interfaces, plus que de ports, n’est pas une erreur) et confirmer que vous écoutez le 162, sous Windows avec la liste de vérification ci-dessus.

Erreurs courantes. Une community fausse est jetée en silence : je l’ai mesuré, aucune réponse, aucune erreur. « Community fausse », « équipement éteint », « pare-feu au milieu » et « SNMP jamais activé » se ressemblent côté demandeur. La capture de traps montre pourtant que c’est silencieux seulement pour le mauvais côté : l’équipement signale l’échec au serveur de supervision, visible uniquement pour qui écoute le 162. C’est l’argument de sécurité le plus concret pour collecter les traps. Désactivé d’usine ne veut pas dire sûr : ma première tentative avec la community par défaut la plus connue n’a obtenu aucune réponse, SNMP était désactivé d’usine ; le risque est dans la community que vous choisissez en l’activant, et dans la façon dont v2c la transporte. La même community partout : une seule capture ouvre tout l’inventaire. Cinq minutes pour toutes les métriques : bien pour les tendances de capacité, mais un pic de quelques secondes disparaît dans la moyenne. Des traps sans destinataire : une notification doit aboutir chez une personne ou une astreinte, pas dans une boîte aux lettres.

Conclusion

SNMP tient en deux phrases. Le gestionnaire interroge à intervalles réguliers, l’agent répond. En urgence, l’agent prend la parole en premier. Tout le reste est du détail : la MIB fixe de quoi on parle, l’OID quelle adresse on demande, la version qui a le droit de demander.

Le vrai gain n’est pas technique. Sur un réseau supervisé, « Internet est lent » ne déclenche plus de débat : quelqu’un ouvre un graphique, trouve la fenêtre de temps et cherche la cause. Dès qu’une opinion est remplacée par une mesure, le problème devient soluble, avant même d’être résolu.