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