DUPARO Jonathan-Minh CHERRUAU Guillaume Session 2010/2011

Transcription

1 DUPARO Jonathan-Minh CHERRUAU Guillaume

2 Remerciements Nous tenons à remercier tout particulièrement notre enseignant-tuteur, M. Ludovic Fontaine, qui nous a donné l'opportunité de découvrir un protocole d'administration réseau fort intéressant à travers l'intégralité de ce projet, nous souhaitons le remercier également pour sa gentillesse et sa disponibilité. Nous sommes aussi reconnaissant envers M. Ludovic Valentin, diplômé de la prestigieuse école SupInfo, qui nous a apporté de riches informations au sujet de la mise en place de SNMP version 3. 2/41

3 SOMMAIRE Remerciements...2 Introduction...4 I. Objectifs et principe de la supervision réseau...4 II. Le protocole SNMP...5 1) Présentation...5 2) Fonctionnement...6 A - Les agents SNMP...6 B - Le manager SNMP...6 C - La base de données MIB...7 D - Fonctionnement général...9 3) Les commandes SNMP...10 A - Les requêtes et les réponses SNMP...10 B - Analyse d'un échange de trames ) Comparatif des versions...13 A - Historique global des versions...13 B - SNMP v C - SNMP v2c...16 D - SNMP v III. Mise en œuvre du protocole SNMP sur un routeur ) Mise en place de SNMP v1 et SNMP v ) Mise en place de SNMP v A - Sans authentification et sans cryptage...25 B - Avec authentification, mais sans cryptage...26 C - Avec authentification et avec cryptage ) Problèmes rencontrés et solutions apportées...30 Conclusion...31 Glossaire...32 Bibliographie...33 Annexes /41

