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