SNMP (simple Network Management Protocol) est un protole d’administration distant ou locale, utilisé sur les réseaux de type internet, à l’origine conçu pour les ponts et les routeurs, maintenant utilisé pour un peu tout. Il permet à l’administrateur réseau, depuis un poste de contrôle central, d’obtenir et de modifier divers éléments de configuration d’équipements actifs, et de logiciels.

SNMP est un paradoxe dans le monde de l’administration réseau. Conçu comme un protocole censé unifier et simplifier la gestion des matériels et des logiciels (ce qui est un but absolument louable), il n’a pas encore réussi à s’imposer auprès des administrateurs pour des raisons parfaitement valables :

• SNMP n’est pas si simple que ça (lisez donc les spécifications des différentes versions de ce protocole pour en avoir le cœur net) ;
• Sa mise en œuvre (autrement que pour de petits besoins ponctuels) nécessite des investissements gigantesques en logiciels d’administration ;
• Sa sécurité laisse à désirer (c’est un comble pour un protocole dédié à l’administration) bien que la situation se soit bien améliorée avec SNMPv3.

En fait, l’utilisation systématique de SNMP est difficile à justifier lorsqu’on n’administre pas un gigantesque réseau composé de matériels et de logiciels hétérogènes et qu’on n’a pas quelques centaines de milliers d’euros à y consacrer.

Cependant, dans certains cas, SNMP peut tout de même s’avérer fort utile si l’on sait l’utiliser à bon escient.

1. Historique

Trois versions successives de SNMP se sont succédées :

– SNMPv1, en 1990, décrit dans les RFC 1155 à 1157 ;

– SNMPv2, en 1996, décrit dans les RFC 1901 à 1908 ;

– SNMPv3, en 1999, décrit dans les RFC 2571 à 2575.

Bien que SNMPv3 soit maintenant assez ancien, rares sont les matériels qui sont capables de le gérer. Nous nous concentrerons donc sur SNMPv2.

1. Sécurité

Le protocole permettant la gestion des équipements actifs du réseau devrait logiquement être le plus sécurisé de tous les protocoles avec, en particulier, un contrôle d’accès et une confidentialité irréprochable.

Tous les documents décrivant SNMP (avant la version 3) se contentaient, au paragraphe Security Considerations, d’un commentaire laconique :

« Security issues are not discussed in this memo » en français : « Les questions de sécurité ne sont pas abordées dans ce mémo ».

Et, en effet, le contrôle d’accès était approximatif et la confidentialité inexistante.

SNMPv3, quant à lui, accorde enfin une large part de sa spécification au contrôle d’accès, la confidentialité étant naturellement laissée à IPsec.

1. Principes
   1. Les agents

Chaque équipement ou logiciel pouvant être interrogé par SNMP comporte un serveur appelé agent. Celui-ci écoute sur le port UDP 161.

1. Les MIB

Les paramètres pouvant être examinés ou modifiés par l’agent sont définis dans une MIB (Management Information Base), qui est un document décrivant ces différents paramètres, leur type (nombre entier, chaîne de caractères...), s’ils sont modifiables ou non (dans l’absolu, indépendamment des droits d’accès), etc.

La MIB la plus utilisée est certainement la MIB-II, décrite dans le RFC 1213, qui définit un ensemble cohérent de paramètres communs à tous les équipements. C’est cette MIB que nous étudierons par la suite.

Chaque élément d’une MIB est défini par un nom et un numéro (comme d’habitude, on retrouve cette dualité, les noms étant plus faciles à manipuler pour nous, pauvres humains, et les nombres plus faciles à manipuler par les ordinateurs). Ainsi, dans la MIB-II, l’objet sysContact, indiquant le nom de la personne responsable d’un équipement, est défini ainsi :

Description du code :

SYNTAX indique le type de l’objet selon la syntaxe ASN.1 (Abstract Syntax Notation One).

ACCESS indique le mode d’accès à l’objet. Les valeurs suivantes sont possibles :

• read-only
• read-write
• write-only
• not-accessible

STATUS indique si l’objet doit obligatoirement être présent dans toute implémentation de la MIB ou pas. Les valeurs suivantes sont possibles :

• mandatory
• optional
• obsolete

DESCRIPTION est un texte destiné à l’administrateur et qui décrit l’objet.

