Introduction - Première partie

Ce tutoriel vous propose de découvrir la librairie Python PySNMP permettant de dialoguer avec tout matériel compatible avec le protocole du même nom.

Toutefois, avant de se lancer dans une présentation technique décrivant comment exécuter une requête « get » ou « set » en SNMP v2 ou v3, nous vous proposons une présentation des concepts de ce protocole. Ceci vous permettra de mieux comprendre les tenants et aboutissants de la librairie afin de vous mener vers le Graal absolu de sa complète maîtrise.

Dans cette première partie nous présentons le protocole SNMP et l'utilisation de commandes système qui vous permettront de toucher du doigt les concepts que nous exposons.

A la fin de ce tutorial en 4 parties vous serez normalement capable :

• D'exécuter des requêtes GET/SET
• Envoyer des traps
• Créer des sondes pour des outils de supervision comme Nagios, Centreon et consorts.

• Créer un agent SNMP

Avant de continuer la lecture de cet article, si vous débutez sur le sujet, je vous invite à lire cette introduction à la supervision qui vous donnera les bases techniques pour comprendre ce métier ainsi que ses enjeux et les outils à votre disposition. Cette lecture vous aidera à mieux situer la place de SNMP dans cet univers. Le document est très orienté Nagios et dérivés, mais il vous fournira tous les éléments de base pour bien appréhender cette discipline.

Plan

• Présentation du protocole
  • SNMP
  • Les MIB
  • ASN1
• Dialoguer avec des agents en utilisant des commandes système
• PySNMP
  • Les éléments de base
  • Les requêtes
  • Les tables
  • Utiliser ses MIBs avec un agent

Qu'est-ce que SNMP ?

SNMP signifie « Simple Network Management Protocol »

C'est un protocole de gestion de réseau.

Concrètement il permet de superviser l'état des équipements réseaux ou d'un parc informatique, aussi bien le matériel que les services :

• Routeurs, switchs
• Stations de travail
• Imprimantes
• Services (messagerie, ftp, ssh, http, processus, mémoire…)

Par supervision il faut comprendre « obtenir des informations » sur l'état de ces « éléments ». Mais ce protocole permet aussi d'effectuer des actions de maintenance comme redémarrer un service ou une machine, nettoyer les têtes de lecture d'une imprimante, …

Fonctionnement de SNMP

SNMP se base sur l'idée qu'un système de supervision de réseau se compose :

• De nœuds à administrer (Managed Nodes), contenant chacun un agent. L'agent est le service (logiciel) qui dialogue avec les managers pour échanger de l'information sur l'état du nœud
• D'au moins une station d'administration, le manager (Network Management Station)
• D'un protocole permettant d'échanger de l'information entre les agents et le NMS, ce protocole est SNMP

Le site wikipédia offre une présentation succinte de ce dernier dans sa version française. La version anglaise du même article est beaucoup plus complète et cite notamment l'ensemble des RFC qui le décrivent.

Manager et agents (source PySNMP)

 

Comment cela fonctionne ?

• Le manager envoie des requêtes de type « GET » aux agents pour récupérer de l'information sur un service/une machine via le protocole SNMP
• Il peut aussi envoyer des requêtes « SET » pour modifier l'état des services et/ou de la machine gérés par l'agent
• Les agents peuvent envoyer des requêtes de type « TRAP » au manager pour signaler un dysfonctionnement
• Les agents peuvent être regroupés au travers d'un « agent maître »
• Les informations accessibles et fournies par les agents sont organisées dans une base « virtuelle » appelée MIB. Cette base est normalisée.

Echange de requêtes entre le manager et les agents (source wikipédia)

Et c'est tout. C'est simple ?

Pourquoi utiliser SNMP ?

