Cours gratuits » Cours réseau » cours de Protocole SNMPen PDF

cours de Protocole SNMPen PDF

Problème à signaler:

Télécharger



★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Cours complet sur le Protocole SNMP

...

Comme son nom voudrait le faire croire, Simple Network Management Protocol est un protocole "simple" destiné à gérer des équipements informatiques, à distance ou non.

Ce n'est probablement pas un protocole primordial pour un petit réseau local, nous verrons tout de même qu'il peut rendre quelques services.

Il permet principalement de :

  • visualiser une quantité pouvant être impressionnante d'informations concernant le matériel, les connexions réseaux, leur état de charge,
modifier le paramétrage de certains composants,
  • alerter l'administrateur en cas d'événements considérés comme grave,
  • et d'autres choses encore...
  • Le tout à distance, via le réseau. Bref, grâce à ce protocole, un administrateur peut avoir la maîtrise de tout son réseau et de son parc informatique, sans quitter son bureau climatisé (les bureaux des administrateurs sont toujours climatisés, à cause du matériel informatique qui ne supporte pas bien la chaleur). Miraculeux ? Pas vraiment. Simple ? Pas vraiment non plus.

    … … …

    Le principe : Présentation générale

    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 (NTx), vous avez au moins quatre journaux, que vous pouvez rendre plus ou moins verbeux, mais c'est bien sûr sous 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 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" 1 , comme par exemple la température du processeur, la vitesse de rotation des ventilateurs. Dans tout ça, 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 à tous ces besoins.

    Un agent sur chaque équipement

    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, si il a été configuré pour ça. 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...

    Un "manager" sur la station d'administration

    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 à des centaines de kilomètres). Les "boîtes noires" (routeurs, switches...) sont équipés éventuellement d'un agent SNMP (c'est une question de prix).

    Pour les serveurs et les stations il existe probablement un logiciel à installer, quelque soit le système (sérieux). Pour Linux, c'est "NET-SNMP" (ou "UCD-SNMP"), Windows XP professionel, Windows 2000 "pro" et "server" 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.

    Pratiquement...

    Juste pour donner un exemple, voyons ce que ça donne, si, depuis une machine Linux, nous interrogeons l'agent SNMP d'une station Windows XP. Nous faisons ça avec un outil dont 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

    ...

    Encore une fois, ce ne sont que des morceaux choisis, il y en a 1577 lignes et toutes ne sont pas si facilement compréhensibles. Nous verrons par la suite que snmpwalk peut être utilisé de façon plus fine, pour n'obtenir qu'un bout de branche. Comme vous pouvez le remarquer, SNMP peut se révéler être plutôt du genre indiscret. Est-il nécessaire d'indiquer que, dans l'installation par défaut de l'agent SNMP de Windows XP, celui-ci racontera votre vie à n'importe qui ? N'installez pas SNMP sans savoir ce que vous faites et sans vérifier sa configuration par défaut...

    Le protocole

    Les multiples versions

    Commençons par le plus désagréable. SNMP existe au moins dans les versions 1, 2c, 2 et 3. Comme pour tout protocole, les références sont des RFC. Si vous aimez ce genre de lecture :

    … … …

    D'une manière générale, reportez-vous au site rfc-editor2 pour retrouver les RFC, avec les informations sur leur statut (expérimental, obsolète, actif...) Comme vous le voyez, il règne la plus grande confusion dans la définition des versions 2 et 3 de SNMP. La version 2, commencée à être définie en 1996, ne se voit réellement finalisée qu'en décembre 2002, après que la version 3 ait été définie. Ladite version 3, trop récente, n'est pas encore largement utilisée, si bien que c'est la version 1 qui se retrouve être supportée par tous, avec ses (graves) défauts, comme nous le verrons plus loin. Pour que SNMP fonctionne, il n'y a pas qu'un protocole d'échange à définir. Il y a aussi une standardisation des informations que ce protocole peut transporter. C'est un protocole Internet, il doit être utilisable sur des plate-formes hétérogènes (matériel comme système d'exploitation). C'est pour cette raison que l'on parlera de MIB (Management Information Base) et de SMI (Structure of Management Information). Dans ce qui suit, nous nous appuierons principalement sur SNMP v1. Commençons par le plus simple.

    Le protocole lui-même

    SNMP tire son "N" du fait qu'il s'appuie sur UDP d'une part, et qu'il ne propose qu'un nombre très restreint de commandes.

    Les commandes sont les suivantes (version 1) :

    … …

    Les commandes get-request, get-next-request et set-request sont toutes émises par le manager à destination d'un agent et attendent toutes une réponse get-response de la part de l'agent. La commande trap est une alerte. Elle est toujours émise par l'agent à destination du manager, et n'attend pas de réponse. Comme vous le voyez, jusque là, c'est extrêmement simple. Rassurez-vous, ça va nettement se compliquer avec la MIB et la SMI.

    Installation des démons SNMP

    L'installation, sous Linux comme sous Windows ne pose guère de problèmes. Il faudra juste faire un peu attention à ne pas laisser l'accès à n'importe qui sur n'importe quoi.

    Installation

    Linux (Mandrake 9.1)

    Il suffit d'installer les paquets NET-SNMP et NET-SNMP UTILS, avec l'outil que vous préférez.

    Microsoft (Windows XP)

    Allez dans le panneau de configuration :

    • Ajout/suppression de logiciels,
    • ajouter ou supprimer des composants Windows,
    • sélectionnez "Outils de gestion et d'analyse",
    • cliquez sur "Détails",
    • cochez "SNMP (Protocole simplifié de gestion de réseaux)".

    Comme vous le voyez, c'est assez simple à installer, dans un cas comme dans l'autre.

    Configuration

    Là, ça va être un peu plus compliqué sous Linux.

    Nous n'allons pas nous lancer dans une configuration très fine. Juste le minimum pour que :

    • Toute machine du LAN puisse lire la totalité de la MIB, à travers la communauté "public",
    • seule la machine locale puisse écrire, à travers la communauté "xPzrWf" (plus difficile à inventer que "private").

    Linux (Mandrake 9.1)

    Commencez par sauvegarder le fichier /etc/snmp/snmpd.conf qui a été créé avec l'installation. Il est largement documenté, même s'il n'est pas très compréhensible, il vous servira certainement un jour ou l'autre.

    Créez ensuite un nouveau fichier /etc/snmp/snmpd.conf comme suit :

    syscontact ...

    syslocation Le placard de l'entree

    # 1° créer des relations entre les communautés et des noms de sécurité

    # nom.secu source communaute

    com2sec Local localhost xPzrWf

    com2sec LocalNet 192.168.0.0/24 public

    # 2° créer des relations entre des noms de groupes et les noms de sécurité

    # nom.groupe version nom.secu

    group RWGroup v1 Local

    group ROGroup v1 LocalNet

    #3° Créer les diverses vues qui seront autorisées aux groupes

    #

    view tout included .1

    #4° Indiquee les accès aux vues suivant les groupes

    # nom.groupe contexte modele.secu niveau.secu prefixe lecture ecriture notification

    access ROGroup "" v1 noauth exact tout none none

    access RWGroup "" v1 noauth exact tout tout none

    Vous voyez comme c'est simple...

    La communauté "public" pourra lire la totalité de la MIB depuis n'importe quelle machine du LAN (192.168.0.0/24), la communauté "xPzrWf" pourra lire et écrire partout où ce sera possible dans la MIB, uniquement depuis le poste local (localhost). Je vous laisse donc vous débrouiller, si vous souhaitez faire plus compliqué, ce qui sera certainement nécessaire sur un réseau d'entreprise ou un réseau scolaire.

    N'oubliez pas de relancer le démon par un :

    /etc/init.d/snmpd restart

    Microsoft (Windows XP)

    Gérez votre poste de travail, par exemple en cliquant du bouton droit sur "Poste de travail" dans le menu "Démarrer".

    Développez "Service et applications" et repérez "Service SNMP" :

    … … …

    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.

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

    [...# 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 :

    ...# 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 :

    ...# 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 :

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

    ....# 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.

    304