SNMP - Simple Network Management Protocol

1 - Introduction
2 - SNMP (Simple Network Management Protocol)
        2.1- Présentation générale
        2.2- Fonctionnement
        2.3- Les MIBS
3 - Présentation, évolution des versions de SNMP
4 - SNMPv1 et v2
        4.1- Les faiblesses de SNMPv1
        4.2- Les améliorations de SNMPv2c
5 - SNMP v3
        5.1 - User Security Module (USM)
                5.1.1 - L'authentification
                5.1.2 - Le chiffrement
                5.1.3 - L'estampillage de temps
        5.2 - VACM (View Access Control Model)
        5.3 - La trame de SNMPv3
6 - Exemple de trame SNMP
7 - Conclusion

1 - Introduction

L'informatique est de plus en plus présent dans notre vie de tous les jours. On compte désormais sur les services offerts par les réseaux pour le fonctionnement de l'outil informatique, que ce soit en entreprise, lors de transactions bancaires, lors de téléconférences, etc. Les services offerts sont devenus quasi-indispensables. Pour assurer que ces services soient convenables, il est nécessaire de surveiller le réseau et d'agir quand une erreur se produit.

Sur les réseaux physiques de nombreuses composantes sont donc à surveiller : l'utilisation de la largeur de bande, l'état de fonctionnement des liens, les éventuels goulets d'étranglement, les problèmes de câblage, le bon cheminement de l'information entre les machines, etc. Pour ce faire différents points stratégiques sont à observer comme les routeurs, les concentrateurs, les liens, les postes, les imprimantes.

Ainsi, en cas de panne ou de mauvais fonctionnement sur le réseau, l'administrateur doit pouvoir interpréter l'information reçue pour identifier la source du problème. Un protocole de gestion est nécessaire pour exercer les fonctions de gestion sur un réseau. Il doit être capable de dialoguer avec tous les éléments de celui-ci.

2 - SNMP (Simple Network Management Protocol)

2.1- Présentation générale

SNMP (Simple Network Management Protocol) est le protocole de gestion de réseaux proposé par l'IETF. Il est actuellement le protocole le plus utilisé pour la gestion des équipements de réseaux.
SNMP est un protocole relativement simple. Pourtant l'ensemble de ses fonctionnalités est suffisamment puissant pour permettre la gestion des réseaux hétérogènes complexes. Il est aussi utilisé pour la gestion à distance des applications: les bases de données, les serveurs, les logiciels, etc.

L'environnement de gestion SNMP est constitué de plusieurs composantes : la station de supervision, les éléments actifs du réseau, les variables MIB et un protocole. Les différentes composantes du protocole SNMP sont les suivantes:

Les éléments actifs du réseau sont les équipements ou les logiciels que l'on cherche à gérer. Cela va d'une station de travail à un concentrateur, un routeur, un pont, etc. Chaque élément du réseau dispose d'une entité dite agent qui répond aux requêtes de la station de supervision. Les agents sont des modules qui résident dans les éléments réseau. Ils vont chercher l'information de gestion comme par exemple le nombre de paquets en reçus ou transmis.

• La station de supervision (appelée aussi manager) exécute les applications de gestion qui contrôlent les éléments réseaux. Physiquement, la station est un  poste de travail.
• La MIB (Management Information Base) est une collection d'objets résidant dans une base d'information virtuelle. Ces collections d'objets sont définies dans des modules MIB spécifiques.
• Le protocole, qui permet à la station de supervision d'aller chercher les informations sur les éléments de réseaux et de recevoir des alertes provenant de ces mêmes éléments.

2.2- Fonctionnement

Le protocole SNMP est basé sur un fonctionnement asymétrique. Il est constitué d'un ensemble de requêtes, de réponses et d'un nombre limité d'alertes. Le manager envoie des requêtes à l'agent, lequel retourne des réponses. Lorsqu'un événement anormal surgit sur l'élément réseau, l'agent envoie une alerte (trap) au manager.

SNMP utilise le protocole UDP [RFC 768]. Le port 161 est utilisé par l'agent pour recevoir les requêtes de la station de gestion. Le port 162 est réservé pour la station de gestion pour recevoir les alertes des agents.

