Protocole de gestion de réseau simple

Le protocole SNMP ( Simple Network Management Protocol ) est un protocole Internet standard permettant de collecter et d'organiser les informations sur les périphériques gérés sur les réseaux IP et de modifier ces informations pour modifier le comportement des périphériques. Les périphériques qui prennent généralement en charge SNMP incluent les modems câble , les routeurs , les commutateurs réseau , les serveurs, les postes de travail, les imprimantes, etc.

SNMP est largement utilisé dans la gestion de réseau pour la surveillance du réseau . SNMP expose les données de gestion sous forme de variables sur les systèmes gérés organisées dans une base d'informations de gestion (MIB), qui décrit l'état et la configuration du système. Ces variables peuvent ensuite être interrogées à distance (et, dans certaines circonstances, manipulées) par les applications de gestion.

Trois versions importantes du protocole SNMP ont été développées et déployées. SNMPv1 est la version originale du protocole. Les versions plus récentes, SNMPv2c et SNMPv3, présentent des améliorations en termes de performances, de flexibilité et de sécurité.

SNMP est un composant de la suite de protocoles Internet telle que définie par l' Internet Engineering Task Force (IETF). Il se compose d'un ensemble de normes pour la gestion de réseau, comprenant un protocole de couche application , un schéma de base de données et un ensemble d' objets de données .

Dans les utilisations typiques de SNMP, un ou plusieurs ordinateurs administratifs appelés gestionnaires ont pour tâche de surveiller ou de gérer un groupe d'hôtes ou de périphériques sur un réseau informatique . Chaque système géré exécute un composant logiciel appelé agent qui transmet des informations via SNMP au gestionnaire.

Un réseau géré par SNMP se compose de trois éléments clés :

• Appareils gérés
• Agent – ​​logiciel qui s’exécute sur les appareils gérés
• Station de gestion de réseau (NMS) – logiciel qui s'exécute sur le gestionnaire

Un périphérique géré est un nœud de réseau qui implémente une interface SNMP qui permet un accès unidirectionnel (lecture seule) ou bidirectionnel (lecture et écriture) aux informations spécifiques au nœud. Les périphériques gérés échangent des informations spécifiques au nœud avec les NMS. Parfois appelés éléments de réseau, les périphériques gérés peuvent être n'importe quel type de périphérique, y compris, mais sans s'y limiter, les routeurs , les serveurs d'accès , les commutateurs , les modems câble , les ponts , les concentrateurs , les téléphones IP , les caméras vidéo IP , les hôtes informatiques et les imprimantes .

Un agent est un module logiciel de gestion de réseau qui réside sur un périphérique géré. Un agent possède une connaissance locale des informations de gestion et traduit ces informations vers ou depuis un format spécifique à SNMP.

Une station de gestion de réseau exécute des applications qui surveillent et contrôlent les périphériques gérés. Les stations de gestion de réseau fournissent l'essentiel des ressources de traitement et de mémoire nécessaires à la gestion du réseau. Une ou plusieurs stations de gestion de réseau peuvent exister sur n'importe quel réseau géré.

Les agents SNMP exposent les données de gestion sur les systèmes gérés sous forme de variables. Le protocole permet également d'effectuer des tâches de gestion actives, telles que des modifications de configuration, via la modification à distance de ces variables. Les variables accessibles via SNMP sont organisées en hiérarchies. SNMP lui-même ne définit pas les variables qu'un système géré doit proposer. Au lieu de cela, SNMP utilise une conception extensible qui permet aux applications de définir leurs propres hiérarchies. Ces hiérarchies sont décrites comme une base d'informations de gestion (MIB). Les MIB décrivent la structure des données de gestion d'un sous-système de périphérique ; elles utilisent un espace de noms hiérarchique contenant des identifiants d'objet (OID). Chaque OID identifie une variable qui peut être lue ou définie via SNMP. Les MIB utilisent la notation définie par Structure of Management Information Version 2.0 (SMIv2, RFC 2578), un sous-ensemble d' ASN.1 .