• C'est un protocole très ancien et supporté par quasiment tous les constructeurs de matériels réseau.
• Depuis les versions 2 et 3 il est sécurisé, offrant un accès restreint à certaines informations et s'appuie sur des protocoles de chiffrement comme SSH et TLS (mais avec ses propres librairies et outils internes).
• L'information contenue dans les MIBs est normalisée, c'est à dire que quelque soit l'appareil et son constructeur une même information sera accessible au même endroit et de la même manière. Et cela c'est formidable : « Vous êtes administrateur réseau, vous voulez connaître la mémoire totale et disponible d'une machine, vous l'obtiendrez de la même manière quelque soit l'OS (mac/windows/unix/android) et le matériel utilisé (AMD, ARM, Intel, …) ». N'est-ce pas fabuleux ?
• Il est simple (les agents sont légers, la complexité est déportée au niveau des managers)
• Il est indépendant de l'architecture réseau et des éléments (PC, Imprimantes, routeurs, …)
• Il est extensible, on peut personnaliser les bases d'informations en surcroît de ce qu'offre le standard
• Il est Robuste. Il s'appuie sur UDP ou TCP : Il fonctionnera encore lorsque le réseau aura de graves problèmes d'engorgement : une trame d'information UDP c'est léger.

Est-ce si bien ?

Globalement c'est plutôt top, et surtout il a peu de concurrents matures et aussi répandus, mais :

• Des fois quand même il n'est pas très simple : Les MIBs sont « lisibles par l'homme » mais pour reprendre les propos d'un de mes collègues, des fois, ceux qui y arrivent ne se sont pas tous vraiment humains.
• Le protocole est simple mais son implémentation peu s'avérer bien plus complexe.
• La version 3 a implémenté sa propre couche SSH plutôt que de faire comme HTTPS (du HTTP over SSH). Ceci rend plus pénible les communications : il n'y a pas d'auto-négociation pour le chiffrement et vous devez vous-même fournir 5 informations pour créer une connexion sécurisée.
• Certains concurrents commencent à voir le jour comme WMI et offrent un langage d'interrogation plus riche (WQL).

Historique

• La première version du protocole date de 1989. Elle n'offre pas de sécurité et utilise la MIB version 1 qui reste assez simple
• La seconde version a été publiée en 1993
  • Elle apporte plus de sécurité tant au niveau de l'authentification que du chiffrement
  • Elle permet l’administration distribuée

  • Elle apporte une version plus riche de la MIB( MIB-2)

• La version 3 a été publiée en 1998
  • Elle apporte des transactions chiffrées via SSH
  • Elle est plus modulaire

Dans les faits

• La version 2 a eu du mal à démarrer et plusieurs « releases » ont été faites. C'est la version « 2c » qui a su s'imposer. Je vous conseille à ce sujet la lecture de cette présentation de SNMP qui décrit un peu plus ces difficultés de démarrage ainsi que la présentation de PySNMP qui reprend certains de ces points.
• La version 3, tout comme la v2 a eu du mal à s'imposer elle aussi. Elle n'est pas supportée par tous les matériels aujourd'hui même si cela s'est bien amélioré. Les problèmes de sécurité étant devenus vraiment sensibles aujourd'hui elle est la version recommandée.
• SNMP domine le monde TCP/IP et il est le standard recommandé depuis mai 1990

Les MIBs

Avant de pouvoir lancer nos premières requêtes SNMP il convient de comprendre ce qu'est une MIB.

La Management Information Base est une base de données « virtuelle » permettant d'organiser de manière hiérarchique les informations fournies par les agents sur les équipements.

Ce n'est pas une base de données à proprement parler comme une base relationnelle. Elle n'existe qu'au travers de l'agent qui est libre de l'implémenter comme il le souhaite. Quand l'agent ne fonctionne pas, il n'y a pas de données dans la MIB. Seule la description de la MIB (un fichier texte généralement) existe.

Une MIB décrit en fait comment numéroter/accéder à l'information.

C'est l'agent (le logiciel) qui stocke (mais on devrait dire gère) cette information, laquelle est le plus souvent « volatile », comme il le veut.

Il est très important de bien comprendre le point ci-dessus, c'est ce qui gêne souvent la compréhension des MIBs par des nouveaux arrivants sur ce protocole.

Prenons l'exemple du nombre de processus actifs sur une machine. Celui-ci est identifié de manière unique par la MIB-II. Mais cette information est demandée par l'agent au Système d'Exploitation au moment ou il reçoit une requête pour cette dernière, car cette donnée est changeante à chaque instant. Elle n'est donc pas « stockée » par l'OS. Elle n'est pas accessible au travers d'une requête SQL. Elle est fournie quand on la demande, et tant que l'agent ne l'a pas demandée lui-même à l'OS elle n'est pas vraiment disponible ou n'a pas encore d'existence :

