SNMP (Simple Network Ma­na­ge­ment Protocol) : le protocole de base pour la gestion de réseaux

Des or­di­na­teurs aux serveurs, en passant par les com­mu­ta­teurs, routeurs, im­pri­mantes et autres pé­ri­phé­riques, un réseau réunit des appareils très dif­fé­rents. Plus le nombre de par­ti­ci­pants est important, plus l’effort né­ces­saire à l’ad­mi­nis­tra­teur et les dif­fi­cul­tés ren­con­trées dans la gestion du réseau sont con­si­dé­rables. C’est la raison pour laquelle utiliser des outils de gestion est impératif lorsqu’il s’agit de garantir la fonc­tion­na­lité et la sécurité de tous les systèmes sur la durée. L’un des pro­to­coles auquel de nom­breuses solutions lo­gi­cielles ont recours est le Simple Network Ma­na­ge­ment Protocol (SNMP), aujourd’hui considéré comme l’un des prin­ci­paux pro­to­coles standard. Il est supporté par la quasi-totalité des terminaux.

Après environ 2 ans de dé­ve­lop­pe­ment, la première version of­fi­cielle du Simple Network Ma­na­ge­ment Protocol, abrégé en SNMP, a été publiée en mai 1990 dans la requête RFC 1157 . Ce protocole réseau fait partie de la suite des pro­to­coles Internet. Il est dis­po­nible au­jour­d'hui dans ses versions SNMPv2 et SNMPv3 , et le fruit des travaux d’un groupe de travail de l’IETF (Internet Engi­nee­ring Task Force). La fonction prin­ci­pale du protocole SNMP est de permettre une sur­veil­lance et une gestion cen­tra­li­sée de toutes les com­po­santes d’un réseau d’or­di­na­teurs. À cet effet, il décrit la structure des paquets de com­mu­ni­ca­tion né­ces­saires ainsi que le dé­rou­le­ment de la com­mu­ni­ca­tion entre le poste central et les dif­fé­rents appareils.

Le transport des paquets doit être assuré à l’aide du protocole UDP sans connexion. Dans ce cadre, les données et les in­for­ma­tions trans­por­tées sont déposées et en­re­gis­trées dans ce qu’on appelle la Ma­na­ge­ment In­for­ma­tion Base (MIB) dans une sorte de structure en ar­bo­res­cence.

La gestion de réseau via SNMP est basée sur un modèle agents/manager. Le poste de gestion central est ici le système depuis lequel l’ad­mi­nis­tra­teur surveille et gère les dif­fé­rents par­ti­ci­pants au réseau. Pour ce faire, un logiciel de gestion per­met­tant l’in­ter­ro­ga­tion SNMP de données ainsi que l’ini­tia­tion de certaines actions est installé. Les agents, qui sont également des ap­pli­ca­tions, viennent en con­tre­par­tie des dif­fé­rents com­po­sants réseau. Ils col­lec­tent les données per­ti­nentes sur l’hôte cible et les trans­met­tent au poste de gestion. Ils sont par ailleurs en mesure de procéder per­son­nel­le­ment à des réglages et de dé­clen­cher certaines actions. Les ap­pli­ca­tions agents de ce type sont déjà im­plé­men­tées par défaut dans la plupart des systèmes Windows et Linux courants, sous la forme par exemple du Daemon snmpd (uni­que­ment sous Linux).

Le protocole SNMP fixe sept types de messages possibles pour la com­mu­ni­ca­tion entre le manager et l’agent :

• Requête GET : les requêtes GET sont les messages standard per­met­tant de consulter un ensemble de données défini sur l’appareil souhaité dans le réseau.
• Requête GETNEXT : ce format de message est utilisé pour in­ter­ro­ger les ensembles de données con­sé­cu­tifs, par ex. dans le cas de tableaux.
• Requête GETBULK : l’ap­pli­ca­tion de gestion peut envoyer une requête GETBULK (à partir de la version SNMPv2) afin d’in­ter­ro­ger un nombre défini d’ensembles de données avec une seule et même requête. Une requête GETBULK cor­res­pond à plusieurs requêtes GETNEXT con­sé­cu­tives.
• Requête SET : les requêtes SET per­met­tent au manager de modifier un ou plusieurs ensemble(s) de données de l’appareil souhaité dans le réseau ou de dé­clen­cher certaines actions. Un exemple de scénario type né­ces­si­tant plusieurs mo­di­fi­ca­tions si­mul­ta­né­ment : la con­fi­gu­ra­tion d’une adresse IP exigeant l’in­di­ca­tion si­mul­ta­née d’un masque de sous-réseau.
• Réponse GET : si le manager a demandé un ou plusieurs ensemble(s) de données, ou initié des mo­di­fi­ca­tions ou des actions, l’agent répond en envoyant des réponses GET. Ces paquets de réponses con­tien­nent soit les données demandées ou une con­fir­ma­tion des mo­di­fi­ca­tions apportées, soit un message d’erreur lorsque les requêtes n'ont pas reçu de réponses con­ve­nables.
• Trap SNMP : les traps SNMP sont des messages envoyés par les agents sans ins­truc­tions de la part du poste de gestion. Cela se produit lorsqu’un événement imprévu déterminé est survenu. Les traps peuvent com­mu­ni­quer de deux façons dif­fé­rentes sur le type d’événement survenu : la première pos­si­bi­lité, pré­ser­vant les res­sources, consiste à joindre un numéro d’iden­ti­fi­ca­tion unique. Le manager peut se référer à la base de données in­for­ma­tive (MIB) déjà évoquée pour en connaître la sig­ni­fi­ca­tion. Avec la seconde pos­si­bi­lité, les traps SNMP four­nis­sent des in­for­ma­tions sur l’événement, mais con­tien­nent également les données cor­res­pon­dantes sans avoir à afficher un numéro d’iden­ti­fi­ca­tion spé­ci­fique.
• Requête INFORM : les requêtes INFORM assurent gé­né­ra­le­ment la même fonction que les traps SNMP. Con­trai­re­ment à ces dernières, les paquets INFORM se dé­mar­quent toutefois par l’envoi d’un accusé de réception par le manager. Par con­sé­quent, l’agent peut renvoyer le message si celui-ci n’a pas atteint le manager à la première tentative.