SNMP fonctionne dans la couche application de la suite de protocoles Internet . Tous les messages SNMP sont transportés via le protocole UDP ( User Datagram Protocol ). L'agent SNMP reçoit les requêtes sur le port UDP 161. Le gestionnaire peut envoyer des requêtes depuis n'importe quel port source disponible vers le port 161 de l'agent. La réponse de l'agent est renvoyée au port source du gestionnaire. Le gestionnaire reçoit des notifications ( Traps et InformRequests ) sur le port 162. L'agent peut générer des notifications depuis n'importe quel port disponible. Lorsqu'il est utilisé avec Transport Layer Security ou Datagram Transport Layer Security , les requêtes sont reçues sur le port 10161 et les notifications sont envoyées sur le port 10162.

SNMPv1 spécifie cinq unités de données de protocole (PDU) principales. Deux autres PDU, GetBulkRequest et InformRequest, ont été ajoutées dans SNMPv2 et la PDU de rapport a été ajoutée dans SNMPv3. Toutes les PDU SNMP sont construites comme suit :

Les sept types de PDU SNMP identifiés par le champ PDU-type sont les suivants :

Obtenir une demande

Une requête de gestionnaire à agent pour récupérer la valeur d'une variable ou d'une liste de variables. Les variables souhaitées sont spécifiées dans les liaisons de variables (le champ de valeur n'est pas utilisé). La récupération des valeurs de variable spécifiées doit être effectuée par l'agent sous forme d' opération atomique . Une réponse avec les valeurs actuelles est renvoyée.

Définir la requête

Une requête de gestionnaire à agent pour modifier la valeur d'une variable ou d'une liste de variables. Les liaisons de variables sont spécifiées dans le corps de la requête. Les modifications de toutes les variables spécifiées doivent être effectuées par l'agent sous forme d'opération atomique. Une réponse avec de nouvelles valeurs (actuelles) pour les variables est renvoyée.

Obtenir la prochaine demande

Une requête de gestionnaire à agent pour découvrir les variables disponibles et leurs valeurs. Renvoie une réponse avec une liaison de variable pour la variable lexicographiquement suivante dans la MIB. La MIB entière d'un agent peut être parcourue par une application itérative de GetNextRequest à partir de l'OID 0. Les lignes d'une table peuvent être lues en spécifiant les OID de colonne dans les liaisons de variable de la requête.

Obtenir une demande en vrac

Une requête gestionnaire-agent pour plusieurs itérations de GetNextRequest . Une version optimisée de GetNextRequest . Renvoie une réponse avec plusieurs liaisons de variables parcourues à partir de la ou des liaisons de variables dans la requête. Les champs non répéteurs et max-repetitions spécifiques à PDU sont utilisés pour contrôler le comportement de la réponse. GetBulkRequest a été introduit dans SNMPv2.

Réponse

Renvoie les liaisons de variables et les accusés de réception de l'agent au gestionnaire pour GetRequest , SetRequest , GetNextRequest , GetBulkRequest et InformRequest . Le rapport d'erreur est fourni par les champs error-status et error-index . Bien qu'il ait été utilisé comme réponse aux deux opérations get et set, ce PDU était appelé GetResponse dans SNMPv1.

Piège

Notification asynchrone de l'agent au gestionnaire. Alors que dans d'autres communications SNMP, le gestionnaire demande activement des informations à l'agent, il s'agit de PDU qui sont envoyées de l'agent au gestionnaire sans avoir été explicitement demandées. Les interruptions SNMP permettent à un agent de notifier la station de gestion d'événements importants au moyen d'un message SNMP non sollicité. Les PDU d'interruption incluent la valeur sysUpTime actuelle , un OID identifiant le type d'interruption et des liaisons de variables facultatives. L'adressage de destination des interruptions est déterminé de manière spécifique à l'application, généralement via des variables de configuration d'interruption dans la MIB. Le format du message d'interruption a été modifié dans SNMPv2 et le PDU a été renommé SNMPv2-Trap .

InformRequest

Notification asynchrone reconnue. Cette PDU a été introduite dans SNMPv2 et était initialement définie comme une communication de gestionnaire à gestionnaire . Les implémentations ultérieures ont assoupli la définition d'origine pour permettre les communications d'agent à gestionnaire . Les notifications de gestionnaire à gestionnaire étaient déjà possibles dans SNMPv1 à l'aide d'un Trap , mais comme SNMP s'exécute généralement sur UDP où la livraison n'est pas assurée et les paquets abandonnés ne sont pas signalés, la livraison d'un Trap n'était pas garantie. InformRequest corrige ce problème car un accusé de réception est renvoyé à la réception.

La RFC 1157 spécifie qu'une implémentation SNMP doit accepter un message d'au moins 484 octets de longueur. En pratique, les implémentations SNMP acceptent des messages plus longs. S'il est correctement implémenté, un message SNMP est rejeté si le décodage du message échoue et les requêtes SNMP mal formées sont donc ignorées. Une requête SNMP décodée avec succès est ensuite authentifiée à l'aide de la chaîne de communauté. Si l'authentification échoue, une interruption est générée indiquant un échec d'authentification et le message est abandonné.

SNMPv1 et SNMPv2c utilisent des communautés pour établir la confiance entre les gestionnaires et les agents. La plupart des agents prennent en charge trois noms de communauté, un pour la lecture seule, un pour la lecture-écriture et un pour l'interruption. Ces trois chaînes de communauté contrôlent différents types d'activités. La communauté en lecture seule s'applique aux demandes d'obtention . La chaîne de communauté en lecture-écriture s'applique aux demandes de définition . La chaîne de communauté d'interruption s'applique à la réception d' interruptions . SNMPv3 utilise également des chaînes de communauté, mais permet une authentification et une communication sécurisées entre le gestionnaire et l'agent SNMP.

En pratique, les implémentations SNMP prennent souvent en charge plusieurs versions : généralement SNMPv1, SNMPv2c et SNMPv3.

SNMP version 1 (SNMPv1) est l'implémentation initiale du protocole SNMP. La conception de SNMPv1 a été réalisée dans les années 1980 par un groupe de collaborateurs qui considéraient que l'effort officiellement parrainé par l'OSI/IETF/NSF (National Science Foundation) (HEMS/CMIS/CMIP) était à la fois impossible à mettre en œuvre sur les plateformes informatiques de l'époque et potentiellement impraticable. SNMP a été approuvé sur la base de la conviction qu'il s'agissait d'un protocole provisoire nécessaire pour prendre des mesures en vue du déploiement à grande échelle d'Internet et de sa commercialisation.

La première demande de commentaires (RFC) pour SNMP, désormais connue sous le nom de SNMPv1, est apparue en 1988 :

• RFC 1065 — Structure et identification des informations de gestion pour les réseaux Internet basés sur TCP/IP
• RFC 1066 — Base d'informations de gestion pour la gestion des réseaux Internet basés sur TCP/IP
• RFC 1067 — Un protocole simple de gestion de réseau

En 1990, ces documents ont été remplacés par :

• RFC 1155 — Structure et identification des informations de gestion pour les réseaux Internet basés sur TCP/IP
• RFC 1156 — Base d'informations de gestion pour la gestion des réseaux Internet basés sur TCP/IP
• RFC 1157 — Un protocole simple de gestion de réseau

En 1991, la RFC 1156 (MIB-1) a été remplacée par la norme plus souvent utilisée :

• RFC 1213 — Version 2 de la base d'informations de gestion (MIB-2) pour la gestion des réseaux Internet basés sur TCP/IP

SNMPv1 est largement utilisé et constitue le protocole de gestion de réseau de facto dans la communauté Internet.

SNMPv1 peut être transporté par des protocoles de couche transport tels que User Datagram Protocol (UDP), OSI Connectionless-mode Network Service (CLNS), AppleTalk Datagram Delivery Protocol (DDP) et Novell Internetwork Packet Exchange (IPX).

La version 1 a été critiquée pour son manque de sécurité. La spécification permet en effet l'utilisation d'une authentification personnalisée, mais les implémentations largement utilisées « ne prennent en charge qu'un service d'authentification trivial qui identifie tous les messages SNMP comme des messages SNMP authentiques ». La sécurité des messages dépend donc de la sécurité des canaux sur lesquels les messages sont envoyés. Par exemple, une organisation peut considérer que son réseau interne est suffisamment sécurisé pour qu'aucun chiffrement ne soit nécessaire pour ses messages SNMP. Dans de tels cas, le nom de communauté , qui est transmis en clair , tend à être considéré comme un mot de passe de facto, malgré la spécification d'origine.

SNMPv2, défini par les RFC 1441 et RFC 1452, révise la version 1 et inclut des améliorations dans les domaines des performances, de la sécurité et des communications entre gestionnaires. Il a introduit GetBulkRequest , une alternative aux GetNextRequests itératifs pour récupérer de grandes quantités de données de gestion dans une seule requête. Le nouveau système de sécurité basé sur les parties introduit dans SNMPv2, considéré par beaucoup comme trop complexe, n'a pas été largement adopté. Cette version de SNMP a atteint le niveau de maturité de la norme proposée, mais a été jugée obsolète par les versions ultérieures.

Le protocole de gestion de réseau simple basé sur la communauté version 2 , ou SNMPv2c , est défini dans les RFC 1901– RFC 1908. SNMPv2c comprend SNMPv2 sans le nouveau modèle de sécurité controversé SNMP v2, utilisant à la place le schéma de sécurité communautaire simple de SNMPv1. Cette version est l'une des rares normes à atteindre le niveau de maturité du projet de norme de l'IETF et a été largement considérée comme la norme SNMPv2 de facto Elle a ensuite été reformulée dans le cadre de SNMPv3.

Le protocole SNMPv2u , ou User-Based Simple Network Management Protocol version 2 , est défini dans les RFC 1909– RFC 1910. Il s'agit d'un compromis qui tente d'offrir une plus grande sécurité que SNMPv1, mais sans entraîner la grande complexité de SNMPv2. Une variante de ce protocole a été commercialisée sous le nom de SNMP v2* , et le mécanisme a finalement été adopté comme l'un des deux cadres de sécurité de SNMP v3.

La version 2 de SNMP introduit l'option pour les compteurs de données 64 bits. La version 1 a été conçue uniquement avec des compteurs 32 bits, qui peuvent stocker des valeurs entières de zéro à 4,29 milliards (précisément4 294 967 295 ). Un compteur 32 bits version 1 ne peut pas stocker la vitesse maximale d'une interface de 10 gigabits ou plus, exprimée en bits par seconde. De même, un compteur 32 bits qui suit les statistiques d'une interface de 10 gigabits ou plus peut revenir à zéro en moins d'une minute, ce qui peut être un intervalle de temps plus court que celui pendant lequel un compteur est interrogé pour lire son état actuel. Cela entraînerait une perte de données ou des données non valides en raison du basculement de valeur non détecté et de la corruption des données de suivi des tendances.

Le compteur 64 bits version 2 peut stocker des valeurs de zéro à 18,4 quintillions (précisément 18 446 744 073 709 551 615) et il est donc peu probable qu'il subisse un basculement de compteur entre les événements d'interrogation. Par exemple, il est prévu que l'Ethernet 1,6 térabit soit disponible d'ici 2025. Un compteur 64 bits incrémenté à un taux de 1,6 billion de bits par seconde serait capable de conserver les informations d'une telle interface sans basculement pendant 133 jours.

SNMPv2c est incompatible avec SNMPv1 dans deux domaines clés : les formats de message et les opérations de protocole. Les messages SNMPv2c utilisent des formats d'en-tête et d'unité de données de protocole (PDU) différents de ceux des messages SNMPv1. SNMPv2c utilise également deux opérations de protocole qui ne sont pas spécifiées dans SNMPv1. Pour surmonter l'incompatibilité, la RFC 3584 définit deux stratégies de coexistence SNMPv1/v2c : les agents proxy et les systèmes de gestion de réseau bilingues.

Un agent SNMPv2 peut agir en tant qu'agent proxy pour le compte des périphériques gérés par SNMPv1. Lorsqu'un NMS SNMPv2 émet une commande destinée à un agent SNMPv1, il l'envoie à l'agent proxy SNMPv2. L'agent proxy transmet les messages Get, GetNextet Setà l'agent SNMPv1 sans les modifier. Les messages GetBulk sont convertis par l'agent proxy en GetNextmessages, puis transmis à l'agent SNMPv1. De plus, l'agent proxy reçoit et mappe les messages d'interruption SNMPv1 aux messages d'interruption SNMPv2, puis les transmet au NMS.

Les systèmes de gestion de réseau SNMPv2 bilingues prennent en charge SNMPv1 et SNMPv2. Pour prendre en charge cet environnement de gestion double, une application de gestion examine les informations stockées dans une base de données locale pour déterminer si l'agent prend en charge SNMPv1 ou SNMPv2. En fonction des informations contenues dans la base de données, le NMS communique avec l'agent à l'aide de la version appropriée de SNMP.

Bien que SNMPv3 n'apporte aucun changement au protocole en dehors de l'ajout de sécurité cryptographique, il semble très différent en raison de nouvelles conventions textuelles, de nouveaux concepts et d'une nouvelle terminologie. Le changement le plus visible a été de définir une version sécurisée de SNMP, en ajoutant des améliorations de sécurité et de configuration à distance à SNMP. L'aspect sécurité est abordé en offrant à la fois une authentification forte et un cryptage des données pour la confidentialité. Pour l'aspect administration, SNMPv3 se concentre sur deux parties, à savoir les initiateurs de notifications et les transitaires proxy. Les modifications facilitent également la configuration et l'administration à distance des entités SNMP, ainsi que la résolution des problèmes liés au déploiement à grande échelle, à la comptabilité et à la gestion des pannes.

Fonctionnalités et améliorations incluses :

• Identification des entités SNMP pour faciliter la communication uniquement entre entités SNMP connues – Chaque entité SNMP possède un identifiant appelé SNMPEngineID, et la communication SNMP n'est possible que si une entité SNMP connaît l'identité de son homologue. Les interruptions et les notifications sont des exceptions à cette règle.
• Prise en charge des modèles de sécurité – Un modèle de sécurité peut définir la politique de sécurité au sein d'un domaine administratif ou d'un intranet. SNMPv3 contient les spécifications d'un modèle de sécurité basé sur l'utilisateur (USM).
• Définition des objectifs de sécurité où les objectifs du service d'authentification des messages incluent la protection contre les éléments suivants :
  • Modification des informations – Protection contre toute altération par une entité SNMP non autorisée des messages en transit générés par un principal autorisé.
  • Mascarade – Protection contre les tentatives d’opérations de gestion non autorisées pour un mandant en usurpant l’identité d’un autre mandant disposant des autorisations appropriées.
  • Modification du flux de messages – Protection contre les messages réorganisés, retardés ou relus de manière malveillante, ce qui pourrait affecter les opérations de gestion non autorisées.
  • Divulgation – Protection contre les écoutes clandestines sur les échanges entre les moteurs SNMP.
• Spécification pour USM – USM comprend la définition générale des mécanismes de communication suivants disponibles :
  • Communication sans authentification et confidentialité (NoAuthNoPriv).
  • Communication avec authentification et sans confidentialité (AuthNoPriv).
  • Communication avec authentification et confidentialité (AuthPriv).
• Définition de différents protocoles d'authentification et de confidentialité – Les protocoles d'authentification MD5, SHA et HMAC-SHA-2 et les protocoles de confidentialité CBC_DES et CFB_AES_128 sont pris en charge dans l'USM.
• Définition d'une procédure de découverte – Pour trouver le SNMPEngineID d'une entité SNMP pour une adresse de transport et une adresse de point de terminaison de transport données.
• Définition de la procédure de synchronisation temporelle – Pour faciliter la communication authentifiée entre les entités SNMP.
• Définition du framework SNMP MIB – Pour faciliter la configuration et l’administration à distance de l’entité SNMP.
• Définition des MIB USM – Pour faciliter la configuration et l’administration à distance du module de sécurité.
• Définition des MIB du modèle de contrôle d'accès basé sur la vue (VACM) – Pour faciliter la configuration et l'administration à distance du module de contrôle d'accès.

La sécurité était l'une des plus grandes faiblesses de SNMP jusqu'à la version 3. L'authentification dans les versions 1 et 2 de SNMP se résume à un mot de passe (chaîne de communauté) envoyé en texte clair entre un gestionnaire et un agent. Chaque message SNMPv3 contient des paramètres de sécurité codés sous forme de chaîne d'octets. La signification de ces paramètres de sécurité dépend du modèle de sécurité utilisé. L'approche de sécurité dans la version 3 vise :

• Confidentialité – Cryptage des paquets pour empêcher l’espionnage par une source non autorisée.
• Intégrité – Intégrité du message pour garantir qu’un paquet n’a pas été altéré pendant le transit, y compris un mécanisme facultatif de protection contre la relecture des paquets.
• Authentification – pour vérifier que le message provient d’une source valide.

v3 définit également l'USM et le VACM, qui ont été suivis plus tard par un modèle de sécurité de transport (TSM) qui a fourni la prise en charge de SNMPv3 sur SSH et SNMPv3 sur TLS et DTLS.

• USM (User-based Security Model) fournit des fonctions d'authentification et de confidentialité (cryptage) et fonctionne au niveau du message.
• VACM (View-based Access Control Model) détermine si un principal donné est autorisé à accéder à un objet MIB particulier pour exécuter des fonctions spécifiques et fonctionne au niveau PDU.
• TSM (Transport Security Model) fournit une méthode d'authentification et de chiffrement des messages sur des canaux de sécurité externes. Deux transports, SSH et TLS/DTLS, ont été définis et utilisent la spécification TSM.

Depuis 2004, l' IETF reconnaît le protocole Simple Network Management Protocol version 3 tel que défini par les RFC 3411– RFC 3418 (également connu sous le nom de STD0062) comme la version standard actuelle de SNMP. L' IETF a désigné SNMPv3 comme une norme Internet complète , le niveau de maturité le plus élevé pour une RFC. Elle considère les versions antérieures comme obsolètes (les désignant de différentes manières comme historiques ou obsolètes ).

Les puissantes capacités d'écriture de SNMP, qui permettraient la configuration des périphériques réseau, ne sont pas pleinement utilisées par de nombreux fournisseurs, en partie à cause d'un manque de sécurité dans les versions SNMP antérieures à SNMPv3, et en partie parce que de nombreux périphériques ne peuvent tout simplement pas être configurés via des modifications d'objet MIB individuelles.

Certaines valeurs SNMP (en particulier les valeurs tabulaires) nécessitent une connaissance spécifique des schémas d'indexation de table, et ces valeurs d'index ne sont pas nécessairement cohérentes entre les plates-formes. Cela peut entraîner des problèmes de corrélation lors de la récupération d'informations à partir de plusieurs périphériques qui peuvent ne pas utiliser le même schéma d'indexation de table (par exemple, la récupération de mesures d'utilisation du disque, où un identifiant de disque spécifique est différent selon les plates-formes.)

Certains fournisseurs d'équipements majeurs ont tendance à étendre de manière excessive leurs systèmes de configuration et de contrôle centrés sur l'interface de ligne de commande (CLI) propriétaire.

En février 2002, le Centre de coordination de l'équipe d'intervention d'urgence informatique (CERT-CC) du Carnegie Mellon Software Engineering Institute (CM-SEI) a publié un avis sur SNMPv1, après que le groupe de programmation sécurisée de l'université d'Oulu a mené une analyse approfondie de la gestion des messages SNMP. La plupart des implémentations SNMP, quelle que soit la version du protocole qu'elles prennent en charge, utilisent le même code de programme pour décoder les unités de données de protocole (PDU) et des problèmes ont été identifiés dans ce code. D'autres problèmes ont été détectés lors du décodage des messages d'interruption SNMP reçus par la station de gestion SNMP ou des requêtes reçues par l'agent SNMP sur le périphérique réseau. De nombreux fournisseurs ont dû publier des correctifs pour leurs implémentations SNMP.

Étant donné que SNMP est conçu pour permettre aux administrateurs de surveiller et de configurer les périphériques réseau à distance, il peut également être utilisé pour pénétrer dans un réseau. Un nombre important d'outils logiciels peuvent analyser l'ensemble du réseau à l'aide de SNMP. Par conséquent, des erreurs dans la configuration du mode lecture-écriture peuvent rendre un réseau vulnérable aux attaques.

En 2001, Cisco a publié des informations indiquant que, même en mode lecture seule, l'implémentation SNMP de Cisco IOS est vulnérable à certaines attaques par déni de service . Ces problèmes de sécurité peuvent être résolus grâce à une mise à niveau de l'IOS.

Si SNMP n'est pas utilisé dans un réseau, il doit être désactivé sur les périphériques réseau. Lors de la configuration du mode lecture seule SNMP, une attention particulière doit être portée à la configuration du contrôle d'accès et aux adresses IP à partir desquelles les messages SNMP sont acceptés. Si les serveurs SNMP sont identifiés par leur IP, SNMP n'est autorisé à répondre qu'à ces IP et les messages SNMP provenant d'autres adresses IP seront refusés. Cependant, l'usurpation d'adresse IP reste un problème de sécurité.

SNMP est disponible en différentes versions, et chaque version a ses propres problèmes de sécurité. SNMP v1 envoie les mots de passe en texte clair sur le réseau. Par conséquent, les mots de passe peuvent être lus avec l'analyse des paquets . SNMP v2 permet le hachage des mots de passe avec MD5 , mais cela doit être configuré. Pratiquement tous les logiciels de gestion de réseau prennent en charge SNMP v1, mais pas nécessairement SNMP v2 ou v3. SNMP v2 a été spécifiquement développé pour assurer la sécurité des données , c'est-à-dire l'authentification , la confidentialité et l'autorisation , mais seule la version 2c de SNMP a obtenu l'approbation de l' Internet Engineering Task Force (IETF), tandis que les versions 2u et 2* n'ont pas obtenu l'approbation de l'IETF en raison de problèmes de sécurité. SNMP v3 utilise MD5, Secure Hash Algorithm (SHA) et des algorithmes à clé pour offrir une protection contre les modifications de données non autorisées et les attaques par usurpation d'identité . Si un niveau de sécurité plus élevé est nécessaire, la norme de chiffrement des données (DES) peut être utilisée en option dans le mode de chaînage de blocs de chiffrement . SNMP v3 est implémenté sur Cisco IOS depuis la version 12.0(3)T.

SNMPv3 peut être soumis à des attaques par force brute et par dictionnaire pour deviner les clés d'authentification ou les clés de chiffrement, si ces clés sont générées à partir de mots de passe courts (faibles) ou de mots de passe qui peuvent être trouvés dans un dictionnaire. SNMPv3 permet à la fois de fournir des clés cryptographiques aléatoires distribuées uniformément et de générer des clés cryptographiques à partir d'un mot de passe fourni par l'utilisateur. Le risque de deviner les chaînes d'authentification à partir des valeurs de hachage transmises sur le réseau dépend de la fonction de hachage cryptographique utilisée et de la longueur de la valeur de hachage. SNMPv3 utilise le protocole d'authentification HMAC - SHA-2 pour le modèle de sécurité basé sur l'utilisateur (USM). SNMP n'utilise pas de protocole d'authentification challenge-handshake plus sécurisé . SNMPv3 (comme d'autres versions du protocole SNMP) est un protocole sans état , et il a été conçu avec un minimum d'interactions entre l'agent et le gestionnaire. Ainsi, l'introduction d'un challenge-response handshake pour chaque commande imposerait une charge à l'agent (et éventuellement au réseau lui-même) que les concepteurs du protocole jugeaient excessive et inacceptable.

Les lacunes de sécurité de toutes les versions SNMP peuvent être atténuées par des mécanismes d'authentification et de confidentialité IPsec . SNMP peut également être transporté en toute sécurité via Datagram Transport Layer Security (DTLS).

De nombreuses implémentations SNMP incluent un type de découverte automatique où un nouveau composant réseau, tel qu'un commutateur ou un routeur, est découvert et interrogé automatiquement. Dans SNMPv1 et SNMPv2c, cela se fait via une chaîne de communauté qui est transmise en texte clair à d'autres périphériques. Les mots de passe en texte clair constituent un risque de sécurité important. Une fois que la chaîne de communauté est connue en dehors de l'organisation, elle peut devenir la cible d'une attaque. Pour alerter les administrateurs d'autres tentatives de collecte de chaînes de communauté, SNMP peut être configuré pour transmettre des interruptions d'échec d'authentification du nom de communauté. Si SNMPv2 est utilisé, le problème peut être évité en activant le chiffrement des mots de passe sur les agents SNMP des périphériques réseau.

La configuration par défaut courante pour les chaînes de communauté est « public » pour un accès en lecture seule et « privé » pour une lecture-écriture. En raison des valeurs par défaut bien connues, SNMP est arrivé en tête de la liste des problèmes de configuration par défaut courants du SANS Institute et était numéro dix dans le SANS Top 10 des menaces de sécurité Internet les plus critiques pour l'année 2000. Les administrateurs système et réseau ne modifient souvent pas ces configurations.

Qu'ils s'exécutent via TCP ou UDP, les protocoles SNMPv1 et v2 sont vulnérables aux attaques d'usurpation d'adresse IP . Grâce à l'usurpation d'adresse IP, les attaquants peuvent contourner les listes d'accès aux périphériques dans les agents implémentés pour restreindre l'accès SNMP. Les mécanismes de sécurité SNMPv3 tels que USM ou TSM peuvent empêcher les attaques d'usurpation d'adresse IP.