REMERCIEMENT
Au terme de nos études de 1er cycle Universitaire en
Informatique, qu'il nous soit permis d'exprimer nos sentiments de gratitude aux
différentes personnes qui nous ont encadré et soutenu tout au
long de notre formation rendant ainsi possible l'accomplissement du
présent travail.
Notre gratitude s'adresse tout particulièrement au
professeur MANYA NDADI Léonard, qui en dépit de ses multiples
occupations et sollicitations a accepté de diriger ce travail.
Notre reconnaissance va aussi tout droit à l'assistant
MANYA Franck, qui accepté de lire et porter des correctifs à ce
travail. Mais aussi l'assistant Jean Claude MUDILU, pour ses conseils et
suggestions éclairés, qui nous ont été utiles pour
l'élaboration de ce travail.
Nous nous sentons également redevable à
l'égard de tous les Professeurs et Assistant de la Faculté des
sciences en général et ceux du Département de
Mathématique et Informatique en particulier, pour le savoir qu'ils
nous ont transmit. Qu'ils trouvent à travers ce travail le fruit de leur
encadrement.
Nous tenons enfin de remercier tous ceux et toutes celles qui
nous ont soutenus de loin ou de près durant notre cycle de graduat. Nous
pensons donc à :
Ø Mes parents OLENGA EMUNGU
Gilbert et KUMBE SEKE Anne, qui ses dépenses malgré les
difficultés économiques d'assurer notre formation.
Ø Aux couples KALONJI et
LOMAME ; nos tentes et oncles Nelly, Kabibi, Véronique,
Régine, ELANDO, Valentin ; nos frères et soeurs Antoine,
Maurice, Raphaël, Fisco, Anny, Michel, Lisette ; nos cousins et
cousines Bijou ATANDJO, Peggy, Louise, Michel ABIBO, Rex MUKOBO, Miriam ;
nos neuves et nièces Joël, Riemann ; sans oublié Maman
BWAYA Thérèse et Jackie, et par-dessus tous, JEHOVAH Dieu le
pourvoyeur de toute chose, ainsi que tous ceux ou toutes celles qui nous sont
chers.
INTRODUCTION
Les réseaux informatiques ont aujourd'hui autant
d'importance que les ordinateurs eux mêmes, au point que la plupart de
nos activités ne pourraient plus être envisagées sans la
mise en place de ces réseaux. On assiste à leur
déploiement à tous les niveaux de la société, dans
les entreprises, au niveau national et international, y compris dans les
domiciles des usagers. Quant aux entreprises, ces réseaux leur apportent
un moyen efficace pour mettre en oeuvre un travail coopératif, pour
faire communiquer des ordinateurs distants, pour partager des données,
mais aussi pour imprimer à distance, envoyer des messages, et
accéder à des bases de données
délocalisées.
Le réseau n'est pas une entité statique. Il
subit des évolutions. Son évolution a mis en jeu bien des aspects
technologiques. On peut même parler de mutation au vu des progrès
fulgurants qu'il a enregistrés depuis ces débuts. A savoir les
matériels d'infrastructure réseaux (commutateur,
répétiteur, routeur, modem, serveur etc.) ont de capacité
de traitement importante et offrent des fonctionnalités de plus en plus
complexe. Le débit, qui permet de caractériser la rapidité
avec laquelle on communique au travers du réseau, est passé d'un
facteur de 1 à un facteur de millions de millions (gigabits). Une autre
évolution importante tient à la transformation de réseau
physique câblé en un réseau sans fils potentiellement
présent n'importe où dans le monde, y compris dans les endroits
les plus reculés où il n'existe pas d'infrastructure physique.
Cette évolution concerne également le type d'information
véhiculé. Alors qu'à ses débuts, le réseau
était principalement utilisé pour transmettre du texte ou des
données, grâce aux nouvelles vitesses de transmission et2aux
nouvelles techniques de codage, il se transforme peu à peu en
réseau multimédia capable de faire transiter, en plus des
données, de la voix, et de la vidéo. Cette capacité va
ouvrir de nouvelles perspectives notamment en terme d'applications interactives
voix-données. C'est ce développement que l'on observe
actuellement avec les nouvelles normes de réseaux mobiles telles que les
cas chez nous aujourd'hui le réseau GPRS avec les sociétés
de télécommunication en place.
L'évolution de réseau dont nous venons de parler
pose un problème majeur : la manière dont ceux-ci sont
pratiquement géré. En effet, avec la multiplication des machines
qui ne cessent d'être fabrique des jours aux jours, la complexification
des architectures qui s'en suivent, et leur possible éclatement
géographique, il devient évidement difficile de gérer un
réseau.
A cette difficulté s'ajoute aussi le problème
d'hétérogénéité des technologies
sous-jacentes et celle d'offrir une vu unifiée du réseau à
l'administrateur et, d'autre part, la distribution et la grande quantité
d'informations à collecter et à traiter.
Une autre contrainte de la gestion est la
dépendance de service : Les activités des entreprises
deviennent aussi dépendantes du fonctionnement de ce moyen de
communication. Aussi est-il donc crucial que les services de communications du
réseau soient disponibles en permanence. Les éventuels
dysfonctionnements ou pannes doivent être détectés le plus
rapidement possible et traités dans un délai compatible avec les
activités de l'entreprise. C'est en cette activité de
surveillance du réseau et des services qu'il offre que consiste,
précisément, la gestion de réseau. Cette dernière
couvre différentes tâches qui doivent être
réalisées dans des échelles de temps plus ou moins
importantes. Les cinq activités principalement reconnues en sont la
gestion de la configuration, la gestion des fautes, la gestion des
performances, la gestion de la sécurité et enfin la gestion des
comptabilités. Ces activités peuvent être plus ou moins
importantes selon l'activité de l'entité qui met en place le
réseau.
Nous l'avons dit précédemment, le
matériel d'infrastructure réseau est de plus en plus
sophistiqué et permet d'être contrôlé en
distance : c'est là un des points fondamentaux de la gestion
réseau, il est aujourd'hui nécessaire, étant donné
l'étendue et la complexité des réseaux, de pouvoir le
gérer à distance depuis son poste de travail et n'avoir
qu'à se déplacer qu'en derniers recours, lors qu'une
opération physique est nécessaire.
Comme son nom l'indique le protocole SNMP, simple network
management protocole (protocole de gestion de réseau simplifié)
que nous allons étudier plus en détails au cour de ce travail
à pour rôle exclusif la gestion de réseau, il à
été développé pour apporter des moyens simple
d'administration en distance aux administrateurs.
Le but de cette étude consistera dans un premier temps
de comprendre le principe de ce protocole, son fonctionnement, et son apport
dans la tâche de l'administration et dans le second temps exploiter le
langage de programmation java pour implémenter une application de
gestion de réseau basé sur ce protocole.
Notre motivation n'est pas de donner aux lecteurs de ce
présent travail une liste en tous points exhaustive d'informations sur
tous les concepts, toutes les architectures et plates-formes existant dans la
gestion de réseau (nombre de publications y pourvoient : livres,
articles, normes, etc.), mais un ensemble d'informations techniques à
partir desquelles le lecteur, qu'il soit étudiant, technicien,
ingénieur, administrateur réseau ou architecte réseau,
puisse rapidement comprendre le concept de base du protocole SNMP et cela au
travers une application informatique concret.
Pour l'élaboration de ce présent travail, nous
avons procédé d'abord par une lecture approfondie des ouvrages de
référence à la matière en vue de bien assimiler le
concept théorique de base qui régit l'administration
réseau, le protocole SNMP et la programmation en java. Mais aussi par
des entretiens réguliers avec les professionnels qualifier à la
matière et nos différents encadreurs.
Ce travail comporte 3 chapitres brièvement
décrits comme suivent :
Ø Le chapitre 1 est une introduction aux
concepts de base de la gestion de réseau ; il permet de comprendre les
enjeux stratégiques de la gestion et de se familiariser avec ses
activités. Il présente une méthode qui permet à
l'administrateur réseau de concevoir une architecture de gestion.
Ø Le chapitre 2 décrit le protocole
SNMP. Il explique le fonctionnement, les différentes composantes d'une
architecture de gestion basée sur SNMP et montre les échanges
entre la station de gestion et les agents SNMP à des fins de
surveillance.
Ø Le chapitre 3 traite l'implémentation
de l'application en java. Il montre pas à pas comment ont peut mettre
au point une application de gestion en se base sur le protocole SNMP en
java.
CHAPITRE I INTRODUCTION AUX CONCEPTS DE BASE DE LA GESTION DE
RESEAU
I.1
Introduction
La gestion de réseau est la tâche quotidienne de
tout administrateur réseau. Il s'agit entre autre d'assurer le suivi du
réseau, de définir des procédures et de les faire
connaître aux utilisateurs, de gérer les mots de passe, de
prendre en charge le suivi des sauvegardes et résoudre les
éventuels incidents qui peuvent survenir. Au-delà,
anticipé les évolutions technologiques et intégrer de
nouveaux outils de gestions. Vérifier le fonctionnement optimal de
chaque matériel, paramétrer celui-ci, ou de le mettre à
jour régulièrement. Ainsi, dans les réseaux informatiques
d'aujourd'hui, la gestion est un problème de tous les jours. Le recours
à des techniques d'administration efficace est important pour une bonne
gestion économique des moyens de communication dont on dispose, mais
aussi pour avoir une vue d'ensemble des équipements et des
systèmes de communication utilisés par l'entreprise. C'est
à niveau qu'intervient l'administration réseau.
L'administration réseau met en oeuvre des moyens
humains, techniques, et financières de contrôle, de coordination
et de surveillance des diverses ressources mise en oeuvre en respectant les
contraintes de coûts et de qualité. Avec objectif, de maintenir le
service et de permettre l'évolution du système.
I.2
Ressource à gérer
Plusieurs niveaux de gestion doivent être
distingués, dont il est nécessaire de comprendre
l'utilité. Un bon critère de différenciation peut
être appliqué à partir des éléments
constitutifs du réseau, soit des équipements réseau, des
ordinateurs, des logiciels, ou des utilisateurs. À titre d'exemple :
Ø La gestion de l'infrastructure réseau
: elle concerne la gestion de tous les éléments du réseau
et des logiciels embarqués qui constituent les différents
réseaux de l'entreprise. On désigne par élément du
réseau chacun des équipements qui sont branchés au
réseau, ainsi que les logiciels y résidant. Les routeurs, les
concentrateurs, les répéteurs, les passerelles, les modems, la
connectivité, sont les éléments qui constituent
l'infrastructure du réseau.
Ø La gestion des ordinateurs : elle concerne
tous les aspects relatifs à la gestion des points d'accès au
réseau. Elle englobe la gestion des stations terminales, ainsi que de
tous les logiciels supportés par ces stations : système
d'exploitation réseau, les applications et les services de communication
mis à la disposition des usagers.
I.3
Attente d'une administration réseau
L'administrateur réseau est celui qui est
chargé, de la lourde tâche de s'occuper du réseau. Son
travail regroupe beaucoup de chose. A cet égard l'ISO (International
standard organization) l'organe habileté à standardiser les
normes de réseau à définit l'étendue du travail
d'administration est à retenue cinq domaine fonctionnels de gestion
suivant :
Ø La gestion des configurations
Ø La gestion des fautes
Ø La gestion de performances
Ø La gestion des sécurités
Ø La gestion des coûts ou la gestion des
comptabilités
I.3.1
La gestion de la configuration
La gestion de la configuration permet de désigner et de
paramétrer différents objets. Une configuration peut être
faite manuellement par un opérateur (via l'interface graphique) ou par
téléchargement complet (lors d'une réinitialisation d'un
équipement par exemple).
Procédure
Les procédures requises pour gérer une
configuration sont :
Ø La collecte d'informations ;
Ø Le contrôle de l'état du
système ;
Ø Et enfin la sauvegarde de l'état dans
un historique.
Figure 1-1 Gestion de la configuration
La gestion de la configuration couvre l'ensemble des
fonctionnalités suivantes :
Ø Démarrage, initialisation des
équipements ;
Ø Positionnement des paramètres ;
Ø Cueillette des informations d'état et
intervention dans les paramètres ;
Ø Modification de la configuration du
système ;
Ø Association des noms aux objets
gérés ;
Ø Changement de l'adresse IP d'une machine ;
Ø Changement de l'adresse IP d'un routeur ;
Ø Changement de la table de routage.
I.3.2
La gestion des fautes
Ce domaine recouvre la détection, l'isolement et la
correction des pannes survenant sur un équipement. L'action curative qui
en découle peut être faite à distance (si
l'équipement répond) ou par un contact humain qui agira sur
l'équipement. Un historique des évènements est
également disponible
Figure 1-2 Gestion des fautes
Type
de panne
Les pannes peuvent être d'origine internes, à
caractère permanent (composant en pannes) ou externes (goulets
d'étranglement, trafic intense, etc.), Cette dernière est plus
difficile à détecter, car elle est à caractère
aléatoire.
La gestion de faute couvre l'ensemble des
fonctionnalités suivantes :
Ø La détection des fautes : elle
comprend la préparation de rapports d'incidents de fonctionnement,la
gestion de compteurs ou des seuils d'alarme, le filtrage
d'événements par filtrage en amont des informations, l'affichage
des dysfonctionnements.
Ø La localisation : on y procède au
moyen de rapports d'alarme, de mesures et de tests.
Ø La réparation : elle consiste à
prendre les mesures correctives (réaffectation de ressources, routages,
limitation du trafic par filtrage, maintenance), ou encore à
rétablir le service (tests de fonctionnement, gestion de systèmes
de secours, etc.).
Ø L'enregistrement des historiques d'incidents
et statistiques : la gestion des fautes ne peut se limiter à ces actions
ponctuelles, nécessaires mais insuffisantes pour donner le service
attendu. C'est la raison pour laquelle elle comporte aussi, d'une part,
l'enregistrement d'historiques d'incidents et la compilation de statistiques
qui peuvent porter sur la probabilité des pannes, leur durée, les
délais de réparation et, d'autre part, un rôle d'interface
avec les usagers qui consiste à les informer des problèmes
réseau et à leur donner la possibilité de signaler
eux-mêmes des incidents telle que :
· La déconnexion d'un câble ;
· Une mauvaise configuration d'un équipement ;
· Une interface défectueuse d'un routeur ;
· La réinitialisation accidentelle
I.3.3 La gestion de la
performance
Ce domaine comprend la collecte des données et
l'analyse statistique permettant la création de tableaux de bord. Ce
domaine est essentiellement lié à l'évolution du
réseau (permet de planifier les changements à apporter afin
d'améliorer les performances du réseau).
Figure 1-3 Gestion de Performance
L'objectif est d'établir des statistiques à
partir des paramètres du réseau.
Ø Débit ;
Ø Temps de réponse ;
Ø Taux d'erreur ;
Ø Temps d'établissement des
connexions
Ø Elle fournit des fonctions qui permettent
à des fins de planification des ressources du réseau :
Ø De recueillir des données statistiques
(taux d'erreurs, temps de transit, débit, etc.) ;
Ø De maintenir et analyser des journaux sur
l'historique de l'état du système (événements). Les
informations obtenues serviront à l'analyse et à la planification
du réseau. On peut diviser cette partie en deux : l'une traitant de la
gestion de la performance en temps réel et l'autre en temps
différé. Pour gérer la performance d'un réseau en
temps réel, il faut mettre en place les fonctionnalités suivantes
:
Ø Enregistrements des mesures de performance :
cela passe par l'établissement et la mise à jour des
critères et des conditions de mesure, la gestion de la collecte
d'informations, le filtrage, la compilation de statistiques, l'adoption de
mesures à la demande ou encore la gestion des fichiers de collecte.
Ø Surveillance de l'activité du
réseau par visualisation de l'utilisation des ressources, le signalement
des dépassements de seuils et l'analyse de la performance : cela
implique une visualisation du fonctionnement du réseau (avec comme
variables pertinentes par exemple la répartition de la charge, les
différents débits, les temps de réponse ou encore la
disponibilité) et une analyse des causes possibles de dépassement
de seuil par corrélation avec les pannes d'équipements, au moyen
de divers indicateurs.
Ø Changement de configuration proactive et
réactive : le fait de gérer la performance en temps réel
suppose que l'on soit capable de prendre des mesures correctives (ou
réactives) et préventives (ou proactives). La gestion
réactive vise à établir lors de la détection d'un
problème de performance des mesures de réaffectation des
ressources par modification des paramètres de configuration ou par
redistribution du trafic. Ces mesures, de par leurs natures, sont prises afin
de répondre à un problème déjà existant. La
gestion proactive consiste à prendre des mesures initiales permettant
d'éviter d'arriver à une situation critique. Cette tâche
est effectuée en temps différé et comporte quant à
elle un ensemble de sous-tâches :
·
L'analyse des informations par la compilation de statistiques, d'historiques ou
encore d'indicateurs de qualité du service ;
·
L'édition de tableaux de bord et de rapports, qu'ils soient
périodiques ou qu'ils oient effectués à la demande ;
·
Une certaine forme d'analyse prévisionnelle par la constitution de
matrices de trafic, par la détection de risques de saturation ou
d'engorgement, par des simulations de scénarios, par le suivi de la
gestion corrective, et enfin par la planification et le dimensionnement du
réseau.
Exemples
Ø Relevé des pertes de connexions entre
deux routeurs.
Ø Relevé des temps de réponse
entre deux sites.
I.3.4
La gestion de la comptabilité
La gestion de la comptabilité permet de connaître
les charges des objets gérés, les coûts de communication,
etc. Cette évaluation est établie en fonction du volume et de la
durée de la transmission.
Figure 1-4 Gestion de la Comptabilité
Elle couvre l'ensemble des fonctionnalités suivantes
:
Ø Les mesures sur l'utilisation des ressources,
et leur enregistrement en vue d'obtenir des historiques ;
Ø Le contrôle des quotas par utilisateur
en faisant des mises à jour des consommations courantes et en
vérifiant les autorisations de consommation ;
Ø le suivi et le contrôle des
dépenses par stockage et mise à jour des tarifs des
opérateurs, par gestion des tickets de taxation, par évaluation
en temps réel de la consommation courante, par vérification des
factures, et enfin par suivi des coûts d'exploitation et de
matériels (investissement, amortissement et maintenance) ;
Ø La gestion financière : bien
évidemment, on retrouve dans la gestion comptable une
Ø Partie financière qui consiste
à ventiler les coûts (par service, par utilisateur ou encore par
application), à analyser et prévoir les dépenses et enfin
à étudier les possibilités de réduction des
coûts ;
Ø La facturation : finalement,
l'activité de gestion comptable aboutit à une facturation
interne, ce qui implique la gestion des clients et des trafics, la production
de tickets de taxation et de factures, le contrôle de la facturation et
enfin le stockage des historiques.
Exemples
Ø Coût d'utilisation d'un réseau
RNIS.
I.3.5
La gestion de la sécurité
La gestion de la sécurité est une fonction de
gestion qui concerne le contrôle et la distribution des informations
utilisées pour la sécurité. Elle englobe le cryptage et la
liste des droits d'accès.
Figure 1-4 Gestion de la Sécurité
À l'appui des politiques de réseau, la gestion
de réseau consiste à collecter les informations de gestion et
à les interpréter. Voici les fonctionnalités qui doivent
être mises en oeuvre :
Ø Dans ce contexte, il faut dans un premier
temps assurer la sécurité relative à l'administration de
réseau elle-même, c'est-à-dire gérer les droits
d'accès aux postes de travail, gérer les droits liés aux
attentes des opérateurs, et enfin les autorisations d'accès aux
informations de gestion.
Ø Ensuite, il faut garantir la
sécurité des accès au réseau géré ;
pour cela, il faut mettre en place des mécanismes qui impliquent des
fonctions telles que la définition des conditions d'utilisation,
l'activation ou la désactivation des mécanismes, la modification
de certains paramètres ou encore la gestion des listes d'autorisation
(aux machines, à différents services ou à divers
éléments de réseau) ; il faut évidemment en outre
effectuer un contrôle des accès (identités, horaires, temps
de connexion, destination) et une détection des tentatives
d'accès frauduleuses (enregistrement, compilation de statistiques et
déclenchement d'alarmes si nécessaire).
Ø Enfin, il faut garantir la
sécurité de l'information par la gestion de mécanismes de
protection, de cryptage et de décryptage, et par la détection
d'incidents et de tentatives de fraude. Voici les fonctions de gestion de
sécurité qui doivent être mises en oeuvre pour supporter
cette activité :
·
Soutien à l'authentification.
·
Contrôle et maintenance des autorisations.
·
Contrôle et maintenance des commandes d'accès.
·
Gestion des clés.
·
Maintenance et examen des fichiers de sécurité.
Exemples
Ø Détection d'intrusions.
Ø Détection d'une attaque par IP
Flooding.
Ø Détection de virus.
1.4 Organisation d'une
administration
Il existe différents types de décision
d'administration :
Ø Décisions opérationnelles :
décision à court terme, concernant l'administration au jour le
jour et opérations temps réel sur le système ;
Ø Décisions tactiques : décision
à moyen terme concernant, l'évolution du réseau et
l'application des politiques de long terme ;
Ø Décisions stratégiques :
décision de long terme concernant les stratégies pour le futur en
exprimant les nouveaux besoins et désirs des utilisateurs.
Ø Ces types déterminent différents
niveaux d'administration:
Ø Le contrôle opérationnel
réseau pour les décisions Opérationnelles
Ø La gestion réseau pour les
décisions tactiques
Ø L'analyse de réseau pour les
décisions tactiques et stratégiques
Ø La planification pour les décisions
stratégiques
1.5 Les systèmes de gestion
de réseau
Un système de gestion réseau est une collection
d'outils pour contrôler et gérer le réseau qui
comprend :
Ø Une interface pour opérateur avec un ensemble
de commandes pour exécuter la plupart des tâches d'administration
de réseaux.
Ø Un minimum d'équipements supplémentaire
intégré au système existant
I.6
Modèle de gestion
La mise en oeuvre de la gestion se fait à travers le
modèle d'administration suivante :
Ø Le modèle Informationnel ;
Ø Le modèle Organisationnel ;
Ø Le modèle Fonctionnel ;
Ø Le modèle de communication.
L'administration dans le réseau Ip utilise seulement
deux modèles à savoir :
Ø Le modèle Informationnel
Ø Le modèle de communication
Le
modèle Informationnel
Il permet de définir les objets administrés
(nom, fonction, relations et attributs divers). La base de données ainsi
constituée est appelée MIB. Cette base est organisée de
manière hiérarchique sous forme d'arbre. La description des
objets dans la MIB est faite en utilisant la syntaxe ASN1 (Abstract Syntax
Notation one).
Le
modèle de communication
Ce modèle sous entend, un protocole dédié
aux échanges de gestion, des messages de commandes/réponse et des
messages de notification.
I.7
Principe général d'administration
Sur le point de l'administration, un système de
réseau informatique se compos d'un ensemble d'objets qu'un
système d'administration surveille et contrôle. Chaque objet est
géré localement par un processus appelé agent qui transmet
régulièrement ou sur sollicitation les informations de gestion
relatives à son état et aux événements qui le
concernent au système d'administration.
Le système d'administration comprend un processus
(manager ou gérant) qui peut accéder aux informations de gestion
de la MIB locale via un protocole d'administration qui le met en relation avec
les divers agents.
Le principe se repose donc sur les échanges :
Ø D'une part, entre une base d'informations
appelée MIB (Management Information Base) et l'ensemble des
éléments administrés (objets) ;
Ø D'autre part, entre les
éléments administrés et le système
d'administration.
Figure 1-5 processus agent/gérant
I.8Architecture d'administration
L'architecture classique d'administration la plus
utilisée est le modèle Gérant/ Agent (Manager/Agent).comme
nous l'avons montrer dans le principes d'administration. Le système est
composé d'une entité d'administration et des entités de
gestion (NME) qui sont géré par cette entité et un
protocole pour la gestion
Chaque entité dans le réseau a un Agent pour
l'opération de gestion, une base de données stockées dans
MIB et assume les travaux ci-dessous :
Ø Collecter des informations statistiques
concernant à la communication, les opérations de
réseau.
Ø Stocker les informations localement dans les
MIBs Répondre les commands de l'entité de contrôle de
réseau, inclus : Transmet des informations statistiques à
l'entité d'administration de réseau, modifie les
paramètres, donne des informations d'état...
L'entité d'administration a une entité de
gestion (NME) et aussi un logiciel pour gérer le réseau
appelé NMA (Network Management Application). NMA contient une interface
permettant l'administrateur fait des opérations de gestion.
1.9 Conclusion
Ce chapitre nous a permis de présenter les concepts de
base de la gestion de réseau pour aider l'administrateur dans sa
tâche de conception d'un système de gestion optimal en fonction
des objectifs de l'entreprise. Le chapitre suivant sera consacré
à l'étude du protocole SNMP qui est une solution de gestion
envisager dans cette étude.
Chapitre II LE PROTOCOLE SNMP
II.1 Historique
SNMP (Simple Network Management Protocol) a été
défini par l'IETF (Internet Engineering Task Force) en 1989. Depuis, il
est devenu un standard pour la gestion de réseaux. Il permet de
faciliter l'échange d'information d'administration entre
différentes entités d'un réseau pour disposer d'une
cartographie du réseau, fournir un inventaire précis de chaque
entité, gérer les Performances, détecter et
résoudre des problèmes.
II.2 Présentation du
protocole
SNMP est un protocole de la famille TCP/IP (Transport control
prototcol, Internet protocol), Etant un protocole Internet, il est compatible
à toutes plateformes hétérogènes et est
installé sur la plupart des matériels réseaux tels que
routeurs et commutateurs et peut donc être utilisé sur tous les
réseaux de type Internet. Il exploite les capacités du protocole
de transport UDP :
Ø Chaque trame possède une adresse
source et une adresse destination qui permettent aux protocoles de niveaux
supérieurs comme SNMP de pouvoir adresser leurs requêtes.
Ø Le protocole UDP peut utiliser un checksum
optionnel qui couvre l'en-tête et les données de la trame. En cas
d'erreur, la trame UDP reçue est ignorée : gage de
fiabilité.
Le protocole UDP fonctionne en mode non connecté,
c'est-à-dire qu'il n'existe pas de lien persistant entre la station
d'administration et l'agent administré. Cela oblige les deux parties
à s'assurer que leurs messages sont bien arrivés à
destination, ce qui apporte également un important gage de
fiabilité pour la gestion réseau.
Deux ports sont désignés pour l'utilisation de
SNMP :
Ø - Port 161 pour les requêtes à
un agent SNMP.
Ø - Port 162 pour l'écoute des alarmes
destinées à la station d'administration.
Cette technologie se situe entre la couche 4 (Transport) et la
couche 7 (application)
Figure 2-1 Le snmp dans la hiérarchie des couches
iso.
II.3 Les composants de base de SNMP
Un réseau administré par SNMP dispose de trois
composants clé : les dispositifs administrés, les agents et
les systèmes d'administration réseau (NMS, Network Management
System).
Ø Un dispositif administré est un noeud
réseau qui contient un agent SNMP et qui réside sur un
réseau administré. Les dispositifs administrés collectent
et conservent des informations d'administration, et rendent ces informations
disponibles aux NMS à l'aide de SNMP. Les dispositifs
administrés, parfois appelés « éléments
réseau », peuvent être des routeurs, des serveurs
d'accès, des commutateurs, des ponts, des hubs, des hôtes
ordinateurs ou des imprimantes.
Ø Un agent est un module logiciel
d'administration réseau qui réside sur un dispositif
administré. Un agent possède une connaissance locale des
informations d'administration et traduit celle-ci en un format compatible avec
SNMP.
Ø Un NMS Les systèmes de gestion de
réseau (network management system notés NMS): C'est-à-dire
une console au travers de laquelle les administrateurs peuvent réaliser
des tâches d'administration, exécutent des applications qui
surveillent et contrôlent des dispositifs administrés. Un NMS
fournit l'essentiel des ressources de traitement et mémoires
nécessaires à l'administration réseau. Il doit y avoir un
ou plusieurs NMS sur un réseau administré.
SNMP est un protocole d'administration distribuée. Un
système peut opérer soit comme un NMS, soit comme un agent, ou
les deux à la fois. Lorsqu'un système fonctionne comme NMS et
agent, un autre NMS est susceptible d'exiger que le système interroge
des dispositifs administrés qui fournissent un résumé des
informations apprises ou rapportent les informations d'administration
conservées en local.
Figure 2-2 schémas de gestion de réseau avec
snmp
II.4 Les opérations
Le protocole SNMP supporte trois types de requêtes :
GET, SET et TRAP. Il utilise alors les opérations suivantes pour la
gestion du réseau :
GetRequest : Cette requête permet aux stations de
gestion (manager) d'interroger les objets gérés et les variables
de la MIB des agents. La valeur de l'entrée de la MIB (nom) est
passée en paramètre. Elle permet d'accéder à une
variable précise.
GetNextRequest : Cette requête permet aux stations de
gestion de recevoir le contenu de l'instance qui suit l'objet nommé
(passé en paramètre) dans la MIB. Cette commande permet en
particulier aux stations de gestion de balayer les tables des MIB. Elle permet
d'accéder à plusieurs variables simultanément.
GetResponse: A chaque envoie d'un message à l'exception
de TRAP, un message de réponse est retourné. Ils ont chacun une
signification bien distincte :
GET-response : tout s'est bien passé,
l'information est transmise.
NoSuchObject' : aucune variable n'a été
trouvée.
NoAccess : vous ne disposez pas des bons droits
d'accès.
Figure 2-3requette snmp
Une requête SNMP est construite de la façon
suivante :
V: version SNMP (v1, v2, v3)
C : type de
communauté (public ou private)
D : donnée (requête:
GET, GET_NEXT, TRAP ...)
Communauté
Un agent SNMP est plus ou moins finement paramétrable,
suivant le système. Il est possible, par exemple de créer des
groupes de sécurité qui auront accès en lecture seule,
d'autres en lecture/écriture, d'autres encore en lecture seule, mais sur
certaines branches seulement...
Chaque groupe devra disposer d'une sorte de mot de passe,
appelé "community". En général, la communauté
"public" est celle qui a le droit de lecture sur les informations non
sensibles.
Nous avons donc des informations à consulter, des
paramètres à modifier et des alarmes à émettre.
Tout cela, en principe, de façon indépendante du matériel
et du logiciel. Il faut donc que SNMP permette de retrouver ces informations et
d'agir sur les paramètres. Pour cela SNMP utilise le Mib.
II.5
Structure SMI (Structure Of Management Information)
La structure SMI décrit les règles de
description de l'information et permet d'identifier de façon unique un
objet de la MIB géré par un agent SNMP. Chaque objet
possède donc un identificateur unique ou OID (Object ID).
SMI s'intéresse aussi à la représentation
des données (et leur type) pour chaque objet de la MIB. Un objet de la
MIB est déclaré et défini en langage ASN.1 (Abstract
Syntax Notation 1 : langage de représentation de donnée).
SNMP n'utilise qu'une petite partie du langage ASN.1. Au
niveau des types, seuls quelques uns sont utilisés comme :
Ø INTEGER : valeur entière sur 32
bits en complément à 2.
Ø OCTET STRING : chaîne de
caractères.
Ø IpAddress : adresse IP.
Ø PhysAddress : adresse MAC (6 octets pour
un réseau de type Ethernet).
Ø Counter : entier de 32 bits non
signé qui s'accroît de 0 à (2exp32 -1) puis revient
à 0.
Ø TimeTicks : compteur de temps sur 32
bits non signé en 1/100 de s.
II.6
La structure de données MIB
La MIB est une base de donnée gérée par
un agent SNMP regroupant les objets gérés en respectant les
règles SMI. Elle possède une structure d'arbre similaire à
celui employé dans le DNS (Domain Name System). On retrouve une racine
non nommée à partir de laquelle on référencie de
façon absolue un objet par son OID (noeud de l'arbre).
Un objet administré (parfois appelé un objet
MIB, un objet ou une MIB) est l'une des nombreuses caractéristiques
possibles d'un dispositif administré. Des objets administrés sont
composés d'une ou plusieurs instances d'objets, lesquelles sont
essentiellement des variables.
Il existe deux types d'objets administrés :
scalaire et tabulaire. Des objets scalaires définissent une seule
instance d'objet. Des objets tabulaires définissent plusieurs instances
liées d'objets, et celles-ci sont regroupées dans des tables
MIB.
Un exemple d'objet administré est atInput, un objet
scalaire qui contient une seule instance d'objet, à savoir la valeur de
l'entier qui indique le nombre total de paquets AppleTalk entrant sur
l'interface d'un routeur.
Un identificateur d'objet (ou ID d'objet) identifie de
manière unique un objet administré dans la hiérarchie de
la MIB. La hiérarchie de la MIB peut être décrite comme un
arbre dont la racine n'a pas de noms et dont les niveaux sont attribués
par différentes organisations.
Figure 2-4 Représentation de la MIB
Les ID d'objets des niveaux supérieurs appartiennent
à différentes organisations de standards, tandis que les ID
d'objets des niveaux inférieurs sont attribués par des
organisations associées.
Les vendeurs peuvent définir des branches
privées qui incluent des objets administrés pour leurs propres
produits. Les MIB non standardisées sont normalement placées dans
la branche expérimentale.
L'objet administré atInput peut être
définit de manière unique soit par le nom d'objet
(iso.identifiedorganization.dod.internet.private.entreprise.cisco.temporary
variables.Apple-Talk.atInput), soit de façon équivalente, par le
descripteur de l'objet (1.3.6.1.4.1.9.3.3.1).
Les tables Mib : ces sont des tables contenant les
informations de l'élément du réseau. Ces Informations sont
hiérarchisées sous forme d'arbre comme nous illustrer ci-haut
:
System : Description de toutes les entités
gérés
Interfaces : Interface de données dynamiques ou
statiques
at. (adresse translation) : Table d'adresses IP pour les
correspondances
d'adresses MAC
Ip : Statistiques du protocole IP, adresse cache et table de
routage
Icmp : Statistiques du protocoles ICMP
Tcp : Paramètres TCP, statistiques et table de
connexion
Udp : Statistiques UDP
Egp : Statistiques EGP, table d'accessibilité
Snmp : Statistiques du protocole SNMP
Examinons quelques éléments de données de
la MIB pour en clarifier le contenu.
Variables MIB Catégorie
Signification
sysUpTime système Durée écoulé
depuis dernier démarrage
fNumber interfaces Nombre d'interfaces réseau
ifMtu interfaces MTU d'une interface particulière
ipDefaultTTL ip Valeur utilisée dans le champ TTL
TIPE : Les protocoles pour la gestion des réseaux
informatiques
Nguyen M_nh T__ng, Promotion 10 26
icmpInEchos icmp Nbre de demandes d'echo ICMP reçues
tcpInSegs tcp Nbre de segments reçus par TCP
udpInDatagrams udp Nbre de datagrammes UDP reçus
Les valeurs des éléments de chacune des
variables ci-dessus peuvent être enregistrées au moyen d'un seul
entier. Toutefois, la MIB permet également de définir des valeurs
plus complexes, comme par exemple la variable ipRoutingTable qui fait
référence à la table de routage d'un routeur.
Extension de la Mib
Au bout d'un moment, les variables choisies pour la Mib (puis
la mib-2) se sont avérées insuffisantes pour plusieurs
applications. On va donc trouver deux autres types de Mib que sont les private
Mib et les Mib R-MON (Remote network Monitoring).
Les privates Mib , représentées en 1.3.6.1.4
dans la structure SMI, permettent aux entreprises de rajouter des variables
pour une implémentation particulière des agents SNMP. Cela leur
permet d'ajouter de nouvelles variables en fonctions des applications qu'elles
veulent.
Les Mib R-MON permettent par exemple de placer des agents SNMP
sur des supports physiques. Sur un câble, on peut connecter une sonde
R-MON qui va enregistrer tout ce qui se passe et que l'administrateur pourra
interroger pour avoir des informations sur les collisions, les débits
à un endroit précis.
II.7
Les différentes versions de SNMP
Plusieurs version du protocole on vue le jours à
savoir :
SNMPv1 : Ceci est la première version du
protocole, tel que définie dans le RFC 1157. La sécurité
de cette version est triviale, car la seule vérification qui est faite
est basée sur la chaîne de caractères " community ".
SNMPsec Cette version ajoute de la sécurité au protocole SNMPv1.
La sécurité est basée sur des groupes. Très peu ou
aucun manufacturiers n'a utilisé cette version qui est maintenant
largement oubliée.
SNMPv2p (historique) : Beaucoup de travaux on
été exécutés pour faire une mise à jour de
SNMPv1. Ces travaux ne portaient pas seulement sur la sécurité.
Le résultat est une mise à jour des opérations du
protocole, des nouvelles opérations, des nouveaux types de
données. La sécurité est basée sur les groupes de
SNMPsec.
SNMPv2c (expérimental): Cette version du protocole est
appelé " community stringbased SNMPv2 ". Ceci est une
amélioration des opérations de protocole et des types
d'opérations de SNMPv2p et utilise la sécurité par
chaîne de caractères " community " de SNMPv1.
SNMPv2u (expérimental): Cette version du protocole
utilise les opérations, les types de données de SNMPv2c et la
sécurité basée sur les usagers.
SNMPv2* (expérimental): Cette version combine les
meilleures parties de SNMPv2p et SNMPv2u. Les documents qui décrivent
cette version n'ont jamais été publiés dans 12 les RFC.
Des copies de ces documents peuvent être trouvées sur le site web
et SNMP Research (un des premiers à défendre de cette
version).
SNMPv3 (standard actuel): Cette version comprend une
combinaison de la sécurité basée sur les usagers et les
types et les opérations de SNMPv2p, avec en plus la capacité pour
les " proxies ". La sécurité est basée sur ce qui se
trouve dans SNMPv2u et SNMPv2*.
II.7.1
SNMP Version 1
SNMP version 1 (SNMPv1) est la première
implémentation du protocole SNMP. Elle est écrite dans le RFC
(Request For Comments) 1157 et fonctionne dans le cadre des
spécifications de SMI (Structure of Management information). SNMPv1
opère sur des protocoles, tels que UDP (User Datagram Procol), IP
(Internet Protocol), OSI CLNS (ConnectionLess Network Service), AppleTalk DDP
(Datagram-Delivery Protocol) et Novell IPX (Internetwork Packet Exchange).
SNMPv1 est largement utilisé et fait office de protocole de facto pour
l'administration réseau dans la communauté internet.
SNMPv1 et SMI
La structure des informations d'administration, ou SMI
(Structure of Management Information), définit les règles de
description des informations d'administrations à l'aide de ASN.1. La
norme SMI de SNMPv1 est définie dans la RFC 1155. La SMI définit
trois spécifications clés : les types de données
ASN.1, les types de données spécifiques à SMI et les
tables MIB de SNMP.
SNMPv1 et les types de données ASN.1
La norme SMI de SNMPv1 spécifie que tous les objets
administrés disposent d'un sous-ensemble de types de données
ASN.1 qui leur est associé. Trois types de données ASN.1 sont
exigées : le nom, la syntaxe et le codage. Le nom sert
d'identificateur d'objet (ID d'objet). La syntaxe définit le type de
données de l'objet (par exemple, entier ou chaîne). La norme SMI
sert d'un sous-ensemble des définitions des syntaxes ASN.1. Les
données de codage décrivent la manière dont les
informations associées à un objet administré sont
formatées sous la forme d'une série d'éléments de
données pour une transmission sur le réseau.
SNMPv1 et les types de données spécifiques
à SMI
La norme SMI de SNMPv1 spécifie l'utilisation de
plusieurs types de données spécifiques à SMI, qui sont
divisés en deux catégories : les types de données
simples et les types de données de portée application
(application-wide data type).
Ø Trois types de données simples sont
définis dans la SMI de SNMPv1 ; chacun d'entre eux
représente une valeur unique : les entiers, les chaines d'octets et
les ID d'objets.
·
Le type de données entier est un entier signé compris dans
l'intervalle - 2 147 483 648 à 2 147 486 647.
·
Les chaînes d'octets sont des séquences ordonnées de 0
à 65535 octets.
·
Les ID d'objets proviennent de l'ensemble de tous les identificateurs d'objets
alloués conformément aux règles spécifiées
dans ASN.1.
Ø Sept types de données de portée
d'application sont définies dans la SMI de SNMPv1 : adresses
réseau, compteurs (counter), gauges, time ticks, opaques, entiers et
entiers non signés.
·
Le type adresses réseau représente une adresse d'une famille de
protocoles particulière. SNMPv1 ne supporte que des adresses IP sur 32
bits.
·
Les compteurs sont des entiers non négatifs dont la valeur augmente
jusqu'à ce qu'elle atteigne un maximum puis revienne à
zéro. Dans SNMPv1, il est spécifié une taille de compteur
sur 32 bits.
·
Les gauges sont des entiers non négatifs qui peuvent croître ou
décroître, mais qui conservent la valeur maximale atteinte.
·
Les time ticks représentent le nombre de centièmes de secondes
écoulés depuis un évènement.
·
Un opaque représente un codage arbitraire qui est utilisé pour
transmettre des chaînes d'informations arbitraires non strictement
conformes au typage de données de SMI.
·
Un entier représente des informations dont la valeur se présente
sous forme d'entiers. Ce type de données redéfinit le type de
donnée entier qui a une précision arbitraire dans ASN.1, mais une
précision bornée dans la norme SMI.
·
Un entier non signé représente des informations dont la valeur se
présente sous la forme d'entiers non signés, ce qui est utilise
quand les valeurs sont toujours négatives. Ce type de données
redéfinit le type de données entier qui a une précision
arbitraire dans ASN.1, mais une précision bornée dans la norme
SMI.
Les tables MIB de SNMPv1
La norme SMI de SNMPv1 définit des tables hautement
structurées qui sont utilisées pour regrouper des instances d'un
objet tabulaire (c'est-à-dire un objet qui contient plusieurs
variables). Les tables sont composées de zéro ou plusieurs lignes
qui sont indexées de telle manière que SNMP puisse
récupérer ou modifier une ligne entière avec une seule
commande Get, GetNext ou Set.
Les
opérations du protocole SNMPv1
SNMP est un protocole simple de type
requête/réponse. Le système d'administration réseau
émet une requête, et les dispositifs administrés retournent
des réponses. Ce comportement est implémenté à
l'aide de l'une des quatre opérations de protocole : Get, GetNext,
Set et Trap.
Ø L'opération Get est utilisée
pour la NMS pour récupérer la valeur d'une ou plusieurs instances
d'objets à partir d'un agent. Si l'agent qui répond à
l'opération Get ne peut pas fournir des valeurs pour toutes les
instances des objets d'une liste, il ne fournit aucune valeur.
Ø L'opération GetNext est
utilisée par le NMS pour récupérer la valeur de la
prochaine instance des objets d'une table ou d'une liste dans un agent.
Ø L'opération Set est utilisée
par le NMS pour définir les valeurs des instances des objets dans un
agent.
Ø L'opération Trap est utilisée
par des agents pour informer de manière asynchrone le NMS de la survenue
d'un événement significatif.
II.7.2
SNMP Version 2
SNMP version 2 (SNMPv2) est une évolution de la
version initiale, SNMPv1. A l'origine, en 1993, SNMPv2 a été
publié sous la forme d'un ensemble de propositions de standards
Internet ; actuellement, il s'agit d'un avant projet de standard. A
l'instar de SNMPv1, SNMPv2 fonctionne dans le cadre des spécifications
de SMI. En théorie, SNMPv2 offre plusieurs améliorations par
rapport à SNMPv1 et notamment des opérations de protocole
supplémentaires.
SNMPv2 et SMI
La structure des informations d'administration, ou SMI
(Structure of Management Information), définit les règles de
description des informations d'administration à l'aide de ASN.1.
La norme SMI de SNMPv2 est définie dans le RFC 1902.
Elle comprend des ajouts et des améliorations par rapport aux types de
données spécifiques a SMI SNMPv1, par exemple les chaînes
de bits (bit string), les adresses réseau et les compteurs. Les
chaînes de bits ne sont définies que dans SNMPv2 ; elles se
composent de zéro ou plusieurs bits nommés qui spécifient
une valeur. Les adresses réseau représentent une adresse en se
référant à une famille de protocoles
déterminée. Si SNMPv1 ne supporte que des adresses sur 32bits,
SNMPv2 peut supporter d'autres types d'adresses. Les compteurs sont des entiers
non négatifs dont la valeur augmente jusqu'à ce qu'ils atteignent
une valeur maximale pour retourner ensuite un zéro. Dans SNMPv1, il est
spécifié un compteur sur 32 bits, alors que dans SNMPv2 il est
défini des compteurs sur 32 et 64 bits.
Les modules d'information
SMI
La norme SMI de SNMPv2 spécifie également des
modules d'informations qui spécifient un groupe de définition
liées. Il existe trois types de modules d'informations SMI : des
modules SMI, des instructions de compatibilité (compliance statements)
et des instructions de capacité (capability statements).
Ø Les instructions de compatibilité
fournissent une manière systématique de décrire un groupe
d'objets administrés qui doivent être implémentés
pour la conformité à un standard.
Ø Les instructions de capacité sont
utilisées pour indiquer le niveau précis de support qu'un agent
réclame compte tenu d'un groupe SMI. Un NMS peut adapter son
comportement à l'égard des agents en fonction des instructions de
capacités associées à chaque agent.
Les opérations du protocole
SNMPv2
Les opérations Get, GetNext et Set utilisés dans
SNMPv2 sont exactement les mêmes que celles de SNMPv1. Cependant, SNMPv2
ajoute et améliore certaines opérations de protocole. C'est ainsi
que l'opération Trap, par exemple, réalise la même fonction
que dans SNMPv1, mais elle se sert d'un format de message différent et
est conçue pour remplacer l'opération Trap de SNMPv1.
SNMPv2 définit aussi de nouvelles opérations de
protocole : GetBulk et inform.
Ø L'opération GetBulk est
employée par le NMS pour récupère de manière
efficace de gros blocs de données, tels que plusieurs lignes d'une
table. GetBulk remplit un message de réponse avec autant de
données demandées que celui-ci peut en contenir.
Ø L'opération Inform permet à un
NMS d'envoyer des informations Trap à un autre NMS et de recevoir
ensuite une réponse.
Dans SNMPv2, si l'agent qui répond aux
opérations GetBulk ne peut pas fournir de valeurs pour toutes les
variables d'une liste, il fournit des résultats partiels.
II.7.3
L'interopérabilité de SNMP
Dans l'état actuel des spécifications, SNMPv2
est incompatible avec SNMPv1 dans deux domaines clés : les formats
des messages et les opérations de protocole. Les messages SNMPv2
utilisent des formats d'en-tête de PDU (Protocol Data Unit)
différents de ceux des messages SNMPv1. SNMPv2 emploie aussi deux
opérations de protocole non spécifiées dans SNMPv1. En
outre, le RFC 1908 définit deux stratégies de coexistences
SNMPv1/SNMPv2 : les agents proxy et les systèmes d'administration
réseau bilingues.
Le format des messages
SNMPv1
Les messages SNMPv1 sont composés de deux
parties : un en-tête de message et une PDU (Protocol Data Unit)
L'en-tête des messages SNMPv1
Les en-têtes des messages SNMPv1 contiennent deux
champs : Numéro de version et Nom de la communauté
(Community Name). Voici la description de ces champs :
Ø Numéro de version. Spécifie la
version de SNMP
Ø Nom de la communauté. Définit
un environnement d'accès pour un groupe de NMS. Les NMS de la
communauté sont dits exister à l'intérieur du même
domaine administratif. Les noms de la communauté font office de forme
faible d'authentification, car les dispositifs qui ne connaissent pas le nom
correct de la communauté sont exclus des opérations SNMP.
Les PDU SNMPv1
Les PDU de SNMPv1 contiennent une commande spécifique
(Get, Set, etc.) et des opérandes qui indiquent les instances d'objet
impliquées dans la transaction. Les champs des PDU sont variables en
longueur, comme prescrit par ASN.1.
|
Type de la PDU
|
ID de la requête
|
Statut de l'erreur
|
Indice de l'erreur
|
Liaison des variables
|
Les champs de la PDU de SNMPv1, présentés sont
les suivants :
Ø Type de la PDU. Spécifie le type de la
PDU transmise.
Ø ID de la requête (request ID). Associe
des requêtes SNMP à des réponses.
Ø Statut de l'erreur. Indique une des erreurs
et des types d'erreurs. Seules les opérations de réponses
définissent ce champ.
Ø Indice de l'erreur. Associe une erreur
à une instance d'objet particulière. Seules les opérations
de réponse définissent ce champ. Les autres opérations
définissent ce champ à zéro.
Ø Liaison des variables. Sert de champ de
données à la PDU SNMPv1. Chaque liaison de variable associe une
instance d'objet particulière a sa valeur courante (a l'exception des
requêtes Get et GetNext pour lesquelles la valeur est ignorée).
Le format de la PDU Trap
|
Entreprise
|
Adresse de l'agent
|
Type de trap générique
|
Code de trap spécifique
|
Indication d'heure
|
Liaison des variables
|
Les champs de la PDU Trap sont les suivants :
Ø Entreprise. Identifie le type de l'objet
administré qui génère le message trap.
Ø Adresse de l'agent. Fournit l'adresse de
l'objet administré qui génère le message trap
Ø Type de trap générique.
Contient un entier représentant l'une des valeurs de trap
prédéfinit en standard (ou trap générique) pour
SNMP.
Ø Code de trap spécifique. Contient un
entier représentant l'une des valeurs de trap pour un constructeur ou
une entreprise particulière (ou trap spécifique).
Ø Indication d'heure. Spécifie la
quantité de temps qui s'est écoulée entre la
dernière réinitialisation réseau et la
génération du trap
Ø Liaison des variables. Le champ
données du PDU Trap de SNMPv1. Chaque liaison de variable associe une
instance d'objet particulière à sa valeur courante.
Le format des
messages SNMPv2
Les messages SNMPv2 sont composés d'un en-tête et
d'une PDU.
L'en-tête des messages
SNMPv2
Les en-têtes des messages SNMPv2 contiennent deux
champs : Numéro de version et Nom de la communauté
(Community Name). Voici la description de ces champs :
Ø Numéro de version. Spécifie la
version de SNMP
Ø Nom de la communauté. Définit
un environnement d'accès pour un groupe de NMS. Les NMS de la
communauté sont dits exister à l'intérieur du même
domaine administratif. Les noms de la communauté font office de forme
faible d'authentification, car les dispositifs qui ne connaissent pas le nom
correct de la communauté sont exclus des opérations SNMP.
Les PDU SNMPv2
SNMPv2 spécifie deux formats de PDU selon
l'opération de protocole de SNMP. Les champs des PDU sont variables en
longueur, comme prescrit par ASN.1.
|
Type de la PDU
|
ID de la requête
|
Non repeaters
|
Liaison des variables
|
Les champs de la PDU de SNMPv2 sont les suivants :
Ø Type de la PDU. Spécifie le type de la
PDU transmise (Get, GetNext, Inform, Response, Set ou Trap).
Ø ID de la requête. Associe des
requêtes SNMP à des réponses.
Ø Statut de l'erreur. Indique une des erreurs
et des types d'erreurs. Seules les opérations de réponse
définissent ce champ.
Ø Indice de l'erreur. Associe une erreur
à une instance d'objet particulière. Seules les opérations
de réponse définissent ce champ. Les autres opérations
définissent ce champ à zéro.
Ø Liaison des variables. Sert de champ de
données de la PDU SNMPv2. Chaque liaison de variable associe une
instance d'objet particulière à sa valeur courante (à
l'exception des requêtes Get et GetNext pour lesquelles la valeur est
ignorée).
Le format de la PDU GetBulk
|
Type de la PDU
|
ID de la requête
|
Non repeaters
|
Liaison des variables
|
Les champs de la PDU GetBulk de SNMPv2 sont les
suivants :
Ø PDU type. Identifie la PDU comme étant
une opération GetBulk.
Ø Request ID. Associe des requêtes SNMP
à des réponses.
Ø Non repeaters. Spécifie le nombre
d'instances d'objet du champ Liaisons de variables qui ne doivent pas
être récupérées plusieurs fois à partir du
début de la requête. Ce champ est utilisé lorsque certaines
des instances d'objets scalaires ne comprennent qu'une variable.
Ø Max répétitions. Définit
le nombre maximal de fois où d'autres variables situées
au-delà de celle spécifiées dans le champ Non repeaters
doivent être récupérées.
Ø Liaison des variables. Sert de champ de
données de la PDU SNMPv2. Chaque liaison de variables associe une
instance d'objet particulière à sa valeur courante (à
l'exception des requêtes Get et GetNext pour lesquelles la valeur est
ignorée).
II.8 La Sécurité
SNMP manque de fonctionnalités en matière
d'authentification, ce qui le rend vulnérable à un grand nombre
de menaces, notamment l'usurpation d'identité (masquerading), la
modification d'informations, les modifications de numéros de
séquences des messages ou des dates et la divulgation.
Il y a usurpation lorsqu'une entité non
autorisée tente de réaliser des opérations
d'administration en se faisant passer pour une entité autorisée.
La modification d'informations implique la tentative d'une entité non
autorisée de modifier un message généré par une
entité autorisée de manière que le message final traduise
des opérations de comptabilisation ou de configuration erronées.
Les modifications des numéros de séquences ou
des dates des messages se produisent lorsqu'une entité non
autorisée réordonne, retarde, copie ou émet de nouveau un
message généré par une entité autorisé.
Etant donné que SNMP n'implémente pas l'authentification,
plusieurs vendeurs n'implémentent pas les opérations Set, ce qui
réduit SNMP à ses fonctions de surveillance.
Dans la version SNMPv1, la sécurité a comme on
pourrait dire, été oublié. Tous les messages passent en
clair sur le réseau. Cela veut dire qu'avec n'importe quel outil
d'écoute (sniffer) nous sommes capables d'intercepter tout le trafic. En
SNMPv2 on peut fixé des listes de contrôle d'accès ACLs qui
sont censées améliorer la sécurité. Le vrai
progrès se fait avec la dernière version où la plupart des
messages passeront en crypté sur le réseau. Beaucoup de
composants réseau exploitent encore la version 1 ou 2. Cela
représente un danger potentiel pour les infrastructures. Il faut savoir
que sur Internet, la plupart des entités réseau sont
administrable par SNMP.
Un exemple d'application simple de composant
administrable : Le modem câble ou ADSL très souvent, les
fournisseurs d'accès contrôle votre débit en bridant votre
modem (c'est surtout valable pour les modems câble) en utilisant cette
technologie. Très souvent aussi, ces modems sont très mal
protégés (pas de mot de passe, acl nulles...). Le
propriétaire du modem, en utilisant les outils adéquats seraient
donc capable de fixer ses propres débits et bien plus encore. Ici ce
qu'on essaye de mettre en évidence se sont surtout les mécanismes
d'authentification qui sont manquants dans les 2 premières version.
La SNMPv3
Il est vrai que SNMPv3 introduit des notions de
sécurité comme :
Ø Authentification / intégrité
basé sur du DES et clef secrète
Ø Confidentialité des données
Ø Contrôle d'accès par la MIB
Mais il est encore expérimental.
II.9
Le SNMP et d'autre protocoles
Le WMI
Contrairement aux autres protocoles, WMI qui signifie Windows
Management Instrumentation, n'est compatible qu'avec le système
d'exploitation Windows. Il permet à tout administrateur de
contrôler, gérer, d'installer, collecter des informations
localement comme à distance. De manière générale,
il étend les possibilités de base d'administration de Windows.
Cependant, bien qu'il puisse faire office d'outil de monitoring il n'est pas
recommandé pour cet usage. Ce protocole peut se montrer assez gourmand
quand il s'agit de capturer (snapshot).
Le CMIP
CMIP ou Common Management Information Protocol, un standard
OSI qui est utilisé avec le protocole CMIS, Common Management
Information Services pour le monitoring and les contrôles de
réseaux hétérogènes. CMIP a été
proposé comme remplacement au protocole beaucoup moins
sophistiqué qu'était SNMP mais n'a pas rencontré un franc
succès. CMIP a la particularité d'offrir une meilleure
sécurité et est capable de reporter des conditions inhabituelles
d'un réseau.
II.10 Avantages et
inconvénients
Nous l'avons vu, le protocole SNMP a de nombreux avantages en
tant qu'outil de gestion réseau :
Ø Accès centralisé : la gestion
réseau s'effectue depuis une machine centrale sans soucis, et c'est
même préférable pour la sécurité.
Ø Sécurité : la
sécurité s'est accrue au cours des différentes versions,
jusqu'à respecter la plupart des contraintes imposées.
Ø Fiabilité : le protocole
utilisé permet de s'assurer que les requêtes sont bien
arrivées à destination et qu'elles ont été
correctement interprétées.
Ø ?Gestion de la diversité :
l'utilisation d'une interface standard à tous les matériels
permet de contrôler de la même manière tous les
équipement réseaux, ce qui a des avantages indéniables
lorsque l'on dispose d'un parc informatique très diversifié.
II.11 Conclusion
Ce pitre nous a permis de comprendre le fonctionnement du
protocole SNMP. Grâce à ces requêtes d'administration et sa
simplicité de mis au point l'administrateur peut maintenir son
réseau malgré la complexité.
Dans le chapitre qui suit il sera question de
concrétiser les informations que nous venons de voir dans ce chapitre en
mettant au point un module logiciel de gestion.
CHAPITRE III MPLEMENTATION JAVA
DE L'APPLICATION DE GESTION
3.1 Introduction
Ce chapitre aborde l'implémentation de
l'application, comme énoncé dans l'introduction, nous allons
exploiter le langage java. L'intérêt porté à ce
langage java est motivé par ses caractéristiques et sa
portabilité. Il est à noter que nous nous sommes en passé
de notion de programmation dans ce travail, plusieurs ouvrages traitent les
techniques et problème de la programmation en java et les lecteurs
pourront s'y référer.
3.2 Présentation du langage
java
3.2.1 Bref historique
Développé par Sun Microsystems depuis la
fin des années 1980, Java est un langage de programmation à usage
général, évolué et orienté objet dont la
syntaxe est proche du C. Il existe 2types de programmes en Java : les applets
et les applications. Une application autonome (stand alone program) est une
application qui s'exécute sous le contrôle direct du
système d'exploitation. Une applet est une application qui est
chargée par un navigateur et qui est exécutée sous le
contrôle d'un plug in de ce dernier.
Les principaux événements de la vie de Java
sont les suivants :
1995 mais: premier lancement commercial
1996 janvier : JDK 1.0
1996 septembre : lancement du JDC
1997 février : JDK 1.1
1998 décembre : lancement de J2SE et du JCP
1999 décembre : lancement J2EE
2000 mai : J2SE 1.3
2002 J2SE 1.4
2004 J2SE 5.0
3.2.2 Les
caractéristiques
Java possède un certain nombre de
caractéristiques qui ont largement contribué à son
énorme succès :
Ø Java est interprété : le
source est compilé en pseudo code ou byte code puis
exécuté par un interpréteur Java : la Java Virtual Machine
(JVM). Ce concept est à la base du slogan de Sun pour Java : WORA (Write
Once, Run Anywhere : écrire une fois, exécuter partout). En
effet, le byte code, s'il ne contient pas de code spécifique à
une plate-forme particulière peut être exécuté et
obtenir quasiment les mêmes résultats sur toutes les machines
disposant d'une JVM.
Ø Java est indépendant de toute
plate-forme : il n'y a pas de compilation spécifique pour chaque
plate forme. Le code reste indépendant de la machine sur laquelle il
s'exécute. Il est possible d'exécuter des programmes Java sur
tous les environnements qui possèdent une Java Virtual Machine. Cette
indépendance est assurée au niveau du code source grâce
à Unicode et au niveau du byte code.
Ø Java est orienté objet : comme la
plupart des langages récents, Java est orienté objet. Chaque
fichier source contient la définition d'une ou plusieurs classes qui
sont utilisées les unes avec les autres pour former une application.
Java n'est pas complètement objet car il définit des types
primitifs (entier, caractère, flottant, booléen,...).
Ø Java est simple : le choix de ses
auteurs a été d'abandonner des éléments mal compris
ou mal exploités des autres langages tels que la notion de pointeurs
(pour éviter les incidents en manipulant directement la mémoire),
l'héritage multiple et la surcharge des opérateurs, ...
Ø Java est fortement type : toutes les
variables sont typées et il n'existe pas de conversion automatique qui
risquerait une perte de données. Si une telle conversion doit être
réalisée, le développeur doit obligatoirement utiliser un
cast ou une méthode statique fournie en standard pour la
réaliser.
Ø Java assure la gestion de la mémoire :
l'allocation de la mémoire pour un objet est automatique à sa
création et Java récupère automatiquement la
mémoire inutilisée grâce au garbage collector qui restitue
les zones de mémoire laissées libres suite à la
destruction des objets.
Ø Java est sûr : la
sécurité fait partie intégrante du système
d'exécution et du compilateur. Un programme Java planté ne menace
pas le système d'exploitation. Il ne peut pas y avoir d'accès
direct à la mémoire. L'accès au disque dur est
réglementé dans une applet. Les applets fonctionnant sur le Web
sous soumises aux restrictions suivantes dans la version 1.0 de Java :
· Aucun programme ne peut ouvrir, lire,
écrire ou effacer un fichier sur le système de
l'utilisateur ;
· Aucun programme ne peut lancer un autre
programme sur le système de l'utilisateur ;
· Toute fenêtre créée par le
programme est clairement identifiée comme étant une fenêtre
Java, ce qui interdit par exemple la création d'une fausse fenêtre
demandant un mot de passe ;
· Les programmes ne peuvent pas se connecter
à d'autres sites Web que celui dont ils proviennent.
Ø Java est économe : le pseudo code
a une taille relativement petite car les bibliothèques de classes
requises ne sont liées qu'à l'exécution.
Ø Java est multitâche : il permet
l'utilisation de threads qui sont des unités d'exécution
isolées. La JVM, elle même, utilise plusieurs threads.
Ainsi a ce basant sur ces caractéristiques,
nous avons porté notre choix sur ce langage pour le développement
de notre application, dans le but de pouvoir déployé notre
application largement dans n'importe quelle plate forme.
3.3 Outils de
développement
La communauté Java est très productive car elle
regroupe :
Ø Sun, le fondateur de Java a travers le JCP (Java
Community Process) qui est le processus de traitement des évolutions de
Java dirigé par Sun. Chaque évolution est traitée dans une
JSR (Java Specification Request) par un groupe de travail constitué de
différents acteurs du monde Java ;
Ø des acteurs commerciaux dont tous les plus grands
acteurs du monde informatique excepté Microsoft ;
Ø la communauté libre qui produit un très
grand nombre d'api et d'outils pour Java .
L'ensemble des API et des outils utilisables est
énorme et évolue très rapidement. Hormis Les api
intégrés dans jdk, pour le développement notre application
nous avons utilisez aussi SNMP api d'AdventNet qui est un api
commercialisé conçu pour les applications SNMP.
3.3.1 Présentation de
l'api
SNMP api d'AdventNet est un api commercialisé,
mais qui peut est être obtenu pour usager académique.
SNMP api d'AdventNet peut être employé
pour développer des applications de gestion de réseau. Les
développeurs des applications de gestion de réseau peuvent
employer la bibliothèque SNMP d'AdventNet pour construire des applet,
des composants, et des applications réparties d'EJB, de CORBA, et de
RMI. La bibliothèque fournit les fonctions et les composants le plus
généralement utilisés pour rendre le développement
plus simple.
3.3.2 Emploi de SNMP Api
D'AdventNet
SNMP api d'AdventNet avec sa hiérarchie des
paquets de Java permet de développer le type mentionné ci-dessus
d'applications d'une manière plus simple et plus rapide. Les divers
paquets disponibles avec ce produit permettent le choix flexible du niveau
désiré de l'appui de bibliothèque. Le choix peut
être porté sur l'api de bas niveau ou l'api haut niveau pour une
programmation plus simple. Pour le développement de notre application,
nous avons porté notre choix sur l'api haut niveau.
3.3.3 Architecture d'Api Haut
Niveau (beans)
L'api niveau élevé est un ensemble de
composants de Java d'UI et de non-UI, qui agissent en tant que base standard de
référence pour des créations d'application et d'outil de
gestion. Ceci laisse établir des applications plus flexibles, des
applet, et des composants. Un certain nombre de perfectionnements ont
été aussi bien ajoutés, rendant l'utilisation de l'APIs
à niveau élevé beaucoup plus productive dans des
développement d'applications. Les composants peuvent être
employés dans n'importe quel constructeur beans de Java ou directement
dans le code de Java.
Le but de l'APIs à niveau élevé
est de faciliter le développement des applications de gestion en
utilisant les bibliothèques de SNMP.
Figure 3-1architecture beans
Ce qui suit sont les composants disponibles dans le
paquet beans qui peut être employé dans des applications ou des
applet de gestion.
Ø
SnmpTarget pour des opérations synchrones de SNMP.
Ø
SnmpRequestServer pour des opérations asynchrones de SNMP.
Ø
SnmpPoller pour des données de SNMP envoyer avec dans les
intervalles indiqués.
Ø
SnmpTrapReceiver pour recevoir des pièges.
Ø
NotificationAdaptor pour l'usage avec TrapReceiver.
Ø
SnmpTable pour travailler avec des données tabulaires de SNMP.
Pour ne citez que ceux là.
3.4 Présentation de
l'application
3.4.1 Environnement de
développement
Nous avons développez cette application dans la
plate forme Windows xp, et J2SE 5.0 a l'aide de l'Environnement de
développement intégré NETBEANS. Ce qui rend le
déploiement de l'application facile dans la plate forme Windows, mais
aussi sous d'autre plate forme par la portabilité de java pour toute
machine possédant Jvm
3.4.2 Explication du programme
Ce programme comporte une seule classe Snmps et
plusieurs méthodes, responsable de message de gestion circulant entre la
station de gestion et les agents snmp présent dans le réseau.
Avant de pouvoir utilisé le programme, il faut
d'abords configuré l'agent snmp du noeud que vous souhaitez manager. Si
vous utilisé Windows pour configuré l'agent suivez les
étapes suivant :
Installation du service SNMP :
Ø Ouvrez l'Assistant Composants de Windows : Cliquez
sur Démarrer, pointez sur Paramètres, cliquez sur Panneau de
configuration, double-cliquez sur Ajout/Suppression de programmes, puis cliquez
sur Ajouter/supprimer des composants Windows.
Ø Dans Composants, cliquez sur Outils de gestion et
d'analyse (sans activer ni désactiver la case à cocher
correspondante), puis cliquez sur Détails.
Ø Activez la case à cocher SNMP (Protocole
simplifié de gestion de réseau), puis cliquez sur OK.
Ø Cliquez sur Suivant. (SNMP démarre
automatiquement à la fin de l'installation)
Figure 3-2 installation snmp sous
windows
Configuration des propriétés de l'agent SNMP
:
Ø Ouvrez le Gestionnaire des Services
Ø Dans le volet des détails, cliquez sur Service
SNMP
Ø Dans le menu Action, cliquez sur
Propriétés.
Ø Sous l'onglet Agent, dans Contact, tapez le nom de
l'utilisateur ou de l'administrateur de cet ordinateur.
Ø Dans Emplacement, tapez l'emplacement physique de
l'ordinateur ou du contact.
Ø Sous Service, activez les cases à cocher
appropriées pour cet ordinateur, puis cliquez sur OK.
Gestion de la sécurité :
Ø Ouvrez le Gestionnaire des Services
Ø Dans le volet des détails, cliquez sur Service
SNMP
Ø Dans le menu Action, cliquez sur
Propriétés.
Ø Sous l'onglet Sécurité, activez Envoyer
une interruption d'authentification, si vous souhaitez qu'un message
d'interruption soit envoyé à chaque échec
d'authentification.
Ø Sous Noms de communautés acceptés,
cliquez sur Ajouter.
Ø Sous Droits de communauté, sélectionnez
un niveau d'autorisation pour permettre à l'hôte de traiter les
requêtes SNMP en provenance de la communauté choisie.
Ø Dans Nom de communauté, tapez un nom de
communauté en respectant la casse, puis cliquez sur Ajouter.
Ø Dans Propriétés de service SNMP,
indiquez si les paquets SNMP en provenance d'un hôte sont acceptés
ou non : Pour accepter les requêtes SNMP provenant d'un hôte
du réseau, quelle que soit son identité, cliquez sur Accepter les
paquets SNMP provenant de n'importe quel hôte. Pour limiter l'acceptation
de paquets SNMP, cliquez sur Accepter les paquets SNMP provenant de ces
hôtes, sur Ajouter, tapez le nom d'hôte, l'adresse IP ou IPX
appropriés, puis cliquez à nouveau sur Ajouter.
Figure 3-3 configurations de l'agent snmp sous
windows
Configuration de trap snmp :
Le programme Evntwin.exe de Microsoft fournit une
manière d'expédier tous les événements Windows
comme trapes SNMP. Cet outil graphique permet de créer facilement un
fichier de configuration utilisable avec la commande Evntcmd.exe. La
liste des événements à expédier comme trapes SNMP
est visible à partir d'Evntcmd.exe ou d'Evntwin.exe. Le convertisseur
des Events en trapes SNMP marche si l'agent SNMP agent est bien
configuré pour envoyer les trapes SNMP.
Les journaux des événements de
l'Observateur d'événements permettent de collecter des
informations sur les problèmes se rapportant au matériel, au
logiciel et au système, et de surveiller les événements de
sécurité Windows.
L'Evntwin.exe configure la traduction des
événements en trapes SNMP, destinations des Trapes SNMP, ou tous
les deux basés sur l'information dans le fichier de
configuration. Lancer la commande evntwin.exe depuis l'invité DOS
"cmd". Le travail se compose ensuite à trouver le nombre
d'événement que vous voulez expédier comme trapes SNMP.
Figure
3-4configuration de trap sous windows
Apres configuration du noeud que vous souhaitez
manager, lancer l'application. Après exécution une fenêtre
s'ouvre avec plusieurs onglets. Veuillez configurer d'abords les
paramètres pour authentification.
Figure
3-5 configuration de lan manager 1.0
Après cette configuration, procédez aux
différentes requêtes de votre choix. Requête GET, GET NEXT,
SET ainsi que le chargement, déchargement de différent mibs de
votre choix et la réception de trap.
Figure 3-6 consoles d'administration
3.5 CONCLUSION
Ce chapitre nous à permis de concrétisé
nos attente, nous avons ainsi parvenu a la mis au point de la dite module de
gestion en java. Le programme tourne malgré quelque bug qui y est encore
attaché, nous espérons le corriger dans l'avenir.
CONCLUSION GENERAL
Cet exercice nous a été profitable à ce
qu'il nous a permis d'élargir notre connaissance sur le protocole SNMP.
Grâce à elle, nous avons pu dégager l'étendu du
travail d'administration comme définie par l'ISO, cette charge que nous
avions qualifier de lourde vu les efforts que doivent conjuguais les
administrateurs réseau pour garder en étant de marche leurs
réseaux et d'intervenir au plus vite possible en cas de panne.
Nous avons aussi vu que le protocole SNMP a été
développé pour faciliter cette administration et qu'a l'aide des
requêtes SNMP simple (get, set ....) et la remontée d'informations
par trap SNMP, on pouvait maintenir son réseau.
C'est ainsi que nous nous sommes efforcé
d'implémenter une application de gestion de réseau exploitant le
protocole SNMP pour concrétiser ses informations. L'application tourne
malgré le bug qui est encore attaché, mais nous comptons
améliorer dans les jours avenir.
BIBLIOGRAPHIE
Ouvrages
[1]. DOUDOUX (Jean ), Développons en java, Février
2003
[2]. TAHE (Serge), Apprentissage du langage java, Juin 2002, pp
246-248
[3]. NAZIM AGOULMINE (Omar cherkaoui), Pratique de la gestion de
réseau, Groupe Eyrolles 2003, pp 2-22
Cours
[4]. KABEYA. D, Télématique, cours 3e Dép.
Math-Info, Univ. Kinsjasa 2007
[5]. KASSORO, Programmation Orienté Object, cours 3e
Dép. Math-Info, Univ. Kinsjasa 2007
Reference Web
[6].
http://www.adventnet.com
(consulté le mardi 20 novembre 2007, 23 :20 :20 :07)
| 
