cours administration des réseaux

ADMINISTRATION DES RESEAUX Mouad Boumahdi

Octobre 2011

Administration des Rseaux

TABLE DES MATIERES

1.

GESTION DES RESEAUX INFORMATIQUES ................................................................................... 3 1.1. INTRODUCTION..............................................................................................................................................3 1.2. GENERALITES ...............................................................................................................................................4 1.3. PRINCIPE GENERAL ......................................................................................................................................5 1.4. ARCHITECTURE DADMINISTRATION .............................................................................................................6

2. PROTOCOLE POUR LA GESTION DES RESEAUX DANS LE MODELE TCP/IP : SNMP .............. 8 2.1. QUELQUES CONCEPTS FONDAMENTAUX ......................................................................................................9 2.2. ARCHITECTURE DE SNMP .........................................................................................................................11 2.3. MODELE D'INFORMATION ............................................................................................................................12 2.4. STRUCTURE DES INFORMATIONS DADMINISTRATION DE RESEAUX (SMI) ................................................16 2.5. MODELE FONCTIONNEL DADMINISTRATION DES RESEAUX .....................................................................18 2.6. PROTOCOLE SNMP ...................................................................................................................................20 3. SECURITE DES VERSIONS DE SNMP ................................................................................................ 26 3.1. SNMP VERSION 1 ......................................................................................................................................26 3.2. SNMP VERSION 2 ......................................................................................................................................26 3.3. SNMP VERSION 3 ......................................................................................................................................27 4. MISE EN UVRE DE SNMP ................................................................................................................. 29 4.1. CONFIGURATION DE SNMP SUR W INDOWS ..............................................................................................29 4.2. CONFIGURATION DE SNMP SOUS LINUX (UBUNTU) ..................................................................................31 4.3. CONFIGURATION DE SNMP SUR UN ROUTEUR CISCO..............................................................................32 5. RMON : REMOTE MONITORING .......................................................................................................... 33 5.1. RMON 1 .....................................................................................................................................................33 5.2. RMON 2 .....................................................................................................................................................34 6. UTILISATION DE SYSLOG .................................................................................................................... 35 6.1. FONCTIONNEMENT DE SYSLOG ..................................................................................................................35 6.2. EXEMPLE CENTRALISATION DE FICHIERS SYSLOG SUR UN SERVEUR CENTRAL.......................................36 7. OUTILS DE SUPERVISION ET DADMINISTRATION DES RESEAUX ............................................ 38 7.1. FONCTIONNALITES DE BASE.......................................................................................................................38 7.2. FONCTIONNALITES AVANCEES ...................................................................................................................38 8. BIBLIOGRAPHIE .................................................................................................................................... 40

Mouad Boumahdi, Octobre 2011

2


1. GESTION DES RESEAUX INFORMATIQUES1.1. INTRODUCTIONDe nos jours, le rseau est en train de devenir obligatoire pour tout le domaine de la vie. La gestion des rseaux donc est indispensable. Il faut souvent avoir recours des techniques dadministration pour pouvoir contrler son fonctionnement mais aussi afin dexploiter au mieux les ressources disponibles, et de rentabiliser au maximum les investissements raliss.


3


1.2. GENERALITESLa gestion des rseaux informatiques constitue un problme dont lenjeu est de garantir au meilleur cot non seulement la qualit du service global rendu aux utilisateurs mais aussi la ractivit face aux besoins de changement et dvolution. La gestion des rseaux informatiques se dfinit comme tant lensemble des moyens mis en oeuvre (connaissances, techniques, mthodes, outils) pour superviser, exploiter des rseaux informatiques et planifier leur volution en respectant les contraintes de cot et de qualit. La qualit de service se dcline sur plusieurs critres, du point de vue de lutilisateur final, notamment la disponibilit, la performance (temps de rponse), la fiabilit, la scurit Les activits dadministration sont communment classes en activits de : Supervision qui consiste surveiller les systmes et rcuprer les informations sur leur tat et leur comportement, ce qui peut tre fait par interrogation priodique ou par remonte non sollicite dinformations de la part des quipements de rseaux eux-mmes. Administration qui dsigne plus spcifiquement les oprations de contrle froid du rseau avec la gestion des configurations et de la scurit, Exploitation qui dsigne lensemble des activits permettant de traiter les problmes oprationnels sur le rseau : maintenance, assistance technique

-


4


1.3. PRINCIPE GENERALSur le point de ladministration, un systme de rseau informatique se compose dun ensemble dobjets quun systme dadministration surveille et contrle.

Chaque objet est gr localement par un processus appel agent qui transmet rgulirement ou sur sollicitation les informations de gestion relatives son tat et aux vnements qui le concernent au systme dadministration. Le systme dadministration comprend un processus (manager ou grant) qui peut accder aux informations de gestion de la MIB locale via un protocole dadministration comme SNMP ou CMIP de qui le met en relation avec les divers agents. Le principe repose donc sur les changes : Dautre part, entre les lments administrs et le systme dadministration. Dune part, entre une base dinformations appele MIB (Management Information Base) et lensemble des lments administrs (objets) ;

Figure 1 Structure fonctionnelle dune administration RseauMouad Boumahdi, Octobre 2011

5


1.4. ARCHITECTURE DADMINISTRATIONLarchitecture classique d'administration appel le modle Grant/ Agent (Manager/Agent). Le systme est composant d'une entit dadministration et des entits de gestion (NME) qui sont gr par cette entit et un protocole pour la gestion comme SNMP.

Mibs PrivesPoll SNMP Trap SNMP ICMP = Ping SNMP : Simple Network Management Protocol MIB : Management Information Base Trap SNMP Poll SNMP SNMP (Mib 2 +Mib Prive) Poll ICMP Poll SNMP Non-SNMP SNMP Mib 2 (Standard)

NMS Manager

Unix/Linux/WinTrap SNMP

Chaque entit dans le rseau a un Agent pour lopration de gestion, une base de donnes stockes dans MIB et assume les travaux ci-dessous : - Collecter des informations statistiques concernant la communication, et les oprations de rseau. - Stocker les informations localement dans les MIBs. - Rpondre aux commandes de lentit de contrle de rseau, Transmet des informations statistiques lentit dadministration de rseau, modifie les paramtres, donne des informations dtat