Les requêtes SNMPIl existe quatre types de requêtes: GetRequest, GetNextRequest, GetBulk, SetRequest.

• La requête GetRequest permet la recherche d'une variable sur un agent.
• La requête GetNextRequest permet la recherche de la variable suivante.
• La requête GetBulk permet la recherche d'un ensemble de variables regroupées.
• La requête SetRequest permet de changer la valeur d'une variable sur un agent.

Les réponses de SNMPÀ la suite de requêtes, l'agent répond toujours par GetResponse. Toutefois si la variable demandée n'est pas disponible, le GetResponse sera accompagné d'une erreur noSuchObject.

Les alertes (Traps, Notifications)Les alertes sont envoyées quand un événement non attendu se produit sur l'agent. Celui-ci en informe la station de supervision via une trap. Les alertes possibles sont: ColdStart, WarmStart, LinkDown, LinkUp, AuthentificationFailure.

2.3- Les MIBS

La MIB (Management Information base) est la basé de données des informations de gestion maintenue par l'agent, auprès de laquelle le manager va venir pour s'informer.

Deux MIB publics ont été normalisées: MIB I et MIB II (dite 1 et 2)

Un fichier MIB est un document texte écrit en langage ASN.1 (Abstract Syntax Notation 1) qui décrit les variables, les tables et les alarmes gérées au sein d'une MIB.

La MIB est une structure arborescente dont chaque noeud est défini par un nombre ou OID (Object Identifier).
Elle contient 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 et une partie spécifique à chaque constructeur. Chaque équipement à superviser possède sa propre MIB. Non seulement la structure est normalisée, mais également les appellations des diverses rubriques.

Ces appellations ne sont présentes que dans un souci de lisibilité. En réalité, chaque niveau de la hiérarchie est repéré par un index numérique et SNMP n'utilise que celui-ci pour y accéder.

Voici un exemple de structure de table MIB :

Ainsi, pour interroger les différentes variables d'activité sur un appareil, il faudra explorer son arborescence MIB. Celle-ci est généralement fournie par le constructeur mais il est aussi possible d'utiliser un explorateur de MIB tel que « Getif MIB Browser ».

Ensuite, pour accéder aux variables souhaitées, on utilisera l'OID (Object Identification) qui désigne l'emplacement de la variable à consulter dans la MIB. On aura par exemple sur un commutateur Nortel Passport l'OID .1.3.6.1.4.1.2272.1.1.20 désignant le taux de charge du CPU.

Lorsqu'une entreprise veut définir son propre ensemble de variables de gestion, elle va enregistrer son numéro d'objet sous le noeud iso.org.dod.internet.private.entreprise. Ces MIB seront dites privées. Elles correspondent à la racine 1.3.6.1.4.1. Voici la liste de toutes les affectations officielles :

entreprise.0-4998
entreprise.5000-9999
entreprise.10000-14999
entreprise.14999-19999
entreprise.20000-24999
entreprise.25000-27274

3 - Présentation, évolution des versions de SNMP

Voici les différentes versions de SNMP:

• SNMPv1 (ancien standard): Ceci est la première version du protocole, tel que définie 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): 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): Beaucoup de travaux on é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): Cette version du protocole est appelé " 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): 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 12 les RFC. Des copies de ces documents peuvent être trouvées sur le site web et SNMP Research (un des premiers à défendre de cette version).
  RFC - 1901
   
• SNMPv3 (standard actuel): 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

4 - SNMPv1 et v2

La trame SNMPv1 est complètement encodée en ASN.1 [ISO 87]. Les requêtes et les réponses ont le même format

• La version la plus utilisée est encore la version 1. Plusieurs versions 2 ont été proposées par des documents de travail, mais malheureusement, aucune d'entre elles n'a jamais été adoptée comme standard. La version 3 est actuellement en voie d'être adoptée. On place la valeur zéro dans le champ version pour SNMPv1, et la valeur 3 pour SNMPv3.
   
• La communauté permet de créer des domaines d'administration. La communauté est décrite par une chaîne de caractères. Par défaut, la communauté est « PUBLIC».
   
• Le PDU (Packet Data Unit).

Le « PDU type » décrit le type de requête, de réponse ou d'alerte. Le Tableau 2 donne les valeurs associées à ces champs.

