Le Protocole SNMP PDF

3/3/2015 1) Le Protocole SNMP
David NOUCHI Annexe A

DESS SSI

http://d.nouchi.free.fr/SNMP/SNMP.htm 1/20

Table des matières

1. Définition et Fonctionnement p 3

1.1. Fonctionnement général de SNMP p 3
1.2. SMI : Structure of Management Information p 3
1.3. Extension de la MIB p 4
1.4. Les différents types d‛opérations p 4
1.5. Format des messages SNMP p 7
1.6. Les noms de communautés p 7
1.7. Les agents SNMP p 8
1.8. Les manageurs SNMP p 8
1.9. Avantages et inconvénients de SNMPv1 p 9
1.10. SNMPv2 p 10
1.11. SNMPv3 p 11

2. Failles de sécurité du protocole SNMP & Solutions p 14

2.1. Introduction p 14
2.2. Description p 15
2.3. Solutions p 16
a. Appliquer un patch conseillé par votre fournisseur p 16
b. Neutraliser le service de SNMP p 16
c. Filtrer les entrées p 16
d. Filtrer le trafic SNMP des hôtes internes non autorisés p 17
e. Changer la chaîne de caractères (nom) de la communauté par défaut p 17
f. Isoler le trafic SNMP sur un réseau séparé p 18
g. Filtrer les sorties p 18
h. Outils et techniques de partage p 18
2.4. L'Information des fournisseurs p 19


Ce rapport de DESS de fin d‛étude sur la sécurité des systèmes d‛information présente le protocole
SNMP utilisé dans le logiciel HP OpenView que j‛ai étudié durant mon stage à la DGA Toulon au Centre
Technique des Systèmes Navals.

Dans une première partie je vais décrire le fonctionnement général du protocole SNMP ainsi que ses
différentes versions avec leurs avantages et leurs inconvénients respectifs.
Dans une deuxième, j‛étudierai ses failles de sécurité ainsi que les méthodes à appliquer pour s‛en
prémunir.
Enfin dans une dernière, j‛analyserai les faiblesses du logiciel HP OpenView ainsi que les différentes
solutions à mettre en place pour les contourner.

1. Définition et Fonctionnement

1.1. Fonctionnement général de SNMP

Le protocole SNMP (Simple Network Management Protocol) a été développé pour permettre à
l‛administrateur d‛interroger les éléments de son réseau sans se déplacer. Le principe de SNMP est très
simple : sur chacune des machines, on installe un petit programme : l‛agent SNMP. Cet agent enregistre
en permanence des informations relatives à la machine. Il stocke ces informations dans une base de
données appelée MIB (Management Information Base).
Ainsi, de son ordinateur, l‛administrateur peut interroger chacune de ses machines et obtenir les
informations souhaitées, comme par exemple le nombre d‛octets reçus et envoyés... Il peut aussi en
modifier certaines.

Le protocole SNMP fonctionne au niveau 7 du modèle OSI, mais se situe directement au-dessus d‛UDP.
Il fonctionne sur un modèle client serveur, où il n‛y a qu‛un seul client, la station d‛administration (NMS =
Network Management Station) et de nombreux serveurs (chaque agent SNMP), le client interrogeant les
serveurs pour récupérer les informations.

Chaque agent est placé sur un nœud du réseau « administrable » (MN : Managed Node). Ces nœuds
peuvent être soit des hôtes (stations de travail ou serveurs), soit des éléments d‛interconnexion (switchs,
hubs, routeurs), soit des supports physiques (câbles).

1.2. SMI : Structure of Management Information

Pour se retrouver dans la foule d‛informations proposées par chaque agent, on a défini une structure
particulière pour les informations, appelée SMI. Chaque information de la MIB peut être retrouvée soit à
partir de son nom de variable, soit à partir d‛un arbre de classification. Cela revient à parcourir des sous-
dossiers et dossiers d‛un disque dur…

Supposons que vous souhaitiez consulter la variable System d‛un hôte, vous pouvez soit lui demander la
variable System directement, soit lui demander la variable ayant pour OID (Object IDentification)
1.3.6.1.2.1.1… correspondant à l‛arborescence de la variable (ISO, Identified Organization, dod, Internet,
Management, MIB2, System).

Cela peut paraître assez contraignant à première vue, mais le nombre de variables étant important, on
ne peut se souvenir de chaque nom. Par contre, il existe de nombreux logiciels permettant d‛explorer la
MIB de façon conviviale, en utilisant cette classification.
Voici ci dessous un exemple d‛arbre MIB :

1.3. Extension de la MIB

Au bout d‛un moment, les variables choisies pour la MIB (puis la MIB2) se sont avérées insuffisantes
pour plusieurs applications. On va donc trouver deux autres types de MIB que sont les Private MIB et les
MIB R-MON (Remote network MONitoring).
Les Private MIB, représentées en 1.3.6.1.4 dans la classification SMI, permettent aux entreprises de
rajouter des variables pour une implémentation particulière des agents SNMP. Cela leur permet d‛ajouter
de nouvelles variables en fonction des applications qu‛elles veulent développer.
Les MIB R-MON permettent par exemple de placer des agents SNMP sur des le trafic.
L‛administrateur pourra l‛interroger pour avoir des informations sur les collisions, les débits à un endroit
précis.

1.4. Les différents types d‛opérations

Deux situations sont possibles pour les échanges de données. Soit l‛administrateur réseau demande
une information à un agent et obtient une réponse, soit l‛agent envoie de lui-même une alarme (trap) à
l‛administrateur lorsqu‛un événement particulier arrive sur le réseau.
Il est donc possible que l‛agent prévienne l‛administrateur de son propre chef si un incident survient.

