DUPARO Jonathan-Minh CHERRUAU Guillaume Session …

DUPARO Jonathan-MinhCHERRUAU Guillaume

Session 2010/2011

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.

Session 2010/2011 - Le protocole SNMP - 2/41

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.........................................................................................13

4) Comparatif des versions ...........................................................................................................13 A - Historique global des versions...........................................................................................13 B - SNMP v1............................................................................................................................14 C - SNMP v2c..........................................................................................................................16 D - SNMP v3............................................................................................................................18

III. Mise en œuvre du protocole SNMP sur un routeur .....................................................................21

1) Mise en place de SNMP v1 et SNMP v2...................................................................................22

2) Mise en place de SNMP v3.......................................................................................................25 A - Sans authentification et sans cryptage................................................................................25 B - Avec authentification, mais sans cryptage.........................................................................26 C - Avec authentification et avec cryptage...............................................................................27

3) Problèmes rencontrés et solutions apportées.............................................................................30

Conclusion..........................................................................................................................................31

Glossaire.............................................................................................................................................32

Bibliographie......................................................................................................................................33

Annexes..............................................................................................................................................34


Introduction

Dans le cadre de notre deuxième année de DUT, nous avons l'occasion de réaliser une étudecomplète sur un des sujets proposés aux étudiants par différents enseignants. Cette longue étude, quis'est déroulée durant plus de 6 mois (s'étalant sur deux semestres) et qui a eu pour moyenne 300h detravail personnel par étudiant, se finalise par ce rapport complet répondant au sujet de l'enseignant-tuteur. 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 leprotocole SNMP (Simple Network Management Protocol). Les différentes fonctionnalités desversions 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 quasi-totalité 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é.


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.


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 :


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 :

• .1.3.6.1.2. NumObjet

• .iso.identifiedorganization.dod.internet.mgmt.NomObjet


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éesExemple 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 statiquesExemple 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 routageExemple d'objets gérés par cette branche : ipInReceives : Nombre de datagramme IP reçus

• Icmp : Statistiques du protocole ICMPExemple 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 connexionExemple d'objets gérés par cette branche : tcpInSegs : Nombre de segments TCP reçus

• Udp : Statistiques UDPExemple 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


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.


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. 1.3.6.1.2.1.1.1.0 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.


snmpgetnext – v n° version -c communauté Ipdestinataire OID


Pour bien comprendre son rôle, nous allons effectuer quatre commandes différentes :

snmputil get Ipbinôme communauté. 1.3.6.1.2.1.1.1

snmputil getnext Ipbinôme communauté. 1.3.6.1.2.1.1

snmputil getnext Ipbinôme communauté. 1.3

snmputil getnext Ipbinôme communauté. 1.3.6.1.2.1.1.0

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.


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.


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.


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 set-request 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 1157. 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 1155


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.


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


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.


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 5 192.168.0.254 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 (.1.3.6.1.2.1.1) donc, system.sysDescr.0 (.1.3.6.1.2.1.1.1), puis on fait un GetNext sur les 5 premiers objets de la branche ifTable.


➢ 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 ».


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 celui-ci 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é.


➔ 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 :


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.


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-SNMPC'est ce programme qui nous servira à communiquer en ligne de commandes avec le routeur Cisco 1841.


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 192.168.0.254.

• 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 192.168.0.1 public

Test et analyse de trame SNMP v1 :

snmpget -v 1 -c public 192.168.0.254 sysUpTime.0


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 -Cr5 192.168.0.254 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.


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 192.168.0.1 version 3 priv guiguiAuthPriv

Les différentes notifications concernant le routeur seront envoyées à l'hôte possédant l'adresse 192.168.0.1. 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 192.168.0.254 sysUpTime.0

L'option -l permet de définir le niveau de sécurité utilisé pour l'échange SNMP.


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


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.


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 192.168.0.254 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


snmp-server group projetAuthPriv v3 priv read SNMPvue write SNMPvue


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 net-snmp est :

snmpget -v 3 -u guiguiAuthPriv -a SHA -A guiguiAuthPriv -l authPriv -x des -X guiguiAuthPriv#enc! 192.168.0.254 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.


Échange de trames lors d'un message TRAP

snmpget -v 1 -c publihc 192.168.0.254 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 192.168.0.1 version 3 priv guiguiAuthPriv).


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 (authentication-failure).

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 192.168.0.254 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 : http://www.cisco.com/techsupport. Copyright (c) 1986-2010 by Cisco Systems