• Le manager demande l'information à l'agent
• L'agent reçoit la demande et appelle une primitive système pour l'obtenir
• L'agent retourne l'information au manager

C'est une information « volatile » qui n'est pas vraiment stockable.

Beaucoup d'informations issues des MIBs sont de cette nature, d'autres sont parfois stockées quelque part, comme le responsable d'une machine, le port d'un service ou encore l'état d'une ligne électrique ou d'une diode (éteinte, allumée). Selon les constructeurs/OS ces informations sont stockées physiquement différemment, mais la MIB les normalise pour la grande majorité afin qu'une même information soit toujours demandée de la même manière par le manager. C'est à l'agent de savoir ou aller la chercher selon le matériel/service géré.

Et cela apporte beaucoup de facilités dans l'écriture de sondes/outils de supervisions. C'est une des grandes forces de ce standard.

MIB-II

Une des MIB les plus connues est la MIB-II, décrite par la RFC 1213.

Elle est mise en œuvre dans quasiment tous les équipements TCP/IP.

Elle compte dix groupes :

• system
• interfaces
• Address Translation
• IP
• ICMP
• TCP
• UDP
• EGP"
• transmission
• et SNMP

C'est à dire que toute information que vous pourriez demander concernant la MIB-II sera classée dans l'un de ces groupes.
Des exemples d'informations que vous pourriez retrouver dans ces ensembles, sont:

• la liste des processus (avec informations mémoire et CPU) ;
• les débits réseaux ;
• le load average ;
• l'utilisation mémoire ;
• le contact du système, l'uptime ;
• l'utilisation de l'espace disque ;
• les tables de routages.

Exemple de description d'une MIB

Enfin, les mibs sont décrites dans un « langage » appelé ASN.1

L'exemple ci-dessous présente l'information « description d'interface (réseau) » telle que décrite en ASN.1 :

ifDescr OBJECT-TYPE
 SYNTAX DisplayString (SIZE (0..255))
 ACCESS read-only
 STATUS mandatory
 DESCRIPTION
 "A textual string containing information about the
 interface. This string should include the name of
 the manufacturer, the product name and the version
 of the hardware interface."
 ::= { ifEntry 2 }

La lecture de la définition de cette donnée est assez compréhensible par elle-même.
Nous indiquons ici :

• son nom, « ifDescr »
• son type, « DisplayString », une chaîne de 255 caractères maximum
• son mode d'accès, « lecture seule »
• son état, « obligatoire »
• enfin son emplacement dans le nœud parent « ifEntry » : 2ème sous-élément du nœud « ifEntry »

Organisation de l'information dans les MIBs

Pour bien comprendre cette description « hiérarchique » de la donnée « ifDescr », voici un graphe représentant la hiérarchie principale de toutes les MIBs :

Hiérarchie principale d'une MIB (Source wikipédia)

Le graphe ci-dessus présente la structure hiérarchique des MIBs.
Sous le nœud racine, noté « . » se trouvent 3 informations numérotées :

• CCITT avec le numéro 0
• ISO avec le numéro 1
• ISO – CCITT avec le numéro 2

Sous le nœud ISO se trouvent 4 informations, elles aussi numérotées :

• standard, avec le numéro 0
• registration authority, avec le numéro 1
• member body, avec le numéro 2
• organization, avec le numéro 3

Le chemin d'accès à l'information « organization » située sous « ISO », elle-même située sous la racine sera « .1.3 » ou encore « .ISO.organization »
Et ainsi de suite.

Par exemple l'accès à l'information « MIB-2 » se fera via le chemin « .1.3.6.1.2.1 » ou encore « .ISO.organization.DoD.Internet.management.MIB-2 »
Et voilà, vous savez tout sur les MIBs : elles définissent des informations en ASN.1, lesquelles sont accessibles via un chemin exprimé avec des numéros ou les noms des informations parentes.

Les OID