Il existe quatre types de requêtes :

 GetRequest : permet d‛obtenir une variable.

 GetNextRequest : permet d‛obtenir la variable suivante (si existante, sinon retour d‛erreur).
 GetBulk : " permet la recherche d‛un ensemble de variables regroupées. "
 SetRequest : permet de modifier la valeur d‛une variable.

Puis, les réponses :

 GetResponse : permet à l‛agent de retourner la réponse au NMS.
 NoSuchObject : informe le NMS que la variable n‛est pas disponible.

Les types d‛erreurs sont les suivants : NoAccess, WrongLenght, WrongValue, WeongType,
WrongEncoding, NoCreatio, NoWritable et AuthorisationError.

Les alertes (traps) sont ColdStart, WarmStart, LinkUP et AuthentificationFailure.

Type de PDU (Protocol Data Nom
Units)
0 GetRequest
1 GetNextRequest
2 SetRequest
3 GetResponse
4 Trap
Le paquet SNMPv1
(La version 1 est la plus utilisée)

SNMP est un protocole, comme son nom l‛indique, pour effectuer de la gestion de réseau. Il permet de
contrôler un réseau à distance en interrogeant les stations qui en font partie sur leur état et modifier
leur configuration, faire des tests de sécurité et observer différentes informations liées à l‛émission de
données. Il peut même être utilisé pour gérer des logiciels et bases de données à distance. Depuis qu‛il
est devenu un standard TCP/IP, son utilisation a beaucoup augmenté. D‛ailleurs, il est le protocole le plus
utilisé pour gérer des équipements de réseau (routeurs, ponts, etc.) et beaucoup de logiciels de gestion
de réseau sont basés sur ce protocole.

Composantes pour l‛utilisation

Ce qui fait partie de l‛utilisation du SNMP dans un réseau:

1. Une station de gestion NMS (Network Management Station) : C‛est la station qui exécute un
programme de gestion SNMP. Son but principal est de contrôler les stations du réseau et de les
interroger sur différentes informations. . Sa configuration matérielle doit posséder un
processeur relativement rapide, beaucoup de mémoire (256 Mo minimum) et un espace disque
suffisant (pour archiver les informations).

2. Des éléments de réseaux avec des agents : Ils sont les éléments à gérer sur le réseau (ex :
logiciels, stations de travail, routeurs, concentrateurs, ponts, etc.). L‛agent est un module résidant
dans chaque nœud du réseau qui a pour fonction d‛aller chercher les informations du système afin
de tenir sa table MIB à jour.

3. Les tables MIB : Elles représentent une base de données maintenue par l‛agent qui contient les
informations sur les transmissions de données et sur les composantes de la station ou du routeur,
etc. (ex : uptime, configuration du routage, état du disque et du port série, nombre de paquets
reçus et envoyées, combien de paquets erronés reçus, etc.). Elles contiennent l‛ensemble des
variables TCP/IP de la station. Ce sont les informations contenues dans ces tables qui sont
demandées par la station de gestion afin d‛effectuer son travail.

Fonctionnement

SNMP fonctionne avec des requêtes, des réponses et des alertes. Autrement dit, NMS envoie des
requêtes à l‛agent sur chaque élément du réseau et celui-ci doit exécuter la requête et envoyer sa
réponse. Il peut aussi rencontrer des alertes asynchrones venant des agents voulant avertir NMS d‛un
problème.

Voici ci-dessous un exemple d‛utilisation de SNMP :

1.5. Format des messages SNMP

Message SNMP standard

Le champ Version précise la version du protocole SNMP utilisée. Le champ Communauté est utilisé afin
d'identifier le manageur et filtrer l'accès aux informations. Le champ PDU SNMP est constitué par l'une
des trois PDU suivantes:

 PDU GetRequest, GetNextRequest et SetRequest

Le champ Type indique s'il s'agit d'une PDU GetRequest, GetNextRequest ou SetRequest. La réponse à la
requête sera retournée avec la valeur fournie par le champ Request-Id, afin d'associer la réponse à la
requête. Le champ Affectation des variables est une suite de couples d'identificateurs et de valeurs
associées. Les valeurs sont fournies uniquement dans le cas d'une PDU SetRequest.

 PDU GetResponse

Le champ Type permet de reconnaître une PDU SetResponse des PDU précédentes (dont le format est
identique). Les champs error-status et error-index nous informent sur le résultat de la requête.

 PDU Trap

Affectation

1.6. Les noms de communautés

L'accès aux informations des MIBs est contrôlé par un mécanisme simple utilisant des noms de
communautés. Un nom de communauté peut être assimilé à un mot de passe connu par l'agent et utilisé
par le manageur pour se faire reconnaître. Les noms de communautés sont configurés sur l'agent et
autorisent trois types d'accès sur les variables de la MIB gérée par l'agent :

 Pas d'accès
 Read-Only
 Read-Write.


Le nom de communauté circule en clair sur le réseau. Beaucoup d'administrateurs préfèrent ainsi
limiter l'accès sur les MIBs en lecture seule, et se déplacent sur les équipements pour modifier certaines
valeurs.

1.7. Les agents SNMP

L'agent SNMP collecte les informations de la MIB de l'équipement et répond aux requêtes du
manageur. On trouve maintenant des agents SNMP sur tout les équipements dits « administrable ». Les
constructeurs fournissent également des agents pour les stations du réseau.
Toutefois, certains vieux équipements administrables ne sont pas conformes à SNMP. Dans ce cas, il
est possible d'utiliser un agent proxy sur un équipement SNMP, qui va servir d'intermédiaire avec celui
non SNMP.

1.8. Les manageurs SNMP