Le « Request ID » permet à la station de gestion d'associer les réponses à ses requêtes.
Le « Error Status » est l'indicateur du type d'erreur. Si aucune erreur ne s'est produite, ce champ est mis à zéro. Les réponses négatives possibles sont décrites dans le tableau suivant :

4.1- Les faiblesses de SNMPv1

Une des plus grandes faiblesses du protocole SNMPv1 est l'absence d'un mécanisme adéquat pour assurer la confidentialité et la sécurité des fonctions de gestion. Les faiblesses comprennent aussi l'authentification et le chiffrement, en plus de l'absence d'un cadre administratif pour l'autorisation et le contrôle d'accès. Ce problème rend la sécurité sur SNMPv1 du type : "SHOW-AND-TELNET", c'est à dire qu'on utilise SNMP pour l'acquisition des données de gestion, mais pas pour effectuer le contrôle on utilise le protocole Telnet.

Le groupe de travail de l'IETF qui a oeuvré sur SNMPv2 a voulu inclure la sécurité dans la nouvelle version. Malheureusement, ce groupe n'a pas pu atteindre un consensus sur le fonctionnement du mécanisme de sécurité. Partant de là, deux propositions ont été développées (SNMPv2u et SNMPv2*). La plupart des experts s'entendent pour dire que deux standards SNMP ne peuvent pas coexister, et que ceci n'est pas une solution à long terme.

Tous les consensus du groupe de travail ont été rassemblés (uniquement les améliorations qui ne portaient pas sur la sécurité), et le groupe de travail SNMPv2 de l'IETF a terminé ses travaux en publiant une version de SNMPv2 (on l'appelle SNMPv2c, RFC 1901, RFC 1905 et RFC 1906) sans sécurité.

4.2- Les améliorations de SNMPv2c

SNMPv2c a introduit quelques nouveaux types, mais sa nouveauté majeure est l'opération GETBULK, qui permet à une plate forme de gestion, de demander en bloc de plusieurs variables consécutives dans la MIB de l'agent. Généralement, on demande autant de variables que l'on peut mettre dans un paquet SNMP. Ceci règle un problème majeur de performance dans SNMPv1. Avec la version 1, la plate forme est obligée de faire un GETNEXT et d'attendre la réponse pour chaque variable de gestion.

5 - SNMP v3

Cette nouvelle version du protocole SNMP vise essentiellement à inclure la sécurité des transactions. La sécurité comprend l'identification des parties qui communiquent et l'assurance que la conversation soit privée, même si elle passe par un réseau public.

Cette sécurité est basée sur 2 concepts :

• USM (User-based Security Model)
• VACM (View- based Access Control Model)

5.1 - User Security Module (USM)

Trois mécanismes sont utilisés. Chacun de ces mécanismes a pour but d'empêcher un type d'attaque.

• L'authentification : Empêche quelqu'un de changer le paquet SNMPv3 en cours de route et de valider le mot de passe de la personne qui transmet la requête.
• Le chiffrement : Empêche quiconque de lire les informations de gestions contenues dans un paquet SNMPv3.
• L'estampillage du temps : Empêche la réutilisation d'un paquet SNMPv3 valide a déjà transmis par quelqu'un.

5.1.1 - L'authentification

L'authentification a pour rôle d'assurer que le paquet reste inchangé pendant la transmission, et que le mot de passe est valide pour l'usager qui fait la requête.

Pour construire ce mécanisme, on doit avoir connaissance des fonctions de hachage à une seule direction. Des exemples de ces fonctions sont : MD5 et SHA-1. 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, 20 octets pour SHA-1).

Pour authentifier l'information qui va être transmise, on doit aussi avoir un mot de passe qui est « partagé ». Le mot de passe ne doit donc être connu que par les deux entités qui s'envoient les messages, et préférablement par personne d'autre.

La figure ci dessous montre le mécanisme d'authentification :

Les étapes d'authentification sont les suivantes :

• Le transmetteur groupe des informations à transmettre avec le mot de passe.
• On passe ensuite ce groupe dans la fonction de hachage à une direction.
• Les données et le code de hachage sont ensuite transmis sur le réseau.
• Le receveur prend le bloc des données, et y ajoute le mot de passe.
• On passe ce groupe dans la fonction de hachage à une direction.
• Si le code de hachage est identique à celui transmis, le transmetteur est authentifié.

