Simple Network Management Protocol Les versions successives

Principe Général Équipements supervisés = nœuds Embarquent des agents SNMP Chaque agent maintient une base d’objets : MIB = Management Information Base Superviseur (ou Manager) centralise la supervision en interrogeant les agents : NMS = Network Management Station

SNMPv1 de 1990 (RFC1157) Échanges client/serveur UDP ports 161 et 162

La MIB v1 (1) Arborescence des objets à gérer Structuré par SMI v1 (Structure of Management Information) Types possibles : INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL, SEQUENCE, SEQUENCE OF, IpAddress, NetworkAddress, Gauge, Counter, TimeTicks, Opaque

La MIB v1 (2) Arbre SMIv1 : Chaque nœud est désigné par un OID, c’est-à-dire la succession des index menant à ce nœud. Une « feuille » est désignée de la même façon, le dernier chiffre étant un 0. On peut aussi utiliser les noms complets. Exemple : iso.org.dod.internet.mgmt à l’OID .1.3.6.1.2

Échanges SNMP Format général : Version Communauté Données Version SNMP v1 SNMP v2c SNMP v3 Valeur du champ 1 3

Format des données SNMP (1) GetRequest, GetNextRequest, SetRequest et GetResponse : Trap : Type RequestID Statut d’erreur Indice OIDs, valeurs ( long. variable) Type Entreprise Adresse agent Alarme générique Alarme spécifique Date OIDs, valeurs

Format (2) : Types : RequestID : numéro de demande, pour faire correspondre demande et réponse

Format (3) Error Status : -> toujours à 0 dans une requête Error Index : Pour savoir quel objet a généré l’erreur -> toujours à 0 ans une requête Numéro Erreur noError 1 tooBig 2 noSuchName 3 badValue 4 readOnly 5 genErr

Format du Trap (1) Champ Description Entreprise OID désignant l’objet en cause Adresse agent Adresse IP de l’agent générant ce Trap Alarme générique Numéro de Trap prédéfini Alarme spécifique Numéro de Trap spécifique à un constructeur Date Temps en centièmes de secondes depuis le dernier boot de l’agent

authenticationFailure Format du Trap (2) : Les codes Trap prédéfinis : Numéro Nom coldStart 1 warmStart 2 linkDown 3 linkUp 4 authenticationFailure 5 egpNeighborLoss 6 enterpriseSpecific

Sécurité et SNMP v1 Authentification par « communautés » faisant office de mot de passe. Une pour la lecture, une pour l’écriture, une pour les traps. Circulent en clair sur le réseau. -> Sécurité très faible.

SNMPv2 de 1996 (RFC1901) Naissance dans la douleur. Pas de consensus autour d’une stratégie de sécurité. La version 2 officialisée est en fait la v2c, appelée « community-based v2 ». Garde le principe des communautés. Quand même des améliorations.

La MIB v2 Structurée par SMI v2 Redéfinie les types possibles : BIT STRING, Integer32, Gauge32, Unsigned32, Counter32, Counter64. SMIv1 ne supportait que des adresses réseau sur 32bits, SMIv2 prend en charge d’autres types d’adresses. La définition des objets est plus complète. Plus d’objets standardisés.

Les nouveaux messages (1) La PDU « GetBulk » pour pouvoir lire plusieurs objets à la fois : « Non-Repeaters » est le nombre d’objets scalaires à lire. « Max-Repetitions » est le nombre maximum d’entrées à lire pour les objets se présentant sous formes de séquences ou de tables. Type RequestID Non- Repeaters Max- Repetitions OIDs, valeurs

Les nouveaux messages (2) La PDU « TrapV2 », appelé Notification. Rôle identique, mais utilise le même format que GetRequest et SetRequest. -> standardisation du format. Peut être acquittée par une PDU « Inform ».

Les nouveaux messages (3) La PDU « Inform » : Pour acquitter un trap, ou pour usage entre deux stations d’administrations. Permet d’étendre le concept et l’utilisation des traps.

Les nouveaux messages (4) La PDU « Report » : En fait pas utilisée en SNMP v2. Mais est utilisée par SNMP v3, principalement pour reporter des problèmes de traitement d’un message SNMP.

Les nouveaux codes d’erreur Code d’erreur Nom 6 noAccess 7 wrongType 8 wrongLength 9 wrongEncoding 10 wrongValue 11 noCreation 12 inconsistentValue Code d’erreur Nom 13 ressourceUnavailable 14 commitFailed 15 undoFailed 16 authorizationError 17 notWritable 18 inconsistentName

Compatibilité ? Peu de problèmes entre v1 et v2c car on garde les communautés. Mais conversion entre SMIv1 et v2. Usage d’un proxy assurant la translation pour les traps et les GetBulk.

SNMPv3 de 2002 (RFC3411) Enfin de la sécurité !! Les messages sont identiques, mais on y rajoute une « couche » de sécurité. L’approche du système d’administration est totalement différente, avec de nouvelles conventions textuelles, et plus de modularité.

« Philosophie » Chaque entité SNMP est découpée en 2 sous-ensembles : le moteur SNMP les applications SNMP Le moteur est composé de 4 sous-systèmes ayant chacun un rôle précis 5 applications