La dernière ligne de la définition attribue à l’objet sysContact le numéro 4 dans le groupe system. En effet, les MIB sont hiérarchisées à la manière des répertoires dans un système de fichiers. Le nom complet de cet objet au sein de la MIB-II est donc system.sysContact (le point est utilisé comme séparateur) ou bien system.4 ou bien 1.sysContact (system a pour numéro 1) ou, encore moins lisible, 1.4.

La MIB-II fait elle-même partie d’une hiérarchie plus large :

• La racine de la hiérarchie n’a pas de nom et est désignée simplement par un point.
• iso (1) désigne l’International Organization for Standardization.
• org (3) a été créé par l’ISO à l’intention de divers organismes.
• dod (6) a été attribué au ministère de la Défense des États-Unis (Department of Defense).
• internet (1) regroupe tout ce qui touche à l’Internet.
• mgmt (2), enfin, est utilisé pour les standards de l’IAB.

Sous .iso.org.dod.internet.mgmt, la MIB-II a pour nom mib-2 et pour numéro 1, de telle sorte que l’objet sysContact a pour nom absolu :

En pratique, cet objet est d’un type discret (ce n’est pas un tableau et il ne contient donc qu’une valeur) donc on lui ajoute un .0 final, ce qui donne comme nom absolu :

Les objets pouvant contenir plusieurs valeurs se voient ajouter à leur nom un .1 pour la première valeur, .2 pour la deuxième et ainsi de suite.

En somme, toute SNMP est simple !

     3.Les opérations

Sans rentrer dans le détail du protocole et des formats de paquets, il est néanmoins intéressant de savoir un minimum comment fonctionne le dialogue entre un agent SNMP et un logiciel d’administration.

Il existe quatre types de messages :

• Get permet de récupérer un objet bien précis.
• Get next renvoie l’objet suivant (dans l’ordre lexicographique) celui passé en paramètre. Ceci est particulièrement utile pour passer en revue toute une MIB.
• Set permet de modifier la valeur d’un objet.
• Trap permet à un agent d’envoyer un signal au logiciel d’administration et ce de son propre chef. Les trois types de messages précédents étaient envoyés par le logiciel d’administration à l’agent, celui-ci fonctionne en sens inverse. Il est très utile pour effectuer une surveillance passive du réseau, les équipements se plaignant si nécessaire.

3.1  ​Les communautés

Dans SNMPv2, le contrôle d’accès est fait en fournissant dans chaque message un mot de passe appelé communauté. Il existe généralement deux communautés, l’une utilisée pour les accès en lecture (c’est par défaut la chaîne de caractères public), l’autre utilisée pour les accès en écriture (c’est par défaut la chaîne de caractères private). Il est évidemment essentiel de modifier ces valeurs et de les tenir secrètes.

​ 4. net-snmp

La plupart des équipements réseau intègrent un agent SNMP. Certains logiciels également, de même que les systèmes d’exploitation commerciaux. Les UNIX libres, quant à eux, utilisent la suite logicielle net-snmp. Celle-ci regroupe un agent, divers outils d’interrogation ainsi qu’une bibliothèque de fonctions C permettant de construire des agents SNMP ou d’intégrer des capacités d’interrogation dans d’autres logiciels.

Nous étudierons dans ce paragraphe l’agent net-snmp ainsi que les outils qu’il fournit.

Les sources sont disponibles à l’URL :  http://net-snmp.sourceforge.net/

​4.1 Compilation

Une fois l’archive décomprimée, la compilation s’effectue de manière classique :

1. Installation

Après avoir pris l’identité du super-utilisateur :

Ceci installe :

• Un ensemble de programmes dans /usr/local/bin ;
• Des bibliothèques dans /usr/local/lib afin de pouvoir communiquer par SNMP depuis des programmes en C ;
• Les fichiers d’en-tête correspondants dans /usr/local/include/ucd-snmp ;
• Divers fichiers dans /usr/local/share/snmp (fichiers de configuration, MIB) ;
• Des pages de manuel dans /usr/local/man.

4.3 Configuration

L’agent SNMP se configure au moyen du fichier /usr/local/share/snmp/snmpd. conf. Bien que non indispensable (l’agent fonctionne fort bien sans ce fichier), il est préférable d’y définir au minimum les paramètres d’emplacement et de contact, ainsi que les droits d’accès (c’est-à-dire les communautés ou des droits d’accès plus complexes) :