http://www.cisco.com/techsupport

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.


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

1977. 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.


Bibliographie

Présentation du protocole SNMP :http://irp.nain-t.net/doku.php/215snmp:10_le_principe

Historique du protocole SNMP :http://www.frameip.com/snmp/

Fonctionnement du protocole SNMP :http://ram-0000.developpez.com/tutoriels/reseau/SNMP/

Mise en place complète de la version 3 :http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/Snmp3.html

Mise en place de la version 3 :http://www.loriotpro.com/ServiceAndSupport/How_to/howto_snmpv3_cisco_EN.php

Définitions pour le glossaire :http://www.dicodunet.com

http://www.wikipedia.fr


http://www.wikipedia.fr/

http://www.dicodunet.com/

http://www.loriotpro.com/ServiceAndSupport/How_to/howto_snmpv3_cisco_EN.php

http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/Snmp3.html

http://ram-0000.developpez.com/tutoriels/reseau/SNMP/

http://www.frameip.com/snmp/

http://irp.nain-t.net/doku.php/215snmp:10_le_principe

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 8 2011 by tp!version 15.0service timestamps debug datetime msecservice timestamps log datetime msecno service password-encryption!hostname Routeur!boot-start-markerboot system flash c1841-advipservicesk9-mz.150-1.M3.binboot-end-marker!logging buffered 51200 warningsenable secret 5 $1$c4mT$Go2XwVZI7onZc3zkcRjxG/!no aaa new-model!!!!crypto pki trustpoint TP-self-signed-983331843 enrollment selfsigned subject-name cn=IOS-Self-Signed-Certificate-983331843 revocation-check none rsakeypair TP-self-signed-983331843!!crypto pki certificate chain TP-self-signed-983331843 certificate self-signed 01 3082023D 308201A6 A0030201 02020101 300D0609 2A864886 F70D0101 04050030 30312E30 2C060355 04031325 494F532D 53656C66 2D536967 6E65642D 43657274 69666963 6174652D 39383333 33313834 33301E17 0D313130 33303830 38343130 325A170D 32303031 30313030 30303030 5A303031 2E302C06 03550403 1325494F 532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3938 33333331 38343330 819F300D 06092A86 4886F70D 01010105 0003818D 00308189 02818100 B27EB16D 671588E4 83223CEC FBFE9388 3AA0FBF3 B83FAE3F C5EDA9C4 82688789 D31C8C49 9C056115 3102A22C DDAC1A89 F5B2441B 2F88B01C 7B7C2894 E795BCC2 B3B8CA87 5C01BCC4 04D7649F 42940CD6 A49B2C50 1B54FD1E A2A2EEBB 9C6D979E 9555446A 3E13D92F 39DC8848 8FCBC145 C2BFCCA5 34210FEC EE133F79 7D5F200F 02030100 01A36730 65300F06 03551D13 0101FF04 05300301 01FF3012 0603551D 11040B30 09820752 6F757465 7572301F 0603551D 23041830 1680148E 14B4862F


1AA9473D 0957D681 B6CE0991 4AD8B530 1D060355 1D0E0416 04148E14 B4862F1A A9473D09 57D681B6 CE09914A D8B5300D 06092A86 4886F70D 01010405 00038181 001691E5 BEF01553 F0112A33 515E395C FE162AB2 F8329D69 70A5449A F18C5782 14000535 687A17F8 CBB0BA80 D7FBA4E2 E05BD19F 39B04B5A 1DB249EF FF351D4F AE4ACE0E 22FA88A9 15B62543 5899EA34 B9077C71 7BB0DC25 1914C01B 878D6E8D 871CB061 2DF53566 D1F896D7 3BE4B8CF D44536DC 454A674D A8891C12 CFD7D740 D7 quitdot11 syslogip source-routeno ip routing!!!!no ip cefno ipv6 cef!multilink bundle-name authenticated!!!license udi pid CISCO1841 sn FCZ1435C2AMusername admin privilege 15 secret 5 $1$uZxn$7/JgILgRRhRAVUqvBTjRI0username tp privilege 0 secret 5 $1$VksD$456wtvj.J4BEp.Ct/Lf7a.!redundancy!!!!!!!!!interface FastEthernet0/0 ip address 192.168.0.254 255.255.255.0 no ip route-cache duplex auto speed auto !!interface FastEthernet0/1 no ip address no ip route-cache shutdown duplex auto speed auto !!