« Philosophie » (suite) Schéma général de toute entité SNMP : Ex agent : CommandResponder et NotificationOriginator

Le message SNMP v3 Aussi appelé : msgSecurityParameters

Sécurité dans SNMP Assurée par le sous-système de sécurité et de contrôle d’accès dans les moteurs SNMP. Sous-système de sécurité : User-based Security Model (USM) Sous-système de contrôle d’accès : View-based Access Control Modem (VACM)

USM : Terminologie (1) snmpEngineID : identifiant unique de chaque entité. Défini par admin ou par algorithme (à partir d’un code constructeur et d’une adresse MAC ou IP). ATTENTION aux doublons. snmpEngineBoots : compteur du nombre de redémarrage de ce moteur depuis la définition de son identifiant. snmpEngineTime : compteur du temps en secondes depuis le dernier redémarrage. snmpSecurityLevel : Trois niveaux possibles : noAuthNoPriv : ni authentification ni cryptage authNoPriv : authentification requise mais pas de cryptage authPriv : authentification et cryptage demandés

USM : Terminologie (2) Machine Autoritaire (« authoritative ») : Si un message SNMP requiert une réponse (Get, GetNext, GetBulk, Set et Request), alors le récepteur du message est autoritaire. Si pas de réponse nécessaire (Trap et Report), c’est l’émetteur qui est autoritaire. Le plus souvent, c’est donc l’agent qui est autoritaire, et la station de supervision est non-autoritaire.

Les rôles d’USM (1) Marquage de temps pour se protéger des attaques par rejeu (« Replay Attack »), c’est-à-dire un attaquant qui enregistre des messages valides pour les renvoyer plus tard. Marquage par le couple { Boots, Time } La machine non-autoritaire maintient une horloge en phase avec celle de la machine autoritaire. Réception d’un message sur une machine autoritaire : différence de temps inférieure à 150 secondes. Utilisé conjointement à l’authentification.

Les rôles d’USM (2) Assurer l’authentification et l’intégrité des paquets : Utilise un hash MD5 ou SHA1 Nécessite que les deux parties connaissent la même clé secrète.

Les rôles d’USM (3) Assurer le cryptage des données de protocole. Actuellement seul le cryptage DES-CBC est standardisé, mais évolution possible, notamment vers AES. Nécessite là encore que les deux parties se mettent d’accord sur une clé secrète de cryptage, qui doit être différente de la clé d’authentification.

USM : clés localisées (1) Gestion des clés !! -> « clés localisées » C’est une clé secrète partagée entre un utilisateur et un agent, calculée de la façon suivante :

USM : clés localisées (2) Conséquences : Un utilisateur particulier n’a plus qu’un mot de passe (ou 2) à retenir, quelque soit le nombre d’agents. Supervision depuis n’importe quelle station. Sur un agent, clé unique à chaque utilisateur : si une clé est compromise, celles des autres utilisateurs ne le sont pas. Clé unique pour chaque agent : si un agent est compromis, seules les clés de cet agent sont compromises, et pas celles des autres agents.

VACM en général Utilise les champs suivants du message : msgFlags msgSecurityModel contextEngineID contextName … pour déterminer l’accès à un objet. Retourne une erreur si accès non permis.

VACM : fonctionnement 5 éléments pour définir les accès : Les groupes Les droits (read, write, ou notify) Les niveaux de sécurité Les contextes Les vues-MIB (« MIB views ») Chaque agent possède 4 tables pour enregistrer les droits d’accès.

VACM : les vues MIB Une « vue MIB » est définie en termes de famille (ou collection) de sous-arbres d’une MIB, chacun des sous-arbres pouvant être inclus ou exclus de cette vue : Exemple simpliste :

VACM : schéma de principe

Niveau de sécurité requis VACM : idée générale Vue MIB Opérations permises Utilisateurs autorisés Niveau de sécurité requis Table Interface SET John Authentification et Cryptage GET / GETNEXT John, Paul Groupe System George Aucun …

SNMPv3 en pratique (1) Options de configuration : Un nom d’utilisateur Un niveau de sécurité Un protocole d’authentification Un mot de passe pour l’authentification (minimum 8 caractères) Un algorithme de cryptage Un mot de passe pour le cryptage (minimum 8 caractères, et différent !)

SNMPv3 en pratique (2) Les étapes de mise en place : Sur l’agent, créer une entrée USM avec les attributs (nom d’utilisateur, type d’authentification, etc … ) Configurer la station de supervision avec les mêmes attributs. Le nom d’utilisateur et le mot de passe correspondant seront renseignés manuellement. Commencer la supervision de l’agent !

Compatibilité ? Problème déjà rencontré entre v1 et v2c. Application « Proxy Forwarder » Capacité « multilinguale » des moteurs SNMP Possibilité d’appliquer des droits d’accès pour des messages v1 ou v2c Seul problème restant : un gestionnaire v1 demandant à lire un objet « Counter64 » sur un agent v2c ou v3. La traduction de l’application Proxy doit ignorer ce type de variable.

Conclusion SNMPv3 est intéressant à utiliser si l’on veut un minimum de sécurité. Support des agents, notamment pour des routers, des switchs ou des onduleurs ? Peut-être plus de traffic réseau ?