Lentit dadministration a une entit logicielle de gestion (Network Management System : NMS) pour grer le rseau interface permettant ladministrateur de raliser des oprations de gestion. Diffrents cas sont envisags : Le nud supervis ne supporte pas SNMP : dans ce cas, la supervision consiste seulement vrifier via ICMP (ping) de sa prsence ou disponibilit sur le rseau. Dans certains cas il est possible davoir accs dautres informations via un proxy SNMP (voir plus loin).


6


-

Le nud supporte SNMP Mib 2 : dans ce cas seuls les donnes contenues dans la Mib 2, peuvent tre rcupres. Pour rappel la Mib 2, est une Mib standard convenues entre les diffrents constructeurs, et est embarque sur lcrasante majorit des quipements rseaux. Gnralement elle permet laccs des donnes non-spcifiques aux constructeurs : Trafic Entrant, Trafic Sortant, Taux dErreur sur un interface, Nom systme de lquipement, Disponibilit,etc. Le nud supporte en plus de la Mib 2, une Mib prive du constructeur : dans ce cas il est possible daccder en plus aux informations de la Mib 2, des informations spcifiques mises disposition par le constructeur dans sa Mib prive.

-

Remarques Importantes : 1. Afin daccder aux Informations contenues dans les Mibs, il faut que ces dernires soient compiles ou charges (loaded) au niveau du NMS Manager, lapplication centrale de supervision. 2. Pour des raisons de scurit, il nest pas recommand de superviser via SNMP des quipements derrire un firewall, c'est--dire dans une zone considre comme non-scurise.


7


2. PROTOCOLE POUR LA GESTION DES RESEAUX DANS LE MODELE TCP/IP : SNMPSNMP est l'un des protocoles les plus rpandus permettant d'administrer le rseau informatique est l'utilisation du protocole SNMP (Simple Network Management Protocol). Il est dvelopp a partir d'anne 80s, et il est devenu le standard actuel dadministration de rseaux TCP/IP. Actuellement cest la version 3 de ce protocole qui est en cours de diffusion. Cette version se compose des fonctionnalits nouvelles, en particulier sur le plan de la scurit.


8


2.1. QUELQUES CONCEPTS FONDAMENTAUX2.1.1. Station dadministration (NMS)Ce terme dsigne le priphrique utilis par l'administrateur pour grer son rseau. Celui-ci doit obligatoirement possder : Des applications spcifiques l'administration. Une interface avec l'administrateur. La capacit pouvoir rcuprer des informations des lments administrs. Une base de donnes obtenue partir des MIBs des lments administrs.

La station NMS peut envoyer des requtes un priphrique afin dobtenir des informations sur son paramtre. Lagent du priphrique reoit la requte et renvoie les informations demandes. Lorsquelle reoit cette rponse, la station NMS peut utiliser les informations de configuration du priphrique afin de dterminer les oprations entreprendre en fonction de son tat.

2.1.2. Agent de gestionCe terme dsigne des agents de SNMP. Ils sont installs dans des priphriques qui supporte le protocole SNMP par exemple: dans des ordinateurs que des hubs, des routeurs, ou encore tout autre type de priphriques. Ces agents connaissent les paramtres du priphrique sur lequel il sexcute et ont pour devoir de rpondre aux requtes de la station d'administration.

2.1.3. Les MIBsCes bases de donnes sont assimiles des bibliothques d'objets nous renseignant sur tous les types de donnes en rapport avec l'activit du rseau. Nous la dtaillerons par la suite.

2.1.4. Les alarmesIl est vident qu'une machine de gestion ne peut constamment demander aux stations surveilles quel est leur tat parce que dans un rseau, normalement, il y a beaucoup de priphriques. C'est la raison pourquoi il est possible de demander aux stations d'mettre de temps en temps (une fois par heure par exemple) un rapport sur son tat et pourquoi pas quelques statistiques. Cela permet de soulager le travail de la station d'administration qui n'a plus qu' couter ses protgs si elle n'a pas d'autres actions de gestion faire.


9


2.1.5. Les PROXIESL'utilisation de SNMP ncessite que tous les agents supportent un protocole commun, tel que UDP et IP, pour celles qui ne le supportent pas, ou sur lesquelles on ne souhaite pas linstaller le concept de proxy a t dvelopp. Ces proxies supplent les machines inadaptes car ils connaissent les objets de la MIB ncessaires pour la gestion du systme mandat. La communication entre le proxy et la machine supple ne peuvent pas utiliser SNMP pour dialoguer et il faut donc, pour le proxy, s'adapter aux protocoles connus par la seconde machine, c'est ce qui est illustr par la figure ci-dessous.

Figure 2 - Gestion des machines ne supportant pas SNMP


10


2.2. ARCHITECTURE DE SNMPL'architecture de gestion du rseau propose par le protocole SNMP est base sur trois lments principaux.

2.2.1. Les quipements grs (managed devices):Ce sont des lments du rseau (ponts, hubs, routeurs ou serveurs), contenant des "objets de gestion" (managed objects) pouvant tre des informations sur le matriel, des lments de configuration ou des informations statistiques.

2.2.2. Les agents de gestionC'est--dire une application de gestion de rseau rsidant dans un priphrique et charg de transmettre les donnes locales de gestion du priphrique au format SNMP.

2.2.3. Les systmes de gestion de rseau (network management systems : NMS)C'est--dire une console au travers de laquelle les administrateurs peuvent raliser des tches d'administration SNMP a t cre pour tre une couche utilisant TCP/IP un niveau suprieur. Le protocole d'administration opre en accord avec UDP (User Datagram Protocol) et IP. A chaque action de la station d'administration, le processus de contrle accde la MIB et avertit l'utilisateur par l'intermdiaire d'une interface graphique. Chaque agent administratif doit lui aussi implmenter SNMP et UDP/IP afin de pouvoir interprter les requtes qui permettent la machine d'administration d'accder sa MIB. SNMP tant reli UDP qui est un protocole sans connexion, il est lui aussi sans connexion, c'est pourquoi les connexions entre station d'administration et agents administratifs ne sont jamais maintenues.