4 Introduction Dans le cadre de notre deuxième année de DUT, nous avons l'occasion de réaliser une étude complète sur un des sujets proposés aux étudiants par différents enseignants. Cette longue étude, qui s'est déroulée durant plus de 6 mois (s'étalant sur deux semestres) et qui a eu pour moyenne 300h de travail personnel par étudiant, se finalise par ce rapport complet répondant au sujet de l'enseignanttuteur. Le sujet qui nous a réunis concerne donc le protocole SNMP, il est le suivant : L'objectif du projet est de mettre en place et d'étudier l'administration du routeur Cisco 1841 via le protocole SNMP (Simple Network Management Protocol). Les différentes fonctionnalités des versions SNMPv1, SNMPv2 et SNMPv3 seront étudiées en terme de configuration sur le routeur, commandes sur le client, analyse de trames échangées via le protocole SNMP, requête/réponse étudiée. Pour ce projet, nous disposons d'un routeur Cisco 1841, ainsi que de deux PC sous Windows. I. Objectifs et principe de la supervision réseau Aujourd'hui, les réseaux informatiques sont devenus indispensables au sein de la quasitotalité des entreprises et des administrations afin de garantir leur bon fonctionnement. Un quelconque problème sur le système d'information pourrait provoquer de lourdes conséquences, aussi bien au point de vue financier qu'organisationnel. De plus la complexité des systèmes a rendu impossible une surveillance manuelle du réseau. C'est pour cela que la supervision des réseaux est alors devenue un outil essentiel pour résoudre ce problème. La supervision réseau se présente sous la forme de logiciels ou de programmes permettant de vérifier l'état et le comportement du réseau ainsi que des machines ou équipements qui y sont connectés. Ils permettent à l'administrateur réseau d'avoir une vue d'ensemble en temps réel de l'état de son parc informatique. La supervision réseau doit permettre d'anticiper les différentes pannes ou incidents pouvant nuire au bon fonctionnement du réseau. Une grande majorité des logiciels de supervision sont basés sur le protocole SNMP, qui est l'objet de ce rapport. Ces différents outils de «monitoring réseau» possèdent de nombreuses fonctions, telles que : L'analyse et la prévention des problèmes La surveillance du système d'informations services réseaux (SMTP, POP3 ) ressources des serveurs (charge processeur, occupation des disques...) La supervision à distance (accès à des équipements réseau à distance) L'optimisation des performances du réseau L'automatisation de processus de configuration des différents éléments du réseau Cependant les solutions de supervision sont parfois très coûteuses et leurs configurations peuvent vite devenir complexes selon le logiciel utilisé. 4/41

5 II. Le protocole SNMP Le protocole SNMP a connu de nombreuses évolutions jusqu'à sa version actuelle. Cette partie est l'occasion de comprendre le protocole et son évolution à travers le temps. 1) Présentation Le protocole SNMP (Simple Network Management Protocol), définie par la norme RFC 1157, est comme son nom l'indique un protocole d'administration réseau qui rend possible la supervision des équipements réseau ainsi que des machines informatiques. Ce protocole permet de subvenir à un grand nombre de besoins par exemple : disposer d'une cartographie du réseau grâce à des applications utilisant le protocole SNMP, fournir une liste d'informations propre à chaque machine du réseau, signaler des dysfonctionnements, etc... Il est actuellement le protocole le plus utilisé pour la gestion de terminaux et d'équipements réseau. Ce protocole est donc utilisé principalement par les administrateurs réseau afin de pouvoir détecter à distance les éventuelles pannes ou problèmes survenant sur le réseau. Tout terminal ou équipement contient énormément d'informations précieuses pour l'administrateur réseau quelque soit le système d'exploitation utilisé par cette machine (Windows, Linux, les systèmes d'exploitation Cisco comme pour les routeurs par exemple). Au sein de la couche transport du modèle OSI, le protocole SNMP est encapsulé dans UDP et est accessible via les ports 161 et 162. Voici sa représentation dans le modèle OSI : De plus, ce protocole offre beaucoup d'avantages, nous pouvons en citer quelques-uns : Il est simple et assez facile d'utilisation, Il nous offre la possibilité de gérer à distance des équipements, Il est compatible avec une large gamme de produits. 5/41

6 L'environnement de gestion SNMP est constitué de trois éléments principaux, que nous détaillerons dans la partie suivante : Les agents SNMP Le ou les managers SNMP (ou station(s) de supervision(s)) La base de données MIB 2) Fonctionnement Le fonctionnement de ce protocole est devenu de plus en plus complexe au fil du temps dû à l'évolution des versions du protocole, mais en contre-partie son fonctionnement est devenu de plus en plus fiable. Il s'appuie sur un principe d'échange d'informations par requêtes portées sur une base de données, entre un agent et un manager SNMP qui s'apparentent respectivement à un serveur et un client. A - Les agents SNMP Lorsque l'on désire administrer une machine ou un équipement, il faut qu'un agent SNMP soit implanté sur celui-ci. Cet agent est assimilé à un serveur, par conséquent il écoute sur un port particulier : le port UDP 161. L'agent gère l'ensemble des informations relatives à son équipement et doit donc rester à l'écoute des éventuelles requêtes que l'administrateur lui enverra pour pouvoir lui répondre. Mais, il faut savoir que c'est lui aussi qui peut envoyer à la station d'administration des messages d'alertes au cas où un problème surviendrait. De plus, il doit pouvoir agir sur les informations contenues en local sur l'équipement concerné afin de répondre à une modification possible d'un des paramètres. B - Le manager SNMP Il correspond à la station de supervision du réseau, où se trouve l'administrateur réseau. C'est lui qui communique avec les agents SNMP via une application avec ou sans interface graphique afin de vérifier que tout fonctionne comme il se doit. Le manager SNMP est également à l'écoute d'un port : le port UDP 162 pour identifier les messages d'alarmes (TRAP). Les informations reçues sont donc centralisées. Schéma montrant le fonctionnement entre ces deux entités : 6/41

7 C - La base de données MIB La base de données, appelée MIB (Management Information base), contenue dans l'équipement à administrer, recense ainsi toutes les informations relatives à cet équipement réseau. Il est donc possible de connaître de façon précise toutes les informations que l'équipement réseau possède dans le but de gérer, au mieux, son fonctionnement. Elle est construite selon un concept arborescent similaire à celui employé dans le DNS (Domain Name System), chacun des chemins permettant d'accéder à une information est appelé OID (Object Identifier) et est représenté par une suite d'entiers séparés par des points selon une recommandation de l International Telecommunication Union. Chacun des noeuds de l'arbre représente un objet. On peut distinguer dans la MIB deux parties, une partie standard commune à tous les équipements réseau, et une partie privée propre à un équipement. Prenons un exemple simple : si l'on souhaite accéder via une requête SNMP à un objet de mgmt l'oid pourra s'écrire sous deux formes : NumObjet.iso.identifiedorganization.dod.internet.mgmt.NomObjet 7/41

8 Présentons maintenant l'une des branches la plus utilisée de la MIB : System : Description système de toutes les entités gérées Exemple d'objets gérés par cette branche : sysuptime : Durée écoulée depuis le dernier démarrage Interfaces : Interface de données dynamiques ou statiques Exemple d'objets gérés par cette branche : ifnumber : Nombre d'interfaces réseau At (adresse translation) : Table d'adresses IP pour les correspondances d'adresses MAC Ip : Statistiques du protocole IP, adresse cache et table de routage Exemple d'objets gérés par cette branche : ipinreceives : Nombre de datagramme IP reçus Icmp : Statistiques du protocole ICMP Exemple d'objets gérés par cette branche : icmpinechos : Nombre de demandes d'echo ICMP reçues Tcp : Paramètres TCP, statistiques et table de connexion Exemple d'objets gérés par cette branche : tcpinsegs : Nombre de segments TCP reçus Udp : Statistiques UDP Exemple d'objets gérés par cette branche : udpindatagrams : Nombre de datagramme UDP reçus Egp : Statistiques concernant le protocole de routage EGP, table d'accessibilité Snmp : Statistiques du protocole SNMP 8/41

9 De plus, il faut savoir qu'en complément du standard MIB définissant les différentes informations d'administration réseau contenu sur un équipement, il existe aussi un standard indépendant qui normalise les règles utilisées pour définir et identifier les variables de la MIB. Il se nomme SMI (Structure of Management Information). SMI a pour buts principaux de poser des restrictions sur les types de variables autorisées au sein de la MIB, de spécifier des règles de nommages des OIDs, ainsi que de créer les règles de définition des types de variables. Le standard SMI indique en particulier que toutes les variables contenues dans une MIB doivent être définies et référencées via la notation ISO de syntaxe ASN.1 (Abstract Syntax Notation 1). C'est grâce à cette syntaxe que les objets de la MIB peuvent s'écrire soit par une suite d'octets, soit par son équivalent via son chemin dans la MIB. Nous avons vu ici comment chaque élément de l'environnement SNMP fonctionne indépendamment des autres. Il serait maintenant nécessaire d'expliquer le fonctionnement interne entre les différents éléments. D - Fonctionnement général Pour bien comprendre le fonctionnement général des trois éléments précédemment cités, procédons à une courte analyse du schéma ci-dessous : Le protocole SNMP permet la communication entre les deux entités bleutées, le manager SNMP et l'agent SNMP qui contient la MIB. Pour interagir avec la MIB, on utilise des requêtes de lecture ou d'écriture à partir d'une application d'administration réseau située sur la station de supervision. En réponse à l'interprétation des requêtes précédentes par la MIB, deux suites sont possibles, soit c'est une réponse contenant les informations demandées par la requête qui sera envoyée, soit c'est une réponse particulière (alerte) indiquant un problème qui sera retournée au manager SNMP. Finalement, le protocole SNMP est un protocole très prisé par les administrateurs réseau, puisqu'il permet un entretien rapide et complet de différents équipements réseau. Nous allons à présent nous pencher sur les différents types de commandes SNMP. 9/41

10 3) Les commandes SNMP Afin que le manager SNMP puisse interroger les agents à superviser, plusieurs requêtes existent. Pour nous familiariser avec le protocole et tester ces différentes requêtes, nous avons utilisé dans un premier temps SNMP util, qui est un petit programme permettant d'interroger la MIB d'une autre machine qui se situe sur le même réseau. Cependant, ce programme ne prenant en charge que les versions 1 et 2 du protocole, nous utiliserons par la suite un programme plus complet pour étudier la version 3. A - Les requêtes et les réponses SNMP Le protocole SNMP supporte trois grands types de requêtes : GET pour la lecture, SET pour l'écriture et TRAP pour les messages d'alertes. La requête GetRequest : Elle permet à la station de gestion l'obtention de la valeur précise d'un objet de la MIB contenu sur l'équipement à gérer. La valeur de l'oid est passée en paramètre. Exemple : Nous souhaitons interroger l'objet qui correspond à une description système, son nom est system.sysdescr.0 et correspond au chemin dans la MIB. La requête peut donc s'écrire de deux façons, soit avec le nom de l'objet, soit avec le chemin de l'objet. On définit auparavant le nom de la communauté par publique (nous verrons par la suite ce qu'est le nom de la communauté). Voici la requête et le résultat via SNMPutil : Avec NET-SNMP, la syntaxe est la suivante : snmpget v n version -c communauté Ipdestinataire OID La requête GetNextRequest : Elle permet à la station de gestion l'obtention de la valeur du prochain objet de la MIB, qui est passée en paramètre à partir d'un objet courant contenu sur l'équipement à gérer. Avec NET-SNMP, la syntaxe est la suivante : snmpgetnext v n version -c communauté Ipdestinataire OID 10/41

11 Pour bien comprendre son rôle, nous allons effectuer quatre commandes différentes : snmputil get Ipbinôme communauté snmputil getnext Ipbinôme communauté snmputil getnext Ipbinôme communauté. 1.3 snmputil getnext Ipbinôme communauté Getnext nous permet d'obtenir la valeur de l'objet le plus proche. Ainsi la première commande ne marche pas puisqu'elle n'utilise pas getnext et porte sur une catégorie d'objet. Au contraire, les autres commandes utilisent getnext et peuvent donc, pour leur part, porter sur une catégorie d'objet. On peut imager cela par un répertoire et son contenu, getnext permet d'afficher le premier fichier du répertoire, alors que get ne peut pas être porté sur un répertoire, mais sur un fichier seulement. Autrement dit, la requête get porte uniquement sur un objet ayant une valeur, alors que la requête getnext porte sur une catégorie d'objets, qui elle n'a pas de valeur propre. La requête getnext n'est pas obligée de connaître le nom d'un objet pour obtenir sa valeur. La requête SetRequest : Elle permet la mise à jour d'une valeur courante d'un objet de la MIB géré par un agent. Avec NET-SNMP, la syntaxe est la suivante : snmpset v n version -c communauté Ipdestinataire OID_à_modifier type_oid(caractère, entier...) nouvelle_valeur Il est important d'ajouter que cette commande n'est possible qu'avec une communauté accessible en lecture et en écriture. La requête Walk : La commande WALK permet d'afficher les valeurs de tous les objets d'une même branche de l'arbre. Remarque : moins le chemin de la branche passée en paramètre dans la commande est long, plus la branche est grande, plus il y a d'objets. 11/41

12 Exemple : La requête Trap : Tout d'abord contrairement à toutes les autres requêtes, celle-ci est envoyée par l'agent SNMP vers la station de supervision. Elle met en œuvre un mécanisme d'alarme permettant à un agent d'informer le manager SNMP en cas de problème. A la réception d'un message TRAP, la station de supervision pourra alors essayer de traiter le problème. Par exemple si il s'agit d'un lien réseau rompu, l'administrateur réseau en est directement informé. Il existe 7 types de messages TRAPS : coldstart, warmstart, linkdown, linkup, authentificationfailure, egpneighborloss, entreprisespecific. Les réponses : En termes de réponse maintenant, à chaque envoi de requêtes SNMP est associée une réponse qui est retournée à la station de supervision à l'exception de la commande TRAP. Les réponses sont généralement du type : get-response : l'information est bien transmise, NoSuchObject : l'objet n'a pas été trouvé, NoAccess : l'accès à une partie de la MIB est interdit, NoWritable : impossibilité d'utiliser la commande SET sur l'objet concerné Il est utile de préciser qu'il existe d'autres commandes qui sont apparues après la première version de SNMP. Cependant nous avons présenté ici, uniquement les commandes existant dans toutes les versions de SNMP, les divers ajouts seront précisés lors du comparatif des différentes versions. 12/41

13 B - Analyse d'un échange de trames Voici ci-dessous un schéma récapitulant les principales commandes SNMP pouvant être effectuées entre un agent et son manager SNMP : L'utilisation du protocole de transport UDP favorise la rapidité des échanges entre manager et agent due au court en-tête du segment UDP. Les commandes get-request, get-next-request et setrequest sont toutes émises par le manager à destination d'un agent et attendent forcément une réponse à la requête de la part de l'agent concerné. Cependant la commande trap, elle, est émise d'un agent vers le manager et n'attend aucune réponse. Après avoir étudié les possibilités concernant les requêtes et les réponses SNMP, il serait intéressant de comparer les différentes versions afin d'observer les éventuels changements. 4) Comparatif des versions A - Historique global des versions Avant d'analyser les multiples versions du protocole, voici à titre informatif leurs histoires : SNMPv1 (ancien standard) 1990 : Ceci est la première version du protocole, tel que défini dans le RFC On dit que la sécurité de cette version est triviale, car la seule vérification qui est faite est basée sur la chaîne de caractères " community ". SNMPsec (historique) 1992 : Cette version ajoute de la sécurité au protocole SNMPv1. La sécurité est basée sur des groupes. Très peu ou aucun manufacturiers n'a utilisé cette version qui est maintenant largement oubliée. RFC /41

14 SNMPv2p (historique) 1993 : 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. La sécurité est basée sur les groupes de SNMPsec. SNMPv2c (expérimental) 1996 : Cette version du protocole est appelée " community stringbased SNMPv2 ". Ceci est une amélioration des opérations de protocole et des types d'opérations de SNMPv2p et utilise la sécurité par chaîne de caractères "community " de SNMPv1. RFC 1441 SNMPv2u (expérimental) 1996 : Cette version du protocole utilise les opérations, les types de données de SNMPv2c et la sécurité basée sur les usagers. SNMPv2* (expérimental) : Cette version combine les meilleures parties de SNMPv2p et SNMPv2u. Les documents qui décrivent cette version n'ont jamais été publiés dans les RFC. Des copies de ces documents peuvent être trouvées sur le site web et SNMP Research (un des premiers à défendre cette version). RFC 1901 SNMPv3 (standard actuel) entre 1999 et 2002 : Cette version comprend une combinaison de la sécurité basée sur les usagers et les types et les opérations de SNMPv2p, avec en plus la capacité pour les " proxies ". La sécurité est basée sur ce qui se trouve dans SNMPv2u et SNMPv2*. RFC 3411 B - SNMP v1 Comme son nom l'indique, il s'agit de la première version du protocole qui fut et qui est encore majoritairement utilisé par les administrateurs réseau. Cependant cette version a un défaut majeur qui est la sécurité. Elle est uniquement basée sur un nom de communauté, «public» par défaut, il suffit donc pour utiliser cette version que l'agent et le manager aient le même nom de communauté. Dans le but de mieux comprendre sur quoi repose cette version, nous allons procéder à une analyse de trame d'un message SNMP v1. 14/41

15 Structure d'un message SNMP v1/v2c : Description des champs : Version : il vaut 0 pour SNMP v1, 1 pour SNMP v2 Communauté : nom de communauté défini par l'administrateur en hexadécimal En bleu, le format du «proctocol data unit» (PDU) : Elle varie en fonction des commandes, Type : 0 pour GetRequest, 1 pour GetNextRequest, 2 pour Response, 3 pour SetRequest, 4 pour Trapv1, 5 pour GetBulkRequest, 6 pour InformRequest, 7 pour Trapv2, 8 pour Report ID : la requête et la réponse associée ont le même identifiant Statut d'erreur : - 0(noError) : pas d erreur, - 1(tooBig) : trop grand : l'agent ne peu répondre avec un seul message, - 2(noSuchName) : nom de la variable inconnu, elle n'existe pas, - 3(badValue) : mauvaise valeur, un ou plusieurs paramètres sont inexacts, - 4(readOnly) : lecture seulement, tentative de modification d'une variable en lecture seule, - 5(genErr) : autres. Index d'erreur : Spécifie la variable qui est source d'erreur 15/41

16 Pour la commande Trap : Entreprise : nom de l'agent qui transmet le message AdresseAgent : permet au manager de savoir de quel agent il s'agit Alarme générique : - 0(coldStart) : démarrage de l'agent, - 1(warmStart) : redémarrage, - 2 (linkdown) : l'interface passe à l'état bas, désactive l'envoi des messages trap de déconnexion ligne, - 3(linkUP) : l'interface passe à l'état bas, désactive l'envoi des messages trap de connexion ligne, - 4 (authentificationfailure) : problème d authentification : nom de communauté invalide - 5 (egpneighborloss) : perte de voisin, - 6 (enterprisespecific) : spécifique à l entreprise. Alarme spécifique : elle est utilisée afin d'identifier une TRAP spécifique à une entreprise. Pour la commande GetBulk (plus de détail dans la partie suivante) : Nombres objets simples : Lit les n premiers objets simples (comparable à un snmpget) Nombre maximum de répétitions : Essaie de lire les m occurrences des objets désignés (comparable à un snmpgetnext) Pour conclure avec cette version, on peut dire qu'elle plait beaucoup de par sa simplicité d'utilisation, mais aucun élément faisant intervenir la sécurité n'est présent ici. Il faut savoir qu'une version sécurisée de SNMP v1 appelé SNMPsec a existé, mais n'a pratiquement pas été utilisé. C - SNMP v2c Comme nous pouvons le constater dans l'historique précédemment cité, la version 2 du protocole SNMP, qui est bien sûr une évolution de SNMP v1, a connu de nombreux tests avant d'aboutir à une version stable. Mais, une seule a réussi à assurer la compatibilité avec SNMP v1 : SNMP v2c. Les principaux changements qui sont apparus dans cette 2e version sont l'ajout de nouvelles requêtes telles que GetBulkRequest, InformRequest ainsi qu'une trame Report. De plus cette version ajoute en outre de nouveaux éléments à la MIB tels que la branche Security et SNMP v2. 16/41

17 On peut rappeler également que la version 2 est basée sur le nom de communauté afin de restreindre l'accès aux équipements géré au seul administrateur. On peut ajouter qu'il existe dans la version 1 et 2c, 3 types de communautés : Communauté en lecture seule : autorise uniquement la lecture des objets, par conséquent impossibilité d'écrire, Communauté en lecture et écriture : autorise la lecture et la modification des objets, Communauté pour les évènements : utilisé par l'agent SNMP pour générer des Traps. La requête GetBulkRequest : Elle s'applique aux commandes vues dans SNMPv1 telles que get et walk, et leur ajoute un nouvel intérêt. Ce mot «Bulk» signifie en anglais volume et permet donc d'obtenir des informations en grandes quantités. Son but principal est de minimiser le nombre d'échange à travers le réseau en permettant au manager SNMP l'accès simultané à plusieurs variables de la MIB. Nous remarquerons qu'avec un Get «classique», il est également possible d'essayer de récupérer plusieurs valeurs de variable à la fois, mais si il y a rien qu'une seule erreur qui se produit parmi tous les objets demandés, l'agent ne renvoie rien au manager à part un message d'erreur. Avec la commande GetBulk, la requête porte sur un maximum de variables possible, avec la possibilité qu'en réponse il en manque quelques-unes. Elle utilise deux paramètres de plus que les autres commandes : NonRepeaters : lit les n premiers objets normaux (assimilable à SnmpGet), MaxRepetitions : essaie de lire les m occurrences des objets désignés (assimilable à SnmpGetNext). Exemple : snmpbulkget -v 2c -c public -Cn 1 -Cr system iftable sysdescr.0=string :"..." ifindex.1=integer:1 ifindex.2=integer:2 ifdescr.1 = STRING : ". " iftype.1= STRING: ". " iftype.2= STRING: ". " On fait un Get sur le premier objet qui apparaît dans la branche system ( ) donc, system.sysdescr.0 ( ), puis on fait un GetNext sur les 5 premiers objets de la branche iftable. 17/41

18 La requête Inform : Grâce à celle-ci, le manager informe l'agent qu'il a reçu un message Trap. C'est une sorte d'acquittement. Cette commande permet également à un manager SNMP de contacter un autre manager SNMP, au cas où il y aurait besoin de 2 stations d'administration, ceci pour l'informer d'un quelconque problème au sujet d'un équipement du réseau. La requête Report : Cette requête est apparue dans la version 2 de SNMP, cependant elle n'a jamais été utilisée pour celle-ci. Nous verrons par la suite que cette trame est présente lors de tout échange entre le manager et l'agent avec SNMP v3. Elle a pour rôle d'autoriser le manager à communiquer avec un de ses agents. Voici un diagramme présentant l'autorisation via la trame report : Finalement, en réponse à une administration simplifiée des routeurs, on peut dire que les deux premières versions de SNMP sont très performantes. Cela dit, lors d'une administration distante de matériels et puisque des données transitent dans le réseau lors de l'utilisation du protocole SNMP, on constate facilement le problème de ces deux versions : comment protéger et sécuriser les informations récupérées? En effet, on remarque que sur le format des trames SNMP v1 et SNMP v2 aucun champ n'est dédié à la sécurité de la communication. Dans l'objectif de résoudre ce problème, une nouvelle version majeure et récente a donc vu le jour : SNMP v3. D - SNMP v3 Cette version de SNMP a été essentiellement mise au point afin d'introduire la sécurité des communications. Cette sécurité comprend à la fois un dispositif d'identification des deux parties souhaitant communiquer, mais aussi une méthode d'encryptage qui permet de garder la communication «confidentielle». 18/41

19 Ce modèle de sécurité de SNMP v3 est principalement basé sur deux concepts : USM (User-based Security Model): Ce module gère trois fonctions. Chacun d'entre eux a pour but de limiter les attaques. L'authentification Elle a pour rôle d'empêcher la modification d'un paquet SNMP v3 qui est en cours d'envoi ainsi que de vérifier la validité du mot de passe de l'utilisateur. L'authentification s'appuie sur des fonctions de hachage cryptographique telles que MD5 (Message Digest 5) ou encore SHA (Secure Hash Algorithm) dans le but de réussir à «crypter» les mots de passe. Ces fonctions prennent en entrée une chaîne de caractères de longueur indéfinie, et génèrent en sortie une chaîne d'octets de longueur finie (16 octets pour MD5 et 20 octets pour SHA). De plus, pour garantir l'authenticité de l'information qui sera transmise, on doit fournir un mot de passe qui sera identique pour l'agent SNMP et le manager SNMP, il est préférable que celuici ne soit connu par personne d'autre. La figure ci-dessous explique le fonctionnement de l'authentification : Les principales étapes d'authentifications sont : L'émetteur groupe les données à transmettre avec le mot de passe d'authentification dans une sorte de paquet. Ce groupe est ensuite envoyé dans la fonction de hachage à une direction (ici MD5). Les données et le code de hachage sont ensuite transmis sur le réseau vers le destinataire. Le récepteur prend le bloc des données, et y ajoute le mot de passe d'authentification commun aux deux entités. Ce groupe est ensuite envoyé dans la fonction de hachage à une direction. Et enfin, si le code de hachage est identique à celui transmis, l'émetteur (en général, une station de supervision) est authentifié. 19/41

20 Le cryptage Il a pour but d'empêcher que toute personne écoutant sur le réseau les requêtes et les réponses de quelqu'un d'autre n'obtienne pas les informations de gestion propre à un équipement. Le cryptage, comme l'authentification, se base sur un mot de passe partagé entre l'agent et le manager. Encore une fois, ce mot de passe doit bien évidemment rester confidentiel. Cependant ces deux mots de passe sont complètement indépendants, ce qui permet au système de cryptage et au système d'authentification d'être aussi indépendant. SNMP v3 utilise le protocole de cryptage symétrique DES-56 (Data Encryption Standard) pour effectuer le cryptage de trame. La figure ci-dessous a pour but d'expliquer le fonctionnement du cryptage : On peut ajouter ici que, contrairement à l'authentification qui s'applique à tout le paquet SNMP v3, le cryptage, lui, est seulement appliqué sur le PDU (les données). L'estampillage de temps Lors de l'envoi d'une requête SNMP, l'authentification et le cryptage ne permettent pas d'éviter qu'une personne récupère cette requête dans l'intérêt de la retransmettre plus tard sur le réseau (Replay Attack). C'est donc maintenant que l'estampillage de temps intervient. Lorsque l'on reçoit un paquet SNMP v3, s'il y a une différence supérieure à 150 s entre la date de création de la trame et son traitement, elle est détruite. Par conséquent la trame SNMP v3 est effective sur un intervalle de temps restreint. VACM (View Access Control Model): Ce second module gère uniquement les restrictions d'accès à certaines parties de la MIB, mais aussi les droits d'accès en lecture et/ou écriture pour un certain groupe ou un certain utilisateur. Après avoir décrit les différents apports de cette version, il serait judicieux de s'intéresser aux modifications de la trame SNMP v3 : 20/41

21 Trame SNMP v3 et signification des champs Après avoir étudié les différentes versions du protocole SNMP ainsi que son fonctionnement, nous allons maintenant expliquer comment mettre en place ces trois versions sur un équipement réseau. III. Mise en œuvre du protocole SNMP sur un routeur Pour la réalisation de ce projet, nous disposons d'un routeur Cisco 1841 ainsi que de deux machines sous Windows XP. Côté manager SNMP (une des deux machines sous Windows XP), nous avons utilisé le logiciel NET-SNMP pour pouvoir effectuer des requêtes. Et côté équipement, nous avons utilisé hyperterminal afin de configuré le routeur. Voici un bref rappel des commandes de base d'hyperterminal : copy running-config flash:startup-config-projet-guillaume-jonathan permet de copier la configuration courante sur la carte flash du routeur. copy running-config startup-config permet de copier la configuration courante dans la configuration de démarrage. copy running-config tftp permet d'enregistrer la configuration dans un fichier texte, après avoir ouvert un serveur tftp. 21/41

22 1) Mise en place de SNMP v1 et SNMP v2 La mise en place de la version 1 active automatiquement la version 2c, aucune commande de configuration supplémentaire n'est nécessaire. Côté Manager SNMP (station de supervision) : Installation du service SNMP de Windows Paramétrage du ou des noms de la communauté Pour accéder à cette fenêtre, il suffit d'aller dans les Outils d'administration Windows, puis dans Service et chercher «Service SNMP». Dans notre cas nous avons configuré deux communautés : public : permettant seulement les requêtes de lecture sur l'agent private : permettant les requêtes de lecture ainsi que les requêtes de modifications On peut également effectuer un filtrage des adresses IP. Autrement dit, nous pouvons filtrer les paquets SNMP provenant de certains hôtes en acceptant, par exemple, uniquement les paquets SNMP provenant des différents agents que cette station administre. Cependant, nous avons ici accepté les paquets SNMP provenant de n'importe quel hôte. Installation du logiciel NET-SNMP C'est ce programme qui nous servira à communiquer en ligne de commandes avec le routeur Cisco /41

