SNMP

De Wiki info-lab.fr
Aller à : Navigation, rechercher

Sommaire

Présentation

SNMP est une architecture de gestion réseau sur le modèle client/serveur (la littérature sur SNMP se réfère plutôt aux termes Agent/station de gestion). Les équipements gérés devront exécuter un client SNMP, l'agents SNMP : En général les imprimantes, PC, serveurs, équipements réseaux, pare-feux possèdent un client SNMP ou ils permettent d'en installer un. Les modems, fax, autocommutateurs téléphoniques ne possèdent pas d'agent SNMP (leurs constructeurs privilégiant leurs solutions propriétaires de supervision très souvent non interopérables ).
Les différentes versions de SNMP sont :

  • SNMP v1 : (1998, RFC 1157) : Sécurité problématique, la seule vérification qui est faite est basée sur les chaînes de caractères "community" (public, private...).
  • SNMP sec : (RFC 1351, RFC 1352, RFC 1353) : Ajoute de la sécurité à SNMP v1, très peu utilisée.
  • SNMP v2p : amélioration du protocole SNMP et intégration de la sécurité de SNMP sec.
  • SNMP v2c : (RFC 1901, RFC 1905, RFC 1906) amélioration du protocole mais avec la sécurité de SNMP v1.
  • SNMP v2u : (RFC 1905, RFC 1906, RFC 1909, RFC 1910) le protocole type V2c avec la sécurité basée sur les usagers (USM).
  • SNMP v2* : Censée combiner v2c et v2u, jamais publiée.
  • SNMP v3 : Reprend le meilleur en protocole et en sécurité de v2p, v2u et v2* : Messages type v2 et sécurité basée sur USM.


SNMP , fonctionnement

l'architecture SNMP est composée de 4 briques :

  • Des agents SNMP installés sur des équipements.
  • Un ou plusieurs serveurs SNMP capables d'interpréter les données émises par les agents. En patois anglo-saxon : NMS (Network Management Station).
  • Un protocole permettant l'échange sécurisé entre les agents et le(s) serveur(s). Il se situe dans la couche applications, au dessus d'UDP.
  • Une MIB (Management Information Base) décrivant les informations gérées. SNMP v3 utilise la MIB2 (SNMP v1 utilisait la MIB1, la MIB2 est apparue à partir de SNMPv2). Chaque agent a une partie de la MIB, celle qui le concerne directement. Les stations de gestion SNMP possèdent la MIB maître qui contient l'ensemble des objets de leur réseau.

La MIB 2 (Management Information Base version 2)

Chaque agent possède une MIB spécifique à l'équipement qui l'héberge. La MIB est une base d'information structurée, décrivant l'ensemble des composants et ressources matérielles ou logicielles d'un équipement.
Les stations de gestion SNMP se doivent de posséder la MIB la plus complète possible, incluant l'ensemble des objets possédant un agent SNMP sur leur réseau. Les solutions de gestion réseau (CACTI, NAGIOS) incluent de base des MIB très complètes, en général exhaustives. Quand un nouvel équipement particulier apparaît (sonde, IDS, optimiseur), et qu'il ne privilégie pas sa solution de gestion propriétaire, le constructeur met parfois à disposition les nouveaux éléments afin d'étendre la MIB maître des stations de gestion SNMP. Ce nouvel équipement peut être alors pris en compte par les stations de gestion SNMP. Parfois une nouvelle RFC décrit ces nouvelles entrées afin de les inclure au standard.
La MIB se présente sous la forme d'une structure hiérarchisée (arborescente) de classes d'objets, regroupées en tables. La MIB2 comporte 10 classes d'objets :

  • System
  • Interfaces
  • Address translation
  • IP
  • ICMP
  • TCP
  • UDP
  • EGP
  • Transmissions
  • SNMP

Un objet est défini par les champs suivants :

  • Object : Nom de l'objet et le numéro identificateur OID.
  • Syntax : Type de syntaxe de l'objet : Entier (Integer), Octet string (0 à 255) ou Null.
  • Definition : définition textuelle de l'objet.
  • Access : read, write-only, read-write ou not-accessible
  • Status : Niveau de support que requiert l'objet.

Voici un exemple d'objet :