11


2.3. MODELE D'INFORMATION2.3.1 Structure et reprsentation des noms dobjetsDans SNMP, touts les objets mangeables peuvent tre des informations matrielles, des paramtres de configuration, des statistiques de performance et autres objets qui sont directement lis au comportement en cours de l'quipement. Les objets sont classs dans une sorte de base de donne appele MIB. Les objets de MIB reoivent un identifiant unique compos de squences de chiffres spars par des points. Cette squence se lit de gauche droite et correspond des noeuds dans larborescence des noms.


12

Administration des Rseaux La gestion de rseau est dfinie par la branche iso(1). Dans cette branche on trouve un certain nombre de dfinitions dorganisations subordonnes. La gestion de rseau entre dans le noeud org(3). Sous le noeud dod(6) se trouvent un certain nombre de rseaux subordonns. La gestion de rseau entre dans le noeud internet(1). Sous le noeud internet(1) se trouvent un certain nombre de noeuds subordonns reprsentant diffrents services et tentatives de normalisation. La gestion de rseau standardise se trouve dans le rseau mgnt(2). Sous le noeud mgnt(2) se trouvent un certain nombre de noeuds subordonns reprsentant diffrents services et tentatives de normalisation. La gestion de rseau standardise se trouve dans le noeud MIB-2(1). Sous le noeud mib-2(1) se trouvent un certain nombre de noeud subordonns reprsentant diffrents groupement de variables MIB. Sous le noeud system(1), on trouve 2 variables MIB sysDescr(1) et sysLocation(2). Les identifiants dobjets de ces variables sobtiennent en crivant de gauche droite les diffrents noeuds, spars par des points : + sysDescr : 1.3.6.1.2.1.1.1 + sysLocation : 1.3.6.1.2.1.1.2 La reprsentation numrique dun nud de larborescence est appele aussi Object Identifier : OID .

-

-

-

-

-

2.3.2 Les tables MIBCe sont des tables contenant les informations de l'lment du rseau. Ces informations sont hirarchises sous forme d'arbre :

system : Description de toutes les entits grs interfaces : Interface de donnes dynamiques ou statiques at (adress translation) : Table dadresses IP pour les correspondances dadresses MAC ip : Statistiques du protocole IP, adresse cache et table de routage


13


icmp : Statistiques du protocoles ICMP tcp : Paramtres TCP, statistiques et table de connexion udp : Statistiques UDP egp : Statistiques EGP, table daccessibilit snmp : Statistiques du protocole SNMP

En plus du standard MIB de TCP/IP, qui sappelle maintenant MIB-II, un nombre important de RFC dtaillent des variables MIB pour divers type de priphriques. Examinons quelques lments de donnes de la MIB pour en clarifier le contenu. Variables MIB sysUpTime ifNumber ifMtu ifInOctet ipDefaultTTL ipInReceives ipForwDatagrams ipOutNoRoutes ipReasmOKs ipFragOKs ipRoutingTable icmpInEchos tcpMaxConn tcpInSegs udpInDatagrams Catgorie systme interfaces interfaces interfaces ip ip ip ip ip ip ip icmp tcp tcp udp Signification Dure coul depuis dernier dmarrage Nombre dinterfaces rseau MTU dune interface particulire Nombre doctet entrants sur un interface MTU dune interface particulire Nbre de datagrammes reus Nbre de datagrammes achemins Nbre derreurs de routage Nbre de datagrammes rassembls Nbre de datagrammes fragments Table de routage IP Nbre de demandes decho ICMP reues Nbre maxi de connexions TCP autorises Nbre de segments reus par TCP Nbre de datagrammes UDP reus

Les valeurs des lments de chacune des variables ci-dessus peuvent tre enregistres au moyen dun seul entier. Toutefois, la MIB permet galement de dfinir des valeurs plus complexes, comme par exemple la variable ipRoutingTable qui fait rfrence la table de routage dun routeur. Des variables MIB supplmentaires sont dfinies pour le contenu de la table et pour permettre aux protocoles dadministration de rseaux de rfrencer les donnes correspondant chaque entre.

2.3.3 Mibs PrivesLes mibs prives ou propritaires, mises disposition par les diffrents quipementiers rseaux ou diteurs dapplications, permettent daccder des informations spcifiques ces quipements ou applications, informations, qui ne sont pas prsentent dans la Mib standard Mib 2 . Dans larborescence de la Mib, les Mibs privs sont iso.org.dod.internet.private.enterprises, voir la figure 3 ci-dessous. rattachs au nud


14


Directement au nud enterprises vient se greffer lidentifiant de chaque constructeur (cisco dans lexemple ci-dessus). De sorte que chaque constructeur a un identifiant unique qui le diffrencie des autres. Puis au dessous de chaque identifiant de constructeur, viennent se greffer les mibs prives du constructeur.

Figure 3 Exemple darborescence des mibs prives cas de cisco Au niveau de la reprsentation sous forme de chiffres, le nud cisco est reprsent par le chiffre 9 , de sorte que lensemble des nuds des mibs cisco par exemple vont commencer par lOID (Object IDenfier) : .1.3.6.1.4.1.9. 1 3 6 1 4 1 9 : : : : : : : iso org dod internet private enterprises cisco


15


2.4. STRUCTURE (SMI)

DES INFORMATIONS DADMINISTRATION DE RESEAUX