23 Côté Agent SNMP : Avant tout paramétrage de SNMP sur le routeur, il est obligatoire de configurer une des interfaces de celui-ci afin de pouvoir communiquer avec lui via les stations de supervision. Cependant nous ne détaillerons pas cette partie de la configuration, les détails apparaissent dans la configuration globale du routeur mise en annexe. Pour information l'adresse IP de l'interface du routeur par laquelle nous communiquons avec lui est Création d'un nom de communauté «public» en lecture seulement : snmp-server community public RO Création d'un nom de communauté «private» en lecture et écriture : snmp-server community private RO read-write Activation des messages traps en cas d'alerte sur l'agent : snmp-server enable traps Configuration de la machine, en général le manager SNMP, qui recevra les messages traps : snmp-server host public Test et analyse de trame SNMP v1 : snmpget -v 1 -c public sysuptime.0 23/41

24 Voici une petite analyse du résultat obtenu avec l'analyseur de trames : Test et analyse de trame SNMP v2c : snmpbulkget -v2c -c public -Cn1 -Cr system iftable Analyse de la commande : - Cn1 : on effectue un get sur le premier objet ce qui correspond au premier objet de la branche System. - Cr5 : on effectue cinq get-next sur les cinq premiers objets de la branche iftable. 24/41

25 2) Mise en place de SNMP v3 Avant de tester les différents fonctionnements possibles de SNMP v3, il y a deux choses à configurer sur le routeur commun aux trois fonctionnements présentés ci-dessous : Création d'une vue «SNMPvue» permettant en général de restreindre l'accès à certaines partie de la MIB (dans notre cas, toute la MIB est inclus dans la vue) : snmp-server view SNMPvue mib-2 included Le mécanisme des vues est géré par le module VACM, vu précédemment. Création du lien vers le Manager SNMP qui va superviser le réseau : snmp-server host version 3 priv guiguiauthpriv Les différentes notifications concernant le routeur seront envoyées à l'hôte possédant l'adresse De plus le mot clé «priv» signifie que ces notifications seront cryptées. Nous allons maintenant mettre en place, pas à pas, la version 3 du protocole SNMP en commençant par le fonctionnement le plus simple. A - Sans authentification et sans cryptage La possibilité la plus simple pour tester SNMP v3 est la méthode sans authentification et sans cryptage. Cependant cette méthode n'ayant pas un très grand intérêt, nous ne nous attarderons pas sur celle-ci. Nous souhaitons pour cela la configuration suivante : Nom du groupe : projetnoauth Nom utilisateur : guiguinoauth Les commandes à entrer dans l'hyperterminal pour configurer ce cas sont : snmp-server group projetnoauth v3 noauth read SNMPvue write SNMPvue Le mot clé «noauth» permet de définir un groupe pour lequel ses utilisateurs auront juste besoin d'un nom d'utilisateur pour communiquer, il n'y a pas besoin de mot de passe pour ce fonctionnement. snmp-server user guiguinoauth projetnoauth v3 La commande pour tester avec net-snmp cette version sans authentification et sans cryptage sur l'invité de commande est : snmpget -v 3 -u guiguinoauth -l noauthnopriv sysuptime.0 L'option -l permet de définir le niveau de sécurité utilisé pour l'échange SNMP. 25/41

