Le protocole SNMP

09/02/2005

Christian CALECA

La MIB

[ Accueil ] [ Le principe ] [ Le protocole ] [ Install. SNMP. ] [ La MIB ] [ Managers ] [ MRTG intro ] [ MRTG en production ]

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.

Mais voyons ça pratiquement :

Ceci, bien entendu, n'est pas une représentation exhaustive, les arbres, c'est bien connu, sont faits pour se développer.

Les branches qui n'aboutissent pas sont là pour indiquer qu'il y a le plus souvent des choses dessus, mais les branches qui semblent finies ne le sont pas forcément.

Les appellations en texte ("member-body" par exemple), peuvent varier légèrement d'une implémentation à l'autre. Rappelons-nous qu'elles ne sont là que pour rendre les choses plus compréhensibles pour le lecteur humain (informaticien). Ce qui ne varie jamais, en revanche, c'est l'index qui y correspond, placé entre parenthèses sur le dessin.

Nous pouvons imaginer à quel point ce système peut être étendu à divers domaines. Pour un réseau IP, c'est clairement le noeud "dod (6)" qui sera le plus utilisé et particulièrement le sous noeud "internet (1)".

Comme d'habitude, avec ce genre d'organisation, un paramètre sera accessible lorsque l'on connaîtra son chemin complet, depuis la racine de l'arbre, en haut sur le dessin. En informatique, les arbres ont toujours leurs racines en haut, parce que c'est un monde "underground".

Il s'agit ici de l'arbre représentant les divers paramètres. La valeur du paramètre (poétiquement la feuille de l'arbre), sera atteinte en y ajoutant un dernier index, qui commencera à 0 et y restera pour les scalaires et ira jusqu'à n pour les tableaux.

Comme cet arbre va dépendre de l'agent, il sera pratique de disposer d'un outil permettant de parcourir cet arbre pour en découvrir la structure. Cet outil se trouvera dans le manager SNMP.

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 :

[root@gw mibs]# snmpget -v 1 -c public localhost .1.3.6.1.2.1.1.3.0
system.sysUpTime.0 = Timeticks: (23599841) 2 days, 17:33:18.41

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 :

[root@gw mibs]# snmpget -v 1 -c public localhost .1.3.6.1.2.1.1.3.1
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: system.sysUpTime.1

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 :

[root@gw mibs]# snmpget -v 1 -c public localhost 1.3.0
system.sysUpTime.0 = Timeticks: (23690312) 2 days, 17:48:23.12

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 :

[root@gw mibs]# snmpget -v 1 -c public localhost system.sysUpTime.0
system.sysUpTime.0 = Timeticks: (23721007) 2 days, 17:53:30.07

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

[root@gw mibs]# snmpget -v 1 -c public localhost .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0
system.sysUpTime.0 = Timeticks: (23878536) 2 days, 18:19:45.36

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" :

[root@gw mibs]# snmptranslate -Tp -IR system
+--system(1)
   |
   +-- -R-- String    sysDescr(1)
   |        Textual Convention: DisplayString
   |        Size: 0..255
   +-- -R-- ObjID     sysObjectID(2)
   +-- -R-- TimeTicks sysUpTime(3)
   +-- -RW- String    sysContact(4)
   |        Textual Convention: DisplayString
   |        Size: 0..255
   +-- -RW- String    sysName(5)
   |        Textual Convention: DisplayString
   |        Size: 0..255
   +-- -RW- String    sysLocation(6)
   |        Textual Convention: DisplayString
   |        Size: 0..255
   +-- -R-- INTEGER   sysServices(7)
   |        Range: 0..127
   +-- -R-- TimeTicks sysORLastChange(8)
   |        Textual Convention: TimeStamp
   |
   +--sysORTable(9)
      |
      +--sysOREntry(1)
         |  Index: sysORIndex
         |
         +-- ---- INTEGER   sysORIndex(1)
         |        Range: 1..2147483647
         +-- -R-- ObjID     sysORID(2)
         +-- -R-- String    sysORDescr(3)
         |        Textual Convention: DisplayString
         |        Size: 0..255
         +-- -R-- TimeTicks sysORUpTime(4)
                  Textual Convention: TimeStamp

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 :

[root@gw mibs]# snmpget -v 1 -c public localhost .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0
system.sysUpTime.0 = Timeticks: (24049155) 2 days, 18:48:11.55

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

Frame 1 (85 on wire, 85 captured)
    Arrival Time: Jul 22, 2003 12:40:55.435257000
    Time delta from previous packet: 0.000000000 seconds
    Time relative to first packet: 0.000000000 seconds
    Frame Number: 1
    Packet Length: 85 bytes
    Capture Length: 85 bytes
Ethernet II
    Destination: 00:00:00:00:00:00 (00:00:00_00:00:00)
    Source: 00:00:00:00:00:00 (00:00:00_00:00:00)
    Type: IP (0x0800)
Internet Protocol, Src Addr: localhost.localdomain (127.0.0.1), Dst Addr: localhost.localdomain (127.0.0.1)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 71
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x3ca4 (correct)
    Source: localhost.localdomain (127.0.0.1)
    Destination: localhost.localdomain (127.0.0.1)
User Datagram Protocol, Src Port: 1867 (1867), Dst Port: snmp (161)
    Source port: 1867 (1867)
    Destination port: snmp (161)
    Length: 51
    Checksum: 0xd027 (correct)
Simple Network Management Protocol
    Version: 1
    Community: public
    PDU type: GET
    Request Id: 0x34339329
    Error Status: NO ERROR
    Error Index: 0
    Object identifier 1: 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0)
    Value: NULL

Et l'autre pour la réponse :

Frame 2 (89 on wire, 89 captured)
    Arrival Time: Jul 22, 2003 12:40:55.437704000
    Time delta from previous packet: 0.002447000 seconds
    Time relative to first packet: 0.002447000 seconds
    Frame Number: 2
    Packet Length: 89 bytes
    Capture Length: 89 bytes
Ethernet II
    Destination: 00:00:00:00:00:00 (00:00:00_00:00:00)
    Source: 00:00:00:00:00:00 (00:00:00_00:00:00)
    Type: IP (0x0800)
Internet Protocol, Src Addr: localhost.localdomain (127.0.0.1), Dst Addr: localhost.localdomain (127.0.0.1)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 75
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x3ca0 (correct)
    Source: localhost.localdomain (127.0.0.1)
    Destination: localhost.localdomain (127.0.0.1)
User Datagram Protocol, Src Port: snmp (161), Dst Port: 1867 (1867)
    Source port: snmp (161)
    Destination port: 1867 (1867)
    Length: 55
    Checksum: 0x4de4 (correct)
Simple Network Management Protocol
    Version: 1
    Community: public
    PDU type: RESPONSE
    Request Id: 0x34339329
    Error Status: NO ERROR
    Error Index: 0
    Object identifier 1: 1.3.6.1.2.1.1.3.0 (SNMPv2-MIB::sysUpTime.0)
    Value: Timeticks: (24049155) 2 days, 18:48:11.55

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.

[ Précédente ] [ Accueil ] [ Suivante ]