Le principe

Une machine informatique, quelle que soit sa fonction, a généralement beaucoup de choses à dire. Elle le dit le plus souvent discrètement, si bien que peu de gens l'entendent.

La plupart de ses utilisateurs ne l'écoute pas, sauf quand elle se met à hurler ou à faire la gueule, ce qui est tout de même assez rare. Elle hurle de diverses façons, une alarme sonore, par exemple, lorsqu'elle est en surchauffe, un écran bleu pour Windows, lorsque le noyau se plante irrémédiablement, elle fait la gueule, par exemple, lorsqu'elle refuse simplement de démarrer… Le reste du temps, elle chuchote divers indicateurs d'état, et certaines remarques, qu'elle consigne généralement dans les logs, sorte de journaux intimes, que, finalement, assez peu de gens consultent.

Les administrateurs sont les seuls à s'y intéresser. Vous serez peut-être surpris de voir à quel point votre machine vous parle. Dans Windows™, vous avez au moins quatre journaux, que vous pouvez rendre plus ou moins verbeux, mais c'est bien sûr sous GNU/Linux que vous découvrirez le mieux tout ce qu'une machine a à dire. L'objectif étant ici de parler de SNMP, nous n'entrerons pas plus dans ces détails. Sachez, si ce n'est pas encore le cas, que sous GNU/Linux, vous avez deux répertoires fortement intéressants :

• /var/log qui contient tous les journaux tenus par votre machine,
• /proc qui est en fait un espace RAM dans lequel vous retrouverez une infinité de compteurs, d'indicateurs, de variables, drapeaux et autres choses encore.

Il y a enfin des informations dont le système ne se soucie pas obligatoirement, mais qui existent, remontées directement par le « firmware » ¹⁾, comme par exemple la température du processeur, la vitesse de rotation des ventilateurs.

Dans tout ceci, il y a une foule d'informations qui intéressent les administrateurs et dont ils aimeraient disposer à distance via le réseau. Il est clair que lorsque le parc contient plusieurs centaines de machines, c'est tout de même plus agréable de disposer de toutes les informations en temps réel et de façon centralisée.

De plus, l'administrateur peut apprécier de pouvoir régler tel ou tel paramètre sans avoir à se déplacer sur le site de la machine concernée.

SNMP est exactement conçu pour répondre à ces besoins.

Chaque équipement que l'on voudra « manager » à distance devra disposer d'un agent SNMP. Cet agent est un serveur, c'est à dire qu'il reste à l'écoute d'un port particulier : le port UDP 161.

La principale fonction de cet agent est de rester à l'écoute des éventuelles requêtes que l'administrateur lui enverra. Lorsqu'il recevra une requête, il y répondra, s'il y est autorisé. Plus exactement, il répondra si la requête est émise par une entité autorisée. Autrement dit, cet agent est là pour écouter des requêtes et y répondre.

L'agent devra éventuellement pouvoir agir sur l'environnement local, si l'administrateur souhaite modifier un paramètre.

Par ailleurs, l'agent SNMP pourra éventuellement émettre des alertes de sa propre initiative, s'il a été configuré pour cette besogne. Par exemple, il pourra émettre une alerte si le débit sur une interface réseau atteint une valeur considérée par l'administrateur comme critique. Il peut y avoir une multitude d'alertes possibles, suivant la complexité de l'agent. La température du processeur, le taux d'occupation des disques durs, le taux d'occupation CPU…

On pourra trouver des agents SNMP sur des hôtes (ordinateurs) mais aussi sur des routeurs, des ponts, des switches…

L'administrateur, sur sa machine d'administration, dispose d'un outil dit « manager ». C'est avant tout un client, dans la mesure où c'est lui qui envoie les requêtes aux divers agents SNMP du réseau. Il devra aussi disposer d'une fonction serveur, car il doit rester à l'écoute des alertes que les divers équipements sont susceptibles d'émettre à tout moment.

Un petit dessin… Tous les équipements disposent d'un agent SNMP, la station d'administration dispose du « manager » :

Dans un tel cas, l'administrateur peut, en théorie, observer le comportement de la totalité de son réseau depuis sa station d'administration. C'est vrai pour un LAN, c'est aussi vrai pour un WAN (entendez par là que l'équipement à administrer peut se trouver géographiquement très loin).

Les « boites noires » (routeurs, switches…) sont équipées éventuellement d'un agent SNMP (c'est une question de prix).

Pour les serveurs et les stations il existe probablement un logiciel à installer, quel que soit le système (sérieux). Pour GNU/Linux : « NET-SNMP » (ou « UCD-SNMP“), Windows XP professionnel et suivants (versions serveur à fortiori) permettent d'installer un agent SNMP.

