SNMP expliqué : MIB, OID, traps et SNMPv3
Un switch de votre réseau répond à quiconque connaît un seul mot, sa communauté, et ce mot traverse le réseau en clair dans chaque requête. Avec lui, un inconnu lit les tables de l'équipement, et avec une communauté en lecture-écriture, il en modifie la configuration.
SNMP est présent sur presque tous vos équipements, et ses versions les plus déployées ont été déclarées historiques en raison de leur sécurité. Au programme : managers et agents, la MIB, les opérations, traps et informs, la version 3, et la configuration chez quatre constructeurs.
Manager et agent
SNMP a deux rôles. Le manager, votre système de supervision, pose les questions. L'agent, sur le routeur ou le switch, y répond.
Les requêtes arrivent à l'agent sur le port UDP 161. Les notifications, ces messages qu'un équipement envoie sans qu'on les lui demande, partent vers le manager sur le port UDP 162. Chaque message est encodé en ASN.1, et un agent doit accepter des messages d'au moins 484 octets.
La MIB et les OID
Ce qu'un agent expose est décrit dans sa MIB, un arbre d'objets numérotés. Chaque objet possède un identifiant d'objet, un OID, qui se lit depuis la racine.
1.3.6.1 est la branche internet. En dessous, mib-2, en 1.3.6.1.2.1, contient les objets standard que tout constructeur implémente. Enterprises, en 1.3.6.1.4.1, attribue à chaque constructeur sa propre branche : celle de Huawei est 2011. Le groupe system vient en premier, et ses premier et troisième objets, sysDescr et sysUpTime, indiquent ce qu'est l'équipement et depuis combien de temps il fonctionne.
Les opérations
Le manager dispose de quelques verbes. Get lit un objet. GetNext lit l'objet suivant, et c'est ainsi qu'on parcourt une table entière. Set écrit.
La version 2 a ajouté GetBulk, qui renvoie de nombreux successeurs en une seule réponse, et c'est ce qui rend rapide le parcours d'une grande table d'interfaces. La version 1 n'a pas de GetBulk. Quand un objet manque, la version 1 répond par l'erreur noSuchName, et la version 2 par des exceptions comme noSuchObject et endOfMibView.
Traps et informs
L'interrogation demande. Les notifications informent. Un trap est envoyé une seule fois et n'est jamais acquitté : Cisco qualifie les traps de non fiables précisément pour cette raison. Un inform est acquitté par le manager et renvoyé tant qu'il ne l'est pas, au prix de mémoire consommée sur l'équipement pendant l'attente. La version 1 n'a pas d'informs.
Toute notification de version 2 commence par les deux mêmes valeurs : l'uptime de l'équipement, et l'OID du trap qui nomme l'événement, par exemple une interface qui tombe.
Les communautés
Les versions 1 et 2c s'authentifient par une communauté, un mot de passe envoyé en clair dans chaque paquet. Cisco et Aruba le disent tous deux dans leurs propres guides. La RFC 3410 qualifie ces versions de fondamentalement non sécurisées, et compare le fait de les autoriser à garder la porte d'entrée en laissant la porte de derrière ouverte.
Une communauté en lecture seule révèle malgré tout les interfaces, les adresses et les noms. Une communauté en lecture-écriture livre le contrôle.
La sécurité de la version 3
La version 3 remplace les communautés par des utilisateurs. Le modèle de sécurité fondé sur l'utilisateur (USM) a trois niveaux. noAuthNoPriv : ni authentification, ni chiffrement. authNoPriv : les messages sont signés. authPriv : signés et chiffrés. Le chiffrement sans authentification n'existe pas ; la RFC interdit cette combinaison.
L'authentification a commencé avec MD5 et SHA-1, et SHA 256 est arrivé avec la RFC 7860. Le chiffrement a commencé avec DES, puis AES 128 dans la RFC 3826. Un message hors d'une fenêtre de 150 secondes est refusé.
Engine ID et clés
Chaque agent possède un engine ID, et les clés de chaque utilisateur sont dérivées du mot de passe et de cet engine ID : le même mot de passe donne donc une clé différente sur chaque équipement.
La conséquence est documentée par Cisco et par Juniper : définissez l'engine ID avant de créer les utilisateurs, car le modifier ensuite invalide tous les utilisateurs, qu'il faut alors tous reconfigurer. Sur une stack Cisco, un changement de priorité suivi d'un redémarrage peut aussi casser l'authentification de la version 3.
Vues et accès
Ce qu'un utilisateur ou une communauté peut lire s'appelle une vue. Une vue inclut ou exclut des sous-arbres de la MIB, et les groupes associent les utilisateurs à une vue de lecture, une vue d'écriture et une vue de notification. Cisco est explicite : tout ce qui n'est pas inclus est implicitement refusé.
Associez les vues à une liste d'accès sur l'agent, pour que seuls vos managers puissent l'interroger. Sur Juniper, une communauté sans instruction clients accepte tout le monde, et sur Aruba, une communauté sans liste d'accès autorise tous les hôtes.
La configuration chez quatre constructeurs
Voici la version 3 avec authentification et chiffrement chez chaque constructeur. Cisco : une vue, un groupe au niveau privacy avec une liste d'accès, et un utilisateur en SHA et AES. Huawei : un groupe avec privacy, et un utilisateur en SHA 256 et AES 128.
Aruba : un utilisateur version 3 avec authentification et chiffrement, plus une commande qui désactive les anciennes versions. Juniper : un utilisateur sous le local engine, rattaché à un groupe par le modèle de contrôle d'accès (VACM).
Des valeurs par défaut différentes
Les valeurs par défaut diffèrent, et elles comptent. Sur Cisco, l'agent est désactivé tant que vous ne le configurez pas, et un hôte déclaré sans mot-clé de version reçoit la version 1. Aruba livre SNMP désactivé, et par défaut seuls les utilisateurs authPriv peuvent se connecter.
Le guide de Huawei indique que la version 3 est sa valeur par défaut. Chez Juniper, la version 3 est par défaut sans authentification et sans chiffrement tant que vous ne les définissez pas.
Trois pannes classiques
Trois pannes reviennent sans cesse. Le manager tombe en timeout : la liste de contrôle de Huawei cite une version différente, une communauté erronée, le manager bloqué par la liste d'accès, un objet hors de la vue, ou un timeout de l'outil d'interrogation plus court que ce dont l'équipement a besoin.
Les informs n'arrivent jamais : sans l'engine ID du manager et un utilisateur correspondant, ils ne sont pas envoyés. Et sur certaines versions Cisco, une communauté créée pour les traps répond aussi aux interrogations, sauf si une liste d'accès la restreint.
Ce que NacTrack montre
Le module SNMP de NacTrack, en bêta, vérifie l'accessibilité de chaque équipement toutes les minutes, et relève les compteurs d'interfaces et l'état de santé toutes les cinq minutes, en versions 1, 2c et 3. Il reçoit les traps sur l'appliance et les transforme en événements.
La page de disponibilité montre le parc, les indisponibilités et les équipements actuellement hors service. La page des événements liste chaque trap et chaque changement d'état, rapprochés de l'inventaire.
Voir ce protocole sur votre réseau
NacTrack lit ces protocoles sur vos équipements, en SSH et en lecture seule.