Les manageurs sont chargés de questionner les agents et de fournir à l'administrateur les
informations récupérées. Ils doivent également gérer les traps et prévenir l'administrateur.
Les outils SNMP vont du simple "browser" de MIB qui permet juste de lire les variables, jusqu'à la plate-
forme d'administration qui peut les afficher de façon pertinente sur des cartes du réseau.

Le marché des plates-formes d'administration est réparti entre deux grandes familles:

 les constructeurs de systèmes distribués (HP, BULL, IBM):
 HP OpenView (pour Unix ou Windows NT)
 ISM
 Tivoli
 Les constructeurs de solutions pour réseaux locaux :
 Novell Network Management System

9. Avantages et inconvénients de SNMPv1

9-1. Avantages

 L'avantage majeur dans le fait d'utiliser SNMP est qu'il est de conception simple. Il est donc aisé
de l'implémenter sur un réseau, puisqu'il ne nécessite pas une longue configuration et qu'il est de
petite taille.
 Un autre atout de SNMP est qu'il est très répandu aujourd'hui. Presque tous les grands
constructeurs de matériel hardware inter-réseaux, tels que les commutateurs ou les routeurs,
implémentent le support SNMP dans leurs produits.

 L'expansion est un autre privilège de SNMP. De par sa simplicité de conception, il est facile de
mettre à jour le protocole pour qu'il réponde aux besoins des futurs utilisateurs.
 Enfin, SNMP est basé sur le protocole de transport UDP, ce qui nécessite moins de ressources et
de connexions simultanées qu'avec TCP.

9-2. Inconvénients
La puissance de SNMP à administrer un réseau n'est plus à démontrer, mais il faut avouer que ce
protocole souffre de quelques défauts :

 A chaque réponse reçue correspond une requête. Le transfert de données à travers le réseau
s'avère donc assez important, ce qui surcharge ce dernier par rapport à ce qu'il aurait été en cas
de non administration.
 Ce protocole n'est pas très pratique pour ramener une grosse quantité de données comme une
table de routage par exemple.
 Les alarmes ne sont pas acquittées et un agent n'est jamais sûr de bien avoir averti sa station
d'administration.
 L'authentification reste très simple et donc non sécurisée. Le mot de passe et les données de
contrôle sont envoyés sans chiffrement sur le réseau.
 SNMP ne permet pas de "commander" un agent, cette manipulation ne peut se faire qu'en
modifiant une entrée de sa MIB.
Exemple : On ne peut pas demander à une passerelle de terminer une connexion TCP donnée, mais
on peut modifier la valeur tcpConnState pour que cette connexion soit fermée.
 SNMP ne supporte pas la communication de station d'administration à station d'administration. Il
est donc impossible à une station d'administration de faire des requêtes à un périphérique
administré par une autre station en passant par son intermédiaire.

1.10. SNMPv2

Devant le succès de SNMP, il a vite semblé nécessaire de développer un successeur qui corrigerait ses
nombreuses faiblesses, notamment en terme de sécurité.
Une version améliorée a été proposée sous le nom SNMPv2. Elle apporte des mécanismes
d'authentification et de chiffrement ainsi que des méthodes de consultation des informations réseaux
plus efficaces.

Plus complexe que SNMP (v1), qui est par ailleurs bien implanté, SNMPv2 ne connaît pas de réel succès
à ce jour.

1.10.1. Domaine d'application

SNMPv2 est conçu pour faciliter la gestion de n'importe quelle ressource, pas seulement de
ressources réseaux. SNMPv2 peut donc être utilisé pour gérer des applications, des systèmes et
communiquer entre gestionnaires.
Grâce à l'ajout des fonctions de communication de gestionnaire, SNMPv2 peut être aussi utilisé en
gestion distribuée.

SNMPv2 propose un cadre concis et flexible pour décrire les informations en promouvant
l'extensibilité dans la définition de MIBs.
De même, SNMPv2 propose un moyen pour décrire les conditions de "conformance" à la définition de MIB
standard ou bien, pour la MIB d'un agent donné, les capacités effectivement implémentées ou non.

1.10.2. Taille, vitesse et efficacité

SNMPv2 reste "simple" pour permettre le développement de petites et rapides implémentations. Le
format des messages de type trap n'est plus différent des autres messages afin de simplifier les
routines d'interprétation des messages.

Le changement majeur dans cette catégorie est l'ajout de la commande get bulk pour l'échange de
grandes quantités d'informations. La commande get bulk est une requête de plusieurs get next
successifs. Auparavant, on était obligé de faire une succession de get next pour lire une table, avec
SNMPv2 une seule commande et réponse peuvent maintenant suffire pour cela.

1.10.3. Sécurité et privautés

SNMPv2 permet de garantir l'authentification des messages et/ou le chiffrement des messages. Ce
système est très riche et permet de définir l'accès à chaque variable, le type de sécurité et de protocole
utilisé pour chaque transaction. Il est ainsi possible de spécifier qui peut faire quelle opération sur quelle
variable et avec quel degré de sécurité : non sécurisé, authentifié ou chiffré.

1.10.4. Déploiement et compatibilité

SNMPv2 a été conçu pour être utilisé sur TCP/IP, OSI et d'autres architectures de communication.
SNMPv2 permet aussi de communiquer avec des plates-formes supportant le protocole SNMPv1.

SNMPv2 va certainement compliquer l'image de la gestion réseau pour la plus part des utilisateurs.
Certaines personnes attendent que SNMPv2 devienne un standard, d'autres veulent profiter
immédiatement des avantages de SNMPv2 et enfin, comme toujours, d'autres refusent radicalement tout
changement ... en attendant OSI... Ceci conduira tôt ou tard à des problèmes d'interopérabilité.

Aujourd'hui, SNMPv2 se met lentement en place, quelque fois de façon partielle, où la partie sécurité
est souvent délaissée. De ce fait, le contrôle d'accès se réduit à un accès non sécurisé pour toutes les
variables.