ip forward-protocol ndip http serverip http access-class 23ip http authentication localip http secure-serverip http timeout-policy idle 60 life 86400 requests 10000!!!access-list 23 permit 10.10.10.0 0.0.0.7!!!!snmp-server user guiguiNoAuth projetNoAuth v3snmp-server group projetNoAuth v3 noauth read SNMPvue write SNMPvuesnmp-server group projetAuthPriv v3 priv read SNMPvue write SNMPvuesnmp-server group projetAuthNoPriv v3 auth read SNMPvue write SNMPvuesnmp-server view SNMPvue mib-2 includedsnmp-server community public ROsnmp-server community private RO read-writesnmp-server location TPReseauxsnmp-server contact guillaume_jonathansnmp-server enable traps snmp authentication linkdown linkup coldstart warmstart

snmp-server enable traps vrrpsnmp-server enable traps ds1snmp-server enable traps ttysnmp-server enable traps eigrpsnmp-server enable traps ospf state-changesnmp-server enable traps ospf errorssnmp-server enable traps ospf retransmitsnmp-server enable traps ospf lsasnmp-server enable traps ospf cisco-specific state-change nssa-trans-changesnmp-server enable traps ospf cisco-specific state-change shamlink interface-old

snmp-server enable traps ospf cisco-specific state-change shamlink neighborsnmp-server enable traps ospf cisco-specific errorssnmp-server enable traps ospf cisco-specific retransmitsnmp-server enable traps ospf cisco-specific lsasnmp-server enable traps envmonsnmp-server enable traps adsllinesnmp-server enable traps c3gsnmp-server enable traps licensesnmp-server enable traps flash insertion removalsnmp-server enable traps icsudsusnmp-server enable traps isdn call-informationsnmp-server enable traps isdn layer2snmp-server enable traps isdn chan-not-availsnmp-server enable traps isdn ietf


snmp-server enable traps ds0-busyoutsnmp-server enable traps ds1-loopbacksnmp-server enable traps ethernet cfm cc mep-up mep-down cross-connect loop configsnmp-server enable traps ethernet cfm crosscheck mep-missing mep-unknown service-upsnmp-server enable traps disassociatesnmp-server enable traps deauthenticatesnmp-server enable traps authenticate-failsnmp-server enable traps dot11-qossnmp-server enable traps switch-oversnmp-server enable traps rogue-apsnmp-server enable traps wlan-wepsnmp-server enable traps rfsnmp-server enable traps aaa_serversnmp-server enable traps atm subifsnmp-server enable traps bgpsnmp-server enable traps bulkstat collection transfersnmp-server enable traps memory bufferpeaksnmp-server enable traps cnpdsnmp-server enable traps config-copysnmp-server enable traps configsnmp-server enable traps config-ctidsnmp-server enable traps dsp card-statussnmp-server enable traps dsp oper-statesnmp-server enable traps entitysnmp-server enable traps fru-ctrlsnmp-server enable traps resource-policysnmp-server enable traps event-managersnmp-server enable traps frame-relay multilink bundle-mismatchsnmp-server enable traps frame-relaysnmp-server enable traps frame-relay subifsnmp-server enable traps hsrpsnmp-server enable traps ipmulticastsnmp-server enable traps isissnmp-server enable traps mpls traffic-engsnmp-server enable traps mpls fast-reroute protectedsnmp-server enable traps mpls rfc ldpsnmp-server enable traps mpls ldpsnmp-server enable traps msdpsnmp-server enable traps mvpnsnmp-server enable traps pim neighbor-change rp-mapping-change invalid-pim-messagesnmp-server enable traps pppoesnmp-server enable traps cpu thresholdsnmp-server enable traps rsvpsnmp-server enable traps ipslasnmp-server enable traps syslogsnmp-server enable traps l2tun sessionsnmp-server enable traps l2tun pseudowire status