Le Manager dispose d'un serveur qui reste à l'écoute, sur le port UDP 162, des éventuels signaux d'alarme (traps). Certains logiciels de supervision utilisant SNMP sont célèbres dans le monde du logiciel propriétaire (commercial, privateur etc.), qui n'ont pas d'équivalent dans le monde du logiciel libre.

En revanche, il reste parfaitement possible d'exploiter SNMP dans le bon vieux mode de la ligne de commande, avec des outils plus « eye candy » comme MRTG, RRDTool, CACTI ou même Zabbix (qui peut faire d'autres choses aussi, avec un agent spécifique), ou avec des scripts qui feront exactement ce que l'on désire, si besoin est.

Juste pour donner un exemple, voyons ce que ça donne, si, depuis une machine GNU/Linux, nous interrogeons l'agent SNMP d'une station Windows XP (ou Vista, ou Seven).

Nous réalisons ceci avec un outil dont GNU/Linux a le secret, et que nous verrons plus loin. Sa particularité est de produire une sortie strictement illisible pour le non initié. Il s'agit de snmpwalk.

Le but n'est pas ici de tout comprendre mais juste de donner une idée des informations que l'on peut obtenir. La sortie faisant 1577 lignes, nous n'en verrons que quelques-unes.

# Quelques infos sur la machine et son OS :
SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 15 Model 2 Stepping 4
            AT/AT COMPATIBLE - Software: Windows 2000 Version 5.1
            (Build 2600 Uniprocessor Free)
...
# Le type de carte réseau :
IF-MIB::ifDescr.2 = STRING: D-Link DFE-528TX PCI Adapter
        - Miniport d'ordonnancement de paquets
...
#Quelques infos sur la configuration IP :
IP-MIB::ipAdEntAddr.127.0.0.1 = IpAddress: 127.0.0.1
IP-MIB::ipAdEntAddr.192.168.0.10 = IpAddress: 192.168.0.10
IP-MIB::ipAdEntIfIndex.127.0.0.1 = INTEGER: 1
IP-MIB::ipAdEntIfIndex.192.168.0.10 = INTEGER: 2
IP-MIB::ipAdEntNetMask.127.0.0.1 = IpAddress: 255.0.0.0
IP-MIB::ipAdEntNetMask.192.168.0.10 = IpAddress: 255.255.255.0
...
RFC1213-MIB::ipRouteNextHop.0.0.0.0 = IpAddress: 192.168.0.250
...
#Les ressources de mémoire de masse :
HOST-RESOURCES-MIB::hrStorageDescr.2 = STRING: C:\ Label:  Serial Number d803c0ad
HOST-RESOURCES-MIB::hrStorageDescr.3 = STRING: D:\
HOST-RESOURCES-MIB::hrStorageDescr.4 = STRING: E:\ Label:DATA  Serial Number 10822ea3
HOST-RESOURCES-MIB::hrStorageDescr.5 = STRING: F:\
HOST-RESOURCES-MIB::hrStorageDescr.6 = STRING: G:\ Label:ZIP-100  Serial Number 1de00d03
...
# Les imprimantes installées :
HOST-RESOURCES-MIB::hrDeviceDescr.1 = STRING: HP DeskJet 600
HOST-RESOURCES-MIB::hrDeviceDescr.2 = STRING: HP DeskJet 550C
...
# Les services en cours d'exécution :
HOST-RESOURCES-MIB::hrSWRunName.1516 = STRING: « rundll32.exe"
HOST-RESOURCES-MIB::hrSWRunName.1520 = STRING: « OLFSNT40.EXE"
HOST-RESOURCES-MIB::hrSWRunName.1820 = STRING: « NAVAPW32.EXE"
HOST-RESOURCES-MIB::hrSWRunName.1836 = STRING: « spampal.exe"
HOST-RESOURCES-MIB::hrSWRunName.2016 = STRING: « rundll32.exe"
HOST-RESOURCES-MIB::hrSWRunName.2128 = STRING: « msimn.exe"
...
# Les applications installées !!!
HOST-RESOURCES-MIB::hrSWInstalledName.9 = STRING: « Ethereal 0.9.8"
HOST-RESOURCES-MIB::hrSWInstalledName.10 = STRING: « Exodus Jabber Client (remove only)"
HOST-RESOURCES-MIB::hrSWInstalledName.11 = STRING: « FileZilla (remove only)"
...
HOST-RESOURCES-MIB::hrSWInstalledName.79 = STRING: « SpamPal: BadWords plugin"
HOST-RESOURCES-MIB::hrSWInstalledName.80 = STRING: « SpamPal"
...
# Ainsi que leur date d'installation...
HOST-RESOURCES-MIB::hrSWInstalledDate.9 = STRING: 2002-12-17,10:29:48.0
HOST-RESOURCES-MIB::hrSWInstalledDate.10 = STRING: 2002-12-15,15:53:18.0
HOST-RESOURCES-MIB::hrSWInstalledDate.11 = STRING: 2003-1-9,10:50:28.0
...
HOST-RESOURCES-MIB::hrSWInstalledDate.79 = STRING: 2003-7-2,17:48:24.0
HOST-RESOURCES-MIB::hrSWInstalledDate.80 = STRING: 2003-6-30,17:38:58.0
...