26 Voici le résultat obtenu avec Wireshark et son analyse de trame : B - Avec authentification, mais sans cryptage On souhaite, a présent, tester SNMP v3 avec l'authentification et avec les paramètres suivant : Nom du groupe : projetauthnopriv Nom utilisateur : guiguiauthnopriv Les commandes à entrer dans l'hyperterminal pour configurer ce cas sont : snmp-server group projetauthnopriv v3 auth read SNMPvue write SNMPvue Le mot clé «auth» permet de définir un groupe pour lequel ses utilisateurs auront besoin d'un nom d'utilisateur ainsi que d'un mot de passe pour s'authentifier. snmp-server user guiguiauthnopriv projetauthnopriv v3 auth sha guiguiauthnopriv Nous avons utilisé ici le protocole SHA par simple choix personnel, nous aurions très bien pu faire la même chose avec MD5. 26/41

27 La commande pour tester cette version avec authentification, mais sans cryptage avec net-snmp est : snmpget -v 3 -u guiguiauthnopriv -l authnopriv -a SHA -A guiguiauthnopriv sysuptime.0 Voici le résultat obtenu avec wireshark et son analyse de trame : C - Avec authentification et avec cryptage Pour finir l'étude de SNMP v3 nous allons maintenant tester en plus de l'authentification l'encryption des trames afin de garantir la confidentialité des données transitant sur le réseau avec les paramètres suivants : nom du groupe : projetauthpriv nom utilisateur : guiguiauthpriv Les commandes à entrer dans l'hyperterminal pour configurer ce cas sont : snmp-server group projetauthpriv v3 priv read SNMPvue write SNMPvue 27/41

