administration des
TRANSCRIPT
Administration des
services réseauInstitut de sciences et technologies
Département Electronique
Master 1 TELECOMMUNICATION
Pr. A. BENMOSTEFA
E-mail: [email protected]
Prérequis:
Les bases des réseaux.
Protocoles de communication.
Modèle OSI.
Les éléments d’un réseau.
Etc…
Objectifs du cours
Acquérir les connaissances et les compétences nécessaires pour
l'exploitation, l'administration, la maintenance et la surveillance des réseaux
informatiques. L’étudiant se familiarisera avec des fonctions et des protocoles
qui doivent lui permettre de gérer entre autres les droits d'accès, le trafic des
données circulant sur le réseau, la sauvegarde des données, le bon
fonctionnement des services notamment les services annuaires, les services de
messagerie électronique et les services d’applications …etc
Contenu de la matière
Objectifs et rôle de l’administration
Modèle d’administration réseaux
Réseau clients serveurs
Les protocoles d’administration
Les services de la couche
d’application
Notions de ports de service
Chapitre 1. Présentation de
l’administration réseau
Contenu de la matière Service Syslog. Service SNMP :
Présentation et Historique du SNMP
Les principes, Configuration,
Avantages et Inconvénients
Chapitre 2. Le Service SNMP
(Simple Network Management
Protocol)
Contenu de la matière
Les différents services annuaires
Domain Name System (DNS)
Dynamic Host Configuration Protocol
(DHCP) et Gestion des adresses IP
avec DHCP
Lightweight Directory Access Protocol
(LDAP). Configuration.
Autres services annuaires
Chapitre 3. Les services
annuaires
Contenu de la matière
Introduction, Généralités sur les
services NIS (Network Information
System) et NFS (Network
File System)
Fonctionnement, Configuration NIS
Serveur NIS et client NIS
Fonctionnement du NFS,
Caractéristiques, Commandes
Chapitre 4. Gestion des
utilisateurs et service NFS
Contenu de la matière
Principes de base de la messagerie
électronique
Format des messages
Protocole SMTP. Installation
configuration et mise en service
Services FTP (File Transfert Protocol)
et Web. Définition, Fonctionnement,
Configuration
Chapitre 5. Service de
messagerie et services
d’application
Contenu de la matière
Introduction, Présentation, Architecture
(domaines, arborescence, forêts)
Gestion des utilisateurs, des groupes et
permissions
Sécurité
Gestion du domaine
Notions d’approbations entre domaines
Exemple d’un contrôleur de domaine
(active directory AD)
Chapitre 6. Contrôleur de
domaine
Chapitre 1
Présentation de l’administration réseau
1. Objectifs et rôle de l’administration
2. Modèle d’administration réseaux
3. Réseau clients serveurs
4. Les protocoles d’administration
5. Les services de la couche
d’application
6. Notions de ports de service
Besoin d’une administration des réseaux:
pourquoi?
Passage d’une administration de quelques ordinateurs (multi-utilisateurs) à
l’administration d’un réseau d’ordinateurs et d’équipements variés
(périphériques, commutateurs, ponts, routeurs …) provenant de différents
constructeurs et ayant différents systèmes d’exploitations).
De nouveaux services réseaux doivent être mis en place (supports pour le
développement d’application client serveurs, serveurs de noms, serveurs de
disques, serveurs de bases de données ...).
Définition de l’administration d’un réseauL’administration de réseaux informatique (ou Network management) se réfère
aux activités, méthodes, procédures comme la surveillance du réseau et aux outils
de mise en oeuvre par l'administrateur réseaux ayant trait à l'exploitation,
l'administration, la maintenance et la fourniture des réseaux informatiques. La
gestion des réseaux informatiques constitue un problème dont l’enjeu est de garantir
au meilleur coût, non seulement la qualité du service rendu aux utilisateurs mais
aussi la réactivité dû aux changements et à l'évolution rapide du secteur
informatique.
Cette gestion des réseaux se définit comme étant l’ensemble des moyens mis en
oeuvre (connaissances, techniques, méthodes, outils, ...) pour superviser, exploiter
des réseaux informatiques et planifier leur évolution en respectant les contraintes de
coût, de qualité et de matériel. La qualité de service se décline sur plusieurs critères
pour le futur utilisateur, notamment la disponibilité, la performance (temps de
réponse), la fiabilité, la sécurité… L’administration des réseaux est couramment
classée en trois activités :
o La Supervision
o l'Administration
o l'Exploitation
Les Rôles de l’administration d’un réseau
L’administrateur réseau est responsable de ce qui peut se passer dans un
réseau administré ; ainsi les rôles d’un administrateur réseau consiste à :
Mettre en place et maintenir l’infrastructure du réseau (organisation, ...) ;
Installer et maintenir les services nécessaires au fonctionnement du réseau;
Assurer la sécurité des données internes au réseau (particulièrement face
aux attaques extérieures) ;
S’assurer que les utilisateurs n’outrepassent pas leurs droits ;
Gérer les « logins » (i.e. noms d’utilisateurs, mot de passe, droits d’accès,
permissions particulières, ...) ;
Gérer les systèmes de fichiers partagés et les maintenir.
Niveaux de décision de l’ASR
Pour une bonne administration d’un réseau, un bon administrateur a
besoin différents niveaux de la prise des décisions d’administration :
les décisions opérationnelles : sont des décisions à court terme, concernant
l’administration du réseau au jour le jour et, la tenue de l’opération se fait à
temps réel sur le système ;
les décisions tactiques : sont des décisions à moyen terme et concernent
l’évolution du réseau et l’application du politique à long terme ;
les décisions stratégiques : sont des décisions à long terme concernant les
stratégies pour le futur en exprimant les nouveaux besoins et les désirs des
utilisateurs.
Ces trois principaux niveaux déterminent alors différents degrés de
l’administration des réseaux informatiques :
la prévoyance : anticiper l’avenir et préparer l’organisation à s’adapter aux
changements ;
l’organisation : construire une structure, définir les responsabilités ou
charges, sélectionner, entrainer les managers ;
les commandements : qui administre quoi?;
la coordination : mettre de l’harmonie, concilier les activités afin que les
fonctions travaillent dans le même sens, à la réalisation de mêmes objectifs;
le contrôle : vérifier si les objectifs sont réalisés conformément aux ordres
et aux principes.
Différents degrés de l’administration
Comparaison avec l’administration d’un système
d’exploitation
Notons que dans le cas d’un système d’exploitation multiutilisateurs,
comme Unix, la gestion du système et des utilisateurs est confié à un super-
utilisateur2 nommé « root » ou racine. Le rôle de l’administrateur (root) est :
configurer le noyau du système d’exploitation ;
sauvegarder les données et réparer les systèmes de fichiers ;
gérer les utilisateurs ;
installer de nouveaux logiciels ;
intégrer des nouveaux disques et de nouvelles partitions ;
configurer le processus de démarrage de Linux ou autre ;
configurer le réseau.
Les protocoles d’administration
Les protocoles d’administration
Chaque fournisseur de réseau propose des outils permettant de mettre en
place la gestion du réseau. De ce fait, si l’on dispose de plusieurs systèmes
hétérogènes, il est très difficile de faire coopérer les différents outils de gestion
de réseau de chaque système. Cependant L’échange d’informations entre
systèmes hétérogènes a été rendu possible par l’intermédiaire de la
normalisation de l’ISO. C’est ainsi que des protocoles d’administration ont vu le
jour. Les protocoles d’administration permettent à la plate-forme de gestion
d’aller chercher les informations sur les éléments de réseaux et aussi de changer
les paramètres sur ces derniers. De plus, ils permettent à la plate-forme de
gestion de recevoir des alertes provenant des éléments de réseaux.
Deux protocoles d’administration réseaux ont été normalisés par l’ISO : La
CMIP (Common Management Information Protocol) et le SNMP (Simple Network
Management Protocol).
Le protocole CMIPLe protocole CMIP est un protocole d’administration de réseau, qui
supporte l’échange d’informations entre l’application d’administration et les
agents. L’information d’administration échangée entre l’application et les agents
est faite par le biais d’objets CMIS (Common Management Information Service),
qui représentent l’entité à administrer. Ces objets peuvent être modifiés ou
contrôlés et ils peuvent être utilisés pour effectuer des tâches sur l’agent
administré.
Le protocole CMIP est un protocole assez utilisé dans le domaine des
télécommunications (RGT : Réseau de Gestion des Télécommunications).
Cependant, ce protocole consomme beaucoup de ressources sur le système
administré, ce qui fait que ce protocole n’est pas très largement diffusé. De
plus, le protocole CMIP est défini pour fonctionner sur la pile du protocole OSI.
Cependant, le standard utilisé de nos jours dans la majorité des environnements
de réseaux locaux est le protocole TCP/IP.
SNMP (Simple Network Management Protocol) est le protocole de
gestion de réseaux proposé par l’IETF (Internet Engineering Task Force). Il est
actuellement le protocole le plus utilisé pour la gestion des équipements de
réseaux. SNMP est un protocole relativement simple; toutefois l’ensemble de ses
fonctionnalités est suffisamment puissant pour permettre la gestion des réseaux
hétérogènes complexes. Il est utilisé aussi pour la gestion à distance des
applications: les bases de données, les serveurs, les logiciels, etc. L’usage du
protocole SNMP peut aussi dépasser largement le cadre de la gestion des
équipements de réseaux. L’environnement de gestion SNMP est constitué de
plusieurs composantes :
une station de gestion de réseau (NMS- Network Management
Stations),
des éléments de réseaux (NE, Network Elements),
des variables MIB
et d’un protocole.
Le protocole SNMP
Comparatif : SNMP/CMIP
Autres protocoles d’administration
Outils d’Administration locale d’un élément du réseauOn peut administrer (gérer ou configurer) un équipement du réseau de
deux façon:
1. Local.
2. A distance.
La gestion local se fait à travers des ports dédiés pour la configuration
local, par exemple le port le plus connu est le port console de
l’équipement, sur le quel l’administrateur raccordera un terminal écran-
clavier asynchrone ou un ordinateur de gestion contient un émulateur, est un
logiciel de gestion comme le HiperTerminal. Ainsi on trouve le port le moins
utilisé, le port Auxiliaire AUX dédié à la connexion d’un modem de
télémaintenance.
Le protocole Telnet
Le premier protocole historique est Telnet. Ce protocole TCP est largement
utilisé pour le contrôle à distance de matériel réseau. La conception est
excessivement simple : une fois que l’on est connecté à la machine distante, les
touches tapées au clavier sont directement transmises à la machine distante et
telnet nous renvoie les réponses de ladite machine. Généralement, la machine
distante commence la transaction par nous demander un mot de passe d’accès,
puis nous donne accès à un shell sur lequel nous pouvons lancer nos commandes.
Exemple d’une application Telnet sur un
routeur CISCOCi-dessus nous pouvons analyser l’exemple d’une session Telnet sur un
commutateur Cisco Catalyst : celui-ci nous réclame un mot de passe d’accès,
puis nous pouvons exécuter des commandes. Ici « show version » nous affiche la
version du système d’exploitation du matériel.
La session Telnet sur un commutateur 3Com Superstack commence de manière similaire à la session Cisco par l’entrée d’un mot de passe. Puis nous accédons à un menu de gestion : il faut alors choisir l’une de ces options pour naviguer à travers les différentes commandes possibles et effectuer des modifications sur le matériel.
Le protocole Telnet/SSHComme nous pouvons le constater, telnet n’est pas un protocole fournissant
une interface commune à tous les matériels réseau. Chaque constructeur inclut
son propre gestionnaire telnet personnalisé, et la gestion du réseau n’est donc
pas uniforme suivant le type de matériel. Telnet assure intrinsèquement la
fiabilité de la transaction de par l’utilisation du protocole TCP, toutefois la
communication entre l’administrateur et le matériel n’est pas cryptée et la seule
sécurité apportée est l’authentification initiale.
Le protocole SSH comble cette lacune en cryptant la transaction via le
protocole SSL. Il permet également d’effectuer des transferts de fichiers entre
les deux hôtes (protocole SCP). Toutefois l’interface reste propre à chaque
matériel et ne permet pas d’effectuer des transactions parallèles ou une gestion
uniforme de ceux-ci.
Interface de gestion basé WEB (ou basé
HTTP)
La gestion réseau par interface Web s’est développée durant ces dernières
années, car celle-ci fournit une interface plus intuitive et plus agréable à utiliser
que l’interface Telnet. Toutefois, à l’instar de Telnet, l’interface reste propre à
chaque matériel réseau et ne permet aucune homogénéisation de la gestion. La
figure suivante montre un exemple d’une page WEB de gestion.
De plus, la gestion peut vite s’avérer fastidieuse s’il y a un grand nombre de
noeuds au sein de notre réseau et qu’il soit nécessaire d’appliquer plusieurs
modifications sur chaque. Enfin, les serveurs Web consomment souvent un
important nombre de ressources sur le matériel, apportant un risque de baisse de
performances.
Vers le protocole SNMPLe protocole SNMP (Simple Network Management Protocol, ou autrement
dit « protocole de gestion réseau simplifié »), que nous allons étudier plus en
détails dans la partie suivante, a pour rôle exclusif la gestion réseau, et offre en
conséquence un grand nombre d’avantages que n’ont pas les autres protocoles.
SNMP propose une interface de transaction commune à tous les matériels, et
donc la plus homogène possible. Son utilisation reste peu importante suite à des
débuts difficiles, mais SNMP tend à devenir à terme l’une des références en
matière de gestion réseau. Voici un exemple d’une interface de gestion WEB.
Les domaines d’activités de L’ADMINISTRATION d’un réseau
Gestion des pannes:
Détection, localisation, isolation, réparation
Gestion des configurations:
Identification des ressources
Installation, initialisation, paramétrage, reconfiguration.
Collecte des informations utiles et sauvegarde d’un historique.
Audit des performances:
Evaluation: collecter les données et établir des statistiques sur les
performances (temps de réponse, taux d’utilisation, débit, taux d’erreur,
disponibilité)
Gestion de trafic : satisfaire les besoins des users (à qui attribuer un grand
dédit…)
Les domaines d’activités (2)
Gestion de la comptabilité:
Gérer la charge des ressources pour empêcher toute surcharge (congestion).
Gérer le coût d’utilisation des ressources et les facturer
Gérer le quota d’exploitation de la ressources ( imprimante, disques…)
Gestion de la sécurité:
But: protéger les ressources du réseau et du système d’administration
Comment: Assurer les services de la sécurité (authentification,
confidentialité, intégrité, disponibilité et non répudiation). En utilisant par
exemple les moyens de cryptographie + logiciel de supervision + audit +
firewall + surveillance des journaux d’évènements.
Journal de sécurité
Journal système
Journal application
Les Modèles d’administration réseaux
selon ISO
Les Modèles d’administration réseaux selon ISO
L’ISO ne spécifie aucun système d’administration des réseaux informatiques
mais définit plutôt un cadre général avec le document ISO 7498-4 dénommé « OSI
Framework » ou « Cadre Architectural OSI » et un aperçu général des opérations
d’administration des systèmes avec le document ISO 1004 dénommé « OSI
System Management » ou « Système d’administration OSI ». Ces documents de
base décrivent trois modèles :
Le Modèle organisationnel ;
Le Modèle informationnel ;
Le Modèle fonctionnel.
Le modèle organisationnel
Le modèle organisationnel, aussi appelé modèle architectural (Managed
System and Agents (MSA) ou Système Administré et Agent) : c’est un modèle
qui organise l’administration OSI, définit la notion de systèmes administrés
(Agents) et définit la notion du système Administrant (DMAP : Distributed
Management Application Processus).Le modèle architectural définit trois types
d’activité :
La gestion du système (System Management) ;
La gestion de couche (Layer Management) ;
Les opérations de couche (Layer Operations).
La gestion du système
La gestion du système (SMAE : System Management Application Entity) met
en relation deux processus Manager et Agent. Le protocole standardisé de
niveau application CMIP « Common Management Information Protocol » est
utilisé. Le Manager envoie des messages de commandes à ses Agents; ceux-ci lui
retournent les résultats des opérations effectuées dans des messages de
réponses.
Modèle de Gestion Manager –Agent sans proxy
Dans ce modèle, l’Agent n’utilise pas les mêmes normes ou la même
syntaxe de communication que le Manager, une entité tierce appelée « Proxy-
Agent » permet d’adapter le protocole de l’Agent et de convertir ses données
au format du Manager. Le Proxy-Agent est situé soit au niveau de l’Agent, soit au
niveau du Manager.
Modèle de Gestion Manager –Agent avec l’agent Proxy
Les agents
Un agent est un programme exécuté sur un équipement que l’on veut
administrer et qui a accès directement aux parties matérielles et logicielles
de cet équipement. Il est interrogé à distance et fournit les informations ou
exécute les instructions demandées avec une certaine possibilité de
raisonnement et de communication.
Système d’administration NMS à base des agents
NMS : « Network Management System »
composé d’éléments incrémental matériel et logiciel
Il doit permettre une vision unifiée et globale du réseau
NME « Network Management Entity »
extraction et collecte des statistiques relatives aux activités réseau
stockage des informations dans une base de données locale
réponse aux requêtes provenant d’un hôte de contrôle du réseau
transmettre les statistiques
transmettre la valeur de certains paramètres de fonctionnement
changer la valeur d ’un paramètre
générer un trafic artificiel pour effectuer certain test
générer des notifications sous certaines conditions
Exemple d’architecture d’administration NMS à
base des agents
Cette figure montre que chaque
élément du réseau (serveur, switch,
routeur où ordinateur
d’administrateur) contient:
Le système d’exploitation OS.
Le module réseau pour la connexion
au réseau comm.
Les équipements réseaux gérés
(administrés) contiennent les agents
ou NME, et les équipements
administrateurs contiennent
l’application NMA.
La gestion de couche
La gestion de couche (ou protocole de couche),fournit les moyens de
transfert des informations de gestion entre les sites administrés. C’est un
dialogue horizontal (CMIP, Common Management Information Protocol, ISO
9596). Les opérations de couche (N), ou protocole de couche (N) supervisent une
connexion de niveau N. Ces opérations utilisent les protocoles OSI classiques pour
le transfert d’information. C’est par exemple : Le CMIP utilise les primitives de
service suivantes (CMISE : Common Management Information Service Element) :
Get :il est utilisé par le gérant pour lire la valeur d’un attribut ;
Set : fixe la valeur d’un attribut ;
Event : permet à un agent de signaler un événement ;
Create : génère un nouvel objet ;
Delete : permet à l’agent de supprimer un objet.
Opérations de couches
Elles concernent les mécanismes mis en oeuvre pour administrer l’unique
instance d’une communication entre 2 entités homologues. Les opérations de
couche N (protocole de Couche N) supervisent une connexion de niveau N en
utilisant un certain nombre de primitive de service. Il s’agit d’un dialogue
Vertical assuré par le CMIS (Common Management Information Service).
Le modèle informationnel
Un modèle informationnel aussi appelé «Management Information Base
(MIB)» ou « Base de l’Information d’Administration» est un modèle qui
constitue la base de données des informations d’administration en énumérant
les objets administrés et les informations s’y rapportant (attributs). L’ensemble
des objets gérés constitue la MIB (ISO 10165).
La MIB contient toutes les informations administratives sur les objets
gérés (ponts, routeurs, cartes,…). La norme ne spécifie aucune organisation
particulière des données ; Seul le processus agent a accès à la MIB et le
processus manager accède aux données via le processus agent.
Le modèle fonctionnel
L’OSI a regroupé les activités d’administration en cinq groupes
fonctionnels «Specific Management Function Area (SMFA) » ou « Aire de Fonction
d’Administration Spécifique »:
Gestion de configuration ;
Gestion de performance ;
Gestion de panne ;
Gestion de comptabilité ;
Gestion de sécurité.
Modèle fonctionnel d’administration selon ISO
La gestion des anomalies ou de panne (Fault
Management) :
elle a pour objectif de faire le diagnostic rapide de toute défaillance interne
ou externe du système (par exemple la panne d’un routeur). Ces pannes peuvent
être d’origine interne résultant d’un élément en panne ou d’origine externe
dépendant de l’environnement du système (coupure d’un lien publique).Cette
gestion implique :
La surveillance des alarmes (filtre, report, …) ; il s’agit de surveiller le
système et de détecter les défauts. On établit un taux d’erreurs et un seuil à
ne pas dépasser.
Le traitement des anomalies ;
La localisation et le diagnostic des incidents (séquences de tests) la
journalistique des problèmes, etc.
La gestion de la configuration (Configuration
Management) :
elle a pour objectif d’identifier de manière unique chaque objet administré
par un nom ou un identificateur d’objet (OID : Object Identifier). Il s’agit
également de :
gérer la configuration matérielle et logicielle et ;
préciser la localisation géographique.
La gestion des performances (Performance
Management) :
elle a pour objectif de contrôler, à évaluer la performance et l’efficacité des
ressources comme le temps de réponse, le débit, le taux d’erreur par bit, la
disponibilité (aptitude à écouler du trafic et à répondre aux besoins de
communication pour lequel la ressource a été mise en service). Elle comprend :
la collecte d’informations, statistiques (mesure du trafic, temps de réponse,
taux d’erreurs, etc.), le stockage et l’interprétation des mesures (archivage
des informations statistiques dans la MIB, calculs de charge du système,
tenue et examen des journaux chronologiques de l’état du système).
Elle est réalisée à l’aide d’outil de modélisation et simulation permettant
d’évaluer l’impact d’une modification de l’un des paramètres du système.
La gestion de la sécurité (Security Management)
Elle couvre tous les domaines de la sécurité afin d’assurer l’intégrité des informations traitées et des objets administrés.
L’ISO a défini cinq services de sécurité :
Les contrôles d’accès au réseau ;
La confidentialité (les données ne sont communiquées qu’aux personnes, ou processus autorisés) ;
L’intégrité (les données n’ont pas été accidentellement ou volontairement modifiées ou détruites) ;
L’authentification (l’entité participant à la communication est bien celle déclarée) ;
La non-répudiation (impossibilité pour une entité de nier d’avoir participé à une transaction).
Pour cela l’ISO utilise les mécanismes d’encryptage, l’authentification des extrémités (source et destinataire) et le contrôle des accès aux données. Notons également que c’est au niveau de la gestion de sécurité que l’on trouve la notion de configuration du serveur AAA3 (Authentification – Authorization –Accounting).
La gestion de la comptabilité (Accounting
Management)
elle permet de connaitre les charges des objets gérés, les coûts de la
consommation… cette évaluation est établie en fonction du volume et la durée
des transmissions. La gestion de la comptabilité comporte les taches suivantes :
la consommation réseau par abonné ;
la définition des centres de coût ;
la mesure des dépenses de structure (coûts fixes) et répartitions ;
la mesure des consommations par services ;
l’imputation des coûts.
Résumes des modèles d’administration d’un réseau
Plateforme du supervision d’un réseau
Plateforme du supervision d’un réseauLa plate forme d’administration communément appelée station
d’administration (Manager), est l’outil de supervision de l’ensemble de réseau,
elle centralise toutes les informations issues du réseau et permet d’agir sur les
différents composants concentrateur, routeurs, etc.
Son rôle est :
de dialoguer avec les équipements réseaux (interrogation et collecte des
données) ;
de recevoir et de traiter les événements en provenance des équipements
réseaux ;
d’afficher graphiquement les objets du réseau ;
de collecter des données et de les enregistrer dans des fichiers ;
de découvrir la topologie du réseau ;
de séquencer l’ensemble de ces tâches et les faire communiquer entre elles.
Exemple d’un système de supervision d’un
élément de réseau à base de SNMP
Exemple d’un système de supervision d’un
élément de réseau à base de SNMP (2)
Exemple d’un système de supervision d’un
élément de réseau à base de SNMP
En général, dans les plus parts des réseaux (surtous les grands réseaux WAN),
ou un réseau LAN professionnel, ou dans un réseau INTRANET, la partie
administration contient une plateforme du supervision, qui est un logiciel utilise
le protocole SNMP installé dans un ordinateur client de l’administrateur utilisé
soit pour la notification des alarmes et évènements en temps réels de ses
équipements de son réseau, soit pour la configuration à distance, soit pour
consultation seulement et inventaires, etc… comme indique la figure,
Exemple d’une application de la
supervision d’un élément du réseau
Exemple d’une application de la
supervision d’un élément du réseau
Cette figure montre un exemple d’un logiciel de supervision basé SNMP,
qui permet à l’administrateur de collecter avec le protocole SNMP l’ensemble
des paramètres des équipements de son réseau, qui permettent le logiciel de
modéliser les équipements et les donner des images très proches du réel, et les
afficher sur son ordinateur des supervision, et comme ça l’administrateur aura
un vision sur tous les équipements juste sur son ordinateur du son bureau de la
supervision, et très facile à utiliser.
Exemple d’un logiciel
CACTI de mesure du
performance d’un
équipement du réseau
Les services de la couche application
où des réseaux
le rôle de la couche application
Dans le contexte du modèle de référence OSI, la couche application
(couche 7) supporte la composante de communication d'une application. La
couche application identifie et détermine la disponibilité des partenaires de
communication voulus, synchronise les applications coopératives et établit une
entente sur les procédures de reprise sur incident et de contrôle de l'intégrité
des données. La couche application est la couche OSI la plus proche du système
d'extrémité et elle détermine si les ressources nécessaires à la communication
entre systèmes existent. Ainsi, sans la couche application, il n'y aurait aucun
support des communications réseau.
le rôle de la couche application (2)
La couche application n'offre aucun service aux autres couches OSI.
Toutefois, elle fournit des services aux processus d'application qui sont audelà de
la portée du modèle OSI. Ces processus d'application incluent notamment les
tableurs, les logiciels de traitement de texte et les logiciels de terminaux
bancaires. De plus, la couche application assure une interface directe pour le
reste du modèle OSI par l'entremise d'applications réseau (comme le Web, le
courrier électronique, le protocole FTP et Telnet) ou une interface indirecte par
l'entremise d'applications autonomes (comme les logiciels de traitement de
texte, les tableurs, les gestionnaires de présentation et les logiciels de
redirection réseau).
Services de la couche Application
La couche application offre différents services
(messagerie, transfert de fichier, émulation de
terminal, annuaire, supervision, …). Ces services sont
normalisés et sont accessibles par des interfaces
normalisées dénommées AE (Application Entity),
équivalent des API (Application Programming Interface).
A l’inverse de la couche Présentation qui n’a pas
d’équivalant en TCP-IP, on peut trouver dans
l’architecture TCP-IP un bon équivalent de couche 7.
Vous avez tous entendu parler de FTP, Telnet ou
encore SNMP ? Le premier est un protocole de transfert
de fichiers, le second un protocole d’émulation de
terminal virtuel en mode caractère et le dernier un
protocole de supervision. Ces protocoles rendent des
services aux applications IP qui les utilisent
(typiquement votre Netscape ou Internet Explorer !).
L’association de processus
Nous avons vu précédemment qu’une application voulant utiliser des services
de couche 7, doit s’interfacer avec un AE (Application element), équivalent à
une API. Lorsque cette application atteint l’élément de couche 7 désiré (par
exemple FTAM), elle est généralement mise en relation avec un élément
équivalent à l’autre bout de la chaîne de transmission. Il est alors nécessaire
d’opérer une synchronisation des processus, et de gérer la mise en relation des
services ne serait-ce que pour pouvoir différencier des connexions FTAM (ou
autres) distinctes et simultanées entre mêmes applications !
Cette fonction est assurée par un module dénommé ACSE (Association Control
Service Element) normalisé ISO 8649 pour le service et 8650 pour le protocole ou
X217/227 à l’IUT-T. Il permet d’offrir les fonctions de base nécessaires pour
mettre en relation deux processus et pour contrôler leur association.
Quelques Services et protocoles de gestion
de la couche application du modèle OSIVoici quelques exemples des services et protocoles de gestion de la couche
application du modèle OSI:
RTSE (ISO 9066) est un protocole de transfert de fichiers.
FTAM (File Transfer Access and Management) est une application de
transfert de fichier fiable référencée sous la norme ISO 8571
CMIP (Common Management Information Protocol) est un protocole de
supervision de réseau au même titre que SNMP d’IP. est décrit dans la norme
ISO 9596
CMISE (Common Management Information Service) défini le service requis
pour la supervision.
Les services de la couche application du modèles
TCP/IP
Le tableau suivant résume les différents services d’un réseau TCP/IP, tel
que chaque service correspond à un protocole d’application, aussi chaque
service correspond à un numéro (où des numéros) de port, selon la couche
transport TCP/UDP.
Service courrier électronique protocole SMTP port POP/25.
Service WEB protocole HTTP port 80.
Service transfert des fichiers protocole FTP port 20 et 21.
Service Emulation terminal protocole Telnet port 25.
Service WEB protocole HTTP port 80.
Service des annuaires DNS protocole DNS port 53.
Service gestion du réseau protocole SNMP port 161 et 162.
Le modèle client/serveur
Modèle client/serveur
La plupart des applications exécutées au sein
d'un environnement réseau sont classées comme
des applications clientserveur. Ces applications,
comme le protocole FTP, les navigateurs Web et le
courrier électronique, sont dotées de deux
composantes qui leur permettent d'assumer deux
rôles : client et serveur. Le côté client est
l'ordinateur local et le demandeur de service. Le
côté serveur est un ordinateur distant qui fournit
des services en réponse aux demandes du client.
Modèle client/serveur (2)
Une application clientserveur répète constamment la routine en boucle qui
suit : demande du client, réponse du serveur; demande du client, réponse du
serveur; etc. Par exemple, un navigateur Web accède à une page Web en
demandant une adresse URL ou adresse Web sur un serveur Web distant. Après
recherche de l'adresse URL, le serveur Web désigné par cette adresse URL répond
à la demande. Ensuite, en fonction de l'information reçue du serveur Web, le
client peut demander des données supplémentaires du même serveur Web ou il
peut accéder à une autre page Web sur un serveur Web différent.
Aussi pour le protocole de l’administration SNMP il y a toujours dans une
communication SNMP un client et un serveur, le client est l’administrateur
(NMA), et l’équipement géré joue le rôle du serveur, parceque c’est lui répond
l’administrateur par les informations qu’il veut.
L’essentiel, dans tous les applications (services), le demandeur du service
joue le rôle du client,( client DHCP, client DNS, client SNMP, client FTP, client
HTTP, etc…), et le répondeur du service est le serveur.
la figure suivante montre un exemple d’un système client/serveur SNMP.
L’architecture CLIENT/SERVEUR, EXEMPLE
DU PROTOCOLE SNMP
Dans cette figure, on a le nouveau terme MIB, présente la base de
données des informations des agents des équipements gérés (serveurs),
qu’on va la détailler dans le chapitre suivant.
L’architecture CLIENT/SERVEUR,
EXEMPLE DU PROTOCOLE SNMP (3)
L’architecture CLIENT/SERVEUR, EXEMPLE
DU PROTOCOLE SNMP (2)
Comme remarque, il faut distinguer entre un serveur d’une application
SNMP, et l’équipement serveur d’un service du réseau, ne sont pas les
mêmes!!!, un serveur par exemple HTTP ou FTP ou DNS ou DHCP peut être
interrogé par une requête SNMP très normal.
Dans la suite…
Etude détaillée du protocole d’administration et de supervision SNMP.
Etude détaillée des différents protocoles des services réseau les plus
importants, et leurs administration, qui sont:
Protocole DHCP, et mise en œuvre (serveur/client DHCP).
Protocole DNS, et mise en œuvre (serveur/client DNS)
Protocole SMTP, et mise en œuvre (serveur/client SMTP)
Protocole FTP, et mise en œuvre (serveur/client FTP)
Protocole HTTP, et mise en œuvre (serveur/client HTTP)
Contenu de la matière Service Syslog. Service SNMP :
Présentation et Historique du SNMP
Les principes, Configuration,
Avantages et Inconvénients
Chapitre 2. Le Service SNMP
(Simple Network Management
Protocol)
SNMP : Motivation
Nécessité d ’avoir un protocole permettant de remonter des
informations sur l ’activité des différentes ressources du
réseau (les serveurs, les routeurs, les commutateurs, etc).et
Administrer à distance des machines indépendamment de
leur architecture
facile.
Sécurisé.
Basé sur le modèle internet TCP/IP.
Le plus utilisé modialement.
A des versions récentes.
Sécurisé.
Répond au modèles d’administration de l’ISO.
SNMP permet la supervision, le contrôle et la modification
des paramètres des éléments du réseau.
Historique
La première version de SNMP, SNMPv1, a été conçue à la fin des années 80 et
standardisée dans le courant de l’année 1990. Sa conception permettait de gérer
la plupart des contraintes que nous avons définies dans la partie précédente,
mais un certain nombre de lacunes persistaient : manque de hiérarchie, peu de
codes d’erreur et de notifications, faibles performances, sécurité laxiste, etc…
L’ensemble de ces problèmes a entraîné le développement d’une nouvelle
version de SNMP, nommée SNMPv2, et dont la conception a commencé en 1993.
Toutefois, plusieurs éditeurs ont rejeté les standards proposés, conduisant à la
création d’autres normes :
SNMPv2p (historique): Beaucoup de travaux ont é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. Cette version est décrite dans les
RFC 1441, RFC 1445, RFC 1446, RFC 1448 et RFC 1449.
SNMPv2c (expérimental): Cette version du protocole est appelée «
community string based 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. Cette version est définie dans les RFC
1901, RFC 1905 et RFC 1906.
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. Cette
version est décrite dans les RFC 1905, RFC 1906, RFC 1909 et RFC 1910.
SNMPv2* (expérimental): Cette version combine les meilleures parties de
SNMPv2p et SNMPv2u, mais les documents qui décrivent cette version n’ont
jamais été publiés.
La version la plus utilisée de SNMP est actuellement SNMPv2c, mais la
tendance s’inverse avec l’introduction en 1997 de la troisième version du
protocole : SNMPv3. Cette version ajoute à la précédente une sécurité plus
importante, ainsi qu’une gestion hiérarchisée, mais sa complexité accrue
entraîne des difficultés d’implémentation et une charge de mise en oeuvre plus
délicate que sur les versions précédentes.
PrésentationSNMP est un protocole de la famille TCP/IP (Internet protocol), 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.
Principe de fonctionnementLe protocole SNMP se base sur le fait qu’il existe une station de gestion
réseau, le manageur, dont le rôle est de contrôler le réseau et de communiquer
via ce protocole avec un agent. L’agent est de manière générale une interface
SNMP embarquée sur le matériel destiné à être administré à distance.
SNMP - éléments principauxcette figure montre les éléments principaux pour la mise en œuvre d’une
administration par SNMP, qui sont:
Système de management NMS. (coté administrateur)
Les équipements gérés contiennent des programmes agent ou agent mandataire
(proxy) pour le cas d’un équipement qui n’utilise pas la même version du SNMP.
Agent mandataire (Proxy)
Cette figure décrit le principe de fonctionnement d’un agent proxy qui fait
la traduction des messages SNMP d’un langage d’une version SNMP vers un autre.
Plan ArchitecturalLa figure suivante montre le plan architecturel du protocole SNMP, qu’il
utilise le UDP pour le transport et la base de donnée MIB des équipements gérés.
La MIB (Management Information Base):
Définitions 1 ressource à gérer = 1 objet
Les objets administrables sont une abstraction des ressources physiques
(interfaces, équipements, etc.) et logiques (connexion TCP, paquets IP, etc.)
MIB : collection structurée d’objets reconnus par les agents
Chaque noeud dans le système doit maintenir une MIB qui reflète l’état des
ressources gérées
Une entité d'administration peut accéder aux ressources du noeud en lisant
les valeurs de l'objet ou en les modifiant
MIB: 2 objectifs
- Un schéma commun : SMI (Structure of Management Information)
- Une définition commune des objets et de leur structure
Le protocole SNMP est constitué de plusieurs commandes différentes :
Get : Cette commande, envoyée par le manageur à l’agent, a pour objectif
de demander une information à l’agent. Celui-ci, dans le cas où la validité de
la requête est confirmée, renvoie au manageur la valeur correspondant à
l’information demandée.
Getnext : Cette commande, envoyée par le manageur à l’agent, a pour
objectif de demander l’information suivante à l’agent : il arrive qu’il soit
nécessaire de parcourir toute une liste de variables de l’agent. On utilise
alors cette commande, à la suite d’une requête ‘get’, afin d’obtenir
directement le contenu de la variable suivante.
Getbulk : Cette commande, est envoyée par la manageur à l’agent pour
connaître la valeur de plusieurs variables : cela évite d’effectuer plusieurs
requêtes Get en série, améliorant les performances (implémenté dans
SNMPv2).
Set : Cette commande, envoyée par le manageur à l’agent, a pour objectif de
définir la valeur d’une variable de l’agent administré. Cela permet
d’effectuer des modifications sur le matériel.
Trap : Lorsqu’un événement particulier survient chez l’agent (connexion,
modification de la valeur d’une variable donnée, etc…), celui-ci est
susceptible d’envoyer ce que l’on appelle une « trap », à savoir un message
d’information destiné à la station d’administration : celle-ci pourra alors la
traiter et éventuellement agir en conséquence. S’il s’agit par exemple de la
coupure d’un lien réseau, cela permet à l’administrateur réseau d’en être
immédiatement informé.
Inform : Dans certains cas, il peut être intéressant pour l’agent d’obtenir une
réponse à une Trap qu’il a émise, afin d’obtenir confirmation que celle-ci a
bien été reçue et analysée : c’est l’objectif d’une commande « inform ».
(Implémenté dans SNMPv2).
Résumé des commandes SNMPv2
Identificateur d ’un objet de la MIB
Est un identificateur unique séquence d ’entiers dont chacun représente
la position de ces successeurs dans l ’arbre.
Exemple: identificateur de l ’objet MIB :
Les variables SNMP et le modèle SMI
L’objectif de SNMP est donc d’obtenir ou de modifier la valeur d’une ou
plusieurs variables du matériel : Il peut s’agir par exemple de l’état d’une
interface réseau (allumé/éteint). Les variables SNMP exploitent le modèle SMI
(Structure of Management Information) qui définit un modèle hiérarchique des
variables. Le modèle est défini dans les RFC1155 et 2578.
Dans ce modèle, les variables sont répertoriées dans une hiérarchie
d’objets. Chaqueobjet est identifié par ce que l’on appelle un OID (Object
IDentifier). La hiérarchie de ces objets se représente sous la forme d’un arbre.
Les branches constituent les différents OIDs et les feuilles les variables. Une
variable peut donc être référencée par la liste ordonnée des différents OIDs
parcourus à partir de la racine de l’arbre.
Le modèle SMI définit également les types de données utilisables pour les
variables : entier, réel, durée, compteur, etc…
Un ensemble d’objets d’un même module est appelé une MIB (Module
Information Bases). Il s’agit d’une base de données référençant la liste des
objets et des variables associées, des types de données utilisés pour chaque
variable et d’un descriptif de cette variable. La base contient éventuellement
des types de données personnalisés.
l’arborescence des OIDs
La figure présente l’arborescence des OIDs, constituant les MIBs. En SNMP, on
utilise communément deux branches :
iso.org.dod.internet.mngt.mib-2 (1.3.6.1.2.1) : il s’agit de la branche
contenant tous les objets standards, définis précisément dans les RFC. Ainsi,
tout agent SNMP doit pouvoir reconnaître cette branche et les variables qui y
sont définies.
iso.org.dod.internet.private.enterprises (1.3.6.1.4.1) : cette branche est
l’origine de tous les objets propres au matériel et définies par le
constructeur. Ainsi, chaque constructeur se voit attribué un identifiant
(VendorID), qui lui fournit un espace de données au sein de l’arbre des MIBs.
Si nous prenons l’exemple de Cisco, dont l’identifiant est 9, toutes les
variables propres à Cisco ont une clé débutant par 1.3.6.1.4.1.9.
Le groupe MIB-2
ce groupe MIB-2 est constitué des objets suivant:
Le groupe MIB-2
Groupe nbre éléments commentaire
system 7 noeud dans le réseau
interfaces 25 interfaces réseau
At 5 IP address translation
ip 65 Internet Protocol
Icmp 26 Internet Control Message Protocol
Tcp 21 Transmission Control Protocol
udp 8 User Datagram Protocol
Egp 22 Exterior Gateway Protocol
Transmission 114 informations sur la transmission
Snmp 28 SNMP
rmon 218 Remote network monitoring
Les fichiers MIBs décrivant les objets
Les fichiers MIBs décrivent précisément chaque chiffre (OID) de la liste
identifiant une variable (la clé), et sa signification. Prenons l’exemple simple de
la variable contenant le nom du matériel interrogé. Il s’agit d’une propriété de
l’objet standard « system » que nous pouvons voir dans l’arborescence de la
figure précédente. La propriété s’appelle « sysName ». On en déduit que la
variable s’appelle alors : iso.org.dod.internet.mngt.mib-2.system.sysName.
Analysons le fichier MIB décrivant l’objet « system » (RFC 1213) :
La structure numérique de la MIB-2
system 1.3.6.1.2.1.1
interfaces 1.3.6.1.2.1.2
at 1.3.6.1.2.1.3
ip 1.3.6.1.2.1.4
icmp 1.3.6.1.2.1.5
tcp 1.3.6.1.2.1.6
udp 1.3.6.1.2.1.7
egp 1.3.6.1.2.1.8
rmon 1.3.6.1.2.1.9
transmission 1.3.6.1.2.1.10
snmp 1.3.6.1.2.1.11
Le fichier fournit toutes les informations relatives à la propriété «sysName» :
Syntaxe : il s’agit d’une chaîne de caractères de taille variant entre 0 et
255.
Accès : l’accès à cette variable se fait en lecture ou en écriture
Etat : cette variable existe et est toujours utilisable.
Description : il s’agit du nom complet du noeud.
Sa place dans l’arborescence : 5ieme propriété de l’objet « system » : On en
déduit que cette variable a pour clé la valeur 1.3.6.1.2.1.1.5.
Le groupe « System »System : correspond au nom de l'agent, n° de version, type de la machine,
nom du système d'exploitation, etc.
Le groupe « Interface »
contient les objets suivants:
ifNumber : le nombre d’interfaces réseau
ifTable: Table qui contient une ligne par interface
ifIndex : Index de l ’interface (son numéro)
ifDescre : Description de l ’interface
ifType : le type de l ’interface (Ethernet, Token-
Ring,...)
ifMtu : le nombre maximum d ’octet que l ’interface
peut envoyer ou recevoir
ifSpped : Une estimation du débit de l ’interface
ifPhyAdress : l ’adresse physique de l ’interface
Le groupe « IP »
contient les objets suivants:
ipForwarding : Agit comme passerelle, ou non
ipDefault TTL : la valeur par défaut du TTL ajouté
dans un paquet IP
ipInReceives : Le nombre total de paquets IP reçus
IpInHdrErrors : Le nombre total de paquets écartés
dus à une erreur sur l ’en-tête
IpInAddrErrors : Le nombre total de paquets écartés
dus à une erreur sur l ’adresse de destination
IpForwDatagrams : Le nombre total de paquets dont
l’entité réceptrice ne représente pas la destination
finale.
Les autres groupes
icmp : statistiques sur les paquets ICMP reçus, envoyés et erronés exemple:
compter le nombre total de messages icmp reçus, reçus par erreur ou non
envoyés
tcp : rend compte des connexions TCP en cours et leurs paramètres de type
nombre max de connexions simultanées permises, nombre d'ouvertures
actives, l'état de chaque connexion (écoute, time-wait,...).
udp : - 4 compteurs renseignent sur le nombre de datagramme UDP envoyés,
reçus, en erreur, ...
egp : gère le protocole egp (External gateway protocol) (routage des paquets
entre routeurs). On a le nbre de paquets entrants, sortants, en erreur, la
table des routeurs adjacents, des infos sur les routeurs...
snmp : requis pour chaque entité mettant en oeuvre le protocole SNMP.
Contient le nombre de messages SNMP entrants et sortants, le nombre de
mauvaises versions reçues ou de nom de communauté invalide, la répartition
du type de requêtes reçues et envoyées (get, get_next, set et trap)
Ainsi, nous avons la description de toutes les variables, leur méthode d’accès et
la clé que nous devons utiliser pour lire ou écrire sa valeur. La majorité des
constructeurs fournit des fichiers MIBs contenant des informations sur les variables
propres à leur matériel, ne faisant pas partie des informations standards.
Il existe un grand nombre d’outils permettant de visualiser l’arbre des MIBs et
de rechercher une variable au sein de celui-ci. L’exemple de la figure suivante est
tiré du site www.snmplink.org, est un explorateur de MIBs
La sécurité dans le protocole SNMPSous SNMPv1 et SNMPv2c, la sécurité est assurée par deux choses :
Dans sa requête, il faut envoyer une chaîne de communauté, qui correspond
en quelque sorte à un mot de passe, et dont les droits varient suivant cette
chaîne : il est ainsi possible d’autoriser certaines personnes un accès en
lecture seule, et à d’autres personnes un accès complet suivant la
communauté qu’ils utilisent.
L’agent peut vérifier et contrôler l’origine des données, afin de vérifier que
la personne en question a accès aux informations. Il s’agit généralement
d’une vérification basée sur l’adresse IP source.
Nous constatons toutefois que la sécurité est particulièrement lacunaire
pour deux raisons : le contenu de la transaction n’est pas crypté, et il suffit que
la communauté soit connue de n’importe qui pour que cette personne puisse lire
les informations.
Ces différents problèmes ont été résolus dans SNMPv3. En effet, celui-ci
propose plusieurs modèles de sécurités différents :
Le premier modèle est dépourvu de sécurités et est comparable à
SNMPv1/v2c.
Le second modèle offre des capacités d’authentification par utilisateur, c’est-
à dire que chaque utilisateur dispose d’un mot de passe d’accès, ainsi que
d’une clé publique de cryptage permettant de sécuriser le contenu de la
transaction.
Le troisième modèle ajoute au précédent un niveau de cryptage
supplémentaire en utilisant le principe d’échange des clés privées : le
contenu des paquets est ainsi totalement crypté mais ce modèle n’est
applicable qu’en fonction des lois sur la cryptographie en vigueur.
Fonctionnement pratique du gestion SNMP
Lorsqu’une commande est expédiée à un agent, on attend de celui-ci une
réponse. Plusieurs cas peuvent se produire :
Aucune réponse (Temps d’attente dépassé)
Erreur dans la requête
La requête a réussi.
1ier cas: Aucune réponse
Plusieurs cas sont susceptibles de produire une absence de réponse de la
part du matériel interrogé :
SNMP est basé sur UDP et il peut arriver que les paquets n’arrivent pas à
destination. Dans ce cas, le temps d’attente de réponse finit par s’écouler et
il convient alors de réémettre la requête.
Suivant l’implémentation des agents et la version de SNMP utilisée, si
l’authentification échoue (mauvaise communauté, mot de passe incorrect),
l’agent peut ne pas répondre à la requête.
Le temps d’attente de réponse peut être paramétré dynamiquement et il est
possible que le temps défini soit trop court pour permettre à la réponse de
revenir.
Enfin, dans le pire des cas, il est possible qu’il n’y ait pas d’agent SNMP
disponible sur le matériel interrogé. Nous ne pouvons en conséquence avoir
de réponse à notre requête.
2ieme cas: ERREURPlusieurs cas sont susceptibles de conduire au renvoi d’une erreur :
Lorsqu’on l’on essaie d’écrire sur une variable en lecture seule
Lorsque l’on essaie de définir la valeur d’une variable avec un type de
données incorrect (si l’on essaie d’écrire une chaîne de caractères dans une
variable de type entier par exemple).
Lorsque la variable n’existe pas.
Lorsque la trame SNMP est incorrecte (corruption, longueur non valide…)
Lorsque l’authentification SNMPv3 a échoué.
3ieme cas: Réussite
Lorsque la requête à l’agent SNMP réussit, celui-ci nous envoie la valeur de
la variable à laquelle on a accédé (que ce soit en lecture ou en écriture).
Les implémentations existantes du
protocole SNMPIl existe des centaines d’implémentations différentes du protocole SNMP, de
par le fait qu’il s’agit d’un protocole parfaitement bien défini et qu’il est de plus en plus exploité au sein des réseaux. Chaque implémentation a ses propres avantages et inconvénients. Certaines ont pour but de fournir des applications de gestion SNMP, d’autres ont pour but de fournir des bibliothèques de fonctions (API) pour la gestion SNMP. Certaines fournissent les deux, comme la distribution net-snmp (www.net-snmp.org) du domaine libre. Celle-ci propose les applications de base pour débuter et utiliser efficacement SNMP.
On retrouve dans la plupart des distributions le même ensemble d’applications de base pour la gestion du matériel via SNMP. Il s’agit des applications suivantes :
Snmpget : Permet de lire une variable d’un agent SNMP
Snmpset : Permet de définir la valeur d’une variable d’un agent SNMP
Snmpwalk : Permet de parcourir une liste de variables d’un agent SNMP.
Snmptrap : Envoie une trap à un manageur
Snmpbulkget, Snmpbulkwalk : Identique à Snmpget et Snmpwalk mais en utilisant des requêtes de type Snmpbulk.
Snmpinform : Envoie une requête Inform à un manageur
Par ailleurs, la plupart des distributions Unix ainsi que les distributions
Microsoft® Windows Server fournissent un agent SNMP pour contrôler à distance
la station et obtenir des informations sur celles-ci. Enfin, la plupart des matériels
réseaux administrables d’aujourd’hui embarquent dans leur système
d’exploitation un agent SNMP pour gérer le matériel à distance.
Exemple de transaction SNMP
Procédons à l’analyse d’un matériel réseau classique, par exemple un
routeur. Cherchons à connaître son nom, son temps de fonctionnement et des
informations sur ses interfaces. Nous considérerons que la communauté d’accès
est « TdS » et que l’adresse de ce matériel est « 172.17.67.253 ».
Reprenons tout d’abord l’exemple présenté dans une partie précédente,
concernant le nom de l’hôte. Nous en avions conclu que la clé de la variable
était 1.3.6.1.2.1.1.5. Effectuons une requête de type GET sur ce matériel et sur
cette clé afin de voir s’il répond conformément à nos attentes :
La syntaxe de la commande est très simple : on appelle snmpget en
définissant le nom de la communauté (-c TdS). On lui fournit l’adresse IP du
matériel à interroger ainsi que la clé que l’on cherche à obtenir. La commande a
réussi et l’agent nous a renvoyé la valeur « routerexemple ». Le nom de ce
système est donc « router-exemple ».
Nous pouvons constater que le principe de sécurité basé sur la communauté
est opérationnel. Essayons d’interroger l’agent en utilisant un nom de
communauté différent, par exemple « test » :
Snmpget nous signale alors qu’il n’a pas eu de réponse : la sécurité
fonctionne. De même, si l’on essaye d’accéder à une variable inexistante,
l’agent renvoie une erreur :
L’agent renvoie une erreur similaire lorsque l’on interroge une branche et
non une feuille de l’arbre des OIDs. Essayons une requête snmpget sur l’objet «
system » lui-même :
Il est nécessaire, pour parcourir toute la branche, d’effectuer une requête
de type « walk », qui constitue en fait une série de requêtes get et get-next. On
obtient ainsi la liste de toutes les variables de la branche :
On obtient ainsi un ensemble d’informations relatives au système : sa
description, le temps depuis quand il fonctionne, l’endroit où il se trouve, la
personne qui s’en occupe, etc… Il faut bien sûr que ces paramètres aient été
précédemment définis dans la configuration de l’agent.
Nous pouvons également modifier les informations directement depuis notre
console, par l’utilisation de commandes SET. Essayons par exemple de modifier la
description de l’endroit où le matériel se trouve (system.sysLocation,
.1.3.6.1.2.1.1.6). Cela se fait par le biais de la commande snmpset. Il est
également nécessaire de lui fournir le type de données utilisé (ici « s » pour «
string, chaîne de caractères ») :
Nous pouvons vérifier que la commande a bien été prise en compte :
La MIB standard fournit des informations sur l’état des interfaces réseaux du
matériel interrogé. L’OID « set iso.org.dod.internet.mgmt.mib-
2.interfaces.ifNumber » nous permet tout d’abord de connaître le nombre
d’interfaces :
Les interfaces sont alors regroupées dans un tableau « .interfaces.ifTable »
contenant la liste des propriétés de chaque interface. Si nous désirons par
exemple connaître le type des interfaces, il nous faudra interroger l’OID «
interfaces.ifTable.ifEntry.ifType » :
On constate que l’agent a ajouté à l’OID le numéro de l’interface : nous
avions vu qu’il y en avait 4, aussi le tableau est indexé de 1 à 4. Nous constatons
que les interfaces n°1 et n°2 sont de types « ethernet », alors que celle de type
n°3 est de type « pppSerial ». Enfin la 4e interface est de type inconnue (ou de
type défini par le constructeur).
Nous pouvons connaître l’état de chacune des interfaces en interrogeant la
propriété ifOperStatus (état courant de l’interface, ix=8) de l’objet ifEntry :
Le programme nous apprend ainsi que les interfaces n°1, 2 et 4 sont actives,
mais que l’interface n°3 est inactive. Il nous serait possible, compte tenu de ces
informations, de désactiver l’une des 3 interfaces actives en définissant la valeur
via une commande de type set.
Il existe plusieurs centaines de milliers d’informations récupérables via
SNMP, en raison de la quantité impressionnante du nombre d’objets. De plus,
ceux-ci sont en constante évolution, aussi ce nombre ne cesse d’augmenter,
chaque constructeur ajoutant ses propres spécificités.
Nommage des Managed Objects
Nommage d’un MO de type scalaire se fait Par concaténation des identificateurs de la
racine à l’objet et en rajoutant un 0 à la fin.
Exemples:
.1.1.0 ⇒ 134.21.1.15
.1.2.1.0 ⇒ “server-1“
.1.2.0 ⇒ ERREUR
Alternative (symbolique): .MY-MIB.info.uptime ⇒12345
Nommage des Managed Objects (2)
Nommage des entrées d’une table:
Au lieu du 0 final, les valeurs des
variable(s) qui forment l’index de
la table sont rajoutées.
Une table est accédée
séquentiellement, valeur par
valeur et non pas dans son
ensemble.
Exemple:
1.3.2.5 ⇒ 2
1.3.1.7 ⇒ 7
Indexation d’une table
Exemple:
OID de la Table = 1.3
1.3.1.5 => 5
1.3.2.5 => 2
1.3.1.1 => Entrée inexistante
1.3.1.9 => 9
1.3.2.1 => Entrée inexistante
1.3.2.9 => 3
1.3.2.7 => 2
Indexation d’une table
Un index n’est pas nécessairement un
entier : Ici l’index est une adresse IP
EXEMPLES: OID de la Table = 1.3
1.3.1.130.89.16.23 => 130.89.16.23
1.3.2.130.89.16.23 => 130.89.16.1
1.3.1.193.22.11.97 => 193.22.11.97
1.3.2.193.22.11.97 => 130.89.16.4
1.3.2.130.89.19.121 => 130.89.16.1
Indexation multiple d’une table
Un index n’est pas toujours unique et par la suite on aura besoin de définir
plus qu’un index pour s’assurer de l’unicité de la combinaison de ces index :
Dans le cas d’une table de routage un noeud peut être atteint par différents
chemins et par la suite l’indexation de la table sur la seule adresse IP destination
ne suffit plus.
Indexation multiple d’une table: Exemple
SMI
La SMI (Structure of Management Information) spécifie les règles de
définition des ‘Managed Objects’ (MO) qui sont:
Variables typées simples (scalaires); elles peuvent être organisées en tables à
2 dimensions au maximum
‘Basés objets’ mais pas orientées objets; les opérations offertes sont
uniquement la lecture et l’écriture
Spécifiés par un sous-ensemble de Abstract Syntax Notation 1 (ASN.1, Version
1988)
Ces règles sont valables quelque soit le protocole de gestion utilisé.
Un MO est défini par Type (Syntax), mode d‘accès (Access), état de
définition (Status), description et un Identificateur unique…
Utilisation de SMI
SMI (Structure of Management Information)
Constitue un moyen normalisé de représenter des informations de gestion :
Définition de la structure d’une MIB particulière
Définition de chacun des objets de la MIB (syntaxe et valeur)
Définitions formelles en A.S.N.1 (Abstact Syntax Not.1)
La structure des informations d ’Administration
(SMI)
Un objet peut agréger plusieurs objets :
object3 Object Identifier {object2 1}
object4 Object Identifier {object2 2}
object2 Object Identifier {object1 1}
Centre universitaire Nour El-Bachir, El Bayadh Année Universitaire:2019-2020
Institut des sciences Module ASR
Département de technologie M1 Telecom TD N_1_SNMP
1-Questions théoriques
1. Quel est l'intérêt d'avoir un arbre de référence qui soit unique ? 2. Tous les objets de l'arbre de référence doivent ils être implémentés dans une MIB? 3. Quels sont les éléments qui définissent un objet géré ? 4. Le type ASN.1 de la valeur d'un objet géré a-t-il un rapport avec la référence de l'objet ? 5. Arbres et MIB : grâce aux arbres donnés en annexe,
a. donner le nom des nœuds correspondant aux OID suivants i. 1.3.6.1.6 ii. 1.3.6.1.2.1.4.22.1.3
b. donner les OID des nœuds suivants :
i. ipAdEntBcastAddr
ii. CiscoIgrp
2-Analyse d’échanges SNMP
Quelle est l'information demandée par le manager au travers de la trame suivante ?
SNMP: len: 38 version: int(1) 0x00 comm: string(6) «public» type: GET-NEXT
req-id: int(2) 0x5e31 error: int(1) 0x00 error-index: int(1) 0x00
var: obj(8) 1 3 6 1 2 1 2 1 val: empty(0)
Quelle est la réponse transmise par l'agent ?
SNMP: len: 40 version: int(1) 0x00 comm: string(6) «public» type: RESPONSE
req-id: int(2) 0x5e31 error: int(1) 0x00 error-index: int(1) 0x00
var: obj(7) 1 3 6 1 2 1 2 1 0 val: 0x06
Même question pour cet échange :
SNMP: len: 178 version: int(1) 0x00 comm: string(6) «public» type: GET-NEXT
req-id: int(2) 0x00a2a2 error: int(1) 0x00 error-index: int(1) 0x00
var: obj(9) 1 3 6 1 2 1 2 2 1 1 val: empty(0)
var: obj(9) 1 3 6 1 2 1 2 2 1 2 val: empty(0)
var: obj(9) 1 3 6 1 2 1 2 2 1 3 val: empty(0)
var: obj(9) 1 3 6 1 2 1 2 2 1 4 val: empty(0)
var: obj(9) 1 3 6 1 2 1 2 2 1 5 val: empty(0)
var: obj(9) 1 3 6 1 2 1 2 2 1 6 val: empty(0)
var: obj(9) 1 3 6 1 2 1 2 2 1 7 val: empty(0)
var: obj(9) 1 3 6 1 2 1 2 2 1 8 val: empty(0)
var: obj(9) 1 3 6 1 2 1 2 2 1 9 val: empty(0)
var: obj(9) 1 3 6 1 2 1 2 2 1 10 val: empty(0)
SNMP: len: 219 version: int(1) 0x00 comm: string(6) «public» type: RESPONSE
req-id: int(2) 0x00a2a2 error: int(1) 0x00 error-index: int(1) 0x00
var: obj(10) 1 3 6 1 2 1 2 2 1 1 1 val: int(1) 0x01
var: obj(10) 1 3 6 1 2 1 2 2 1 2 1 val: string(9) «Ethernet0»
var: obj(10) 1 3 6 1 2 1 2 2 1 3 1 val: int(1) 0x06
var: obj(10) 1 3 6 1 2 1 2 2 1 4 1 val: int(2) 0x05dc
var: obj(10) 1 3 6 1 2 1 2 2 1 5 1 val: gauge(4) 0x00989680
var: obj(10) 1 3 6 1 2 1 2 2 1 6 1 val: string(6) ******
var: obj(10) 1 3 6 1 2 1 2 2 1 7 1 val: int(1) 0x01
var: obj(10) 1 3 6 1 2 1 2 2 1 8 1 val: int(1) 0x01
var: obj(10) 1 3 6 1 2 1 2 2 1 9 1 val: time(2) 0x0420
var: obj(10) 1 3 6 1 2 1 2 2 1 10 1 val: counter(4) 0x6b055aa0
Centre universitaire Nour El-Bachir, El Bayadh Année Universitaire:2019-2020
Institut des sciences Module ASR
Département de technologie M1 Telecom TD N_1_SNMP
3-MIB
En supposant que tous les routeurs implémentent une MIB-II, le but de l’exercice est de trouver l’algorithme permettant de réaliser l'équivalent du programme traceroute avec en paramètre l'adresse du routeur source et celle du routeur destination. Types disponibles : IpAddress pour adresse IP
Questions :
a. Trouver le nœud qui indique le destinataire suivant sur la route de destination. b. Ecrire l’algorithme.
4-Analyse de la définition d’une MIB
Nous allons nous intéresser à la structure de donnée correspondant à la spécification d’un protocole ressemblant à FTP :
Un site client peut se connecter par un port donné à un site serveur.
Le client s’identifie à l’aide d’un nom et d’un mot de passe auxquels est associé un répertoire par défaut.
Lorsque le client veut récupérer un fichier, il doit envoyer au serveur une requête de récupération, celui-ci va alors mettre le fichier à disposition sur un port différent à a chaque requête.
On veut modéliser avec une MIB pour agent SNMP le protocole ci dessus. L’agent SNMP sera dans le serveur et doit contenir les informations nécessaires à la gestion des utilisateurs et des connexions. Quelques remarques :
Seuls les feuilles de l’arbre peuvent être accessibles !
Le champ « password » doit être inaccessible.
A chaque couple nom/prénom est associé un index utilisateur
A chaque fichier est associé un index.
Seuls les noms de fichier ainsi que les numéros de port sont accessibles en lecture écriture.
Tous les status sont mandatory Questions : - Quel est le chemin permettant d’accéder à la MIB suivante dans l’arbre SNMP ?
- Compléter la spécification de MIB en s’aidant des parties déjà écrites et en tenant compte des indications
précédentes. - Comment spécifier que les numéros de ports utilisables sont sur l’intervalle ( 2048 … 32448) ? - Quelles modifications doit on apporter à la mib pour permettre la gestion d’envoi de fichiers au serveur par le client ? ( structures d’informations à rajouter, comment les rattache on à la MIB déjà construite) ?
MyFTPModule ::= DEFINITIONS BEGIN
myftp OBJECT IDENTIFER ::=
{1 3 6 1 99}
usersTable OBJECT TYPE
SYNTAX SEQUENCE OF
UsersTableEntry
ACCESS [ A COMPLETER ]
STATUS mandatory
::= {myFtp 1}
usersTableEntry OBJECT TYPE
SYNTAX UsersTableEntry
ACCESS [ A COMPLETER ]
STATUS mandatory
INDEX usersIndex,
Centre universitaire Nour El-Bachir, El Bayadh Année Universitaire:2019-2020
Institut des sciences Module ASR
Département de technologie M1 Telecom TD N_1_SNMP
usersName,
usersPassword
::= {userTable 1}
usersIndex OBJECT TYPE
SYNTAX INTEGER
ACCESS [ A COMPLETER ]
STATUS mandatory
::= {userTableEntry 1}
[ A COMPLETER ]
usersHome OBJECT TYPE
SYNTAX HomePath
ACCESS [ A COMPLETER ]
STATUS mandatory
::= {userTableEntry 4}
inFileTable OBJECT TYPE
SYNTAX SEQUENCE OF InFileTableEntry
ACCESS [ A COMPLETER ]
STATUS mandatory
::= {myFtp 2}
inFileTableEntry OBJECT TYPE
SYNTAX InFileTableEntry
ACCESS [ A COMPLETER ]
STATUS mandatory
INDEX inFileIndex
::= {inFileTable 1}
[ A COMPLETER ]
UsersTableEntry ::= SEQUENCE {
usersIndex INTEGER,
usersName OCTET STRING,
usersPassword OCTET STRING,
[ A COMPLETER ]
}
InFileEntry ::= SEQUENCE {
[ A COMPLETER ]
}
NumPort ::= INTEGER (1000..65535)
HomePath ::= FileName
FileName ::= SEQUENCE {
separator OCTET STRING SIZE(1),
dirsNames SEQUENCE OF OCTET STRING
}
END
Centre universitaire Nour El-Bachir, El Bayadh Année Universitaire:2019-2020
Institut des sciences Module ASR
Département de technologie M1 Telecom TD N_1_SNMP
Annexes
Centre universitaire Nour El-Bachir, El Bayadh Année Universitaire:2019-2020
Institut des sciences Module ASR
Département de technologie M1 Telecom TD N_1_SNMP
MIB II
(1)
Système (1)
Interface (2)
Ip (4) ipForwarding (1) Forwarding (1)
Not-forwarding (2)
IpDefaultTTL (2)
ipInReceives (3)
IpInHdrErrors (4)
ipInAddrErrors (5)
ipForwDatagrams (6)
ipInUnknownProtos (7)
ipInDiscards (8)
ipInDelivers (9)
ipOutRequests (10)
ipOutDiscards (11)
ipOutNoRoutes (12)
ipReasmTimeout (13)
ipReasmReqds (14)
ipReasmOKs (15)
ipReasmFails (16)
ipFragOKs (17)
IpFragFails (18)
ipFragCreates (19) IpAddrEntry (1) IpAdEntAddr (1)
IpAdEntIfIndex (2)
IpAdEntNetMask (3)
ipAdEntBcastAddr (4)
IpAdEntReasmMaxSize (5)
ipAddrTable (20)
IpRoutingTable (21) ipRouteEntry (1) IpRouteDest (1)
IpRouteIfIndex (2)
ipRouteMetric1(3)
ipRouteMetric2 (4)
ipRouteMetric3 (5)
ipRouteMetric4 (6)
ipRouteNextHop (7)
ipRouteType (8) Other (1)
Invalid (2)
Direct (3)
Remote (4)
ipRouteProto (9) Other (1)
Local (2)
Netmgmt (3)
Icmp (4)
Egp (5)
Ggp (6)
Hello (7)
Rip (8)
Is-is (9)
Es-is (10)
CiscoIgrp (11)
BbnSpfIgp
(12)
Ospf (13)
Bgp (14)
ipRouteAge (10)
ipRouteMask (11)
IpNetToMediaTable (22) IpNetToMediaEntry (1) IpNetToMediaIfIndex (1)
IpNetToMediaPhysAddress (2)
IpNetToMediaNetAddress (3)
IpNetToMediaType (4)
Icmp (5)
Tcp (6)
Udp (7)
Egp (8)
Transmission
(10)
Exemple (11)
Centre universitaire Nour El-Bachir, El Bayadh Année Universitaire:2019-2020
Institut des sciences Module ASR
Département de technologie M1 Telecom TD N_1_SNMP