Cet article est apparu pour la première fois dans le 'linux journal'.
Nous l'éditons avec l'autorisation de l'auteur.
Introduction
Dans le monde actuel, où l'informatique se dirige vers le concept de réseau, le travail des administrateurs systèmes est très complexe. Sa mission consiste à maintenir en fonctionnement des ressources tels que les routeurs, les hubs, les serveurs, ainsi que tout dispositif critique qui compose le réseau.
Il existe un grand nombre de raisons pour lesquelles un administrateur a besoin de monitoriser, entre autres : l'utilisation de la largeur de bande, l'état de fonctionnement des liens, la détection de goulets d'étranglement, détecter et résoudre les problèmes du cablage, administrer le cheminement de l'information entre les machines, etc. La supervision du réseau prend en compte l'étude des problèmes de sécurité.
Dans de nombreux cas, le réseau d'une organisation s'entrelacent avec des liens couteux vers des réseaux étendus (WAN) ou avec internet, lesquels coûts dépendent du volume du trafic. Il est très important de maintenir un registre statistique du trafic d'informations qui circulent par ces liaisons. Cette situation est assez commune en Europe, où les liaisons X.25 sont encore assez courantes. La tarification de ce type de lignes se réalise en fonction du nombre de paquets envoyés et reçus.
Un autre type de liaison, comme le "point à point" (Frame relay), sont en tarif plein. Pour ceux, la compagnie téléphonique doit garantir une largeur de bande, qu'il est important de superviser.
A la fin de cet article, nous présentons un outil qui permet de faire un suivi graphique du trafic des routeurs. Il est facilement configurable pour pouvoir superviser d'autres catégories d'informations du réseau.
Qu'est-ce-que le SNMP ?
La réponse a tous les problèmes exposés précédemment, c'est le protocole Simple Network Management Protocol (SNMP). Elaboré dans les années 80, son principal objectif était d'intégrer la gestion des différents types de réseau au travers d'un outil simple et qui produise peu de surcharge pour le réseau.
SNMP opère au niveau applicatif, en utilisant le protocole de transport TCP/IP, qui ignore les aspects spécifiques du hardware sur lequel il fonctionne. La gestion se réalise au niveau IP, Grâce auquel il peut contrôler les dispositifs qui sont connectés au travers des réseaux accessibles depuis Internet, et pas seulement ceux qui sont connectés sur le réseau local. Evidemment, si un dispositif de routage avec le matériel distant ne fonctionne pas correctement, on ne pourra pas superviser sa reconfiguration.
Le protocole SNMP est composé de deux éléments : l'agent et le gestionnaire (manager). C'est client-serveur, dans laquelle l'agent joue le rôle de serveur et le manager le rôle de client.
L'agent est un programme qui doit s'exécuter sur chaque noeud du réseau qu'on doit superviser. Il offre une interface de tous les éléments qu'il peut configurer. Ces éléments sont stockés dans des structures de données appelées "Management Information Base" (MIB), qu'on décrira plus loin. Elles représentent la partie "serveur", qui contient l'information qu'on souhaite gérer et attendent des commandes de la part du client.
Le gestionnaire est le software qui s'exécute sur la station chargée de superviser le réseau, et son travail consiste à consulter les différents agents qui se trouvent dans les noeuds du réseau, les données qu'ils obtiennent.
Il y a une commande spéciale dans SNMP qui s'appelle trap, qui permet à un agent d'envoyer des données qui n'ont pas été sollicitées de manière explicite par le gestionnaire, pour informer d'événements tels que : erreurs, défaillances du courant électrique...etc
En réalité, SNMP est un protocole très simple, vu que toutes les opérations se réalisent au travers d'un processus de charge et stockage (load and store), ce qui permet un jeu de commandes réduit. Un gestionnaire peut réaliser seulement deux types d'opérations différentes sur un agent : lire ou écrire la valeur d'une variable dans le MIB de l'agent. Ces deux opérations sont connus comme demande de lecture (get-request) et demande d'écriture (set-request). Il existe une commande pour répondre à une demande de lecture qui s'appelle get-response, qui est utilisée uniquement par l'agent.
La possibilité d'ampliation du protocole est directement en relation avec la capacité du MIB de stocker des nouveaux éléments. Si un fabricant souhaite ajouter une nouvelle commande à un dispositif, comme un routeur, il doit seulement ajouter les variables correspondantes dans la base de données (MIB).
Presque tous les fabricants implémentent des versions agents de SNMP dans leurs dispositifs : routeurs, hubs, systèmes opérationnnels, etc. Linux ne fait pas exception, et il existe plusieurs agents SNMP disponibles de manière publique sur Internet.
Le problème de la sécurité
SNMP n'offre pas beaucoup de support pour l'authentification. Il offre seulement un schéma de deux mots-clés (two-passwords). La clef publique permet aux gestionnaires de réaliser des demandes de valeurs de variables, alors que la clef privé permet de réaliser des demandes d'écriture. On appelle ces mots-clés les SNMP communities. Chaque dispositif connecté avec un réseau gestionnaire SNMP doit être configurées avec ces deux "communities".
Il est courant d'assigner par défaut la valeur "public" au community public et "private" au privé. Il est très important de modifier ces valeurs pour protéger le réseau.
Qu'est-que le MIB ?
SNMP définit un standard séparé pour les données gérées par le protocole. Ce standard définit les données maintenues par un dipositif en réseau, ainsi que les opérations qui sont autorisées. Les données sont structurées en arborescence : il y a seulement un chemin entre la racine et la variable. Cette structure arborescente s'appelle Management Information Base (MIB) et on peut trouver des informations sur celle-ci dans divers RFC.
La version actuelle de TCP/IP MIB est la 2 (MIN-II) et elle est définit dans la RFC-1213. L'information est divisée par un dispositif qui maintient 8 catégories (voir ci-après). Toute variable doit se trouver dans une de ces catégories.
Table 1. Information TCP/IP
Categorie |
Information |
interfaces |
Information des interfaces réseau |
addr-translation |
Information sur les translations d'adresses |
ip |
Information sur le protocole IP |
icmp |
Information sur le protocole ICMP |
tcp |
Information sur le protocole TCP |
udp |
Information sur le protocole UDP |
egp |
Information sur le protocole egp (exterior Gateway) |
La définition d'un élément concret MIB implique la specification du type de donnée qu'il peut contenir. Normalement, les éléments du MIB sont des entiers, mais il peut stocker également des chaines de caractères ou des structures plus complexes comme des tables. Les éléments du MIB sont nommés "objets". Les objets sont les noeuds (feuilles) de l'arbre du MIB, si bien qu'un objet peut contenir plus d'une instance, par exemple un objet table. Pour référencer une valeur contenue dans un objet, on doit ajouter le numéro de l'instance. Quand l'objet possède une instance unique, c'est l'instance 0.
Par exemple, l'objet ifNumber de la catégorie "interfaces" est un entier qui représente le nombre d'interfaces présentes dans le dispositif. L'objet ipRoutingTable de la catégorie ip contient la table de routage du dispositif.
Il faut se rappeler qu'il est nécessaire d'utiliser le numéro de l'instance pour lire la valeur d'un objet. Dans ce cas, le nombre d'interfaces présentes dans le routeur peut être observé au moyen de l'instance ifNumber.0.
Dans le cas d'un objet "table", il faut utiliser l'index de la table comme dernier numéro pour spécifier l'instance (liste de la table).
Il existe un autre standard que définit et identifie les variables MIB, appelé "Structure de Management Information" (SMI). SMI spécifie les variables MIB, celles-ci étant déclarées selon un langage formel ISO appelé ASN.1, ce qui entraîne qu'aussi bien la forme comme le contenu des variables sont dénuées de toute ambiguité.
Le champ des nombres ISO (arbre) est situé à l'intérieur d'une autre champ de nombres, joint à d'autres arborescences d'autres standards d'autres organisations. A l'intérieur du champ de nombres ISO se situe un enbranchement spécifique pour l'information MIB. Au sein de cet enbranchement MIB, les objets sont à la fois hierarchisés en sous-enbranchements pour les différents protocoles et applications, de manière que chaque information peut être représentée de façon non équivoque.
La figure 1 montre que le champ nom de l'espace TCP/IP MIB est situé juste sous le champ mgmt name space of thede l' IAB. La hierarchie précise aussi un nombre pour chacun des niveaux.
Figure 1. Organigramme TCP/IP
 |