Avec cette technique, le mot de passe est validé sans qu'il ait été transmis sur le réseau. Quelqu'un qui saisit les paquets SNMPv3 passants sur le réseau ne peut pas facilement trouver le mot de passe.

Pour ce qui est de SNMPv3, l'authentification se fait à l'aide de HMAC-MD5-96 ou de HMAC-SHA- 96, qui est un peu plus compliqué que ce qui a été décrit ici. Le résultat de la fonction de hachage est placé dans le bloc paramètres de sécurité du paquet SNMPv3.

L'authentification se fait sur tout le paquet.

L'étape d'authentification ne vise pas à cacher l'existence du paquet ou à le chiffrement. Si l'on utilise uniquement l'authentification, les personnes qui saisissent les paquets passants sur le réseau peuvent encore en voir le contenu. Toutefois, elles ne peuvent pas changer le contenu sans connaître le mot de passe.

5.1.2 - Le chiffrement

Le chiffrement a pour but d'empêcher que quelqu'un n'obtienne les informations de gestion en écoutant sur le réseau les requêtes et les réponses de quelqu'un d'autre.

Avec SNMPv3, le chiffrement de base se fait sur un mot de passe « partagé » entre le manager et l'agent. Ce mot de passe ne doit être connu par personne d'autre. Pour des raisons de sécurité, SNMPv3 utilise deux mots de passe : un pour l'authentification et un pour le chiffrement. Ceci permet au système d'authentification et au système de chiffrement d'être indépendants. Un de ces systèmes ne peut pas compromettre l'autre.

SNMPv3 se base sur DES (Data Encryption Standard) pour effectuer le chiffrement.

On utilise une clé de 64 bits (8 des 64 bits sont des parités, la clé réelle est donc longue de 56 bits) et DES chiffrement 64 bits à la fois. Comme les informations que l'on doit chiffrer sont plus longues que 8 octets, on utilise du chaînage de blocs DES de 64 bits.

Une combinaison du mot de passe, d'une chaîne aléatoire et d'autres informations forme le « Vecteur d'initialisation ». Chacun des blocs de 64 bits est passé par DES et est chaîné avec le bloc précédent avec un XOR. Le premier bloc est chaîné par un XOR au vecteur d'initialisation. Le vecteur d'initialisation est transmis avec chaque paquet dans les « Paramètres de sécurité », un champs qui fait partie du paquet SNMPv3.

Contrairement à l'authentification qui est appliquée à tout le paquet, le chiffrement est seulement appliquée sur le PDU.

La RFC 3826 "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model" relate l'intégration d'AES dans SNMP. Celui renforce le chiffrement en remplacement du DES. Cependant, pour le moment, cette RFC est en cours de validation et donc pas encore officialisée.

5.1.3 - L'estampillage de temps

Si une requête est transmise, les mécanismes d'authentification et de chiffrement n'empêchent pas quelqu'un de saisir un paquet SNMPv3 valide du réseau et de tenter de le réutiliser plus tard, sans modification.

Par exemple, si l'administrateur effectue l'opération de remise à jours d'un équipement, quelqu'un peut saisir ce paquet et tenter de le retransmettre à l'équipement à chaque fois que cette personne désire faire une mise à jour illicite de l'équipement. Même si la personne n'a pas l'autorisation nécessaire, elle envoie un paquet, authentifié et chiffré correctement pour l'administration de l'équipement.

On appelle ce type d'attaques le « Replay Attack ». Pour éviter ceci, le temps est estampillé sur chaque paquet. Quand on reçoit un paquet SNMPv3, on compare le temps actuel avec le temps dans le paquet. Si la différence est plus que supérieur à 150 secondes, le paquet est ignoré.

SNMPv3 n'utilise pas l'heure normale. On utilise plutôt une horloge différente dans chaque agent. Ceux-ci gardent en mémoire le nombre de secondes écoulées depuis que l'agent a été mis en circuit. Ils gardent également un compteur pour connaître le nombre de fois où l'équipement a été mis en fonctionnement. On appelle ces compteurs BOOTS (Nombre de fois ou l'équipement a été allumé) et TIME (Nombre de secondes depuis la dernière fois que l'équipement a été mis en fonctionnement).

