SNMP

Table des matières 1. Définition et Fonctionnement p

3

1.1. Fonctionnement général de SNMP p 31.2. SMI : Structure of Management Information p 31.3. Extension de la MIB p 41.4. Les différents types d’opérations p 41.5. Format des messages SNMP p 71.6. Les noms de communautés p 71.7. Les agents SNMP p 81.8. Les manageurs SNMP p 8

1.9. Avantages et inconvénients de SNMPv1 p 91.10. SNMPv2 p 101.11. SNMPv3 p 11

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

14

2.1. Introduction p 142.2. Description p 152.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 Units)

Nom

0 GetRequest1 GetNextRequest2 SetRequest3 GetResponse4 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.2Le patch PHSS_26138 s700_800 11.x OV EMANATE14.2Le 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/serviceset 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

SNMP

Documents

Transcript of SNMP