Nous ne détaillerons pas ici la configuration de droits d’accès plus fins. Néanmoins, dans des situations réelles, il est indispensable d’étudier en détail la documentation des agents SNMP afin de limiter au strict nécessaires les possibilités d’accès.

 4.4 Lancement de l’agent SNMP

L’agent SNMP se lance sous l’identité du super-utilisateur. Compte tenu des différentes actions qu’il peut être amené à accomplir, il n’est pas envisageable d’en restreindre les privilèges.

Les options les plus utiles sont :

• -V pour journaliser (dans le fichier /var/log/snmpd.log par défaut) les messages reçus et émis par l’agent ;
• -d pour journaliser également le contenu des datagrammes (cette option est rarement utilisée, sauf dans des buts pédagogiques) ;
• -A pour journaliser à la suite du fichier existant et ne pas en écraser l’ancien contenu ;
• -L pour journaliser à l’écran plutôt que dans un fichier (utile uniquement pendant la mise au point du fichier de configuration) ;
• -f pour que l’agent ne se mette pas en arrière-plan (utile uniquement pendant la mise au point du fichier de configuration).

En pratique, l’agent se lance ainsi dans une configuration de production :

Lors de la phase de mise au point, il se lance plutôt ainsi :

4.5. Interrogation d’agents SNMP

 4.5.1.Parcours d’une MIB

L’outil snmpwalk permet de parcourir une MIB (la MIB-II par défaut) au moyen de l’opération get next. Il suffit de lui indiquer le nom de la machine et la communauté permettant d’y accéder en lecture :

4.5.2 Lecture d’un objet

L’outil snmpget permet de récupérer la valeur d’un objet bien précis (par défaut dans la MIB-II) :

4.5.3 Modification d’un objet

L’outil snmpset permet de modifier la valeur d’un objet bien précis (par défaut dans la MIB-II) :

5.MRTG

Voici un cas pratique, très simple et néanmoins fort utile d’utilisation de SNMP.

MRTG est un logiciel permettant d’interroger divers types d’appareils (routeurs, commutateurs, ordinateurs) et de représenter sous forme graphique le trafic réseau sur chacune de leurs interfaces.

Les graphiques sont réalisés en interrogeant les équipements à intervalle régulier (par défaut, toutes les cinq minutes) par SNMP.

5.1 Compilation

Une fois l’archive décomprimée, la compilation s’effectue de manière classique :

5.2   Installation

Après avoir pris l’identité du super-utilisateur 

Ceci installe :

• Divers programmes dans /usr/local/mrtg-2/bin ;
• De la documentation dans /usr/local/mrtg-2/doc ;
• Des fichiers additionnels dans /usr/local/mrtg-2/lib ;
• Des pages de manuel dans /usr/local/mrtg-2/man.

MRTG fonctionne également fort bien sans qu’il y ait besoin de l’installer.

 5.3  Configuration

MRTG se configure au moyen d’un fichier qui peut être généré automatiquement grâce au programme cfgmaker fourni avec MRTG :

On peut surveiller ainsi plusieurs équipements différents, il suffit de concaténer leurs fichiers de configuration en un seul fichier qui servira de configuration globale à MRTG.Quelques paramètres peuvent être rajoutés en tête du fichier de configuration global :

Le paramètre :

• WorkDir indique le chemin d’accès du répertoire dans lequel MRTG va générer ses fichiers HTML et ses images.
• Language demande à MRTG de parler français.
• RunAsDaemon indique à MRTG qu’il va fonctionner en tâche de fond (plutôt que d’être lancé par cron).

Les deux valeurs du paramètre Options demandent à MRTG respectivement d’afficher un axe des abscisses orienté de gauche à droite (il fait l’inverse par défaut) et d’indiquer des valeurs de trafic en bits par seconde (il compte en octets par seconde par défaut).​

5.4 Lancement

MRTG se lance en tâche de fond en lui indiquant le nom de son fichier de configuration :

Dans une configuration de production, il conviendra de lancer MRTG sous l’identité d’un utilisateur non privilégié puisqu’il ne nécessite pas les privilèges du super-utilisateur :