Object : atPhysAddress {1.3.6.1.2.1atEntry 2}
Syntax : OCTET STRING
Definition : The Media-dependant physical address
Access : read-write
Status : mandatory

Les variables concernant la vitesse, le taux d'erreur, et les adresses d'interfaces seront représentées sous forme de table dans la classe d'objets "Interfaces".
Une MIB particulière, la MIB RMON1 puis la RMON2 permettent d'étendre les possibilités de SNMP en autorisant des moniteurs distants à contrôler le trafic circulant à travers le réseau.

Les requêtes SNMP

SNMP est un protocole sans connexion, au dessus d'UDP, de type question-réponse : la station de gestion pose régulièrement des questions sur l'état de l'agent, qui lui répond. Parfois la communication est unidirectionnelle, par exemple quand un agent détecte un problème et envoie une alarme (trap) à sa station de gestion.
Les principales requêtes SNMP sont :

  • GET : commande de la station vers l'agent pour interroger l'état des variables d'une partie ou de toute sa MIB. La commande GET provoque toujours une réponse de l'agent vers la station.
  • SET : Permet à la station de gestion d'agir sur la valeur d'un objet de la MIB d'un agent. Permet à distance de changer l'état d'une interface, de modifier une table de routage... La commande SET provoque toujours une réponse de l'agent vers la station.
  • TRAP : Commande d'un agent vers sa station pour notifier un évènement (anomalie, dépassement de seuil d'alarme...). cette commande n'attend pas de réponse.
  • INFORM : Commande d'un agent vers sa station pour notifier un évènement ; contrairement à TRAP, cette commande attend une réponse.

Les commandes GET, SET et les réponses associées (GetResponse et SetResponse) transitent sur le port UDP 161. Les commandes TRAP et INFORM transitent sur le port UDP 162.
Tous les agents ne supportent pas toutes les commandes : Pour des raisons de sécurité, certains constructeurs désactivent la commande SET REQUEST qui permet de modifier via SNMP l'état d'un agent. Interroger : oui ; modifier un état : non !

Détails de la MIB : Hiérarchie des objets, MIB privées et extensions

Hiérarchie des objets, nommage et OID

Pour identifier chaque objet, l'IETF y a associé un code unique dans la MIB 2, documenté dans la RFC 1213.
Voici le début de la structure hiérarchisée de la MIB 2 :
SNMP.MIB-Tree.PNG

Dans cette structure arborescente, chaque objet est défini par un OID (Object ID), calculé à partir de la racine :
Par l'exemple l'objet MIB-2, nommé dans la MIB 2 iso.org.dod.internet.mgmt.mib-2. a pour OID 1.3.6.1.2.1.

Voici les objets que nous sommes susceptibles de trouver dans chaque objet de la MIB :

  • Dans SYSTEM (1):
    • description de l'agent (1)
    • OID (2)
    • Uptime (3)
    • Personne à contacter (4)
    • Nom de l'agent (5)
    • Localisation (6)
    • Services proposés (7)
  • Dans INTERFACE (2) :
    • ifNumber (2)
    • ifTable (3)
      • if Entry (1)
        • ifIndex (1)
        • ifDescr (2)
        • ifType (3)
        • ifMtu (4)
        • ifSpeed (5)
        • ifPhyAddress (6)
        • ifAdminStatus (7)
        • ..............
  • Dans Address translation (3) : (ou plutôt traduction)