Comme vous pouvez vaguement le deviner, SNMP peut se révéler être plutôt du genre indiscret. C'est un outil pour les administrateurs et les informations bonnes pour les administrateurs doivent souvent rester confidentielles.

Nous aurons largement l'occasion d'approfondir l'étude de la façon dont les données sont organisées et donc, la façon dont on peut retrouver plus ou moins simplement l'information que l'on cherche ou que l'on désire mettre à jour via SNMP.

Contentons-nous pour l'instant d'admettre que l'ensemble des informations que peut fournir un objet (serveur, switch, routeur, imprimante, point d'accès WI-FI…) est classé de manière arborescente, par thème et sous-thème.

Juste histoire de nous mettre l'eau à la bouche, voyons comment il est possible d'interroger un agent SNMP pour lui demander le descriptif de l'hôte qui l'héberge.

La question, c'est (nous n'expliquerons pas tout de suite la formule magique) :

$ snmpget -On -c public -v 2c 172.16.252.2 .1.3.6.1.2.1.1.1.0

La réponse est ici :

.1.3.6.1.2.1.1.1.0 = STRING: ProCurve J4899B Switch 2650, revision H.10.35, ROM H.08.02 (/sw/code/build/fish(mkfs))

Pour seule explication, vous avez droit pour l'instant à ceci : Nous avons interrogé un switch « manageable » qui dispose de l'adresse IP 172.16.252.2, pour obtenir sa description. Nous savons maintenant qu'il s'agit d'un modèle Hewlett Packard ProCurve de la série 2650, modèle J4899B.

Nous aurions pu poser la question de manière légèrement différente :

$ snmpget -Ot -c public -v 2c 172.16.252.2 .1.3.6.1.2.1.1.1.0

nous aurions alors obtenu comme réponse :

SNMPv2-MIB::sysDescr.0 = STRING: ProCurve J4899B Switch 2650, revision H.10.35, ROM H.08.02 (/sw/code/build/fish(mkfs))

Pas vraiment plus clair, mais qui fait apparaitre SNMPv2-MIB::sysDescr.0 en lieu et place de .1.3.6.1.2.1.1.1.0.

Avec un peu d'effort, nous pouvons même poser la question d'une troisième façon :

$ snmpget -Of -c public -v 2c 172.16.252.2 .1.3.6.1.2.1.1.1.0

ce qui nous vaudra comme réponse :

.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = STRING: ProCurve J4899B Switch 2650, revision H.10.35, ROM H.08.02 (/sw/code/build/fish(mkfs))

C'est à dire que nous avons ici .iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 plutôt que .1.3.6.1.2.1.1.1.0. C'est plus long et ça veut dire exactement la même chose, mais avec du texte.

Les trois « machins » :

• .1.3.6.1.2.1.1.1.0 ;
• SNMPv2-MIB::sysDescr.0 ;
• .iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 ;

veulent dire la même chose et sont parfaitement équivalents. Nous verrons que la représentation numérique est toujours utilisable, alors que les représentations en mode texte ne le seront pas toujours, il nous faudra éventuellement une sorte de dictionnaire.

Pour ceux qui ont roulé leur bosse dans divers domaines de l'informatique (programmation orientée objet, DOM etc.), cette façon de faire leur rappellera des méthodes habituelles de classement arborescent.

Il y a dans ces réponses un mot d'apparence anodine, mais d'importance fondamentale pourtant : la MIB. Aucun rapport avec les protozoaires. Ici, MIB veut dire « Management Information Base ». Disons que c'est le fameux dictionnaire.

Nous pouvons donc conclure que les informations que peuvent échanger un agent SNMP et son manager, sachant que nous sommes sur un réseau apte à interconnecter des nœuds hétérogènes :

• sont classées dans une structure arborescente ;
• que la structure de cet arbre doit être normalisée ;
• que la structure des informations elles-mêmes doit également être normalisée ;
• que des dictionnaires doivent exister, pour différentes fonctions que nous verrons par la suite.

Sur tout nœud de réseau équipé d'un agent SNMP, il sera possible de trouver les informations nécessaires à une bonne supervision.