L'évolution de SNMPv1 vers SNMPv2 est une étape importante dans l'évolution de SNMP. Le champ
d'application couvert maintenant par SNMP s'est largement étendu.
Toutefois, il faut bien se rappeler que SNMP est un standard d'échange d'informations de gestion. Ceci
n'est qu'une partie du problème de la gestion réseau. En ce qui concerne l'interface utilisateur, il reste
encore beaucoup à faire. Il y a bien sur la présentation des informations mais aussi leur interprétation.

Il serait bien de disposer, par exemple, d'un langage permettant à l'utilisateur ou aux vendeurs de
définir un traitement à effectuer avec les informations obtenues par SNMP. Par exemple, les dispositions
à prendre ou les actions à effectuer face aux conclusions que le système peut tirer de ces informations.

Si SNMPv2 poursuit son évolution vers un protocole de gestion simple et performant, il reste encore
du chemin à parcourir avant de disposer de vrais outils de gestion réseau.

11. SNMPv3

1.11.1. Les améliorations de SNMPv3

Comme nous avons pu le voir dans la partie précédente, le contrôle d'accès pour les versions
antérieures à SNMPv3 est approximatif et la confidentialité inexistante. SNMPv3, quant à lui, résout le
problème de la sécurité et de la modularité. Les nouveautés apportées par SNMPv3 sont les suivantes :
Sécurité :
 Authentification et chiffrement.
 Autorisation et contrôle d'accès.
Administration :
 Nommage des entités.
 Gestion de la compatibilité.
 Destinations des notifications.
 Configuration à distance.
1.11-2. Le fonctionnement de la sécurité dans SNMPv3

Cette partie décrit les mécanismes de sécurité utilisés dans SNMPv3. Ils sont au nombre de quatre et
chacun d‛entre eux a pour but d'empêcher un type d'attaque :

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, des fonctions de hachage à une seule direction sont nécessaires. 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 fixe (16 octets pour MD5, 20 octets pour SHA-1).
Ces fonctions de hachage à une seule direction ont la propriété suivante :
Étant donné une chaîne d'octets qui est le résultat d'une fonction de hachage à une direction. Il doit être
très difficile de trouver une quelconque chaîne d'entrée qui, une fois passée dans la fonction, donne cette
même chaîne en sortie.
Pour authentifier l'information qui va être transmise, on doit aussi possédé un mot de passe qui est «
partagé ». Celui-ci ne doit donc être connu que par les deux entités qui s'envoient
les messages.
Les étapes d'authentification sont alors les suivantes :

 Le transmetteur groupe les 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 passant 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 et HMAC-SHA- 96.
Il est important de rappeler que l'étape d'authentification ne vise pas à cacher l'existence du
paquet ou à le rendre illisible. Si uniquement l'authentification est appliquée, les personnes qui
saisissent les paquets passant sur le réseau peuvent encore voir le contenu du paquet. Toutefois, elles ne
peuvent pas en changer le contenu sans connaître le mot de passe.

La localisation des mots de passe :

SNMP pose un problème de sécurité particulier. Une plate-forme de gestion peut communiquer avec
des dizaines ou quelquefois des centaines d'agents. Si le même mot de passe est utilisé par chaque agent,
on court le risque qu'un des agents soit volé ou compromis.
La connaissance du mot de passe compromettrait alors la sécurité entière du domaine d'administration.
De la même façon, utiliser un mot de passe différent pour chaque agent n'est pas une solution
envisageable : il n'est pas raisonnable pour un administrateur de connaître des dizaines ou
des centaines de mots de passe différents.

La solution adoptée par SNMPv3 est d'utiliser un seul mot de passe, mais de passer par une
étape de « localisation ». Un mot de passe localisé ne fonctionne qu'avec un seul agent.
Avant de localiser, il nous faut une chaîne de caractères qui soit unique à chaque agent. Avec
SNMPv3, on utilise le « ContextEngineID ». Cette chaîne est générée par un ensemble de données comme
l'adresse MAC de la carte Ethernet, l'adresse IP, des nombres aléatoires ou
une chaîne spécifiée par l'administrateur.
On commence par trouver le ContextEngineID de l'agent auquel on veut envoyer une requête.
On groupe le ContextEngineID et le mot de passe ensemble et on passe le groupe dans une
fonction de hachage à une direction.
C'est le mot de passe localisé qui est mémorisé dans l'agent et qui est utilisé par la plate-forme. Il est
employé dans l'authentification et le chiffrement des paquets SNMPv3.
Les détails de la localisation sont décrits dans le RFC2274. Cette étape est très coûteuse en
temps processeur. Les plates-formes de gestion sont donc instruites d'utiliser un cache pour éviter de
répéter ce calcul plusieurs fois.

Le chiffrement :

Le chiffrement a pour but d'empêcher quiconque de lire les informations de gestion contenues dans un
paquet SNMPv3 en écoutant sur le réseau les requêtes et les réponses.
Avec SNMPv3, le chiffrement de base se fait sur un mot de passe « partagé » entre la plate-forme 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. On
recommande à l'usager d'utiliser deux mots de passe distincts. 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 le DES (Data Encryption Standard) pour effectuer le chiffrement.
Contrairement à l'authentification qui est appliquée à tout le paquet, le chiffrement est seulement
appliqué sur le «ScopedPduData», voir Figure ci-dessous : Description d'un paquet SNMPv3.


L'estampillage du temps :

L'estampillage du temps doit empêcher la réutilisation d'un paquet SNMPv3 valide que quelqu'un a
déjà transmis. En effet, si une requête est transmise, les mécanismes d'authentification, de localisation
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 ultérieurement, sans modification. On appelle cette attaque le « replay attack ».

