La MIB   

C’est quoi la MIB ?

C’est donc la base d’informations de gestion. Il y a, nous commençons à bien le comprendre :

des informations à consulter,des paramètres à modifier,des alarmes à émettre...

Tout ça, en principe, de façon indépendante du matériel et du logiciel. Il faut donc que SNMP permette de retrouver ces information et d’agir sur les paramètres de façon indépendante du matériel, comme du logiciel.

La MIB se présente comme une base de données normalisée, qui permettra de lire et d’écrire sur les équipements distants, de façon également normalisée. Ce sera à l’agent lui-même de faire la traduction entre les informations transmises par SNMP et la plate-forme.
Structure de la MIB

Elle est extrêmement simple pour un informaticien, et donc assez compliquée pour un cerveau humain "normal".

Elle est organisée hiérarchiquement, de la même façon que l’arborescence des domaines Internet.

Elle contient une partie commune à tous les agents SNMP en général, une partie commune à tous les agents SNMP d’un même type de matériel et une partie spécifique à chaque constructeur.

Elle peut contenir des scalaires (valeurs uniques) ou des tableaux de scalaires.

Non seulement la structure est normalisée, mais également les appellations des diverses rubriques. Ces appellations ne servent à rien, si ce n’est à rendre les choses plus lisibles (ce qui peut prêter à rire). En réalité, chaque niveau de la hiérarchie est repéré par un index numérique et SNMP n’utilise que cette façon de faire.

Quelques exemples simples

Utilisons les outils de Linux, dont le manque d’ergonomie n’a d’égal que le fait qu’ils nous obligent à comprendre ce que l’on fait.

Quelque chose de très simple, pour commencer, obtenir " l’uptime " de la machine locale, le temps depuis lequel le système est en service. Dans l’arbre que nous avons juste dessus, nous voyons qu’il faut passer par les noeuds .1.3.6.1.2.1.1.3 . Nous ajoutons un zéro à cette suite, pour indiquer la feuille :

Nous ne somme pas encore en mesure de comprendre toute la finesse de cette commande, mais nous pouvons déjà observer deux choses :

la ligne de commande se termine par le chemin complet d’accès à la variable souhaitée,

ça fonctionne, puisque le système répond autrement que par un message d’erreur.

En effet, si nous nous étions trompés dans le chemin, nous aurions obtenu, soit autre chose que la valeur souhaitée, soit, plus probablement, un message d’erreur :

Comme .1.3.6.1.2.1, autrement dit .iso.org.dod.internet.mgmt.mib est le début de chemin le plus souvent employé, il est possible de le sous-entendre de la façon suivante :

Si le chemin indiqué commence par un point (.1.3.6.1.2.1.1.3.0) il s’agit d’un chemin absolu, s’il ne commence pas par un point (1.3.0), il est considéré comme relatif à ce qui manque, à savoir .1.3.6.1.2.1.

Enfin, il est possible de parler presque anglais :

Attention aux lettres majuscules et minuscules. Bien entendu, le chemin complet fonctionne ici aussi, à la condition de connaître parfaitement la syntaxe du chemin :

Amusez-vous un peu avec, et vous constaterez vite que, finalement, c’est plus facile avec les index.

Voyons tout de même l’outil "snmptranslate", sorte de couteau suisse de SNMP, qui permet, par exemple d’obtenir la traduction entre versions numérique et textuelle (et réciproquement) d’un chemin, mais qui permet également de retrouver la forme de l’arbre.

Ici, nous essayons de visualiser la branche qui part de "system" :

En plus de l’arborescence (nom et index numérique), nous obtenons également le type de variable et son état (lecture seule ou lecture/écriture).

Pour en finir à ce niveau avec la MIB et les commandes de base associées sous Linux, disons ceci :
Les outils ont besoin de connaître la version SNMP utilisée (option -v 1 pour SNMP v1),
les outils ont besoin de connaître la "communauté" (à voir comme un mot de passe, nous y reviendrons plus bas). Ici la communauté autorisée en lecture s’appelle "public" (option -c public),
les outils ont besoin de connaître la cible (adresse IP de l’agent SNMP interrogé), dans l’exemple : la machine locale,
enfin, les commandes ont souvent besoin de savoir à quelle feuille de la MIB on s’intéresse.

Les communautés

Un agent SNMP est plus ou moins finement paramétrable, suivant le système. Il est possible, par exemple de créer des groupes de sécurité qui auront accès en lecture seule, d’autres en lecture/écriture, d’autres encore en lecture seule, mais sur certaines branches seulement...

Chaque groupe devra disposer d’une sorte de mot de passe, appelé "community". En général, la communauté "public" est celle qui a le droit de lecture sur les informations non sensibles.

L’inconvénient majeur est qu’avec SNMP v1, qui est actuellement la seule version vraiment stabilisée et reconnue par tous, ce mot de passe circule en clair sur le réseau, ce qui rend dans ce cas SNMP plus que dangereux.

Les versions suivantes de SNMP corrigent ce problème majeur.

Vérifications sur le réseau

Pour en finir avec cette page, un petit sniff sur le réseau pour vérifier tout ça. Voici la commande utilisée, avec sa réponse :

Et voici ce que le sniffeur récupère. Deux paquets UDP, l’un pour la question :

Et l’autre pour la réponse :

Vous avez noté le passage de la communauté en clair ? Ca veut dire qu’il est plus que dangereux d’utiliser ce protocole dans sa version 1 pour manager un système à distance. N’importe qui sur le réseau pouvant récupérer cette information pour ensuite, faire ce qu’il voudra.