I. Présentation
Le protocole SNMP (Simple Network Management Protocol) est un protocole standard de l’IETF utilisé pour la gestion et la supervision d’équipements réseaux. Si le protocole SNMPv2c est toujours très utilisé dans les réseaux d’entreprise modernes, cela ne veut pas dire qu’il est sans défauts avec notamment de sérieuses failles de sécurité comme l’absence de chiffrement et une authentification qui repose sur une chaîne de communauté qui est transmise en clair.
Le protocole SNMPv3 a alors vu le jour pour répondre à ces problématiques en intégrant des fonctionnalités de sécurité avancées telles que l’authentification par HMAC (MD5 ou SHA) et le chiffrement des paquets par DES ou AES. Le protocole permet aussi un contrôle d’accès plus fin avec le User-based Security Model (USM) et le View-based Access Control Model (VACM).
Dans cet article, nous allons étudier SNMPv2c et SNMPv3 à travers des captures réseau effectuées à l’aide de Wireshark. L’objectif ici est de mettre en avant les principales différences en termes de sécurité entre SNMPv2c et SNMPv3, que ce soit au niveau des paquets ou de la confidentialité des données. Cette étude permettra de voir de façon concrète pourquoi SNMPv3 n’est aujourd’hui plus qu’une seule et unique option dans tous les environnements où un minimum de sécurité est requis.
II. Qu’est-ce que le SNMP ?
A. Rôle et objectifs de SNMP dans les réseaux
Le Simple Network Management Protocol (SNMP) est un protocole standardisé par l’IETF (Internet Engineering Task Force) qui permet la gestion et la supervision des équipements d’un réseau informatique. Il est défini pour fonctionner sur les réseaux TCP/IP et est massivement utilisé dans les environnements d’entreprise, des petites structures jusqu’aux grandes infrastructures distribuées.
Son objectif principal est de fournir un mécanisme universel d’interrogation et de modification à distance des informations de configuration et d’état des équipements réseau : routeurs, commutateurs, points d’accès Wi-Fi, imprimantes réseau, serveurs, onduleurs, etc.
SNMP permet notamment :
La supervision de l’état de santé des équipements
La surveillance des performances réseau (trafic, erreurs, charge)
Le déclenchement d’alertes en cas d’anomalie
L’automatisation des tâches de maintenance à distance
La centralisation des données de gestion dans un outil unique
Parmi les cas d’usage typiques, on retrouve :
L’utilisation de logiciels de supervision comme Centreon, Zabbix, Nagios ou PRTG pour afficher des tableaux de bord en temps réel et générer des alertes.
La mise en place de scripts d’administration permettant de collecter des métriques ou de modifier des paramètres via des requêtes SNMP.
La gestion d’inventaire automatisée avec des outils comme OCS Inventory.
SNMP repose sur une architecture client-serveur dans laquelle les équipements surveillés (les agents SNMP) fournissent des données au manager SNMP (l’outil de supervision), souvent sous forme de requêtes.
B. Fonctionnement général du protocole (Manager / Agent / MIB)
Dans cette partie de l’article, nous allons aborder le fonctionnement général du protocole SNMP, ce qui sera l’occasion d’évoquer la terminologie associée à celui-ci.
Le manager est l’entité centrale chargée de collecter et d’exploiter les données SNMP. C’est généralement une application logicielle installée sur un serveur (ex. : Centreon, Zabbix). Il interroge les agents pour obtenir des informations et peut aussi envoyer des commandes de modification.
Source : SlideServe @ Joseph M Edwards
Un agent est une application résidant sur l’équipement supervisé. Il écoute sur le port UDP 161 et répond aux requêtes du manager. L’agent accède aux informations locales (charge CPU, interfaces, etc.) et les expose via la MIB.
Source : SlideServe @ Joseph M Edwards
MIB (Management Information Base)
Il s’agit d’une base de données hiérarchique décrivant l’ensemble des objets pouvant être surveillés ou modifiés via SNMP. Chaque objet de la MIB est associé à un identifiant unique : l’OID (Object Identifier). Les MIB sont généralement rédigées en ASN.1 et regroupent des objets normalisés ou propriétaires.
Un OID est une suite de chiffres hiérarchiques séparés par des points, identifiant un objet dans la MIB. Par exemple :
– .1.3.6.1.2.1.1.5.0 correspond généralement au nom de l’équipement (sysName)
– .1.3.6.1.2.1.2.2.1.10.1 désigne le nombre d’octets reçus sur une interface réseau
De plus, SNMP définit plusieurs types de messages standardisés :
– GET : Permet au manager de récupérer la valeur d’un objet de la MIB.
– GETNEXT : Permet d’explorer la MIB en récupérant l’objet suivant dans la hiérarchie.
– SET : Permet de modifier la valeur d’un objet (avec les droits suffisants).
– TRAP : Notification envoyée de manière asynchrone par l’agent vers le manager pour signaler un événement (panne, alerte, etc.).
– INFORM : Similaire à TRAP, mais avec accusé de réception, introduit avec SNMPv2c.
Ces messages sont transportés en UDP, généralement sur les ports 161 (requêtes) et 162 (traps).
C. Évolution du protocole : SNMPv1, SNMPv2c et SNMPv3
L’histoire du protocole SNMP a débuté il y a plus de 40 ans et il y a plusieurs versions de ce protocole. Voici quelques mots sur ces versions et leurs caractéristiques.
Développé à la fin des années 1980, le protocole SNMPv1 se caractérise par les propriétés suivantes :
– Fonctionnalités basiques de supervision
– Authentification rudimentaire via une simple chaîne de texte : la community string
– Pas de chiffrement, données en clair sur le réseau
Au début des années 1990, une nouvelle version de SNMP a été publiée : version 2c. Elle a permis l’ajout de plusieurs améliorations, même si la sécurité a été négligée à cette époque :
– Introduction de nouveaux types de messages (GETBULK, INFORM)
– Performances accrues pour les échanges volumineux
– Toujours basé sur le mécanisme de community string
– Aucune amélioration en matière de sécurité
SNMPv2c a été préféré à SNMPv2p (version sécurisée, mais trop complexe à déployer). Il reste aujourd’hui encore largement utilisé malgré ses limitations.
La version actuelle de SNMP, à savoir SNMPv3, a été standardisé en 2002 (RFC 3410 à 3418). Elle a permis d’introduire plusieurs améliorations, notamment sur la partie sécurité :
– Intégration d’un modèle de sécurité basé sur les utilisateurs (USM)
– Authentification forte (HMAC avec MD5 ou SHA)
– Confidentialité des données via chiffrement (DES ou AES)
– Contrôle d’accès granulaire avec le modèle VACM
SNMPv3 répond aux exigences de sécurité modernes et permet une supervision sécurisée même sur des réseaux sensibles. Il est compatible avec les équipements SNMPv1/v2c grâce à des mécanismes d’interopérabilité.
D. Problèmes de sécurité des versions antérieures (v1 / v2c)
SNMPv1 et SNMPv2c souffrent de nombreux manquements en termes de sécurité :
Community string en clair
Les versions v1 et v2c se reposent sur une chaîne de communauté (public, private, …) comme seul facteur d’authentification. Cette chaîne est transmise en clair, permettant à un malfaiteur équipé d’un simple sniffeur comme Wireshark de s’en emparer en quelques secondes.
Les paquets SNMP sont transmis sans aucune couche de chiffrement, rendant possible l’écoute et l’analyse du contenu à loisir. Toutes les informations de supervision sont alors exposées à une interception passive sur le réseau.
Authentification insuffisante
Mis à part la community string, il n’y a pas de mécanisme supplémentaire d’identification. Le système est facile à duper, ne permet pas d’authentifier sérieusement l’émetteur des requêtes.
Conséquences concrètes :
Ces faiblesses en termes de sécurité ont des conséquences concrètes ! Nous pouvons citer quelques exemples.
– Interception de renseignements sur l’infrastructure
– Imitation d’un élément supervisé (SNMP spoofing)
– Changement inapproprié de réglages sensibles (avec SET)
– Obtention de manière détournée de la topologie du réseau
Toutes ces raisons font que SNMPv1 et SNMPv2c ne conviennent plus à des environnements professionnels actuels, notamment dans des secteurs où confidentialité, intégrité et authentification sont des impératifs normatifs ou contractuels (ex. : banque, santé, industrie, …).
III. Mécanismes de sécurité apportés par SNMPv3
Avec SNMPv3, l’architecture du protocole évolue profondément pour répondre aux enjeux de sécurité réseau. Alors que SNMPv1 et SNMPv2c exposaient les systèmes à des risques majeurs (comme la transmission de données en clair ou l’absence d’authentification forte), SNMPv3 intègre nativement des mécanismes d’authentification, de chiffrement et de contrôle d’accès. Ces mécanismes reposent sur deux modèles fondamentaux : USM (User-based Security Model) pour la sécurité des échanges, et VACM (View-based Access Control Model) pour la gestion fine des droits.
A. Authentification HMAC (MD5 / SHA)
Le premier pilier de la sécurité en SNMPv3 est l’intégrité des messages, assurée par une authentification HMAC. Concrètement, SNMPv3 utilise une fonction de hachage (comme MD5, SHA-1 ou SHA-256) combinée à une clé secrète (le mot de passe de l’utilisateur) pour générer une signature du message. À la réception, cette signature est recalculée et comparée à celle jointe dans le paquet. Toute modification, même minime, entraîne un échec d’authentification.
Techniquement, la signature HMAC est insérée dans le champ msgAuthenticationParameters du message SNMP. Ce champ est calculé sur tout le message (hors lui-même) via l’algorithme défini. Le résultat est un code HMAC de 12 octets (pour SHA-1 ou MD5) qui garantit que le message n’a ni été altéré ni falsifié.
L’utilisation de SHA est fortement recommandée, car MD5 est aujourd’hui vulnérable aux attaques de collision. Une attaque de collision MD5 est une méthode permettant de créer une paire d’entrées pour lesquelles MD5 produit des sommes de contrôle identiques.
Note : En 2010, le CMU Software Engineering Institute considère que MD5 est « cryptographiquement cassé et impropre à une utilisation ultérieure » et la plupart des applications du gouvernement américain nécessitent désormais la famille de fonctions de hachage.
B. Chiffrement avec DES / AES
SNMPv3 propose en option un chiffrement de la charge utile des messages, assurant la confidentialité des données transmises. Ce chiffrement est activé pour les utilisateurs de niveau authPriv et repose sur les algorithmes DES (56 bits) ou AES (128 bits).
Lors de l’envoi d’un message SNMPv3, les données PDU sont chiffrées à l’aide d’une clé dérivée du mot de passe de chiffrement, passé avec l’option -X dans les outils net-snmp. Le vecteur d’initialisation est généré à partir d’un compteur de messages et d’un identifiant unique de l’utilisateur (engineID). Le champ encryptedPDU remplace alors la PDU classique, empêchant toute lecture directe du contenu avec un simple Wireshark.
Nous observerons plus tard, une capture Wireshark, où l’on identifie clairement un message chiffré par la présence du champ scopedPDU (encrypted) au lieu des champs standards comme sysDescr.0 visibles dans SNMPv2c.
L’usage d’AES est aujourd’hui la norme, notamment AES-128-CFB, car DES est obsolète, facilement cassable et parfois désactivé dans les systèmes pour des raisons de sécurité.
C. Modèle de sécurité basé sur les utilisateurs (USM)
SNMPv3 repose sur le modèle USM (User-based Security Model), dans lequel chaque message est associé à un utilisateur SNMP défini localement sur l’agent. Ce modèle permet de spécifier pour chaque utilisateur le niveau de sécurité attendu : noAuthNoPriv, authNoPriv, ou authPriv. Le premier n’utilise aucun mécanisme de sécurité (comme SNMPv1/v2c), le second ajoute une vérification d’authenticité, et le troisième assure en plus la confidentialité des échanges.
Un utilisateur peut être créé via l’outil net-snmp-config de la manière suivante :
net-snmp-config –create-snmpv3-user \
-a SHA -A “authPass123” \
-x AES -X “cryptPass456” \
-u adminsnmp
Cette commande enregistre un utilisateur adminsnmp, avec authentification SHA et chiffrement AES, les mots de passe étant dérivés pour générer les clés internes. Sur un hôte Linux, ces utilisateurs sont ensuite stockés dans /var/lib/net-snmp/snmpd.conf ou une base persistante selon l’implémentation.
Dans une trame SNMPv3, on retrouve les champs msgUserName, msgAuthenticationParameters et msgPrivacyParameters, qui reflètent directement les choix de sécurité faits pour l’utilisateur.
D. Modèle de contrôle VACM
Le modèle VACM (View-based Access Control Model) permet de restreindre l’accès aux différentes parties de la MIB, en lecture, écriture ou notification, en fonction de l’utilisateur SNMPv3. Cela permet de configurer un contrôle d’accès fin, en définissant des vues, des groupes et des règles d’accès.
Une vue est un sous-ensemble d’OID autorisés. Par exemple, une vue contenant uniquement les informations système peut être définie par :
view viewSystemOnly included .1.3.6.1.2.1.1
Ensuite, cette vue peut être associée à un groupe d’utilisateurs :
group readonlyGroup usm adminsnmp
Enfin, on applique une règle d’accès :
access readonlyGroup “” usm authPriv exact viewSystemOnly none none
Dans ce cas, l’utilisateur adminsnmp ne pourra accéder qu’à la vue viewSystemOnly, et uniquement en lecture. Toute tentative d’accès à une autre branche de la MIB sera refusée avec un message “noSuchName” ou “authorizationError” selon les cas.
Ce modèle est essentiel dans des contextes sensibles, où un utilisateur SNMP ne doit voir qu’un nombre limité d’informations (par exemple, supervision par un prestataire externe). Il permet de concilier sécurité, principe du moindre privilège et traçabilité des accès.
Source : SlideServe @ Joseph M Edwards
IV. Mise en place d’un environnement de test SNMPv2c vs SNMPv3
Pour évaluer concrètement les différences entre SNMPv2c et SNMPv3, un laboratoire de test a été mis en place avec une architecture simple, mais représentative des environnements réseau classiques.
Le laboratoire est constitué de deux machines virtuelles sous Linux Debian 12, configurées pour simuler un agent SNMP et un poste client. Sur la machine agent, le service snmpd (démon SNMP fourni par la suite net-snmp) est installé et configuré pour supporter à la fois SNMPv2c et SNMPv3. La machine cliente dispose des outils en ligne de commande snmpget et snmpwalk pour interroger l’agent. Enfin, le réseau est monitoré à l’aide de Wireshark pour capturer et analyser les trames échangées.
Pour en savoir plus sur Wireshark suivez nos articles :
Dans notre laboratoire, nous serons dans la situation suivante : notre firewall paramétré avec du SNMPv2c et une machine Linux utilisant du SNMPv3.
A. Wireshark : analyse des flux SNMPv2c
Afin de capturer précisément les échanges SNMP entre le client et l’agent, nous avons utilisé Wireshark. Cet outil permet d’effectuer des captures réseau, de les filtrer finement, et extraire des informations.
Ce mode de capture permet de visualiser les requêtes snmpget et snmpwalk lancées depuis le poste client, ainsi que les réponses retournées par l’agent SNMP. Dans le cas de SNMPv2c, les trames affichées révèlent très clairement la community string utilisée, les OID interrogés et les valeurs retournées. Ces éléments sont visibles en clair dans les trames capturées, ce qui expose potentiellement des informations sensibles à tout attaquant à l’écoute sur le réseau.
En revanche, lorsqu’une requête est envoyée via SNMPv3 avec chiffrement activé (mode authPriv), les trames capturées par Wireshark contiennent des sections chiffrées. Le contenu du message (OID, valeurs, identité de l’utilisateur) est masqué. Par exemple, une requête SNMPv3 de type snmpget retourne un paquet avec un champ EncryptedPDU, dans lequel aucune information exploitable ne peut être extraite, même avec l’analyse poussée de Wireshark.
Pour essayer ceci, nous allons faire un snmpwalk sur notre firewall et la community string utilisée afin de voir ce que la capture réseau nous retourne :
snmpwalk -v 2c -c IT-Connect 110.30.111.38
La capture nous montre une série de requêtes de type get-next-request envoyées par le client, ainsi que les réponses correspondantes de type get-response émises par l’agent. Ces échanges permettent de parcourir l’arborescence SNMP grâce à l’outil snmpwalk. Les OID interrogés (ex. : 1.3.6.1.2.1.92.1.3.2.1.10…) ainsi que les valeurs retournées sont entièrement visibles en clair, tout comme les types d’opérations effectuées. Voici l’un des principaux défauts de SNMPv2c : l’absence totale de chiffrement et d’authentification forte, exposant l’intégralité du dialogue SNMP à toute personne en mesure d’écouter le trafic réseau.
B. Wireshark : analyse des flux SNMPv3
Désormais, effectuons le test avec notre machine Linux configuré avec SNMPv3. Nous utiliserons la commande suivante afin de pouvoir effectuer un snmpwalk :
snmpwalk -v3 -l authPriv -u centreon -a SHA -A “MySuperSecretPass123!” -x AES -X “MySuperSecretPass123!” 10.30.111.64
Dans cette seconde capture réseau, on observe nos échanges SNMPv3 entre nos hôtes. Contrairement à la précédente capture en SNMPv2c, toutes les trames apparaissent sous la forme d’unités PDU chiffrées, identifiées par le champ encryptedPDU: privKey. Cela signifie que les messages SNMP sont chiffrés à l’aide d’une clé privée, conformément au niveau de sécurité authPriv de SNMPv3, qui combine authentification forte et chiffrement des données. Les contenus exacts des requêtes et des réponses (OID, types d’opérations, valeurs, etc.) sont totalement inaccessibles à l’analyse sans disposer des clés de déchiffrement.
V. Conclusion
L’évolution de SNMP du protocole v2c à v3 constitue une avancée intéressante en termes de sécurité et de gouvernance réseau. SNMPv2c s’appuie sur une community string envoyée en clair sur le réseau, un mécanisme d’authentification insuffisant qui expose les infrastructures à des risques de compromission par interception. Cette vulnérabilité a été maintes fois démontrée, notamment via des outils de sniffing tels que Wireshark, facilitant les attaques par usurpation d’identité. En effet, SNMPv2c ne dispose pas non plus d’un contrôle d’accès robuste, autorisant toute entité disposant de la community string à interroger ou modifier les équipements réseau, ce qui constitue un risque réel en environnement professionnel.
À l’inverse, SNMPv3 introduit un modèle de sécurité complet, le User-based Security Model (USM), qui repose sur des utilisateurs authentifiés via des mécanismes cryptographiques (HMAC avec SHA ou SHA-2). Il assure également la confidentialité des échanges grâce à un chiffrement symétrique (AES, DES). Par ailleurs, le contrôle d’accès est assuré par le View-based Access Control Model (VACM), qui permet de définir finement les permissions d’accès selon l’utilisateur, le groupe et le contexte, rendant ainsi la gestion plus granulaire et sécurisée. Ces mécanismes sont décrits en détail dans la norme officielle RFC 3411 et ses annexes.
L’importance de cette sécurisation accrue dépasse le cadre technique et s’inscrit dans des exigences réglementaires strictes. Par exemple, le RGPD impose aux entreprises de protéger les données personnelles et de mettre en place des mesures de sécurité adaptées, ce qui inclut la sécurisation des protocoles d’administration réseau. Ceci est pertinent en fonction de ce qui est remonté comme information via votre supervision.
De même, la norme internationale ISO/IEC 27001 impose un cadre strict pour la gestion des risques liés aux systèmes d’information, incluant la mise en œuvre de contrôles d’accès et la traçabilité, tous deux pris en charge par SNMPv3. Le guide technique du NIST, notamment le NIST SP 800-115, recommande également l’utilisation de protocoles sécurisés pour la gestion des équipements afin de limiter les surfaces d’attaque.
Enfin, sachez qu’il existe aussi des alternatives au protocole SNMP, comme les protocoles NETCONF et RESTCONF qui utilisent des formats de données structurés (XML, JSON) et le transport est sécurisé via HTTPS.
Je m’appelle Bezet-Torres Mattéo et je suis étudiant en cycle d’ingénieur en cybersécurité. Je suis passionné par l’informatique et souhaite faire part de mes connaissances et mes expériences à travers mes écrits.