Pour l‛éviter, 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 supérieur à 150 secondes, le
paquet est ignoré.

1.11.3. Conclusion

Contrairement à ce que l'on pourrait penser, SNMPv3 n'est pas compatible avec SNMPv1.
Ceci n'empêche pas SNMPv1 de fonctionner à coté de SNMPv3 (« Dual stack »), il suffit de
placer deux agents ou deux plates-formes de gestion côte à côte.
Les standards SNMPv1 et SNMPv2c décrivent essentiellement un protocole de transport des
données entre un agent et une plate-forme de gestion. Rien n'est mentionné sur l'architecture
ou l'environnement dans lequel SNMP doit être utilisé.

Avec l'arrivée de SNMPv3, le standard SNMP décrit maintenant une architecture pour la
plate-forme de gestion et l'agent. Toutefois, SNMP reste un protocole simple, dont la vocation
première est d'être placé dans les instruments de réseau. SNMP est donc un bon protocole
pour obtenir des informations de gestion à partir des équipements de gestion, maintenant
encore meilleur avec l'ajout de la sécurité.

2. Failles de sécurités du protocole SNMP

2.1. Introduction

Cette partie présente les différentes failles de sécurité rencontrées par l‛utilisation du protocole
SNMP (Simple Network Management Protocol) intégré et utilisé dans de nombreux dispositifs de divers
constructeurs.
Dans une première partie, je vais présenter les vulnérabilités rencontrées par l‛utilisation de ce
protocole et dans une deuxième, je vais montrer les différents moyens que l‛on peut utiliser pour se
prémunir de ces failles de sécurités.

Systèmes Affectés

Des produits d‛un très grand nombre de fournisseurs peuvent être affectés. En plus des fournisseurs
qui ont fourni la rétroaction pour cette partie, une liste de fournisseurs entrés en contact avec le CERT
concernant ces problèmes est fourni dans la partie solution un peu plus loin.

De nombreux autres systèmes se servant de SNMP peuvent également être vulnérables mais n'ont pas
été spécifiquement examinés.

Vue d'ensemble

De multiples vulnérabilités ont été rapportées dans les réalisations de tests SNMP effectuées par
divers fournisseurs. Ces vulnérabilités peuvent permettre un accès privilégié non autorisé, des attaques
par déni de service, ou causer des comportements instables.
2.2. Description

Le Simple Network Management Protocol (SNMP) est un protocole largement déployé qui est
généralement employé pour surveiller et contrôler des dispositifs réseau. La version 1 du protocole
(SNMPv1) définit plusieurs types de messages SNMP qui sont utilisés pour demander des changements
d'information ou de configuration, répondre aux demandes, énumérer des objets SNMP, et envoyer des
alertes non sollicitées.

Le groupe de programmation de l‛université d'Oulu (OUSPG, http://www.ee.oulu.fi/research/ouspg/) a
rapporté de nombreuses vulnérabilités dans l‛utilisation de SNMPv1 de différents fournisseurs. Plus
d'informations sur l'OUSPG peuvent être trouvées sur le cite du CERT :
http://www.cert.org/advisories/CA-2002-03.html .

La recherche d'OUSPG s'est concentrée sur la façon dont les agents SNMPv1 et la poignée de
manageurs demandent et emprisonnent des messages. En appliquant le PROTOS c06-snmpv1 à une variété
de produits populaires utilisant SNMPv1, l'OUSPG a indiqué les vulnérabilités suivantes:

 VU#107186 - De multiples vulnérabilités dans SNMPv1 emprisonnent la manipulation

Des messages d‛alarme SNMP sont envoyés des agents aux manageurs. Un message d‛alarme peut
indiquer une condition d'avertissement, d'erreur ou autrement informer le manageur sur l'état de
l'agent. Les manageurs SNMP doivent correctement décoder ces messages d‛alarme et traiter les
données résultantes. Dans l'essai, OUSPG a trouvé de multiples vulnérabilités sur de nombreux
manageurs SNMP qui décodent et traitent des messages d‛alarme SNMP.

 VU#854306 - Vulnérabilités multiples dans la manipulation de requêtes SNMPv1

Les messages de requêtes SNMP sont envoyés des manageurs aux agents. Ces messages sont utilisés
pour obtenir l'information d'un agent ou pour demander à l'agent de configurer le dispositif d‛une
machine. Les agents SNMP doivent correctement décoder ces requêtes et traiter les données
résultantes. Dans l'essai, OUSPG a trouvé des vulnérabilités multiples dans la manière dont de
nombreux agents SNMP décodent et traitent ces messages SNMP.

Les vulnérabilités dans le décodage, le traitement des messages SNMP par les manageurs et les agents
peuvent avoir comme conséquence des états de déni de service, des vulnérabilités dans le format des
chaînes de caractères, et des débordements de buffer. Quelques vulnérabilités n'exigent pas du message
SNMP d'employer la chaîne de caractères correcte de la communauté SNMP.

Impact :

Ces vulnérabilités peuvent causer des états de déni de service, interruptions de service, et dans
certains cas peuvent permettre à un attaquant d'accéder au dispositif affecté. Les impacts spécifiques
changeront suivant le produit.

2.3. Solutions

Il faut noter que plusieurs des étapes recommandées ci-dessous peuvent avoir un impact significatif
sur les opérations réseau et/ou architectures réseau journalières. Il faut s‛assurer que tous les
changements basés sur les recommandations suivantes n'affecteront pas irréversiblement les possibilités
d'opérations réseau.

1. Appliquer un patch conseillé par votre fournisseur

La partie « 2.4. » contient l'information fournie par les fournisseurs. Veuillez consulter cette partie
pour déterminer si vous devez contacter votre fournisseur directement.