Ici se trouve la table MAC ou table de pontage ou table ARP (équivalences MAC-IP)

  • Dans IP (4) : (c'est la partie de la MIB la + importante)
    • ipForwarding (1)
    • ipDefaultTTL (2)
    • ipInReceives (3)
    • ipInHdrErrors (4)
    • ipInAddrErrors (5)
    • .................
    • ipAddrTable (20)
      • ipAddreEntry (1)
        • ipAdEntAddre (1)
        • ipAdEntIfIndex (2)
        • ipAdEntNetMask (3)
        • ipAdEntBcastAddr (4)
        • ..............
    • ipRouteTable (21)
    • ................
  • Dans ICMP (5) :

nous trouvons des compteurs et statistiques pour diagnostiquer les problèmes d'IP.

  • Dans TCP (6) :

connexions TCP en cours, nombre max de connexions simultanées, état des connexions...

  • Dans UDP (7) :

Nombre de datagrammes UDP, erreurs, adresses IP source et destination...

  • Dans EGP (8) :

infos sur routeurs adjacents, leurs tables de routage ...

  • Dans transmission (9) :

Des infos sur le support de transmission utilisé

  • Dans SNMP (10) :

Nombre de messages SNMP entrants/sortants, noms de communauté invalides, infos authentification ...

L'OID de l'Objet iso.org.dod.internet.mgmt.mib-2.interface.ipAddrTable.ipAddreEntry.ipAdEntNetMask. soit le masque de sous réseau de la 1ère interface est situé à l'emplacement 1.3.6.1.2.1.2.20.1.3 dans la MIB2.

MIB privées ou exclusives

Les équipementiers peuvent créer des MIB spécifiques à leurs équipements, sous 1.3.6.1.4.1 soit iso.org.dod.internet.private.entreprise.. Ces MIB particulières, appelées MIB privées ou exclusives sont mises à disposition par ces équipementiers pour être prises en compte par les stations de gestion SNMP.

Extensions normalisées de la MIB

Pour pouvoir analyser le trafic réseau sur des segments et en détecter les anomalies, l'IETF a développé un extension de la MIB, que l'on a appelé Rmon 1 (pour la MIB1) et Rmon2 (pour la MIB2). Cette extension est un objet de la MIB de nom iso.org.dod.internet.mgmt.mib-2.rmon. situé à l'emplacement 1.3.6.1.2.1.16. Essentiellement utilisé par des sondes que l'on place en coupure sur des segments d'un réseau, et qui analysent le trafic qui les traverse. La RMON2 contient les classes d'ojets suivantes :

  • Statistiques Ethernet (taux de collision...) (1)
  • Les historiques : état du réseau à travers le temps. (2)
  • Les alarmes et les seuils d'alerte. (3)
  • La gestion des hôtes sur le réseau local. (4)
  • Les groupes TOP-hôtes générant le + de trafic. (5)
  • Les matrices de flux : communications entre groupe d'adresses d'un même sous réseau. (6)
  • Les filtres pour surveiller des paquets particuliers (7)
  • Les paquets capturés. (8)
  • les évènements générés par une condition remplie. (9)
  • Tocken ring. (10)
  • Définition des protocoles (couche 3 et au dessus) que la sonde sait analyser. (11)
  • Enregistrement des statistiques selon le protocole défini. (12)
  • Relation entre adresse MAC et protocole utilisé. (13)
  • Mesure globale des trames liées à un protocole. (14)
  • Mesure entre 2 hôtes. (15)
  • Accès aux couches hautes pour analyse. (16)
  • Mesure des performances d'un protocole applicatif entre 2 hôtes. (17)
  • Mémorisation des statistiques de couche 3. (18)
  • Configuration de la sonde. (19)

Les améliorations apportées par SNMPv3 : Modularité, sécurité

A cause de sa MIB v1 et de ses lacunes en sécurité, SNMP v1 ne doit plus être utilisé. Il faut utiliser SNMPv2 et sa MIB (v2) associé à SNMP v3 pour la sécurité.
Tout équipement compatible SNMP v3 est appelé ENTITE SNMP et peut être au choix soit un AGENT, soit un MANAGER en fonction des modules qu'il exécute ou pas. Toute ENTITE SNMP exécute donc un MOTEUR SNMP et un certains nombre d'APPLICATIONS SNMP.

  • Le MOTEUR SNMP identifié par un numéro unique (le snmpEngineID) au sein de chaque domaine administratif SNMP, et qui contient les 4 modules suivants :
    • Le DISPATCHER chargé de renvoyer vers le bon sous-système de traitement un message reçu quand on exécute plusieurs versions différentes de SNMP.
    • Le SOUS-SYSTEME DE TRAITEMENT DE MESSAGES : Envoi des messages (PDU SNMP) et extractions des informations d'un message reçu du DISPATCHER. On peut lancer jusqu'à 3 instances différentes de ce sous-système, que l'on nomme modèles. Les 3 modèles de traitement de messages existants sont ceux correspondant à SNMP v1, v2c et v3.
    • Le SOUS-SYSTEME DE SECURITE qui fournit les services de sécurité nécessaires à l'authentification et à la confidentialité des messages. Il peut contenir plusieurs modèles de sécurité qui définissent les services offerts, les protocoles employés... Pour SNMPv3 l'IETF préconise l'utilisation de chiffrement, d'authentification, la disparition des communautés et le contrôle d'accès par utilisateurs.
    • Le SOUS-SYSTEME DE CONTRÔLE D'ACCES qui permet grâce à des modèles de mettre en oeuvre des politiques de droits d'accès aux objets de la MIB en fonction de l'identité du demandeur et des droits qui lui sont associés. Défini dans la RFC 2274 qui traite de USM (User-based Security Model).
  • Les APPLICATIONS chargées de faire fonctionner SNMP v3 :
    • GENERATEUR DE COMMANDES
    • REPONDEUR DE COMMANDES
    • RECEPTEUR DE NOTIFICATIONS
    • GENERATEUR DE NOTIFICATIONS
    • PROXY d'ACHEMINEMENT (pour envoyer les requêtes vers une autre entité)
    • Autres applications

La sécurité dans SNMPv3

La sécurité de SNMPv3 est donc basée sur un modèle de sécurité par UTILISATEUR (USM ou User Security Module) et non plus par COMMUNAUTE. De plus SNMPv3 reprend les meilleures pratiques des différentes sous versions de SNMPv2 afin d'inclure AUTHENTIFICATION, CHIFFREMENT et HORODATAGE. Ce sont bien sûr les Sous-sytème de contrôle d'accès et Sous-système de sécurité qui sont chargés de mettre en oeuvre ces mécanismes.

  • SECURITE par UTILISATEUR : Un utilisateur est ici un usager, un groupe d'usagers, une application, un groupe d'applications IDENTIFIES après avoir été AUTHENTIFIES : A cette IDENTITE correspond un profil très précis qui définit quels mécanismes de sécurité doivent être mis en oeuvre pour cet UTILISATEUR, quelles commandes lui sont autorisées, quels objets de la MIB lui sont accessibles et avec quels droits (lecture, écriture...). On peut donc créer des comptes d'utilisateurs avec des profils de sécurité très différenciés. L'authentification d'un utilisateur est unique, propre à lui, par contre son profil de sécurité est lié au groupe auquel il appartient. Chaque utilisateur doit donc obligatoirement appartenir à un groupe.
  • AUTHENTIFICATION : Assurer l'intégrité des PDU SNMP et authentifier leur origine. L'IETF a prévu HMAC-MD5-96 (ou optionellement HMAC-SHA-96) pour l'authentification SNMPv3.
  • CHIFFREMENT : Pour la confidentialité du contenu des messages l'IETF a préconisé DES en 1998. D'autres algorithmes de chiffrement peuvent être mis en oeuvre mais seul DES est indispensable pour tout équipement compatible SNMPv3.
  • HORODATAGE : Le moteur SNMP horodate tous les messages émis dans la partie chiffrée par DES, afin d'assurer une protection contre les délais et les attaques par rejeu des commandes.

Les limites de SNMP v3

  • Même si certains protocoles de sécurité sont dépassés (DES), la conception modulaire de SNMPv3, y compris dans ses RFC qui se veulent ouvertes et évolutives, permet de mettre en oeuvre des mécanismes de sécurité plus modernes et robustes au sein d'un réseau (à condition que toutes les ENTITES SNMP soient capables de les implémenter) tout en restant 100% compatible SNMPv3. Cette évolutivité a été voulue dès le départ pour SNMPv3, contrairement aux versions v1 et v2. Néanmoins, rien ne certifie que les équipements existants ou futurs implémenteront 3DES, AES ou TWOFISH par exemple et ne se contenteront pas d'implémenter le minimum préconisé par l'IETF : DES.
  • Les problèmes d'hétérogénéité des MIB propriétaires, qui existaient déjà avec SNMPv1 et v2, n'ont pas été résolus par SNMPv3, puisque SNMPv3 n'est qu'une surcouche sécurité au dessus de SNMPv2.
Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Outils