Les informations sont donc numérotées selon leur ordre dans l'arbre de la MIB, ces numéros sont appelés OID (Object IDentifier).
Voici quelques exemples d'OIDs :

• .1.3.6.1.2.1.1 system : uptime, contact, nom
• .1.3.6.1.2.1.2 interfaces: interfaces réseau
• .1.3.6.1.2.1.4 ip: ip routing, etc
• .1.3.6.1.2.1.5 icmp: icmp errors, discards… (icmp c'est par exemple le ping)
• .1.3.6.1.2.1.6/7 tcp ou udp: états des connexions tcp ou udp

La question devient maintenant « comment trouver toutes les informations disponibles dans une MIB ? »
Les réponses seront :

• En lisant les standards et normes associés: https://tools.ietf.org/html/rfc1213
• En exécutant des requêtes avec des outils SNMP qui permettent de parcourir toute l'arborescence d'une MIB.
• En parcourant ces MIBs via des sites Internet qui ont l'amabilité de les représenter facilement, comme le site IP MONITOR.

On observera sur ce dernier que le chemin complet à l'information « ifDescr » est fournit par l'OID.

C'est ce que va nous permettre de faire PySNMP : envoyer des requêtes demandant la valeur d'un nœud (une information) située à un emplacement précis dans une MIB ou modifiant cette valeur.

Et c'est tout. Ou presque. Y voyez-vous un peu plus clair ?

La pratique approche.

Un univers de MIBs

Il existe tout plein de MIBs :

• Selon le matériel (routeur, imprimante) les informations sont différentes.
• Pour cette raison, certains équipements ou constructeurs fournissent donc leurs propres MIB définissant une branche dans l'arbre des OIDs, avec un numéro officiel défini auprès de l'IANA (Internet Assigned Numbers Authority) . On retrouvera par exemple CISCO à cette branche de l'arbre: iso.org.dod.internet.private.entreprise.cisco = 1.3.6.1.4.1.9 A cet emplacement, CISCO est libre de proposer les MIBs décrivant les informations de ses propres matériels comme il l'entend. Beaucoup d'autres sociétés en font autant, comme Alcatel/Nokia pour ne citer qu'eux.

Le site IP Monitor présente de nombreuses bases (mib) pour différents types d'informations/matériels/services que vous pouvez consulter.

Les communautés

L'accès aux informations d'une MIB est filtré par ce que l'on appelle la « communauté », sauf version 3 du protocole.
La « communauté » est une sorte de mot partagé, « public » par défaut.

« public » peut-être rapproché du login « anonymous » disponible sur la plupart des serveurs ftp.

Une demande d'information est toujours exécutée via une communauté.
Selon la communauté utilisée, les informations reçues seront différentes :

• La communauté « public » donne accès au niveau « read-only ».
• Il existe un niveau privé en lecture/écriture ( communauté « private ») qui est le plus souvent désactivé (Il donne accès à toute la configuration système en écriture)

Donc, quand vous souhaitez accéder à/ou modifier une information d'un agent, vous :

• envoyez une requête GET/SET à l'agent
• en fournissant le chemin de l'information désirée, son OID
• en fournissant la communauté utilisée (« private » pour les modifications)
• en fournissant la nouvelle valeur de la donnée en cas de modification
• en fournissant l'adresse IP/nom de domaine ou s'exécute l'agent
• le port utilisé est par défaut le port 161

Utilisation du protocole en ligne de commandes

Pour bien comprendre ce que permet ce protocole, je vous propose d'exécuter les commandes de bases avec des outils systèmes.
Ceci permettra de toucher du doigt la mécanique sous-jacente et de vérifier que les agents comprennent bien vos requêtes avant de les écrire en Python.

Les commandes

Avant de lancer nos premières commandes, regardons les types de requêtes que le protocole propose pour permettre aux manager et agents de s'échanger de l'information :

• Get: Demande de la valeur d'un OID par le manager à l'agent. L'agent retourne l'information via un message de type Response
• GetNext : Demande de l'information suivante dans la MIB. Permet de parcourir une MIB sans connaître ce qu'elle contient
• Set : Modifie la valeur associée à un OID. Permet de changer la configuration ou modifier l'état d'un hôte
• GetBulk : Demande tout un ensemble d'infos en une seule requête. Evite de multiplier les Get et GetNext
• Response : message envoyé par l'agent au manager contenant l'information demandée
• Trap : Message envoyé par l'agent au manager pour signaler un problème
• Inform : Message envoyé par le manager pour confirmer la réception du trap

Pré-requis

Pour lancer nos premières commandes, il convient de disposer d'un agent et d'un manager.
Je vous conseille cet excellent tutorial pour une telle installation sur une machine Linux (type debian).
Pour le manager, vous pouvez installer les outils snmp et mibs de base via ces commandes

sudo apt-get install snmp snmp-mibs-downloader
sudo apt-get install smitools libsmi

Ensuite il vous faut un agent.

Pour le trouver vous pouvez :

• Essayer avec une imprimante réseau ou une machine possédant une adresse IP. Généralement elles sont compatibles avec le protocole SNMP
• Installer votre propre agent en suivant le tutoriel cité précédemment
• Lancer vos commandes vers l'agent « demo.snmplabs.com » librement accessible via Internet, ce que nous ferons.

Enfin, si vous ne disposez pas de la possibilité d'installer les commandes SNMP sous votre Linux, sachez que la librairie PySNMP propose des scripts équivalents en pur Python que vous pouvez installer avec la commande « pip install pysnmp-apps ».

La commande « GET »

Elle accepte plusieurs paramètres dont :

• « -v » : version du protocole
• « -c » : communauté
• « -O » : format de sortie (Essayez a, f, n, s, …)

Exemple :

$ snmpget -v2c -c public -Oa demo.snmplabs.com sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: SunOS zeus.snmplabs.com 4.1.3_U1 1 sun4m

La version du protocole à utiliser est obligatoire, dans la commande ci-dessus nous utilisons le protocole version 2c et la communauté « public ».
Nous demandons l'information « sysDescr ». Pour ce faire nous ajoutons le chemin « .0 » qui désigne « la valeur du noeud sysDescr ».

Les autres valeurs sous un nœuds (.1, .2, etc.) désignent les sous-éléments de ce dernier.
Les informations peuvent donc être demandées via le chemin complet comme sous la forme d'un OID numérique « 1.3.6.1.2.1.1.1.0 » (ou textuel) ou encore via le nom court. Car il est normalement unique.

Vous pouvez donc relancer la commande ci-dessus avec l'OID numérique…

La commande « Get Next »

Elle accepte les mêmes paramètres que « GET » mais retourne non pas l'OID demandé mais celui qui suit dans l'arborescence. En chainant un GET puis plusieurs GET NEXT vous pouvez donc consulter tout l'arbre d'une MIB.

$ snmpgetnext -v2c -Oa -c public -Os demo.snmplabs.com sysDescr.0
sysObjectID.0 = OID: enterprises.20408
$ snmpgetnext -v2c -On -c public -Os demo.snmplabs.com sysObjectID.0
sysUpTimeInstance = Timeticks: (179062573) 20 days, 17:23:45.73

Vous pouvez exécuter GET NEXT sur n'importe quel nœud, donc la racine d'une MIB.

Mais pour parcourir tout un arbre, c'est laborieux.

Les commandes « Get Bulk et Walk »

Pour éviter d'envoyer plusieurs commandes « GET » les unes après les autres ce qui surcharge les échanges réseau, il est possible de demander à consulter plusieurs OID en une seule fois via la commande « GET BULK ». Mais tous les agents ne la supportent pas.

Vous pouvez aussi utiliser la commande « Walk » pour parcourir toute une arborescence, comme vous le feriez avec « GET » et « GET NEXT ». Mais c'est la commande « WALK » qui les exécutera pour vous.

$ snmpwalk -v2c -On -c public -Os demo.snmplabs.com system
sysDescr.0 = STRING: SunOS zeus.snmplabs.com 4.1.3_U1 1 sun4m
sysObjectID.0 = OID: enterprises.20408
sysUpTimeInstance = Timeticks: (179082328) 20 days, 17:27:03.28
sysContact.0 = STRING: SNMP Laboratories, info@snmplabs.com
sysName.0 = STRING: zeus.snmplabs.com
sysLocation.0 = STRING: Moscow, Russia
sysServices.0 = INTEGER: 72
sysORLastChange.0 = Timeticks: (179082382) 20 days, 17:27:03.82
sysORID.1 = OID: enterprises.20408.1.1
sysORDescr.1 = STRING: new comment
sysORUpTime.1 = Timeticks: (123) 0:00:01.23

Traduire des OIDs

La commande « snmptranslate » permet de traduire des OID du mode numérique au mode texte et inversement.

$ snmptranslate -On SNMPv2-MIB::sysDescr.0 
.1.3.6.1.2.1.1.1.0
$ snmptranslate 1.3.6.1.2.1.1.1.0
SNMPv2-MIB::sysDescr.0

Modifier un OID, la commande « SET »

La commande « snmpset » permet de modifier la valeur d'un OID.
Elle n'est disponible qu'avec le protocole v2 et la communauté « private » ou le protocole v3.
L'exemple ci-dessous est fourni pour le protocole v3.

Les paramètres utilisés sont :

• « -u » : utilisateur
• « -l » : niveau de sécurité pour s'identifier
• « -a » : protocole d'authentification (chiffrement mot de passe)
• « -A » : mot de passe d'authentification
• « -x » : algorithme de chiffrement pour la connexion
• « -X » : mot de passe/salt pour le chiffrement de la connexion

C'est là que l'on découvre le côté pénible du protocole v3 qui implémente lui-même les connexions SSH sans faire de SNMP over SSH : il n'y a pas d'auto-négociation des algorithmes de chiffrement, il faut tout préciser par soi-même ! Misérable !

$ snmpget localhost sysLocation.0
SNMPv2-MIB::sysLocation.0 = STRING: Rouans
$ snmpset -u demo -l authPriv -a MD5 -x DES -A pass1 -X pass2 localhost sysLocation.0 s "Earth"
SNMPv2-MIB::sysLocation.0 = STRING: Earth
$ snmpget localhost sysLocation.0
SNMPv2-MIB::sysLocation.0 = STRING: Earth

Recommandations concernant l'utilisation du protocole SNMP et des outils associés

Les versions 1 et 2 du protocole sont insuffisamment sécurisées et pas du tout pour la première.

La protection dans la version 2 du protocole se fait uniquement via les « communautés » qui n'utilisent pas de mot de passe. C'est très faible comme type de protection, car il suffit de connaître le nom de la communauté pour accéder aux informations d'un matériels qui pourraient s'avérer être sensibles.

Les agents WindowsXP étaient particulièrement réputés pour proposer dans leur configuration par défaut beaucoup trop d'informations sensibles, comme les logins des utilisateurs qui étaient accessibles directement via la communauté « public ».

Dans la pratique l'agent fournit par les outils NetSNMP (sous Linux) est relativement lent et n'est pas forcément très bien sécurisé, beaucoup de failles sont découvertes régulièrement.

Aussi, quelque soit la solution retenue, désactivez systématiquement le mode anonyme, ou alors contrôlez chaque information proposée.

Puis, créez des ACLS d'accès à chaque MIB par utilisateur afin d'avoir une maîtrise complète de qui peut faire quoi.

Enfin, nous ne saurions que trop vous recommander de privilégier exclusivement la version 3 du protocole.

Conclusion

Les commandes de base du protocole SNMP sont assez simples une fois que l'on a compris comment manipuler les paramètres qu'elles utilisent.

Cette première partie de l'initiation au protocole SNMP doit normalement vous avoir donné :

• Une compréhension globale du protocole
• Une bonne idée de comment accéder et manipuler les informations des MIBs, avec des commandes système

La seconde partie de ce tutoriel sur SNMP et PySNMP est consacrée à la découverte de PySNMP:

• Installer PySNMP
• Savoir manipuler les composants de base (OIDs, Communautés, Utilisateurs, Contextes, …)
• Exécuter des requêtes GET/GETNEXT/SET

La troisième partie de ce tutoriel vous plongera plus en avant dans l'utilisation de PySNMP pour vous apprendre à lire des tableaux de données.

Enfin, la quatrième partie vous apprendra à créer un agent utilisant une MIB personnalisée.