28 Le mot clé «priv» permet de définir un groupe pour lequel ses utilisateurs auront besoin d'un nom d'utilisateur et d'un mot de passe pour s'authentifier, ainsi que d'un mot de passe pour le cryptage des données.. snmp-server user guiguiauthpriv projetauthpriv v3 auth sha guiguiauthpriv priv des56 guiguiauthpriv#enc La commande pour tester cette version avec authentification et avec cryptage avec netsnmp est : snmpget -v 3 -u guiguiauthpriv -a SHA -A guiguiauthpriv -l authpriv -x des -X guiguiauthpriv#enc sysuptime.0 Voici le résultat obtenu avec wireshark et son analyse de trame : Après avoir mis en place la version la plus évoluée du protocole SNMP v3, il serait maintenant intéressant de s'attarder sur l'analyse d'un message TRAP lors d'une requête SNMP v1 ou même v2c. 28/41

29 Échange de trames lors d'un message TRAP snmpget -v 1 -c publihc sysuptime.0 La requête SNMP v1 du manager vers l'agent avec un nom de communauté incorrect : Trame intermédiaire envoyée de l'agent vers le manager : On peut observer ici que malgré l'émission d'une requête avec la version 1 comportant un nom de communauté incorrect, on obtient tout de même une réponse intermédiaire cryptée. Cette réponse est envoyée par l'utilisateur guiguiauthpriv configuré auparavant (snmp-server host version 3 priv guiguiauthpriv). 29/41