La combinaison du BOOTS et du TIME donne une valeur qui augmente toujours, et qui peut être utilisée pour l'estampillage. Comme chaque agent a sa propre valeur du BOOTS/TIME, la plate-forme de gestion doit garder une horloge qui doit être synchronisée pour chaque agent qu'elle contacte. Au moment du contact initial, la plateforme obtient la valeur du BOOTS/TIME de l'agent et synchronise une horloge distincte.

5.2 - VACM (View Access Control Model)

Permet le contrôle d'accès au MIB. Ainsi on a la possibilité de restreindre l'accès en lecture et/ou écriture pour un groupe ou par utilisateur.

5.3 - La trame de SNMPv3

Le format de la trame SNMPv3 est très différent du format de SNMPv1. Ils sont toutefois codés tous deux dans le format ASN.1 [ISO 87]. Ceci assure la compatibilité des types de données entres les ordinateurs d'architectures différentes.

Pour rendre plus facile la distinction entre les versions, le numéro de la version SNMP est placé tout au début du paquet. Toutefois, le contenu de chaque champ varie selon la situation. Selon que l'on envoie une requête, une réponse, ou un message d'erreur, les informations placées dans le paquet respectent des règles bien définies dans le standard. Voici comment les champs d'un paquet SNMPv3 sont remplis :

Version SNMP
Pour SNMPv3, on place la valeur 3 dans ce champ. On place 0 pour un paquet SNMPv1.

Identificateur de message
Ce champ est laissé à la discrétion du moteur SNMP. On retrouve souvent des algorithmes, où le premier message de requête est envoyé avec un nombre aléatoire et les suivants avec les incréments de 1. Les paquets qui sont émis en réponse à une requête portent la même identification que le paquet de la requête.

Taille maximale
Le moteur choisit la taille maximale d'une réponse à une requête selon ses capacités en mémoire tampon et ses limites à décoder de longs paquets. Quand on envoie une réponse à une requête, on doit veiller à ne pas dépasser la taille maximale.

Drapeaux
Trois bits sont utilisés pour indiquer :
- Si une réponse est attendue à la réception de ce paquet. (Reportable Flag)
- Si un modèle de chiffrement a été utilisé (Privacy Flag)
- Si un modèle d'authentification a été utilisé (Authentification Flag)

Le modèle de sécurité
Ce module identifie le type de sécurité qui est utilisé pour chiffrer le reste du paquet. Cet identificateur doit identifier de façon unique chaque module de sécurité. Actuellement, l'algorithme de chiffrement DES (Data Encryption Standard) et l'algorithme d'authentification HMAC-MD5-96 ont été choisis comme algorithmes utilisés dans SNMPv3. HMAC-SHA-96 est optionnel.

Les informations de sécurité
Ces informations ne sont pas décrites dans le standard SNMPv3, ce bloc est laissé au soin des modules de sécurité. D'un module de sécurité à un autre, ces informations seront différentes. Le module de sécurité DES a standardisé le contenu de ce bloc.

Les identificateurs de contextes
Avec SNMPv1, il était possible d'avoir une seule base d'informations (MIB) par agent. Ceci n'est pas suffisant pour certains équipements qui peuvent contenir plusieurs fois les mêmes variables. Par exemple, un commutateur ATM contient plusieurs cartes qui ont chacune leurs propres bases d'informations. Le contexte permet de distinguer entre plusieurs bases d'informations et même plusieurs agents. On distingue entre des agents, par exemple, quand on a un moteur qui agit comme passerelle entre SNMPv3 et du SNMPv1. On envoie donc un paquet SNMPv3 en identifiant à quel agent SNMPv1 on désire que le paquet soit retransmis.

6 - Exemple de trame SNMP

Téléchargez le l'exemple de trame SNMP

7 - Conclusion

On soulignera le manque de sécurité évident qui subsiste sur les premières versions de SNMP (v1 et v2). C'est dans ce but qu'a donc été développée la dernière version (v3) de SNMP. Depuis 2002 celle-ci a été décrétée comme standard pour ce protocole. Pourtant la version 1 reste encore beaucoup utilisée et peu d'entreprises évoluent en passant en sur la dernière version.