Sécurité et communautés SNMP

La sécurité est importante en management de réseaux car l’accès aux équipements doit être
restreint au seul administrateur.

A cette fin, SNMP définit la notion de communauté ou Community. Une communauté

représente un groupe d’équipements ayant le même administrateur.

Communautés SNMP
Il existe trois Communautés en SNMP V1 et V2c:

 Communauté en lecture seule : Cette communauté autorise la lecture des variables

de l’équipement. (Community Read Only)
 Communauté en lecture et écriture : Cette communauté autorise la modification des
variables de l’équipement par la commande SET. (Community Read Write)

 Communauté pour les événements : Cette communauté est utilisée par l’agent pour
générer les paquets de type Trap.

Un manager doit connaître les communautés d'un équipement pour lire et/ou écrire les objets
SNMP de cet équipement.

Dans un message SNMP, la communauté SNMP fonctionne comme un mot de passe, le

message est authentifié dans la mesure où l'émetteur connaît le mot de passe. La communauté
n’étant pas cryptée dans les paquets SNMP parcourant le réseau, un nombre important de
failles de sécurité basées sur l’usurpation d’adresse et de communauté, est possible. Le
mécanisme de communauté du protocole SNMP dans ses versions 1 et 2c en fait un protocole
mal sécurisé. Pour faire face à cette problématique, diverses études ont été entreprises pour
finalement aboutir à la version trois du protocole qui permet plusieurs modes de sécurisation
basés sur une authentification forte et un possible chiffrement des informations contenues
dans le paquet. La version 3 du protocole permet l’utilisation d’un profil utilisateur associé à
un mot de passe.

Sécurité dans SNMP :

SNMP v1 :
Avantages et inconvénients de SNMPv1

1) Les 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.

1
 · 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.

2) Inconvénients

Le 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 grande 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.

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é.

2
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.

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 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.

Du côté sécurité, 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é.

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.

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.

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. 

SNMPv3

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 à

3
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.

Le fonctionnement de la sécurité dans SNMPv3

1) L'authentification :

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

Pour construire ce mécanisme, 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éder 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.

4
          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.

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.

C'est le mot de passe localisé qui est mémorisé dans l'agent et qui est utilisé par la plate-

5
forme. Il est employé dans l'authentification et le chiffrement des paquets SNMPv3.
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.

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érieure à 150
secondes, le paquet est ignoré.

 Remarque

La dernière version du protocole vise essentiellement à

inclure la sécurité des échanges. La sécurité comprend
l’identification Manager/Agent, et la confidentialité des
informations. Cette sécurité est basée sur deux concepts :
USM (User Security Model) et VACM (view-based Access
Control Model).

USM : trois mécanismes sont utilisés, chacun ayant pour

but d’empêcher un type d’attaque : (l’authentification, le
chiffrement et l’horodatage ou estampillage du temps)

VACM : permet le contrôle d’accès à la MIB en

restreignant l’accès en lecture et/ou écriture pour un
groupe ou pour un utilisateur.

6
7
 La RMON MIB et la sonde RMON

L'analyseur RMON représente un grand pas en avant dans l'administration d’interréseaux. Il définit
une MIB de surveillance à distance qui complète MIB-II et fournit à l'administrateur des informations
précieuses sur le réseau. RMON offre la caractéristique remarquable de n'être qu'une spécification
d'une MIB, sans modification du protocole SNMP sous-jacent, mais qui permet d'étendre
considérablement la fonctionnalité SNMP.

Avec MIB-II, l'administrateur réseau peut obtenir des informations qui sont purement locales à
certains équipements individuels.

 Imaginons un réseau local comprenant plusieurs équipements, chacun d'entre eux doté d'un agent
SNMP. Une station d'administration SNMP peut recevoir des informations sur la quantité de trafic
entrant et sortant de chaque équipement, mais avec MIB-II, elle ne peut pas être informée
facilement du trafic global du réseau local.

L'administration réseau dans un environnement d’interréseaux nécessite généralement un moniteur

par sous-réseau.

8
La norme RMON, à l'origine appelée IETF RFC 1271, et maintenant RFC 1757, a été conçue pour
fournir une surveillance et des diagnostics proactifs aux réseaux locaux distribués. Des dispositifs de
surveillance, appelés agents ou analyseurs, placés sur des segments stratégiques du réseau
permettent de créer des alarmes définies par l'utilisateur, ainsi que de rassembler une multitude de
statistiques vitales grâce à l'analyse de chaque trame d'un segment.

La norme RMON répertorie les fonctions de surveillance dans neuf groupes correspondant aux
topologies Ethernet, plus un dixième dans RFC 1513 pour les paramètres spécifiques à Token Ring. La
norme RMON a été développée dans le but d'être déployée comme une architecture distribuée dans
laquelle les agents et les analyseurs communiquent avec une station d'administration centralisée,
c’est-à-dire un client, au moyen du protocole SNMP. Ces agents ont défini des structures MIB SNMP
pour les neuf ou dix groupes RMON Ethernet ou Token Ring, ce qui permet une interopérabilité entre
les constructeurs d'outils de diagnostic RMON. Les groupes RMON sont définis ci-dessous:

 Groupe de statistiques – Tient à jour les statistiques d’erreur et d’utilisation du

sous-réseau ou du segment en cours de supervision. Il s'agit, par exemple, de
l'utilisation de la bande passante, du broadcast, du multicast, de l'alignement CRC,
des fragments, et ainsi de suite.
 Groupe de l'historique – Conserve des échantillons statistiques périodiques du
groupe des statistiques et les stocke en vue d’une extraction ultérieure. Il s'agit, par
exemple, de l'utilisation, du nombre d'erreurs et du nombre de paquets.
 Groupe des alarmes – Permet à l’administrateur de configurer l’intervalle et le seuil
d’échantillonnage pour tout élément enregistré par l’agent. Il s'agit, par exemple,
des valeurs absolues et relatives, ou des seuils en augmentation ou en diminution.
 Groupe des systèmes hôtes – Définit la mesure des différents types de trafic en
provenance et à destination des systèmes hôtes connectés au réseau. Il s'agit, par
exemple, des paquets envoyés ou reçus, des octets envoyés ou reçus, des erreurs
et des paquets de broadcast et de multicast.
 Groupe des systèmes hôtes TopN – Génère un rapport des systèmes hôtes TOPN
en s'appuyant sur les statistiques du groupe des systèmes hôtes.
 Groupe des matrices de trafic – Stocke les erreurs et les statistiques d’utilisation
relatives aux paires de nœuds qui communiquent sur le réseau. Il s'agit, par
exemple, des erreurs, des octets et des paquets.
 Groupe des filtres – Moteur de filtrage qui génère un flux de paquets à partir de
trames correspondant au schéma défini par l’utilisateur.
 Groupe d'interception des paquets – Définit la méthode de mise en tampon
interne des paquets qui répondent aux critères de filtrage.
 Groupe des événements – Permet de consigner des événements, également
appelés pièges générés, à l’intention de l'administrateur, avec date et heure. Il
s'agit par exemple de rapports personnalisés s'appuyant sur le type d'alarme