30 Trame de type TRAP : Sur cette trame, on peut voir comme indiqué ci-dessus, l'adresse de l'agent d'où provient le message TRAP (utile lorsque le manager SNMP gère plusieurs agents). De plus, il est précisé le type de TRAP dont il s'agit, il correspond ici à une mauvaise authentification (authenticationfailure). La configuration de ces différentes versions sur le routeur fut la partie la plus intéressante de ce projet. Cependant elle fut aussi la plus complexe, en particulier à cause des différents problèmes rencontrés. 3) Problèmes rencontrés et solutions apportées Durant notre projet, nous nous sommes heurtés à des problèmes qui n'étaient pas prévus lors de la planification. Ceux-ci nous ont bloqués, nous empêchant de percer les secrets de la troisième version du protocole qui était la plus intéressante. Le premier problème fut au niveau du système d exploitation implémenté dans le routeur. Nous nous sommes aperçus, à force d'essayer de faire fonctionner le cryptage des données envoyées par les trames, que ce système d'exploitation Cisco, IP Base, n'était qu'une version basique qui ne permettait pas cette option. De plus, ce système d'exploitation ne permettait pas de mettre en œuvre l'authentification via SHA, il supportait seulement MD5. Par chance, l'iut a pu nous fournir un routeur plus performant implémentant une version plus poussée, en terme de système d'exploitation. Pour illustrer une nouvelle fois l'utilité du protocole SNMP nous pouvons connaître le nom de ce système d'exploitation via cette commande : snmpget -v 1 -c public sysdescr.0 SNMPv2-MIB::sysDescr.0 = STRING : Cisco IOS Software, 1841 Software (C1841-ADVIPSERVICESK9-M), Version 15.0(1)M3, RELEASE SOFTWARE (fc2) Technical Support : Copyright (c) by Cisco Systems 30/41

31 C'est ainsi que notre avancée vers la mise en place de la version 3 a pu se poursuivre. Le deuxième problème qui a fait suite à celui-ci était un problème de version logiciel sur la station de supervision. Pour faire fonctionner la version 3 de SNMP avec le cryptage, nous avions besoin d'un petit programme, OpenSSL, utilisé par net-snmp qui avait pour but de chiffrer les informations. Ce petit programme venait de subir une mise à jour qui présentait des bugs et qui nous empêchait de faire fonctionner correctement les commandes SNMP v3, il fut simplement nécessaire de retourner à la version antérieure qui était stable pour que là le cryptage soit opérationnel. Notre capacité d'adaptation durant ce projet nous a ainsi permis de confronter nos connaissances à des problèmes spontanés. Conclusion SNMP est donc devenu le standard incontournable dans le domaine de la supervision et de l'administration de réseaux informatiques. Cependant la première version du protocole est toujours la plus utilisée par les entreprises de par sa simplicité. Dans quelques années, la dernière version devrait sans doute être de plus en plus prisée par les administrateurs réseau, car elle présente tout de même des avantages non négligeables tels que la sécurité, qui est devenue ces dernières années un élément clé des systèmes d'informations, et la compatibilité avec IPv6. 31/41