2. Neutraliser le service de SNMP

En règle générale, le CERT/cc recommande de neutraliser n'importe quel service ou les possibilités qui
ne sont pas explicitement exigées, y compris SNMP. Cependant, certains produits affectés ont montré un
comportement ou un déni de service inattendu une fois exposés à la suite d'essai d'OUSPG même si
SNMP n'était pas permis. Dans ces cas, la neutralisation de SNMP devrait être employée en même temps
que les pratiques de filtrage énumérées ci-dessous pour assurer une protection additionnelle.

3. Filtrer les entrées

Comme mesure provisoire, il est possible de limiter la portée de ces vulnérabilités en bloquant l'accès
des services SNMP au périmètre du réseau.

Le filtrage d'entrée contrôle l'écoulement du trafic sur le réseau. Les serveurs sont typiquement les
seules machines qui doivent accepter le trafic provenant d‛Internet. Ainsi, le filtrage des entrées devrait
être effectué à la frontière pour interdire le trafic d'arrivée lancé par des services non autorisés. Pour
SNMP, le filtrage d'entrée des ports suivants peut empêcher des attaquants extérieurs au réseau
d'utiliser les dispositifs vulnérables dans le réseau.

 SNMP 161/udp # Simple Network Management Protocol (SNMP)
 SNMP 162/udp # système de gestion des messages SNMP

Les services suivants sont moins communs, mais peuvent être employés sur certain produits utilisant
SNMP :

 snmp 161/tcp # Simple Network Management Protocol (SNMP)
 snmp 162/tcp # système de gestion des messages SNMP
 smux 199/tcp # SNMP Unix Multiplexer
 smux 199/udp # SNMP Unix Multiplexer
 synoptics-relay 391/tcp # SynOptics SNMP Relay Port
 synoptics-relay 391/udp # SynOptics SNMP Relay Port
 agentx 705/tcp # AgentX

 snmp-tcp-port 1993/tcp # cisco SNMP TCP port
 snmp-tcp-port 1993/udp # cisco SNMP TCP port

Remarque : vous devez soigneusement considérer l'impact de bloquer les services que vous pouvez
employer.

