Le protocole SNMP (Simple Network Management Protocol ou protocole simple de gestion de réseau) a été originellement conçu, en 1988, pour donner la possibilité à un administrateur réseau de communiquer avec les autres éléments du réseau à partir d’une console (NMS, Network Management Station) et d’en assurer la gestion : vérifier l’état du réseau ou d’un appareil, contrôler le trafic et détecter les erreurs, etc. Pour ce faire, des requêtes sont en-voyées vers des agents logiciels installés sur chaque élément du réseau, qu’il s’agisse de routeurs, de concentrateurs, de commutateurs, de PC… En réponse à ces requêtes, les agents renvoient, sous forme de paquets (traps), des variables, à savoir une suite numérique dressant un état des éléments mis sous surveillance. Ce peut être la dernière fois que la machine a été allumée, quelles applications ont été ouvertes, les interruptions, les dysfonctionnements sur le réseau. Autant d’éléments codifiés transmis et en-voyés au fur et à mesure par l’agent qui constituent une base de données appelée MIB (Management Information Base, lire encadré). Le NMS envoie ses requêtes par le port 161 et l’agent répond par le port 162. Ce principe de fonctionnement émis lors de la conception de la version 1 de SNMP reste toujours valide.Malheureusement, si cette version 1 était satisfaisante en son temps, elle présentait néanmoins nombre de lacunes, dont la plus importante est sans conteste la sécurité des transmissions, assurée par une authentification sommaire fondée sur une séquence de code. Or, l’interception d’un message émis par un agent SNMP peut avoir de graves répercussions pour l’entreprise. En effet, ces messages donnent, de manière assez claire, l’état des coupe-feu de l’entreprise, les chaînes de configuration d’un routeur, les rapports d’activité des messageries et leur configuration, les droits d’accès, etc. Il est facile de voir quel usage pourrait faire un pirate de ce type de données. En 1988, beaucoup d’utilisateurs n’avaient pas conscience de l’urgence de ce type de problème et préféraient attendre que d’autres versions de SNMP le résolvent. La version 2 offrira effectivement des fonctions d’authentification avancées, veillera à l’intégrité des messages remis et protégera la transmission des réponses. Seul bémol, la mise en place de cette version impliquait une modification de la structure des messages, incompatible avec la version antérieure. La version 3, telle qu’elle est définie dans la RFC 2570 et 2574, visera à pallier les déficiences de la version 2 afin d’utiliser SNMP de façon sécurisée de bout en bout. À cette fin, il fallait, entre autres, redéfinir les autorisations et les contrôles d’accès et y adjoindre la possibilité d’administrer ces fonctions à distance. D’où la naissance du modèle USM (User-based Security Model) pour éviter la falsification des messages de commande en utilisant des mots de passe personnels chiffrés. Pour identifier les utilisateurs ou les moteurs SNMP, le modèle USM se sert d’un chiffrement symétrique à clé privée utilisant l’algorithme HMAC-MD5-96. Mieux encore, lors de la transmission d’un message, USM modifie à chaque n?”ud la clé de chiffrement, ce qui évite, si un segment est endommagé, de menacer l’intégrité des informations reçues par le reste du réseau.
L’émetteur aussi est protégé
À cette protection du message s’ajoute celle de l’émetteur, effectuée par la mise en place d’une clé privée, non accessible depuis SNMP, – en ayant recours cette fois à l’algorithme CBC-DES. La version 3 de SNMP abrite en outre un mécanisme de synchronisation entre les différents moteurs SNMP afin d’empêcher la duplication d’un message lors de son trajet en s’appuyant sur le temps parcouru depuis l’émetteur jusqu’au récepteur. Ce mécanisme de synchronisation possède une double fonction, d’information et d’authentification. Pour la première, l’autorité SNMP (la console) donne aux agents du réseau un temps machine relatif (l’heure à laquelle le système est redémarré) et un temps absolu (l’heure réelle). En comparant les deux temps lors de la réception des messages, la console peut hiérarchiser l’information et dresser ainsi les liens de cause à effet. Pour la sécurité proprement dite, les messages entre les éléments du réseau ne sont valables que dans un repère temporel donné. En cas d’interception du message, celui-ci ne serait plus valide, car la limite de temps serait dépassée. Enfin, dernier maillon de la chaîne sécuritaire, chaque utilisateur dispose de droits spécifiques de lecture et d’écriture dans la MIB : VACM (View-based Access Control Model). Chacun ne peut désormais opérer que dans un champ restreint et défini. Un opérateur de surveillance ne pourra, par exemple, que repérer la défaillance d’un routeur, tandis que l’administrateur réseau pourra changer les tables de routage à sa guise…
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