Comme nous l’avons déjà évoqué, le Simple Network Ma­na­ge­ment Protocol impose l’uti­li­sa­tion du protocole de transport sans connexion UDP pour la trans­mis­sion des paquets de messages énumérés. Ceci permet de garantir une sur­veil­lance du réseau qui préserve par­ti­cu­liè­re­ment les res­sources. Pour l’envoi des dif­fé­rentes requêtes GET aux agents (ainsi que pour les réponses cor­res­pon­dantes), le SNMP utilise le port UDP 161, tandis que les traps SNMP sont envoyés au­to­ma­ti­que­ment à travers le port UDP 162.

Ini­tia­le­ment, le SNMP ne per­met­tait pas aux ges­tion­naires de com­mu­ni­quer entre eux et aux agents d’envoyer des messages avec accusé de réception. D’autre part, de nom­breuses ap­pli­ca­tions n’étaient que par­tiel­le­ment sup­por­tées au début du protocole malgré l’ambition d’être un standard ouvert. C’est pourquoi les cor­rec­tifs du protocole apparus au cours des années suivantes ont prin­ci­pa­le­ment visé à intégrer des mé­ca­nismes cor­res­pon­dants dans le Simple Network Ma­na­ge­ment Protocol. Une autre as­pi­ra­tion es­sen­tielle du groupe de travail IETF res­pon­sable du protocole a été, dès le début, d’accroître la sécurité du processus de gestion. On peut observer ce résultat dans la troisième version. Cette étape d’op­ti­mi­sa­tion du protocole SNMP ainsi que d’autres étapes sont pré­sen­tées de façon un peu plus détaillée dans la des­crip­tion suivante des dif­fé­rentes versions SNMPv1, SNMPv2 et SNMPv3.

En tant que première version du protocole de gestion de réseau, la version SNMPv1 pose les bases du modèle ges­tion­naires/agents et les bases de la com­mu­ni­ca­tion entre le poste de gestion et les dif­fé­rents agents. Le Simple Network Ma­na­ge­ment Protocol y est décrit comme un protocole simple agissant au niveau de l’ap­pli­ca­tion et pouvant s’appuyer sur l’UDP (User Datagram Protocol) et l’Internet Protocol (IP), mais aussi sur des pro­to­coles réseau com­pa­rables tels que le DDP Ap­ple­Talks (Datagram Delivery Protocol) ou Internet Packet Exchange (IPX). Le seul mécanisme de sécurité intégré est alors l’échange d’un nom de com­mu­nauté envoyé avec les requêtes cor­res­pon­dantes.

L’un des problèmes majeurs de la première version du protocole SNMP réside dans le fait que le nom de com­mu­nauté assure la sécurité n’est transmis qu’en texte clair. C’est la raison pour laquelle les dé­ve­lop­peurs se sont ra­pi­de­ment penchés sur une nouvelle variante appelée Secure SNMP, dans laquelle cette chaîne serait transmise sous une forme chiffrée. Toutefois, cette version n’a jamais été publiée, car elle a été di­rec­te­ment remplacée par la version SNMPv2. D’autres amé­lio­ra­tions ont été apportées à la version initiale du protocole : un trai­te­ment des erreurs optimisé, la pos­si­bi­lité d’une com­mu­ni­ca­tion de manager à manager ainsi que des commandes SET plus per­for­mantes. Le principal avantage comparé à la version SNMPv1 réside toutefois dans l’im­plé­men­ta­tion des nouveaux types de messages GETBULK (pour l’in­ter­ro­ga­tion de plusieurs données dans une même requête) et INFORM (pour les accusés de réception des réponses des agents).

Après la première étape, de moindre ampleur, franchie avec la deuxième version du protocole, l’IETF s’est plei­ne­ment consacrée à la sécurité dans la version SNMPv3 et a remplacé le nom de com­mu­nauté par un nom d’uti­li­sa­teur et un mot de passe. D’autre part, et con­trai­re­ment aux versions an­té­rieures, la troisième version du protocole inclut des fonc­tion­na­li­tés per­met­tant de chiffrer la trans­mis­sion des paquets SNMP. La version SNMPv3 offre en tout trois types d’au­then­ti­fi­ca­tion et de chif­fre­ment dif­fé­rents :