32 Glossaire DES -56 (Data Encryption Standard) : C'est un algorithme de chiffrement des données permettant de faire transiter des données en toute confidentialité. Le chiffrement est réalisé sur le message en clair par bloc de 64 bits. Il est basé sur un ensemble de transformations composé de transpositions, de substitutions et d'opérations non linéaires réaliser sur le texte à chiffrer, afin que le message encrypté soit le plus difficile possible à décrypter. MD5 (Message Digest Algorithm) : C'est un algorithme de chiffrement générant une clef de 128 bits quelque soit la taille du message de départ et permet de vérifier l'intégrité des données d'un message. Lors du transfert d'un message signé par une clef MD5, l'émetteur génère une clef MD5, sorte d'empreinte digitale du message, puis envoie le message avec la clef au destinataire. A la réception le destinataire va de nouveau calculer la clef MD5 du message et la comparer avec celle envoyée par l'émetteur. Si les deux clefs sont identiques, la transmission s'est bien passée, dans le cas contraire le destinataire sait que le message a été altéré durant la transmission et peut éventuellement demander sa réémission. OSI (Open Systems Interconnection) : C'est un modèle qui a été défini par l'iso (Organisation Internationale de normalisation) en Il décrit les concepts utilisés et les étapes à suivre pour réaliser une interconnexion entre réseaux hétérogènes. Ainsi tout type de réseaux devaient respecter ces normes. Ce modèle est organisé sous forme d'une pile contenant 7 couches (Annexe n 5). SHA (Secure Hash Algorithm) : Mis au point en 1993 par l'agence de sécurité nationale américaine (NSA), SHA est un algorithme de cryptage, qui est parfois appelé prise d'empreinte. Il est notamment utilisé pour les paiements en ligne. Son principe repose sur l'établissement d'une chaîne de caractères, de taille fixe, appelée clé. C'est donc cette clé qui servira de référence pour l'authentification. Trame : Dans le domaine des réseaux, une trame est un bloc d'information binaire transmis sur un support physique, tels que les câbles coaxiaux ou fibre optique, d'un émetteur vers un destinataire. UDP (User Datagram Protocol) : C'est un protocole qui permet la transmission de données de manière très simple entre deux machines désirant communiquer. 32/41

33 Bibliographie Présentation du protocole SNMP : Historique du protocole SNMP : Fonctionnement du protocole SNMP : Mise en place complète de la version 3 : Mise en place de la version 3 : Définitions pour le glossaire : /41

34 Annexes Annexe n 1 : Configuration complète du routeur Cisco 1841 Current configuration : 7816 bytes Last configuration change at 08:50:17 UTC Tue Mar by tp version 15.0 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname Routeur boot-start-marker boot system flash c1841-advipservicesk9-mz m3.bin boot-end-marker logging buffered warnings enable secret 5 $1$c4mT$Go2XwVZI7onZc3zkcRjxG/ no aaa new-model crypto pki trustpoint TP-self-signed enrollment selfsigned subject-name cn=ios-self-signed-certificate revocation-check none rsakeypair TP-self-signed crypto pki certificate chain TP-self-signed certificate self-signed D A6 A D0609 2A F70D E30 2C F532D 53656C66 2D E65642D D E17 0D A170D A E302C F 532D5365 6C662D E65 642D D F300D 06092A F70D D B27EB16D E CEC FBFE9388 3AA0FBF3 B83FAE3F C5EDA9C D31C8C49 9C A22C DDAC1A89 F5B2441B 2F88B01C 7B7C2894 E795BCC2 B3B8CA87 5C01BCC4 04D7649F 42940CD6 A49B2C50 1B54FD1E A2A2EEBB 9C6D979E A 3E13D92F 39DC8848 8FCBC145 C2BFCCA FEC EE133F79 7D5F200F A F D FF FF D 11040B F F D E 14B4862F 34/41

35 1AA9473D 0957D681 B6CE0991 4AD8B530 1D D0E E14 B4862F1A A9473D09 57D681B6 CE09914A D8B5300D 06092A F70D E5 BEF01553 F0112A33 515E395C FE162AB2 F8329D69 70A5449A F18C A17F8 CBB0BA80 D7FBA4E2 E05BD19F 39B04B5A 1DB249EF FF351D4F AE4ACE0E 22FA88A9 15B EA34 B9077C71 7BB0DC C01B 878D6E8D 871CB061 2DF53566 D1F896D7 3BE4B8CF D44536DC 454A674D A8891C12 CFD7D740 D7 quit dot11 syslog ip source-route no ip routing no ip cef no ipv6 cef multilink bundle-name authenticated license udi pid CISCO1841 sn FCZ1435C2AM username admin privilege 15 secret 5 $1$uZxn$7/JgILgRRhRAVUqvBTjRI0 username tp privilege 0 secret 5 $1$VksD$456wtvj.J4BEp.Ct/Lf7a. redundancy interface FastEthernet0/0 ip address no ip route-cache duplex auto speed auto interface FastEthernet0/1 no ip address no ip route-cache shutdown duplex auto speed auto 35/41

36 ip forward-protocol nd ip http server ip http access-class 23 ip http authentication local ip http secure-server ip http timeout-policy idle 60 life requests access-list 23 permit snmp-server user guiguinoauth projetnoauth v3 snmp-server group projetnoauth v3 noauth read SNMPvue write SNMPvue snmp-server group projetauthpriv v3 priv read SNMPvue write SNMPvue snmp-server group projetauthnopriv v3 auth read SNMPvue write SNMPvue snmp-server view SNMPvue mib-2 included snmp-server community public RO snmp-server community private RO read-write snmp-server location TPReseaux snmp-server contact guillaume_jonathan snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart snmp-server enable traps vrrp snmp-server enable traps ds1 snmp-server enable traps tty snmp-server enable traps eigrp snmp-server enable traps ospf state-change snmp-server enable traps ospf errors snmp-server enable traps ospf retransmit snmp-server enable traps ospf lsa snmp-server enable traps ospf cisco-specific state-change nssa-trans-change snmp-server enable traps ospf cisco-specific state-change shamlink interface-old snmp-server enable traps ospf cisco-specific state-change shamlink neighbor snmp-server enable traps ospf cisco-specific errors snmp-server enable traps ospf cisco-specific retransmit snmp-server enable traps ospf cisco-specific lsa snmp-server enable traps envmon snmp-server enable traps adslline snmp-server enable traps c3g snmp-server enable traps license snmp-server enable traps flash insertion removal snmp-server enable traps icsudsu snmp-server enable traps isdn call-information snmp-server enable traps isdn layer2 snmp-server enable traps isdn chan-not-avail snmp-server enable traps isdn ietf 36/41