Il est important de préciser que la plus grande partie du logiciel nécessite le point-racine (.) pour localiser un objet dans la MIB. Si on n'inclut pas ce point-racine, on suppose que le path est relatif depuis .iso.org.dod.internet.mgmt-mib-2.
De cette manière, l'objet ifNumber de la catégorie "interfaces" peut s'appeler :
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber
ou son équivalent numérique :
.1.3.6.1.2.1.2.1
et l'instance est la suivante :
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber.0
ou son équivalent numérique:
.1.3.6.1.2.1.2.1.0
On peut ajouter des MIB additionnels à cette arborescence conformément à la définition de nouveaux objets par les vendeurs, et leurs publications RFC correspondantes.
Quel est l'avenir de SNMP ?
Une nouvelle spécification dénommée SNMPv2 est actuellement en développement rapide. Cette version essaie de résoudre les lacunes existantes en matière de sécurité du protocole actuel, au moyen de mécanismes qui se recentrent sur la privatisation, l'authentification et le contrôle de l'accés. Il autorisera également un mécanisme complexe de spécifications de variables, ainsi quelques nouvelles commandes. Le problème de SNMPv2 c'est qu'il n'existe actuellement aucun standard largement accepté, à la différence de SNMPv1. Il n'est pas facile de rencontrer des versions de SNMPv2 d'agents ou de software qui utilisent les nouvelles commandes. Il faut laisser passer le temps et nous verrons ce qu'il en adviendra dans le futur proche.
SNMP sur Linux
Un des packages les plus populaires de SNMP est CMU-SNMP. Développé initialement à l'université de Carnegie Mellon, est a été transporté sur Linux par Juergen Schoenwaelder et Erik Schoenfelder. Il est entièrement compatible avec le standard SNMPv1 et inclut quelques fonctionalités de la version SNMPv2.
La distribution contient quelques outils de gestion qui permettent, depuis la ligne de commande, d'envoyer des demandes aux dispositifs qui exécutent les agents SNMP. Il contient également un programme agent SNMP, destiné a s'exécuter sur Linux, qui propose des gestionnaires s'exécutant sur le réseau (ou le système même) : informations sur l'état des interfaces, les tables de routage, instances d'initialisation, information de contact...
Un caractéristique précieuse qui a été ajoutée avec CMU-SNMP est C-API, qui permet aux programmeurs de construire des outils complexes de gestion basés sur les capacités du réseau de la distribution.
L'installation sur un système Linux est simple, quoique légèrement différente de l'installation d'origine. Il existe une distribution avec les exécutables pré-compilés des outils de gestion, le daemon et la bibliothèque API.
La première décision à prendre c'est de savoir si on monte la distribution avec les sources ou avec les exécutables. Il n'est pas difficile de trouver ce package sur Internet. La distribution binaire s'installe et s'exécute sans problème avec les systèmes Linux qui supportent le standard ELF. Nous expliquerons donc comment installer la distribution binaire. C'est de bon usage de charger des distributions binaires uniquement sur des serveurs Internet de confiance pour éviter les chevaux de Troie et autres problèmes de sécurité.
Il faut copier le fichier cmu-snmp-linux-3.4-bin.tar.gz sur le répertoire racine (/), le décompresser avec la commande suivante : Put the file cmu-snmp-linux-3.2-bin.tar.gz in the root directory (/) of your Linux system and decompress it with the command:
gunzip cmu-snmp-linux-3.2-bin.tar.gz
puis extraire les fichiers de l'archive tar avec la commande:
tar xvf cmu-snmp-linux-3.2-bin.tar
Vous devriez avoir alors tous les utilitaires et les bibliothèques correctement installés sur le système, à l'exception du fichier de configuration suivant de l'agent : /etc/snmp.conf. Vous pouvez le créer en exécutant le script suivant :
/tmp/cmu-snmp-linux-3.2/etc/installconf
avec ces paramètres:
/tmp/cmu-snmp-linux-3.2/etc/installconf -mini
où password est le mot-clé public (community) qu'on va utiliser. Maintenant on peut éditer le nouveau fichier de configuration /etc/snmp.conf. On peut y modifier la valeur du port UDP utilisé par l'agent, les variables systemContact, sysLocation et sysName, ainsi que les paramètres de vitesse de l'interface pour les cartes de réseau et les port PPP.
Les outils les plus importants de ce package sont :
- /usr/bin/snmpget un programme destiné à la consultation d'une valeur concrète pour un agent MIB du réseau (un routeur, un hub...)
- /usr/bin/snmpgetnext il permet de lire l'objet suivant dans l'arbre MIB sans connaître nécessairement son numéro.
- /usr/bin/snmpsetun outil pour écrire des valeurs dans les objets des agents distants.
- /usr/bin/snmpwalkun outil qui lit un objet complet ou une série d'objets sans spécifier l'instance exacte. Il est utile pour interroger des objets de type table.
- /usr/bin/snmpnetstat
- /usr/bin/snmptrapd Daemon qui écoute les "traps" des agents.
- /usr/bin/snmptestoutil interactif destiné à démontrer les possibilités de API.
L'agent est situé dans le répertoire /usr/sbin/snmp.
CMU_SNMP intalle aussi un fichier MIB dans /usr/lib/mib.txt. C'est un bon endroit pour chercher quel type d'information on peut demander à un dispositif en réseau.
L'agent doit être lancé en exécution au démarrage de la machine. On peut faire cela en ajoutant les lignes suivantes dans un fichier d'initialisation (par exemple /etc/rc.f/rc.local) :
/usr/sbin/snmpd -f ; echo 'démarrer snmpd'
Une fois que l'agent est lancé dans la machine Linux, on peut essayer une fonction avec un outil quelconque de gestion, par exemple :
/usr/bin/snmpget -v 1 localhost public interfaces.ifNumber.0
lequel retournera le numéro des interfaces configurés dans le système, y:
/usr/bin/snmpwalk -v 1 localhost public system
retourne toutes les valeurs du sous-arbre "system" du MIB. (Voir la Figure 2 pour le résultat de cette commande.)
|