En complment du standard MIB qui dfinit les informations spcifiques dadministration rseaux et leur signification, un standard spar spcifie lensemble des rgles utilises pour dfinir et identifier les variables MIB. Ce sont les rgles de gestion des informations dadministration, SMI (Structure of Management Information). Pour que le protocole dadministration de rseaux reste simple, SMI pose des restrictions sur les types de variables autorises dans la MIB, spcifie les rgles de nommage de ces variables et cre les rgles de dfinition des types de variables. Par exemple: SMI comprend des dfinitions de termes comme IpAddress (dfini comme une chane de 4 octets) et Counter (entier appartenant lintervalle [0,2e32-1] et indique que ce sont les termes utiliss pour dfinir les variables MIB. De plus, SMI dcrit la faon dont la MIB rfrence les tables de valeurs (les tables de routage IP, par exemple).

2.4.1. Dfinitions formelles utilisant ASN.1Le standard SMI indique que toutes les variables MIB doivent tre dfinies et rfrences laide de la notation ISO de syntaxe abstraite ASN.1 (Abstract Syntax Notation 1). ASN.1 est un langage formel qui prsente 2 caractristiques principales: une notation utilise dans les documents manipuls par les humains une reprsentation code et concise de la mme information, utilise dans les protocoles de communication.

Dans les 2 cas, la notation formelle limine toutes les ambiguts possibles, tant du point de vue de la reprsentation que de la signification. Au lieu de dire par exemple, quune variable contient une valeur entire, un concepteur qui utilise ASN.1 doit dfinir la forme exacte et le domaine des valeurs prises par cet entier.

2.4.2. Les messagesLe format et la longueur des messages CMIP sont variables et relativement complexes. On utilise ASN.1 pour dcrire la structure des messages CMIP. Voici un exemple dutilisation dASN.1 dcrivant la structure dune trame Ethernet: Ethernet-Frame::= SEQUENCE { destAddr OCTET STRING (SIZE(6)), srcAddr OCTET STRING (SIZE(6)), etherType INTEGER (1501..65535), data ANY (SIZE(46-1500)), crc OCTET STRING (SIZE(4))


16

Administration des Rseaux } Dans ce cas, il sert attribuer la variable de gauche la dfinition du membre de droite. SEQUENCE reprsente une liste ordonne dlments. Cette liste ordonne contient les champs dune trame Ethernet, notamment ladresse de destination, ladresse source, le type dEthernet, les donnes et le CRC. Le type dun champ est spcifi la suite du nom. Par exemple, destAddr et srcAddr sont dclars comme tant de type OCTET STRING, dfinissant une variable de 0 ou plusieurs octets.La valeur de chaque octet est comprise entre 0 et 255. La taille de la chane obtenue est place aprs la dclaration de la chane OCTET STRING. Ethertype est dfini en tant que INTEGER, savoir une valeur entire de taille et de prcision arbitraire. Le (1501..65535) situ juste aprs permet de dfinir sa plage de valeur. Le champ de donne est de type ANY et sa taille varie de 46 1500 octets.En utilisant la notation ASN.1, les messages SNMP prennent le format suivant: SNMP-message::= SEQUENCE { version INTEGER {version-1(1)}, community OCTET STRING, data ANY }


17


2.5. MODELE FONCTIONNEL DADMINISTRATION DES RESEAUXLOSI a regroup les activits dadministration en cinq groupes fonctionnels.

2.5.1. La gestion des anomalies( Fault Management)Lobjectif est le diagnostic rapide de toute dfaillance interne ou externe du systme, tout dysfonctionnement (panne dun routeur) ; ces pannes pouvant tre dorigine interne rsultant dun lment en panne ou dorigine externe rsultant dpendant de lenvironnement du systme(coupure dun lien publique). Cette gestion implique : La surveillance des alarmes (filtre, report, ) ; il sagit de surveiller le systme et de dtecter les dfauts. On tablit un taux derreurs et un seuil ne pas dpasser, et une action automatique ou manuelle raliser en cas de dpassement du seuil. On distingue cinq types dalarmes : Critiques (Critical), Majeures (Major), Mineure (Minor), Avertissement (Warning), Normale (Normal). Le traitement des anomalies soit de manire automatique via des actions automatiques en cas de loccurrence dune alerte, soit manuellement. La corrlation entre les diffrentes alertes reues, afin de remonter la cause source ( rootcause) du problme ayant engendr lalerte. La localisation de la root-cause, et le retour au fonctionnement normal. Lacquittement de lalerte indiquant ainsi la fin du problme. Cration de rapport de disponibilit et la gestion du journal des erreurs ou incidents.

-

-

-

2.5.2. La gestion de la configuration (Configuration Management)Cela consiste identifier de manire unique chaque objet administr par un nom ou un identificateur dobjet (OID, Object Identifier). Il sagit galement de grer la configuration matrielle et logicielle et de prciser la localisation gographique.

2.5.3. La gestion des performances (Performance Management)Cela consiste contrler, valuer la performance et lefficacit des ressources, savoir le temps de rponse, le dbit, le taux derreur par bit, la disponibilit (aptitude couler du trafic et rpondre aux besoins pour lesquels la ressource a t mise en service).


18


Elle comprend la collecte dinformations statistiques(mesure du trafic, temps de rponse, taux derreurs, etc. ), le stockage et linterprtation des mesures (archivage des informations statistiques dans la MIB, calculs de charge du systme, tenue et examen des journaux chronologiques de ltat du systme).

2.5.4. La gestion de la scurit ( Security Management)Cela concerne le contrle daccs au rseau, la confidentialit des donnes qui y transitent, leur intgrit et leur authentification (lentit participant la communication est bien celle qui a t claire).

2.5.5. La gestion de la comptabilit (Accounting Management)Cela consiste grer la consommation rseau par abonn, de relever les informations permettant dvaluer les cots de communication. La comptabilit est tablie en fonction du volume et de la dure des transmissions.


19


2.6. PROTOCOLE SNMPSNMP est un protocole utilis dans des programmes de gestion de rseaux informatiques dans le monde TCP/IP. Leur fonctionnement est asymtrique, il est constitu dun ensemble de requtes, de rponses et dun nombre limit dalertes. La Station de Gestion envoie des requtes lagent, lequel retourne des rponses. SNMP utilise le protocole UDP. Le port 161 est utilis par lagent pour recevoir les requtes de la station de gestion. Le port 162 est rserv pour la station de gestion pour recevoir les alertes des agents. Le gestionnaire SNMP doit tre mme de lire et de modifier les valeurs des variables MIB des priphriques quil gre. Lorsquun vnement inattendu se produit sur un des priphriques grs, par exemple un chec de transmission et une modification dtat, le priphrique envoie message de trap SNMP au gestionnaire SNMP. Ce message contient une indication de lvnement ayant provoqu la gnration du message. Le gestionnaire SNMP doit alors prendre des mesures qui simposent. Il peut se contenter denregistrer le message dans un fichier de suivi, ou prendre des mesures plus immdiates, par exemple demander des informations complmentaires au priphrique lui ayant envoy le message. Ces informations supplmentaires sont obtenues grce des requtes de lecture des variables MIB. Si le gestionnaire SNMP est programm pour contrler le priphrique, il peut lui demander de modifier la valeur de ses variables MIB. Lorsque le gestionnaire dcide de modifier ltat du priphrique, il le fait en modifiant les variables MIB du priphrique. Par exemple, le gestionnaire modifiera la variable MIB ipPowerOff dun priphrique afin de lteindre distance. Comme les variables MIB sont ordonnes selon leur identificateur dobjet, le gestionnaire SNMP peut parcourir toutes les variables du priphrique en utilisant la commande SNMP GetNext.


20


2.6.1. Les operationsLe protocole SNMP supporte trois types de requtes : GET, SET et TRAP. Il utilise alors les oprations suivantes pour la gestion du rseau.

2.6.1.1. Type de lire les informations GET GetRequest : Cette requte permet aux stations de gestion (manager) d'interroger les objets grs et les variables de la MIB des agents. La valeur de l'entre de la MIB (nom) est passe en paramtre. Elle permet d'accder une variable prcise. GetNextRequest : Cette requte permet aux stations de gestion de recevoir le contenu de l'instance qui suit l'objet nomm (pass en paramtre) dans la MIB. Cette commande permet en particulier aux stations de gestion de balayer les tables des MIB. Elle permet d'accder plusieurs variables simultanment. GetResponse: des requtes, l'agent rpond toujours par GetResponse. Toutefois si la variable demande n'est pas disponible, le GetResponse sera accompagn d'une erreur noSuchObject.


21

Administration des Rseaux GetBulkRequest : (version 2 et version 3 ) Cette requte est une amlioration du SNMP, elle permet aux stations de gestion (manager) d'interroger les objets grs et les variables de la MIB des agents. Il permet la station de gestion de rcuprer efficacement des grandes donnes . Exemple : GetRequest(1.3.6.1.2.1.6.4) provoque le retour de GetResponse (tcpMaxConn = x ) o x est le rsultat de la requte).

2.6.1.2. Type de modification des informations SET SetRequest : Cette requte permet aux stations de gestion de modifier une valeur de la MIB ou d'une variable et de lancer des priphriques. Elle permet par exemple un manager de mettre jour une table de routage. SetRequest provoque aussi le retour de GetResponse. Exemple: SetRequest(1.3.6.1.2.1.6.13.1.1 GetResponse(tcpConnState = 12). = 12 ) provoque le retour de

2.6.1.3. Type de non sollicits Les alarmes TRAP : Lorsquun priphrique entre dans un tat anormal, lagent SNMP prvient le gestionnaire SNMP par le biais dun Trap SNMP. Le message Trap peuvent tre cold start (dmarrage froid), warm start (dmarrage chaud), rinitialisation de lagent SNMP, authentication failure (chec dauthentification, lorsquun nom de communaut incorrect est spcifi dans une requte), loss of EGP neighbour (perte de voisin EGP) InformRequest : (version 2 et version 3) Le but de l'InformRequest-PDU est rellement de faciliter la communication d'information entre les stations de gestion de rseau. L'agent SNMP sur un NMS peut choisir d'informer des autres d'une certaine information en envoyant une InformRequest-PDU cet autre l'agent de SNMP.

2.6.2. Description du protocole

2.5.2.1. Format des PDUs


22


Description des champs : version : Version de SNMP. community : Nom de la communaut (agit comme un mot de passe). request-id : Utilis pour diffrencier les messages. error-status : Utilis pour signaler une erreur (0 si pas d'erreur). error-index : Indique la sous-catgorie d'erreur. variablebindings : Nom des variables avec leurs valeurs. enterprise : Type de l'objet gnrant l'alarme. agent-addr : Adresse de l'metteur de l'alarme. generic-trap : Identificateur de l'alarme. specific-trap : Identificateur d'alarme spcifique. time-stamp : Temps coul depuis la dernire rinitialisation de l'entit. Le champ communaut (community) est une chane de caractre quil faut voir comme un mot de passe de validation dune requte SNMP par lagent ou par le manager. Si la communaut est incorrecte, la requte est rejete. La communaut passe en clair sur le rseau.

2.6.2.2. Envoie dun message Pour envoyer un message, l'agent de SNMP doit excuter les procdures suivantes : Utilise ASN.1 pour crer un PDU. Ce PDU est mis un service d'authentification , avec des adresses de destination, et de la source et du nom de la communaut, le service d'authentification va alors excuter leurs oprations et les oprations de cryptage.


23


-

Le message est construit partir du PDU avec l'ajout du nom de la communaut et la version de SNMP. Ce nouvel objet ASN.1, est enfin cod en utilisant BER et envoy au service de transport.

-

2.6.2.3. Rception dun messagePour envoyer un message, l'agent de SNMP doit excuter les procdures suivantes : Le message est reu et se voit oprer une vrification syntaxique. Si le message est dfectueux, il est ignor. Le numro de version est vrifi, s'il n'est pas conforme, le message est ignor. Le nom d'utilisateur, le PDU, l'adresse de source et de destination au niveau transport, sont mis un service d'authentification. Si l'authentification choue, le service prvient l'entit transport de SNMP, laquelle envoie une alarme et ignore le message. Si l'authentification russit, le service renvoie un PDU de la forme d'un objet ASN.1 qui se conforme la norme RFC 1157. L'entit du protocole va vrifier la syntaxe de message (sous la forme ASN.1). Si le message est choue, le message est ignor. En revanche, la politique d'accs SNMP est choisie et PDU est trait continment.

-

-

-

-

2.6.2.4. Interaction avec la couche transport UDPQuelques rappels sur UDP Les trames UDP sont vhicules dans les paquets IP comme tant des donnes. Chaque trame possde une adresse de source et une adresse de destination qui permettent aux protocoles de niveau suprieurs comme SNMP de pouvoir adresser leurs requtes. Le protocole UDP peut utiliser un checksum optionnel qui couvre l'en-tte et le donnes de la trame. En cas d'erreur, la trame UDP reue est ignore.

-

Il y a deux ports dsigns pour l'utilisation de SNMP : le numro 161pour les requtes standard et le numro 162 pour l'coute des alarmes destines la station d'administration. Cas de perte PDU


24

Administration des Rseaux UDP est un protocole qui n'est pas fiable 100% et la perte de trames est donc possible. Or rien n'empche UDP de perdre un trame contenant un message SNMP. Dans ce cas, plusieurs cas s'offrent nous : Le paquet perdu est du type Get ou une rponse d'un agent administr. Cela provoque un manque d'information au niveau de la station d'administration qui n'est pas important : Voyant la rponse ne pas arriver, la station d'administration peut dcider d'elle mme de renvoyer sa requte. L'identificateur de requte tant identique, il n'y a pas de risque de recevoir plusieurs rponses dues des questions dupliques. En cas de non-rponse permanent, cette station peut dclarer ce priphrique muet comme dfaillant. Le paquet perdu est du type Set. Il est alors plus judicieux de faire un Get sur cette entre afin de savoir si c'est la requte qui a t perdue ou alors sa rponse. C'est une alarme qui a t perdue. Comme aucun acquittement n'est ncessaire suite une alarme, la station d'administration ne sera jamais avertie par le signal. Il est donc ncessaire que la station d'administration scrute rgulirement l'tat de ses agents pour se mettre au courant des ventuels changements pour lesquels il n'aurait pas reu d'alarme.

-

-


25


3. SECURITE DES VERSIONS DE SNMP3.1. SNMP VERSION 1SNMP Version 1 n'est pas un protocole scuris. Cependant, il a un systme minimal de scurit appel les communauts de SNMP. Les communauts (community) de SNMP ont le rle de mots de passe pour l'information de SNMP. Il y a trois genres de communaut (community name) de SNMP : Lecture seule, lecture/criture, et pige (trap). Lecture Seule (read-only) : Configur au niveau du nud rseau superviser et du NMS manager, il permet ce dernier de pouvoir interroger rgulirement lagent SNMP embarqu au niveau de du nud. De mme quutilis avec les commandes snmpwalk , snmpget , il permet de rcuprer des informations depuis la ligne de commande. Lecture/criture (read / write) : Configur au niveau du nud rseau superviser et du NMS manager, il permet ce dernier de pouvoir mettre jour une valeur de MIB via snmpset : SetRequest , pouvant ainsi agir sur la configuration de lquipement. Pige (trap) : En gnral, la valeur de la communaut (community) de pige n'est pas utilis. Elle a t conue pour permettre des administrateurs de rseau de grouper des entits en masse compacte de rseau ensemble dans des groupes, ou des communauts. Puis, les stations de gestion peuvent tre configurs pour traiter seulement des piges reus d'une ou plusieurs communauts uniques identifiant la communaut d'une entit par la valeur de la communaut de pige envoye avec le pige. Puisque la plupart des applications de gestion de rseau ont d'autres manires de limiter quelles entits sont contrles, cette capacit est habituellement superflue. Si nous essayons d'accder un agent de SNMP avec une valeur fausse de la Communaut de SNMP, l'agent ne nous fournira pas l'information. Dans la plupart des cas, les valeurs du champ communaut de SNMP pour un objet de rseau ne peuvent pas tre obtenues ou changes par l'intermdiaire du SNMP. Souvent, les valeurs du champ communaut de l'agent de SNMP devront tre dfinies dans un dossier de configuration qui est tlcharg l'agent.

3.2. SNMP VERSION 2Le cadre de scurit de SNMP V2 traite le problme de l'authentification de l'expditeur de message, de son contenu et des problmes d'oreille indiscrte. SNMPv2 soutient l'utilisation du protocole d'authentification d'identifier la fiabilit de sources et d'empcher la modification de message. SNMPv2 soutient l'utilisation du chiffrage de garder l'intimit de messages. La procdure recommande d'authentification est le protocole Digest Authentication. Ce protocole est bas sur message-digest pour authentifier la source de message et pour empcher le message trifouillant. Message -digest:


26

Administration des Rseaux C'est un message trait comme une squence des nombres de 32 bits. Il est juste un calcul mathmatique excut sur ces nombres et inclus avec le message.. L'authentification montre seulement que le message est vritable, il n'empche pas une oreille indiscrte de lire le message.

3.3. SNMP VERSION 3SNMP V3 peut rsoudre les problmes de scurit qui ont infest SNMPv1 et SNMPv2. Il n'y a aucun autre changement au protocole. Il n'y a aucune nouvelle opration. SNMPv3 soutient toutes oprations dfinies par Versions 1 et 2. Le changement le plus important est que la version 3 abandonne la notion des grants (manager) et des agents. Des grants et les agents s'appellent maintenant les entits de SNMP. Chaque entit se compose d'un moteur de SNMP et d'une ou plusieurs applications de SNMP. Le moteur de SNMP v3 :

-

Il se compose de quatre morceaux : l'expditeur, le sous-ensemble de traitement de message, le sous-ensemble de scurit, et le sous-ensemble de contrle d'accs. Le travail de l'expditeur est d'envoyer et recevoir des messages. Il essaye de dterminer la version de chaque message reu (c.--d., v1, v2, ou v3) et, si la version est soutenue, remet le message au loin au sous-ensemble de traitement de message. L'expditeur envoie galement des messages de SNMP d'autres entits . Le sous-ensemble de traitement de message prpare des messages pour tre envoy et extrait des donnes partir des messages reus. Un systme de traitement de message peut contenir des modules de traitement de message multiple. Par exemple, un sous-ensemble peut avoir des modules pour traiter les demandes SNMPv1, SNMPv2, et SNMPv3. Il peut galement contenir un module pour d'autres modles de traitement qui doivent tre dfinis encore. Le sous-ensemble de scurit fournit des services d'authentification et d'intimit. L'authentification emploie des valeurs de la communaut (versions 1 et 2 de SNMP) ou l'authentification utilisateur-base par SNMPv3. l'authentification Utilisateur-base emploie les algorithmes de MD5 ou de SHA pour authentifier des utilisateurs sans envoyer un mot de

-

-


27

Administration des Rseaux passe dans l'espace libre. Le service d'intimit emploie l'algorithme de DES pour chiffrer et dchiffrer des messages de SNMP.


28


4. MISE EN UVRE DE SNMPDans ce chapitre sont prsentes les tapes suivre pour configurer SNMP au niveau des platesformes Windows et Linux, et sur un routeur cisco.

4.1. CONFIGURATION DE SNMP SUR WINDOWSL'installation de SNMP sous Windows ne pose gure de problmes. 1. Elle commence tout dabord par installer la composante windows : SNMP . 2. Ensuite grez le poste de travail, par exemple en cliquant du bouton droit sur "Poste de travail" dans le menu, puis accder au Gestionnaire des Services , et allez dans les proprits du Service SNMP .

3. Configurer le champ communaut (community) pour la scurit et spcifier les stations qui peuvent accder cet agent l.


29



30


4.2. CONFIGURATION DE SNMP SOUS LINUX (UBUNTU)Linstallation et configuration de SNMP sous UBUNTU se fait en trois tapes : 1. Installation : partir de la ligne de commande excuter la commande suivante : sudo apt-get install snmpd 2. Configuration : Sauvegarder le fichier standard de configuration de SNMP :

mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.org

-

Crer un nouveau fichier de configuration SNMP /etc/snmp/snmpd.conf, dont le contenu est :

rocommunity public # Community name pour Lire syslocation "estem, casablanca" # Lieu


31


syscontact [email protected] # personne de contactFaire en sorte que snmpd le daemon de snmp utilise le nouveau fichier cr et quil soit lcoute de tous les interfaces : Editer /etc/default/snmpd Changer de : # snmpd options (use syslog, close stdin/out/err). SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1' : # snmpd options (use syslog, close stdin/out/err). #SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1' SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf' Re-dmarrer snmpd : /etc/init.d/snmpd restart 3. Test : Faire un snmpwalk depuis un autre poste vers le poste linux qui vient dtre configur.

4.3. CONFIGURATION DE SNMP SUR UN ROUTEUR CISCOSe connecter au routeur cisco, et partir de la ligne de commande cisco, entrer en mode config , puis raliser les actions suivantes :Router(config)#snmp-server community XXXX RO ( "XXXX" est le community Read-only : lecture seule) Router(config)#snmp-server community YYYY RW ( "YYYY" est le community Read/Write : lecture / criture) Router(config)#snmp-server host @IP_Serveur ( "@IP_Serveur " est ladresse IP du serveur qui va recevoir les Traps / Alertes du retour).


32


5. RMON : REMOTE MONITORINGstandard RMON (Remote Monitoring) est bas sur lutilisation du protocole de management SNMP et requiert deux composants, un manager snmp et des agents snmp supportant Le RMON. Lassociation des deux composants est quivalente un systme danalyseurs rseaux distribus.

Le rle du manager snmp est de collecter par SNMP les donnes de trafic sur les agents RMON et de les prsenter sous forme tabulaire ou graphique. Les agents, aussi appels sonde RMON, sont chargs de l'analyse et ventuellement de la capture du trafic en un point quelconque du rseau et de rpondre au requte du manager snmp. Une sonde RMON peut aussi tre considre comme un analyseur rseau communiquant. Les sondes RMON ou agent RMON sont disponibles sous plusieurs formes. Il existe des quipements ddis cette fonction (Netscout, Sniffer distributed), dautres non ddis cette fonction mais incluant des agents RMON comme cest le cas de certains commutateurs Ethernet. Finalement les sondes RMON existent sous forme de logiciels installer sur des systmes dexploitation standards Windows ou LINUX (Sonde Network General). Le standard RMON dfinit des jeux de compteurs de trafic et de fonctions quil rassemble dans des groupes numrots et spcifis dans des fichiers MIB. RMON se dcline en deux versions, RMON 1 et RMON 2, pour couvrir les 7 couches du modle OSI.

5.1. RMON 1Le standard RMON 1 a t cr initialement pour avoir des informations sur le trafic rseau au niveau physique et liaison (Physical et logical link layer) et supporte les protocoles Ethernet et Token Ring. Le standard RMON1 est dfini par le RFC 1757 (Request For Comments) de lIETF (Internet Engineering Task Force). Une sonde RMON ou un commutateur Ethernet supportant le standard RMON1 (groupes 1,4,5,6) fournit des statistiques sur le(s) segments Ethernet: 1. Quantit de paquets et doctets reus et transmis au global sur le segment. 2. Quantit de paquets de broadcast, de multicast et derreurs au global sur le segment. 3. Tailles des paquets et rpartition 4. Quantit de paquets et doctets reus et transmis par une adresse Ethernet (MAC). 5. Quantit de paquets et doctets reus et transmis pour une paire dadresses Ethernet dans le sens source vers destination. 6. Quantit de paquets et doctets reus et transmis pour une paire dadresses Ethernet dans le sens destination vers source. 7. Quantit de paquets et doctets reus et transmis par les n adresses Ethernet les plus bavardes.


33


5.2. RMON 2Le standard RMON version 2 a tendu lanalyse du trafic rseau de RMON 1 limit au niveau Ethernet aux protocoles de niveau suprieur tel que TCP/IP. Le standard RMON2 est dfini par le RFC 2021 (Request For Comments) de lIETF (Internet Engineering Task Force). Des informations statistiques sont disponibles au niveau de la couche rseau (IP) et de la couche application (TCP/UDP) : 1. Quantit de paquets et doctets reus et transmis par protocole de transport (IP, IPX, AppleTalk etc.). 2. Quantit de paquets et doctets reus et transmis par un host IP (adresse IP). 3. Quantit de paquets et doctets reus et transmis pour une paire dadresses IP dans le sens source vers destination. 4. Quantit de paquets et doctets reus et transmis pour une paire dadresses IP dans le sens destination vers source. 5. Quantit de paquets et doctets reus et transmis par les n adresses IP les plus bavardes. 6. Quantit de paquets et doctets reus et transmis par un host IP (adresse IP) pour une application identifie par le port TCP/UDP. 7. Quantit nombre de paquets et doctets reus et transmis pour une paire dadresses IP dans le sens source vers destination pour une application identifie par le port TCP/UDP. 8. Quantit de paquets et doctets reus et transmis pour une paire dadresses IP dans le sens destination vers source pour une application identifie par le port TCP/UDP. 9. Quantit de paquets et doctets reus et transmis par les n adresses IP les plus bavardes pour une application identifie par le port TCP/UDP.


34


6. UTILISATION DE SYSLOGSyslog est un protocole dfinissant un service de journaux d'vnements d'un systme informatique. C'est aussi le nom du format qui permet ces changes. Lintrt de son utilisation rside dans sa capacit fournir des informations systmes sur ltat de lquipement, que ne peuvent fournir les Mibs. La combinaison des deux permettra de mettre en en place une configuration avance.

6.1. FONCTIONNEMENT DE SYSLOGEn tant que protocole, Syslog se compose d'une partie cliente et d'une partie serveur. La partie cliente met les informations sur le rseau, via le port UDP 514. Les serveurs collectent l'information et se chargent de crer les journaux. L'intrt de Syslog est donc de centraliser les journaux d'vnements, permettant de reprer plus rapidement et efficacement les dfaillances d'ordinateurs prsents sur un rseau. Le protocole syslog utilise un socket afin de transmettre ses messages. Suivant les systmes, celui-ci est diffrent:

Plate-forme

Mthode

Linux

Un SOCK_STREAM unix nomm /dev/log; certaines distributions utilisent SOCK_DGRAM

BSD

Un SOCK_DGRAM unix appel /var/run/log.

Solaris (2.5infrieurs)

et

Un flux SVR4 appel /dev/log.

Solaris (2.6 suprieurs)

et En plus du flux habituel, une porte multithreaded appele /etc/.syslog_door est utilise.

HP-UX 11 et suprieur

HP-UX utilise le Tube Unix nomm /dev/log de taille 2048 bytes


35


AIX 5.2 and 5.3

Un SOCK_STREAM ou un SOCK_DGRAM unix appel /dev/log.

Un journal au format syslog comporte dans l'ordre les informations suivantes : la date laquelle a t mis le log, le nom de l'quipement ayant gnr le log (hostname), une information sur le processus qui a dclench cette mission, le niveau de gravit du log, un identifiant du processus ayant gnr le log et enfin un corps de message. Certaines de ces informations sont optionnelles.

Exemple : Sep 14 14:09:09 machine_de_test dhcp service[warning] 110 corps du message

Les niveaux de gravit Syslog, souvent appels level sont au nombre de huit reprsents par un chiffre de 0 (Emergency) 7 (Debug) :

0 Emerg (emergency) 1 Alert 2 Crit (critical) 3 Err (error) 4 Warning 5 Notice 6 Info (informational) 7 Debug 8 none

Systme inutilisable Une intervention immdiate est ncessaire Erreur critique pour le systme Erreur de fonctionnement Avertissement vnement normal mritant d'tre signal pour information seulement Message de mise au point Ignorer ce message

Cette indication est particulirement importante car elle normalise de fait la reprsentation de la gravit d'un log, ce qui rend par exemple possible l'interoprabilit entre quipements de collecte de logs et quipements de gnration d'alertes.

6.2. EXEMPLE CENTRALISATION DE FICHIERS SYSLOG SUR UN SERVEURCENTRALDans cet exemple, sont prsentes titre dillustration, les tapes suivre pour configurer des routeurs cisco afin quils envoient automatiquement les donnes de syslog vers un serveur centralis. Au niveau de caque routeur, se connecter en mode enable puis accder la configuration :


36


R1>enable R1#configure terminal Enter configuration commands, one per line. R1(config)#logging host 192.168.105.3 Ladresse IP 192.168.105.3 est ladresse IP du serveur qui centralisera lensemble des syslog. Remarque : Il est tout fait possible de centraliser sur un mme serveur syslog , les syslog de lensemble des routeurs, switchs ou serveurs dune entreprise. Une fois centralise une mthode dutilisation serait la recherche rgulire dans le syslog central de mots cls indiquant le dysfonctionnement recherch. End with CNTL/Z.


37


7. OUTILS DE SUPERVISION ET DADMINISTRATION DES RESEAUXPlusieurs outils ou solutions de supervision existent sur le march. Elles sont soient proposes par des diteurs, soient dorigine opensurce , titre dexemple nous citons : Nagios HP Openview Netview / Tivoli dIBM Solarwinds, Cacti .etc.

Le choix de lune ou autre solution, doit rpondre plusieurs critres, et pas uniquement techniques : Le cot dacquisition La Qualit du support et service aprs-vente La facilit de mise en uvre Ltendue du primtre superviser ou administrer.

Sur le plan technique, nous prsentons ci-aprs quelques critres diffrenciateurs, permettant de juger ou classifier les solutions les unes par rapport aux autres.

7.1. FONCTIONNALITES DE BASECi-aprs quelques fonctionnalits de base que doit respecter toute solution de supervision : Monitoring de la Disponibilit des Plates-formes Monitoring du Trafic : In, Out, Errors, Bande Passante Monitoring des Performances : CPU, RAM,etc. Alertes en cas de Dpassement de Seuils Actions Automatiques Corrlation des vnements Graphes de Visualisation Rapports : Disponibilit, Top Ten des Consommations, Inventaires,etc. Accs : Administrateurs, Oprateurs, etc.

7.2. FONCTIONNALITES AVANCEES


38

Administration des Rseaux Ci-aprs, sont indiques quelques fonctionnalits avances que peuvent supporter les outils de supervision ou dadministration : Multi-tenancy Gestion des VLANs Gestion de HSRP Hot Standby Router Protocol Gestion des Rseaux MPLS et IP VPN Gestion des Protocoles de Routage Monitoring de la Tlphonie sur IP : SIP, Jitter,etc. Plug-Ins de Performance Constructeurs


39


8. BIBLIOGRAPHIEGESTION DES RESEAUX INFORMATIQUES : JP et M Claude - Ed Eyrolles GESTION DE RESEAUX : Arpege - Ed Masson RESEAUX LOCAUX : Samuel Pierre - Ed Eyrolles COMPRENDRE LES RESEAUX D'ENTREPRISE : Philippe Gomez et Pierre Bichon - Ed Eyrolles


40

cours administration des réseaux

Documents