SNMP
par _SebF & Sandra
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 cryptage
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
8 - Discussion autour de la
documentation
9 - Suivi du document
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.
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.
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 SNMP
Il 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.
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
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
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 :
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 cryptage, 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é.
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.
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
:
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 cryptage : 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.
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 crypter. 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.
Le cryptage 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 cryptage 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 cryptage.
Ceci permet au système d'authentification et au système de cryptage 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 cryptage.
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 encrypte
64 bits à la fois. Comme les informations que l'on doit encrypter 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 cryptage 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.
Si une requête est transmise, les
mécanismes d'authentification et de cryptage 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 encrypté 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.
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.
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 cryptage 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 encrypter le reste
du paquet. Cet identificateur doit identifier de façon unique chaque module de
sécurité. Actuellement, l'algorithme de cryptage 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.
Téléchargez le l'exemple de trame SNMP
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.
Vous pouvez poser toutes vos questions,
vos remarques et vos expériences à propos de l'entête SNMP. Pour cela,
rendez-vous sur le
Forum "TCP-IP".
Le 09 Décembre 2007, par Stéphane CALON
et Sébastien FONTAINE, ajout des références AES dans le chapitre 5.1.2
Le 11 septembre 2006, par Sébastien
FONTAINE,
finition du document.
Le 19 janvier 2006, par Sandra PERAIRE,
création du document
|