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