snmp-server enable traps vtpsnmp-server enable traps pw vcsnmp-server enable traps firewall serverstatussnmp-server enable traps ipmobilesnmp-server enable traps nhrp nhssnmp-server enable traps nhrp nhcsnmp-server enable traps nhrp nhpsnmp-server enable traps nhrp quota-exceededsnmp-server enable traps isakmp policy addsnmp-server enable traps isakmp policy deletesnmp-server enable traps isakmp tunnel startsnmp-server enable traps isakmp tunnel stopsnmp-server enable traps ipsec cryptomap addsnmp-server enable traps ipsec cryptomap deletesnmp-server enable traps ipsec cryptomap attachsnmp-server enable traps ipsec cryptomap detachsnmp-server enable traps ipsec tunnel startsnmp-server enable traps ipsec tunnel stopsnmp-server enable traps ipsec too-many-sassnmp-server enable traps mpls vpnsnmp-server host 192.168.0.1 informs version 3 priv guiguiAuthPrivsnmp-server host 192.168.0.1 version 3 priv guiguiAuthPrivsnmp-server host 192.168.0.1 public!!control-plane !!


Annexe n°2 : Liste des utilisateurs SNMP créés pour la mise en place

Routeur#show snmp user

User name : guiguiNoAuthEngine ID : 800000090300DC7B94949306storage-type : nonvolatile activeAuthentication Protocol : NonePrivacy Protocol : NoneGroup-name : projetNoAuth

User name : guiguiAuthPrivEngine ID : 800000090300DC7B94949306storage-type : nonvolatile activeAuthentication Protocol: SHAPrivacy Protocol : DESGroup-name : projetAuthPriv

User name : guiguiAuthNoPrivEngine ID : 800000090300DC7B94949306storage-type : nonvolatile activeAuthentication Protocol: SHAPrivacy Protocol : NoneGroup-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 security model:v1readview : *ilmi writeview : *ilmi

notifyview: <no notifyview specified>row status : active

groupname : ILMI security model:v2creadview : *ilmi writeview : *ilmi


groupname : public security model:v1readview : v1default writeview: <no writeview specified>

notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.Frow status: active


groupname : public security model:v2creadview : v1default writeview: <no writeview specified>


groupname : private security model:v1readview : v1default writeview: <no writeview specified>

notifyview: <no notifyview specified>row status : active access-list: read-write

groupname : private security model:v2creadview : v1default writeview: <no writeview specified>

notifyview: <no notifyview specified>row status : active access-list: read-write

groupname : projetNoAuth security model:v3 noauthreadview : SNMPvue writeview : SNMPvue


groupname : projetAuthPriv security model:v3 privreadview : SNMPvue writeview : SNMPvue


groupname : projetAuthNoPriv security model:v3 authreadview : SNMPvue writeview : SNMPvue



Annexe n°4 : Liens de téléchargement des programmes utiles à ce projet

Lien de téléchargement SNMPutil :http://membres.multimania.fr/devinfo/snmp.html

Lien de téléchargement NET-SNMP 5.5 x86.exe :http://sourceforge.net/projects/net-snmp/files/net-snmp%20binaries/5.5-binaries/

Lien de téléchargement Openssl 0.9 Light :http://openssl-light.software.informer.com/0.9/

Annexe n°5 : Les couches du modèle OSI (http://sebsauvage.net/comprendre/tcpip/osi.html)

Le modèle OSINuméro Nom RôleCouche 7 Applicative C'est à ce niveau que sont les logiciels : navigateur, logiciel d'email,

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 de

donnéesEn 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.

Couche 1 Physique 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.


http://openssl-light.software.informer.com/0.9/

http://sourceforge.net/projects/net-snmp/files/net-snmp%20binaries/5.5-binaries/

http://membres.multimania.fr/devinfo/snmp.html

DUPARO Jonathan-Minh CHERRUAU Guillaume Session …

Documents

Transcript of DUPARO Jonathan-Minh CHERRUAU Guillaume Session …