Il est important de noter que dans de nombreuses utilisations de SNMP, le démon SNMP peut être lié
à toutes les interfaces IP sur le dispositif. Ceci a des conséquences importantes quand des mesures de
filtrage de paquet exigées sont utilisées pour protéger un dispositif utilisant ou permettant SNMP. Par
exemple, même si un dispositif rejette des paquets SNMP dirigés vers les adresses IP de ses interfaces
réseaux normales, il peut encore être possible d'exploiter ces vulnérabilités sur ce dispositif par
l'utilisation de paquets dirigés aux adresses IP suivantes :

 " tout-ceux " qui ont une adresse d‛émission (broadcast),
 adresse d'émission de sous-réseau (broadcast),
 toutes adresses internes de réception (loopback) (généralement utilisées pour la gestion des
routeurs, et ne pas confondre avec l'adresse 127.0.0.1 de boucle de retour de la pile IP).

Une grande attention devrait être accordée aux adresses des types mentionnés ci-dessus par la
planification d'emplacements du paquet filtrant en tant qu'élément de la stratégie de sécurité pour ces
vulnérabilités.

En conclusion, les emplacements (l‛endroit où l‛on place le filtre) peuvent bloquer l'accès aux services
RPC suivants liés à SNMP :

 snmp 100122 na.snmp snmp-cmc snmp-synoptics snmp-unisys snmp-utk
 snmpv2 100138 na.snmpv2 # SNM Version 2.2.2
 snmpXdmid 100249

Veuillez noter que ce travail peut ne pas protéger les dispositifs vulnérables contre des attaques
internes.

4. Filtrer le trafic SNMP des hôtes internes non autorisés

Dans de nombreux réseaux, seulement un nombre limité de systèmes de gestion réseau doit lancer des
messages de requêtes SNMP. Par conséquent, il peut être possible de configurer les agents systèmes
SNMP (ou les dispositifs réseaux entre les systèmes de gestion et d'agents) afin qu‛ils rejettent les
requêtes des systèmes non autorisés. Ceci peut réduire, mais pas complètement éliminer, le risque des
attaques internes.

Cependant, il peut avoir des effets néfastes sur la charge du réseau due à la charge accrue imposée
par le filtrage, ainsi une considération soigneuse est exigée avant exécution. Les avertissements
semblables au travail précédent concernant les adresses d'émission (broadcast) et de réception (loopbac)
s'appliquent ici.

5. Changer la chaîne de caractères (nom) de la communauté par défaut

La plupart des produits utilisant ou permettant SNMP utilisent la chaîne de caractères (nom) de la
communauté par défaut " public " pour l'accès en lecture seulement et " privé " pour l'accès lecture/
écriture. Comme avec n'importe quel mécanisme connu de contrôle d'accès par défaut, le CERT/cc
recommande que les administrateurs réseau changent la chaîne de caractères (c‛est-à- dire le nom) de la
communauté en un nom de leur propre choix.

Cependant, même lorsque les noms de communautés sont changés par défaut, ils passeront toujours en
texte clair et seront donc sujets à des attaques de reniflement de paquet (sniffing). SNMPv3 offrent
des possibilités additionnelles pour assurer l'authentification et l'intégrité comme décrit dans le
RFC2574 .

Puisque plusieurs des vulnérabilités identifiées dans ce consultatif se produisent avant que les noms de
communauté soient évaluées, il est important de noter qu‛exécuter cette seule étape n'est pas suffisant
pour atténuer l'impact de ces vulnérabilités. Néanmoins, elle devrait être exécutée en tant qu‛une bonne
méthode en matière de sécurité.

6. Isoler le trafic SNMP sur un réseau séparé

Dans les situations où le blocage ou la neutralisation de SNMP n'est pas possible, l'exposition à ces
vulnérabilités peut être restreint en limitant l' accès SNMP aux réseaux séparés et en faisant une
gestion isolée du réseau pour qu‛il ne soit pas publiquement accessible. Bien que ceci implique idéalement
des réseaux physiquement séparés, ce genre de séparation n'est probablement pas faisable dans la
plupart des environnements.

Des mécanismes tels que LANs virtuel (VLANs) peuvent être employés pour aider à isoler le trafic sur
un même réseau physique. Notez que les VLANs ne peuvent pas strictement empêcher un attaquant
d'exploiter ces vulnérabilités, mais elles peuvent rendre la tâche plus difficile pour un attaquant qui veut
lancer des attaques.

Une autre option est de limiter les sites le trafic SNMP pour séparer les réseaux privés virtuels
(VPNs), qui utilisent l'authentification cryptographique forte.
Notez que ces solutions peuvent exiger des changements étendus à l'architecture d‛un réseau.

7. Filtrer les sorties

Le filtrage de sortie contrôle l'écoulement du trafic pendant qu'il laisse le réseau sous le contrôle de
l‛administrateur. Il a besoin en général de limiter les machines fournissant des services publiques pour
lancer le trafic relié à l'Internet. Dans le cas des vulnérabilités de SNMP, l'utilisation d‛un filtrage de
sortie sur les ports énumérés ci-dessus à votre frontière de réseau peut empêcher votre réseau d'être
employé comme une source pour des attaques venant d'autres sites.

8. Outils et techniques de partage

Puisque traiter ces vulnérabilités liés aux systèmes et aux réseaux est si complexe, le CERT/cc
fournira un forum où les administrateurs peuvent partager les idées et les techniques qui peuvent être
employées pour développer des défenses appropriées.

2.4. L'Information des fournisseurs

Dans cette partie se trouve les principales solutions proposées par les fournisseurs qui ont effectué
des tests sur leur produit. Nous présenterons ici seulement les fournisseurs qui nous intéressent comme
HP par exemple. Des informations plus détaillées sont données sur le site du CERT :
http://www.cert.org/advisories/CA-2002-03.html

1. Bulletin Consultatif Général De DataComm
Site de référence : http://www.gdc.com/products/bulletin.shtml

Vulnérabilités multiples dans de nombreuses implémentations du protocole SNMP.
Les applications de l‛équipe GDC emploient le protocole SNMP de HP OpenView NNM pour la gestion de la
communication de réseau SNMP avec sa carte Manager SpectraComm (SCM). Le SCM contient un agent
proxy SNMP.

Recommandations:
1. Le SCM n'a pas un nom de communauté en lecture/écriture par défaut " privé " qui permet d‛éviter que
des intrus changent les configurations du matériel ou prennent la main sur la gestion ou les données du
réseau informatique. Le SCM lit par défaut seulement le nom de la communauté " public ". Il est conseillé
au client de changer ceci.
2. Les clients principaux de gestion réseau de GDC emploient habituellement un LAN privé séparé pour
leur trafic de gestion pour éliminer l'entrée à l‛exposition extérieure.
3. Obtenez et installez les patchs de HP et de HPOV des sites énumérés.
2. HP HpOV NNM (Network Node Manager)
Quelques problèmes ont été trouvés dans le produit NNM.
Système : HP-UX utilisant le démons snmpd ou OPENVIEW
Les patchs suivants sont disponibles maintenant:
Le patch PHSS_26137 s700_800 10,20 OV EMANATE14.2

Le patch PHSS_26138 s700_800 11.x OV EMANATE14.2
Le patch Psov_03087 EMANATE14.2 de Solaris 2.x

Chacune des trois patchs est disponible : http://support.openview.hp.com/cpe/patches/
En outre les patchs PHSS_26137 et PHSS_26138 seront bientôt disponibles.
NOTE: Les patchs sont marquées OV(OpenView). Cependant, les patchs sont également applicables aux
systèmes qui n‛utilisent pas OpenView.

N'importe quel système HP-UX 10.x ou 11.x faisant tourner les démons snmpd ou snmpdm est vulnérable.
Pour déterminer si votre système de HP-UX a les démons snmpd ou snmpdm installés, faites la commande
suivante : swlist -l file | grep snmpd

Si un patch n'est pas disponible pour votre plate-forme ou vous ne pouvez pas installer un patch
disponible, les démons snmpd et snmpdm peuvent être neutralisés en enlevant leurs entrées de
/etc/services et les permissions d'exécution de /usr/sbin/snmpd/ et usr/sbin/snmpdm.

3. Hewlett-Packard Company
PROBLÈME: Vulnérabilités dans la demande de SNMP et la manipulation des alarmes.
PLATEFORME: HP 9000 série 700 séries 800 HP-UX fonctionnant sous HP-UX 10.x et 11.x

MATERIEL: Commutateurs de HP Procurve Progiciels Du ---->> JetDirect MC/ServiceGuard,
Moniteurs SME HA
DOMMAGES: Déni de service possible, interruptions de service, accès non autorisé.
SOLUTIONS: Appliquez les patchs ou mettez en application les workarounds.
Pour HP-UX:
 Agent de PHSS_26137 s700_800 HP-ux 10,20 OV EMANATE14.2
 Agent de PHSS_26138 s700_800 HP-ux 11.x OV EMANATE14.2
 PSOV_03087 Solaris 2.X EMANATE Release 14.2

Pour des systèmes utilisant OV NNM:
 PHSS_26286 s700_800 HP-ux 10,20 pour fixer les pièges du démon ovtrapd
 PHSS_26287 s700_800 HP-ux 11.x pour fixer les pièges du démon ovtrapd
 PSOV_03100 Solaris 2.x pour fixer les pièges du démon ovtrapd
 NNM_00857 de NT 4.X/Windows 2000 pour fixer les pièges du démon ovtrapd
Les clients peuvent télécharger ces patchs sous forme de mises à jour de logiciel à:
http://www.hp.com/rnd/software/switches.htm
Produit Version
Commutateur de HP Procurve 2524 (J481Á) F.04.08 ou plus grand
Commutateur de HP Procurve 2512 (J481À) F.04.08 ou plus grand
Commutateur 4108GL (J486Ä) G.04.05 de HP Procurve ou plus grand
Commutateur 4108GL-bundle (J4861A) G.04.05 de HP Procurve ou plus grand
PROBLÈME : NNM (NETWORK NODE MANAGER)
Quelques problèmes trouvés dans le produit de NNM ont été rapportés pour éviter certaines
vulnérabilités. Les patchs sont disponibles.
MATERIEL : Progiciels Du -->> JetDirect

État de la version du progiciel de JetDirect
--->> version X.08.32 ou inférieur : VULNÉRABLE (où X = A à K)
--->> version X.21.00 plus supérieur : NON VULNERABLE (où X = L à P)
SYSTEMES: Systèmes de HP-UX utilisant le démon snmpd ou OPENVIEW
N'importe quel système HP-UX 10.x ou 11.x faisant tourner les démons snmpd ou snmpdm est
vulnérable. Pour déterminer si votre système de HP-UX a les démons snmpd ou snmpdm installés,
faites la commande suivante : swlist -l file | grep snmpd
SOLUTIONS: installez les patchs appropriés
Les clients peuvent télécharger ces patchs sous forme de mises à jour du logiciel à :
http://www.hp.com/rnd/software/switches.htm
Les problèmes trouvés dans le produit de sont corrigés dans les patchs disponibles à:
http://support.openview.hp.com/cpe/patches/nnm/6.2/s700_800_11.X.jsp
Workaround: Changez le nom de communauté et employez la liste de contrôle d‛accès comme décrit
dans l‛impression de HP Jetdirect.
Sécurité : SNMPv1 se fonde sur le nom de communauté. Il est important qu‛il soit configuré sur le
matériel Jetdirect et maintenu secret.
les serveurs d'impression de Jetdirect offrent un Access Control List qui peut être employé pour
indiquer quels machines peuvent faire des changement de configuration SNMP sur les serveurs
d'impression de Jetdirect.

Les étapes ci-dessous peuvent aider à empêcher l'exploitation de vulnérabilités :
-> NEUTRALISEZ SNMP SUR UN SERVEUR D'IMPRESSION DE JETDIRECT
1. Mettez à jour les progiciels au niveau le plus élevé comme décrit dans le document de mise à jour
de Jetdirect : http://www.hp.com/cposupport/networking/support_doc/bpj06917.html
note: La neutralisation de SNMP peut affecter la découverte de matériel et le port des moniteurs qui
emploient SNMP pour obtenir le statut du matériel.
2. Telnet au dispositif de Jetdirect (sur les derniers progiciels) et tapez:

snmp-config: 0
quit
Ceci va neutraliser complètement SNMP sur le matériel de Jetdirect.
HP recommande toujours d‛upgrader ses progiciels de Jetdirect pour éliminer les derniers bugs et
pour bénéficier d‛avantage de sécurité. Ceux-ci sont téléchargeables gratuitement sous leur dernier
version. Par exemple, le dernier progiciel pour le J3110A est G.08.32.

4. Microsoft Corporation

Les documents suivants concernant cette vulnérabilité sont fournis par Microsoft:
http://www.microsoft.com/technet/security/bulletin/MS02-006.asp


Le Protocole SNMP PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Le Protocole SNMP PDF

Transféré par

Droits d'auteur :

Formats disponibles

3/3/2015 1) Le Protocole SNMP

David NOUCHI Annexe A

Table des matières

1.3. Extension de la MIB

 GetRequest : permet d‛obtenir une variable.

1.5. Format des messages SNMP

 PDU GetRequest, GetNextRequest et SetRequest

implémentent le support SNMP dans leurs produits.

Ces fonctions de hachage à une seule direction ont la propriété suivante :

Les étapes d'authentification sont alors les suivantes :

qui est de SNMPv3, l'authentification se fait à l'aide de HMAC-MD5-96 et HMAC-SHA- 96.

 agentx 705/tcp # AgentX

2.4. L'Information des fournisseurs

Site de référence : http://www.gdc.com/products/bulletin.shtml

3. Obtenez et installez les patchs de HP et de HPOV des sites énumérés.

2. HP HpOV NNM (Network Node Manager)

Quelques problèmes ont été trouvés dans le produit NNM.

Système : HP-UX utilisant le démons snmpd ou OPENVIEW

Les patchs suivants sont disponibles maintenant:

Le patch PHSS_26137 s700_800 10,20 OV EMANATE14.2

PROBLÈME: Vulnérabilités dans la demande de SNMP et la manipulation des alarmes.

DOMMAGES: Déni de service possible, interruptions de service, accès non autorisé.

SOLUTIONS: Appliquez les patchs ou mettez en application les workarounds.

PROBLÈME : NNM (NETWORK NODE MANAGER)

MATERIEL : Progiciels Du -->> JetDirect

SYSTEMES: Systèmes de HP-UX utilisant le démon snmpd ou OPENVIEW

SOLUTIONS: installez les patchs appropriés

2. Telnet au dispositif de Jetdirect (sur les derniers progiciels) et tapez:

Ceci va neutraliser complètement SNMP sur le matériel de Jetdirect.

Vous aimerez peut-être aussi