37 snmp-server enable traps ds0-busyout snmp-server enable traps ds1-loopback snmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop conf ig snmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service -up snmp-server enable traps disassociate snmp-server enable traps deauthenticate snmp-server enable traps authenticate-fail snmp-server enable traps dot11-qos snmp-server enable traps switch-over snmp-server enable traps rogue-ap snmp-server enable traps wlan-wep snmp-server enable traps rf snmp-server enable traps aaa_server snmp-server enable traps atm subif snmp-server enable traps bgp snmp-server enable traps bulkstat collection transfer snmp-server enable traps memory bufferpeak snmp-server enable traps cnpd snmp-server enable traps config-copy snmp-server enable traps config snmp-server enable traps config-ctid snmp-server enable traps dsp card-status snmp-server enable traps dsp oper-state snmp-server enable traps entity snmp-server enable traps fru-ctrl snmp-server enable traps resource-policy snmp-server enable traps event-manager snmp-server enable traps frame-relay multilink bundle-mismatch snmp-server enable traps frame-relay snmp-server enable traps frame-relay subif snmp-server enable traps hsrp snmp-server enable traps ipmulticast snmp-server enable traps isis snmp-server enable traps mpls traffic-eng snmp-server enable traps mpls fast-reroute protected snmp-server enable traps mpls rfc ldp snmp-server enable traps mpls ldp snmp-server enable traps msdp snmp-server enable traps mvpn snmp-server enable traps pim neighbor-change rp-mapping-change invalid-pim-messa ge snmp-server enable traps pppoe snmp-server enable traps cpu threshold snmp-server enable traps rsvp snmp-server enable traps ipsla snmp-server enable traps syslog snmp-server enable traps l2tun session snmp-server enable traps l2tun pseudowire status 37/41

38 snmp-server enable traps vtp snmp-server enable traps pw vc snmp-server enable traps firewall serverstatus snmp-server enable traps ipmobile snmp-server enable traps nhrp nhs snmp-server enable traps nhrp nhc snmp-server enable traps nhrp nhp snmp-server enable traps nhrp quota-exceeded snmp-server enable traps isakmp policy add snmp-server enable traps isakmp policy delete snmp-server enable traps isakmp tunnel start snmp-server enable traps isakmp tunnel stop snmp-server enable traps ipsec cryptomap add snmp-server enable traps ipsec cryptomap delete snmp-server enable traps ipsec cryptomap attach snmp-server enable traps ipsec cryptomap detach snmp-server enable traps ipsec tunnel start snmp-server enable traps ipsec tunnel stop snmp-server enable traps ipsec too-many-sas snmp-server enable traps mpls vpn snmp-server host informs version 3 priv guiguiauthpriv snmp-server host version 3 priv guiguiauthpriv snmp-server host public control-plane 38/41

39 Annexe n 2 : Liste des utilisateurs SNMP créés pour la mise en place Routeur#show snmp user User name : guiguinoauth Engine ID : DC7B storage-type : nonvolatile active Authentication Protocol : None Privacy Protocol : None Group-name : projetnoauth User name : guiguiauthpriv Engine ID : DC7B storage-type : nonvolatile active Authentication Protocol: SHA Privacy Protocol : DES Group-name : projetauthpriv User name : guiguiauthnopriv Engine ID : DC7B storage-type : nonvolatile active Authentication Protocol: SHA Privacy Protocol : None Group-name : projetauthnopriv Annexe n 3 : Liste des groupes SNMP (il y en a beaucoup qui sont créés par défauts) Routeur#show snmp group groupname : ILMI readview : *ilmi security model:v1 writeview : *ilmi notifyview: <no notifyview specified> row status : active groupname : ILMI readview : *ilmi security model:v2c writeview : *ilmi notifyview: <no notifyview specified> row status : active groupname : public readview : v1default security model:v1 writeview: <no writeview specified> notifyview: *tv.ffffffff.ffffffff.ffffffff.f row status: active 39/41

40 groupname : public readview : v1default security model:v2c writeview: <no writeview specified> notifyview: <no notifyview specified> row status : active groupname : private readview : v1default security model:v1 writeview: <no writeview specified> notifyview: <no notifyview specified> row status : active access-list: read-write groupname : private readview : v1default security model:v2c writeview: <no writeview specified> notifyview: <no notifyview specified> row status : active access-list: read-write groupname : projetnoauth readview : SNMPvue security model:v3 noauth writeview : SNMPvue notifyview: <no notifyview specified> row status : active groupname : projetauthpriv readview : SNMPvue security model:v3 priv writeview : SNMPvue notifyview: <no notifyview specified> row status : active groupname : projetauthnopriv readview : SNMPvue security model:v3 auth writeview : SNMPvue notifyview: <no notifyview specified> row status : active 40/41

41 Annexe n 4 : Liens de téléchargement des programmes utiles à ce projet Lien de téléchargement SNMPutil : Lien de téléchargement NET-SNMP 5.5 x86.exe : Lien de téléchargement Openssl 0.9 Light : Annexe n 5 : Les couches du modèle OSI ( Le modèle OSI Numéro Nom Rôle Couche 7 Applicative C'est à ce niveau que sont les logiciels : navigateur, logiciel d' , FTP, chat... Couche 6 Présentation Elle est en charge de la représentation des données (de telle sorte qu'elle soit indépendante du type de microprocesseur ou du système d'exploitation par exemple) et - éventuellement - du chiffrement. Couche 5 Session En charge d'établir et maintenir des sessions (c'est-à-dire débuter le dialogue entre 2 machines : vérifier que l'autre machine est prête à communiquer, s'identifier, etc.) Couche 4 Transport En charge de la liaison d'un bout à l'autre. S'occupe de la fragmentation des données en petits paquets et vérifie éventuellement qu'elles ont été transmises correctement. Couche 3 Réseau En charge du transport, de l'adressage et du routage des paquets. Couche 2 Liaison données Couche 1 Physique de En charge d'encoder (ou moduler) les données pour qu'elles soient transportables par la couche physique, et fournie également la détection d'erreur de transmission et la synchronisation. C'est le support de transmissions lui-même : un fil de cuivre, une fibre optique, les ondes hertziennes... HTTP, FTP, TCP, UDP, IP, ICMP, PPP, Ethernet et la totalité des autres protocoles entrent dans le modèle OSI. Chaque protocole est situé dans une couche précise du modèle OSI : Quand vous abordez un protocole que vous ne connaissez pas, essayez de savoir à quel niveau des couches OSI il se place, et avec quels autres protocoles il communique. Cela vous aidera à mieux le comprendre. 41/41