Télécoms M1 CTD Admin-Réseaux - BENMOSTEFA [PDF]

Zitiervorschau

Administration des services réseau Institut 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



Objectifs et rôle de l’administration



Modèle d’administration réseaux

Contenu de la matière



Réseau clients serveurs

Chapitre 1. Présentation de l’administration réseau



Les protocoles d’administration



Les services de la couche d’application



Notions de ports de service

Contenu de la matière

Chapitre 2. Le Service SNMP (Simple Network Management Protocol)



Service Syslog. Service SNMP : Présentation et Historique du SNMP



Les principes, Configuration, Avantages et Inconvénients

Contenu de la matière

Chapitre 3. Les services annuaires



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



Introduction, Généralités sur les services NIS (Network Information System) et NFS (Network

Contenu de la matière



File System)

Chapitre 4. Gestion des utilisateurs et service NFS



Fonctionnement, Configuration NIS Serveur NIS et client NIS



Fonctionnement du NFS, Caractéristiques, Commandes

Contenu de la matière

Chapitre 5. Service de messagerie et services d’application



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

Contenu de la matière

Chapitre 6. Contrôleur de domaine



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 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éseau L’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 :

Différents degrés de l’administration 

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.

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 superutilisateur2 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 CMIP Le 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.

Le protocole SNMP 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.

Comparatif : SNMP/CMIP

Autres protocoles d’administration

Outils d’Administration locale d’un élément du réseau On 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 écranclavier 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 CISCO

Ci-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/SSH Comme 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 SNMP Le 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



Modèle de Gestion Manager –Agent avec l’agent 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 « ProxyAgent » 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.

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éseau La 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 OSI Voici 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



Service WEB



Service transfert des fichiers



Service Emulation terminal



Service WEB



Service des annuaires DNS

protocole DNS



Service gestion du réseau

protocole SNMP

protocole HTTP

port 80.

protocole FTP protocole Telnet

protocole HTTP

port POP/25.

port 20 et 21. port 25.

port 80. port 53. 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

Chapitre 2. Le Service SNMP (Simple Network Management Protocol)



Service Syslog. Service SNMP : Présentation et Historique du SNMP



Les principes, Configuration, Avantages et Inconvénients

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ésentation SNMP 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 fonctionnement Le 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 principaux cette 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 Architectural La 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, TokenRing,...) 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 SNMP Sous 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: ERREUR Plusieurs 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 SNMP Il 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.mib2.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 Institut des sciences Département de technologie M1 Telecom

Année Universitaire:2019-2020 Module ASR 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: req-id: int(2) 0x00a2a2 var: obj(9) 1 3 6 1 2 1 var: obj(9) 1 3 6 1 2 1 var: obj(9) 1 3 6 1 2 1 var: obj(9) 1 3 6 1 2 1 var: obj(9) 1 3 6 1 2 1 var: obj(9) 1 3 6 1 2 1 var: obj(9) 1 3 6 1 2 1 var: obj(9) 1 3 6 1 2 1 var: obj(9) 1 3 6 1 2 1 var: obj(9) 1 3 6 1 2 1 SNMP: len: 219 req-id: int(2) var: obj(10) 1 var: obj(10) 1 var: obj(10) 1 var: obj(10) 1 var: obj(10) 1 var: obj(10) 1 var: obj(10) 1 var: obj(10) 1 var: obj(10) 1 var: obj(10) 1

int(1) 0x00 comm: string(6) «public» type: GET-NEXT error: int(1) 0x00 error-index: int(1) 0x00 2 2 1 1 val: empty(0) 2 2 1 2 val: empty(0) 2 2 1 3 val: empty(0) 2 2 1 4 val: empty(0) 2 2 1 5 val: empty(0) 2 2 1 6 val: empty(0) 2 2 1 7 val: empty(0) 2 2 1 8 val: empty(0) 2 2 1 9 val: empty(0) 2 2 1 10 val: empty(0)

version: int(1) 0x00a2a2 error: 3 6 1 2 1 2 2 1 3 6 1 2 1 2 2 1 3 6 1 2 1 2 2 1 3 6 1 2 1 2 2 1 3 6 1 2 1 2 2 1 3 6 1 2 1 2 2 1 3 6 1 2 1 2 2 1 3 6 1 2 1 2 2 1 3 6 1 2 1 2 2 1 3 6 1 2 1 2 2 1

0x00 comm: string(6) «public» type: RESPONSE int(1) 0x00 error-index: int(1) 0x00 1 1 val: int(1) 0x01 2 1 val: string(9) «Ethernet0» 3 1 val: int(1) 0x06 4 1 val: int(2) 0x05dc 5 1 val: gauge(4) 0x00989680 6 1 val: string(6) ****** 7 1 val: int(1) 0x01 8 1 val: int(1) 0x01 9 1 val: time(2) 0x0420 10 1 val: counter(4) 0x6b055aa0

Centre universitaire Nour El-Bachir, El Bayadh Institut des sciences Département de technologie M1 Telecom

Année Universitaire:2019-2020 Module ASR 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 Institut des sciences Département de technologie M1 Telecom 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

Année Universitaire:2019-2020 Module ASR TD N_1_SNMP

Centre universitaire Nour El-Bachir, El Bayadh Institut des sciences Département de technologie M1 Telecom

Annexes

Année Universitaire:2019-2020 Module ASR TD N_1_SNMP

Centre universitaire Nour El-Bachir, El Bayadh Institut des sciences Département de technologie M1 Telecom MIB II (1)

Système (1) Interface (2) Ip (4)

ipForwarding (1)

Année Universitaire:2019-2020 Module ASR TD N_1_SNMP

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)

ipRouteProto (9)

Other (1) Invalid (2) Direct (3) Remote (4) 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)

IpNetToMediaTable (22)

Icmp (5) Tcp (6) Udp (7) Egp (8) Transmission (10) Exemple (11)

IpNetToMediaEntry (1)

ipRouteAge (10) ipRouteMask (11) IpNetToMediaIfIndex (1) IpNetToMediaPhysAddress (2) IpNetToMediaNetAddress (3) IpNetToMediaType (4)

Centre universitaire Nour El-Bachir, El Bayadh Institut des sciences Département de technologie M1 Telecom

Année Universitaire:2019-2020 Module ASR TD N_1_SNMP