SNMP (Simple Network Management Protocol) très utilisé dans l’administration réseau 1. Introduction
Le protocole SNMP (Simple Network Management Protocol) est très utilisé dans le milieu de l’administration réseau.
En effet, il permet de simplifier grandement la maintenance des réseaux en fournissant aux administrateurs la possibilité d’obtenir de nombreuses informations sur des équipements présents sur le réseau tels que des serveurs, des routeurs ou encore des commutateurs.
Le recueil de ces informations permet d’être informé à tout moment de ce qui se passe sur le réseau et permet de réagir rapidement en cas de problème sur celui-ci, notamment en permettant le management à distance des différents équipements réseaux utilisant le protocole SNMP.
De plus, ce protocole fonctionne suivant un mode « client / serveur » ce qui permet à un administrateur de n’obtenir les informations recueillies par les équipements réseaux que lorsqu’il en fait la demande ou lorsqu’une alerte aura été déclenchée.
Afin d’éviter tout détournement d’information ou contrôle non autorisé sur ces divers équipements, il est également possible d’instaurer des mesures de sécurité permettant de s’assurer que seules des personnes autorisées puissent consulter ces bases d’informations et interagir avec ces équipements.
2.Principe et concept de SNMP
2.1 Le protocole SNMP définit des échanges entre un client et un serveur afin de :
- Connaître l’état d’un appareil.
- Gérer les évènements exceptionnels.
- Mesurer le trafic et les erreurs à distance.
- Configurer les appareils à distance.
2.2 Le protocole SNMP a 4 principaux avantages :
- Il est simple et facile d’utilisation.
- Il implémente la gestion à distance.
- Il est indépendant des architectures.
- Il est très performant au niveau de gestion et de la surveillance des machines.
Voici un exemple implémentant des services de serveillance réseau via le protocole SNMP :
3.L’architecture du protocole SNMP
3.1 Principe de client serveur
Le protocole SNMP est un protocole appartenant à la couche 7 du modèle de référence OSI (couche application). Vous trouverez ci-dessous un schéma récapitulatif des différentes couches du modèle OSI ainsi que quelques exemples de protocoles utilisés pour chacune de ces couches :
Nous pouvons l’assimiler à une relation client serveur puisque une requête est envoyée par le client SNMP en utilisant le protocole UDP, ce qui signifie que des accusés de réception ne sont pas envoyé, et une réponse lui est renvoyée par l’équipement qui a été interrogé. Si la requête n’a pas été transmise correctement, il faut la renvoyer.
L’agent écoute le réseau sur le port UDP 161. De même le manager écoute les traps (autrement dit alarmes) sur le port UDP 162.
Chacune des informations récoltées est enregistrée dans une base. Cette base d’information (MIB) est classée suivant une structure arborescente, comme nous le verrons par la suite.
3.2 La MIBLa MIB est une base de donnée qui contient des variables, contenant les diverses informations récoltées par l’agent SNMP.
Toutes ces variables sont normalisées par différentes normes ISO. Lorsque l’administrateur réseau recherche des informations sur une variable précise, la structure normalisée selon le type de données, lui facilite le travail.
3.3 Qu’est ce qu’un agent et un manager ?La gestion du réseau est basée sur deux principaux éléments:
3.3.1 L’agent et le manager
3.3.1.1 L’agent
C’est avant tout un serveur puisque celui-ci écoute un port UDP qui est indispensable sur chaque équipement réseau que l’on voudrait manager à distance.
L’agent est un logiciel qui fonctionne sur différents éléments réseaux tel qu’un hub, switch ou un routeur et/ou sur une station de travail ou sur un serveur. L’envoi des messages par l’élément réseau est assuré par celui-ci.
Les messages sont envoyés par les agents suite à :
- Une requête envoyée par le manager.
- Un événement important.
Les réponses reçues donnent des informations sur le statut d’une interface réseau, sur la version du système en place, sur l’état des tables de routage, etc...
3.3.1.2 Le manager :
C’est le client qui envoie les requêtes aux différents agents SNMP du réseau. Il se comporte comme un serveur puisqu’il est à l’écoute du port UDP 162.
De plus des alertes peuvent être émise par le client à n’importe quel moment ce qui permet une autonomie du réseau.
4.1 Communauté SNMP et sécurité
Une communauté est une chaîne de caractère. Il existe deux types de communauté : public et privé.
Une communauté publique peut lire des informations, alors qu’une communauté privée peut lire ajouter ou modifier des informations. On l’utilise dans les requêtes SNMP pour permettre d’établir des règles de sécurité. Ses règles ont pour but de restreindre l’accès aux utilisateurs aux différentes informations sur le réseau, et de vérifier et modérer les différents types d’actions auxquels ils ont accès.
Un agent SNMP est plus ou moins finement paramétré pour répondre aux requêtes dont le paramètre communauté est validé dans sa configuration. Chaque communauté SNMP est définie par une chaîne d'octets, ainsi que le nom de la communauté.
Afin d’assurer la sécurité des opérations, le protocole SNMP utilise la notion de message authentique. Il se définit comme un message pour lequel on a contrôlé que l’entité d’application qui l’émet est bien membre de la communauté spécifiée dans ce message.
Une administration sécurisée utilisant des entités applicatives basées sur SNMP doit obligatoirement avoir des services d'authentification capables d'identifier et de contrôler la validité et l’authenticité des messages SNMP. La seule identification possible réside sur le paramètre « communauté ».
4.2 Avantages et inconvénients de SNMPIl est possible de définir un niveau d’opération en lecture seule, ou en lecture/écriture pour plusieurs communautés. En règle générale la communauté publique à des droits en lecture seule sur des données non sensible. Des requêtes qui seraient effectuées avec un paramètre « communauté » inconnu ne sera pas traité.
Nous pouvons donc consulter des informations, modifier des paramètres et créer des alarmes. Tout cela, en principe, indépendamment du matériel et du logiciel. Il faut donc que SNMP permette de retrouver ces informations et d'agir sur les paramètres grâce à la MIB.
4. La communauté SNMP
4.1 Communauté SNMP et sécurité
Une communauté est une chaîne de caractère. Il existe deux types de communauté : public et privé.
Une communauté publique peut lire des informations, alors qu’une communauté privée peut lire ajouter ou modifier des informations. On l’utilise dans les requêtes SNMP pour permettre d’établir des règles de sécurité. Ses règles ont pour but de restreindre l’accès aux utilisateurs aux différentes informations sur le réseau, et de vérifier et modérer les différents types d’actions auxquels ils ont accès.
Un agent SNMP est plus ou moins finement paramétré pour répondre aux requêtes dont le paramètre communauté est validé dans sa configuration. Chaque communauté SNMP est définie par une chaîne d'octets, ainsi que le nom de la communauté.
Afin d’assurer la sécurité des opérations, le protocole SNMP utilise la notion de message authentique. Il se définit comme un message pour lequel on a contrôlé que l’entité d’application qui l’émet est bien membre de la communauté spécifiée dans ce message.
Une administration sécurisée utilisant des entités applicatives basées sur SNMP doit obligatoirement avoir des services d'authentification capables d'identifier et de contrôler la validité et l’authenticité des messages SNMP. La seule identification possible réside sur le paramètre « communauté ».
4.2 Avantages et inconvénients de SNMPIl est possible de définir un niveau d’opération en lecture seule, ou en lecture/écriture pour plusieurs communautés. En règle générale la communauté publique à des droits en lecture seule sur des données non sensible. Des requêtes qui seraient effectuées avec un paramètre « communauté » inconnu ne sera pas traité.
Nous pouvons donc consulter des informations, modifier des paramètres et créer des alarmes. Tout cela, en principe, indépendamment du matériel et du logiciel. Il faut donc que SNMP permette de retrouver ces informations et d'agir sur les paramètres grâce à la MIB.
6. Echange de messagesLes commandes Get-request, Get next request, Set request sont elles, émise du manager vers l’agent, et la commande Get response est émise de l’agent vers le manager.
La commande Trap est une alerte. Elle est toujours émise par l'agent vers le manager, et celle-ci n'attend pas de réponse.
Le format PDU de Get request, Get next request, Get response, et Set request est représenter comme suit :
Les différents types de PDU sont énoncés ci-dessous :
0=> Get request.
1=> Get next request.
2=> Get response.
3=> Set request.
L’id de la requête est en fait un nombre entier qui met en relation la requête demandée par le manager, et la réponse de l’agent.
L’erreur de statut indique si les opérations effectuées sont valides ou invalides. Si celle si ne sont pas valide il renvoie un nombre entier afin de spécifier de quel type d’erreur il s’agit.
L’erreur d’index identifie l'entrée dans la liste d'attaches variable qui a causé l'erreur.
Les objets et valeur représentent les différentes variables se liant entre elles avec leurs noms et leurs valeurs.
6.1 Les GETGet request : Ce message interroge la MIB d’un agent.
Get next request : Le manager reçoit le contenu de la variable qu’il a demandé.
Get response : Accusé de réception des messages Get-request, Get-next-request et Set-request.
6.2 Les SET et TRAP
Set-request : Permet de modifier une variable dans la MIB.
Trap : C’est une alarme informant qu’il existe une anomalie sur le réseau.
PDU : 4 bits
Identifieur de la requête : 4bits
Erreur de statut : 4bits
Erreur d’index : 4bits
Objet x valeur x : variable
6.2.4 Format des requêtes SNMP TRAPv2
PDU : 4 bits
Champ qui associe la requête à la réponse : 4 bits
Identification d’une possible erreur : 4 bits
Associe une erreur a un objet : 4 bits
Objet x et valeur x : variable
6.2.5 Format des requêtes SNMP TRAPV3
Message de version : 4 bits
Message ID : 4 bits
Message de taille maximum : 4 bits
Message des drapeaux : 1 bits
Message du modèle de sécurité : 4 bits
Message des paramètres de sécurité : Variable
Portée du PDU : Variable
7. Les différences et différentes version du protocole SNMP
WQIl semble essentiel de préciser la différence qui existe entre SNMPv1, SNMPv2, et SNMPv3 qui n’est pas représenté ici.
La version SNMPv1 est la moins sécurisée puisque la seule protection qu’elle a est constituée d'une « community string » qui soit dit en passant circule en clair sur le réseau.
Les principales différences entre SNMPv1 et SNMPv2 est qu’en 1993, les RFC 1441 à 1452 ont été rajouter aux RFC de SNMPv1, qui ont donc formé le protocole SNMPv2 avec les RFC 2571 à 2575 . Il en est de même pour SNMPv3.
Les modifications apportées sont les suivantes :
- Les requêtes SNMP ont été redéfinies.
- Création de deux nouvelles branches dans la MIB : SNMPv2, et SNMPv2-M2M (manager to manager)
- Les failles de sécurités ont été colmatées. Il n’y a plus de « community string » en clair sur le réseau, ainsi qu’une authentification des requêtes a été mis en place.
La version SNMP v2 est une évolution plus sécurisé de la version 1 que nous pourrions qualifier d’intermédiaire à la version SNMPv3 qui a obtenu une sécurité optimale avec de nombreuses options supplémentaires. Cependant nous tenons a préciser que SNMPv3 bien qu’il existe reste peu déployé 8. Commandes générique à SNMP
- Activation du protocole SNMP
snmp enable
- Configuration du manager avec un délais d’expiration
snmp-server manager
snmp-server manager session-timeout 10000
- Création d’une communauté publique
snmp-server community name ro
- Création d’une communauté privée
snmp-server community name rw
- Désactivation de l’agent SNMP
no snmp-server
- Configuration de l’extinction d’équipement
snmp-server system-shutdown
· Configuration d’une requête trap :
snmp-server host host [traps | informs][version {1 | 2c | 3 [auth | noauth | priv]} ] community-string [udp-port port] [notification-type]
exemple : snmp-server host 192.168.0.40 snmpv1 public bay-controller environment module
- Configuration d’un nouvel utilisateur
snmp-server user username [groupname remote ip-address
[udp-port port] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password [priv des56 priv password]] [access access-list]
exemple : snmp-server user userone groupone v1 9. Exemple commandes de configuration SNMP
L’exemple suivant autorise l’adresse IP 192.168.0.1.
Puis active le protocole SNMP.
Il autorise ensuite la lecture seule sur la community1,
Et la lecture/écriture sur la communauté2.
Il nous spécifie que M. Dupont est la personne à contacter en cas de problème.
Et le localise à SUPINFO Paris.
Enfin il activation de la capture des requêtes SNMP,
Et configuration de l’interface à capturer (loopback).
Lab-Cisco (config)#access-list 7 permit 192.168.0.1
Lab-Cisco (config)#snmp enable
Lab-Cisco (config)#snmp-server community community1 ro 7
Lab-Cisco (config)#snmp-server community community2 rw 7
Lab-Cisco (config)#snmp-server contact Jean Dupont (33 145 296 445)
Lab-Cisco (config)#snmp-server location SUPINFO Paris
Lab-Cisco (config)#snmp enable traps
Lab-Cisco (config)#snmp trap-source lo0SNMPv2 reste la version la plus stable et la plus utilisé pour le moment de SNMP.
10. Structure du MIB
La MIB est une arborescence comparable pour un informaticien à une arborescence de fichiers.
Elle contient 3 grandes parties :
- Une partie commune à tous les agents SNMP en général.
- Une partie commune à tous les agents SNMP d’un même type de matériel.
- Une partie spécifique à chaque constructeur.
La structure de la MIB est normalisée ainsi que ses appellations des diverses rubriques.
Ses appellations ne servent a rien à part a améliorer la lisibilité de la structure.
L’utilité principale de la MIB, est de contenir une sorte de répertoire pour les administrateurs réseaux avec toutes les informations dont ils ont besoin afin de gérer au mieux le réseau, ainsi que les défaillance de celui-ci.
Il faut de plus savoir que chaque niveau de la hiérarchie de la MIB est indexé numériquement comme dans le tableau qui suit :
Il nous parait essentiel de spécifier que les branches qui n’aboutissent pas sur ce schéma sont aussi là pour indiquer qu’il y a des éléments que nous n’avons pas prit la peine de détailler ici.
De plus les branches qui semblent terminées ne le sont pas forcément puisque pour une meilleure lisibilité nous avons simplifier notre exemple mais cela ne signifie pas qu’il n’y ait pas d’autre sous branches.
CCITT (Comité Consultatif International Télégraphique et Téléphonique).
Propose des normes, dont le nom commence par « T » pour le fax, « V » pour les télécoms ou téléphone et « X » pour les réseaux (publics). Le CCITT n'existe plus, il a été remplacé par l'UIT-T, aussi appelé ITU-T (si on est anglophone).
Les implémentations en texte comme standard(0) par exemple peuvent très bien varier d’une implémentation à l’autre, mais ce qui ne varie jamais en revanche c’est l’index numérique placé entre parenthèse.
Ce système à un très grand potentiel car il peut être adapté à de nombreux domaines. Pour le réseau IP par exemple il est clair que le nœud dod(6) puis Internet(1) sera le plus utilisé.
Comme l’arborescence dépend de l’agent, il pourrait être pratique de connaître la structure de cette arborescence grâce à un outil qui existe déjà dans le manager SNMP.
Si vous rechercher des informations plus complète sur la composition de la MIB je vous invite a consulter ses différentes RFC : RFC 1095 (CMOT) 1213 (MIB-II) 1212 (MIB)et 1189 (CMOT & CMIP).
11. Utilité de SNMP au niveau du monitoring:Grâce à toutes les alertes, nous pouvons nous rendre compte de la congestion réseaux, des saturations de bande passante, etc...
Nous pouvons de plus modéré une trop forte utilisation du réseau,vérifier les états de fonctionnement des différents équipements ou serveurs ainsi que toutes les autres entités du réseau et pour cela de nombreux logiciel comme Nagios nous propose une interface graphique très complète.
Exemple : Imaginons le cas d’une entreprise commerciale dont les revenus dépendent des activités de leur site Web.
Une panne du serveur Web signifierait une perte de bénéfice pour l’entreprise, surtout si cette panne dure longtemps.
Grâce au protocole SNMP et à son système d’alertes, l’administrateur réseau pourra accroître sa réactivité en cas de problème et réparer les serveurs ou équipements réseaux tombés en panne au plus vite.
En effet, le SNMP pourra lui permettre de connaître pratiquement en temps réel l'état du réseau et lui permettre de le surveiller de la manière la plus efficiente possible.
12. Screenshot du logiciel de monitoring Nagios :
(http://www.nagios.org/screenshot.php)
12.1 Détail des statuts :
12.2 Exemple d’histogramme Nagios :
