Architecture

Environnement SNMP

L'environnement de gestion SNMP est constitué de plusieurs composantes : La station de supervision (Manager), les éléments actifs du réseau, les variables MIB et des agents SNMP.

Figure 1 - Environnement SNMP

Les différentes composantes du protocole SNMP sont les suivantes :

• Manager : Il exécute les applications de gestion qui contrôlent les éléments réseaux. Physiquement, la station est un poste de travail. Le manager va aller récupérer les informations auprès des agents et les centraliser
• Elément du réseau : Ce sont les équipements (Ex : Routeur, Switch, Poste de travail, imprimante, …) que l'on cherche à gérer
• Agent SNMP : Chaque élément du réseau dispose d’un agent SNMP qui est répond aux requêtes du manager. Ils vont chercher l’information requise dans la MIB et la retransmette ensuite au manager
• MIB (Management Information Base) : C’est une collection d'objets représentant les caractéristiques du terminal administré

Récupération d'informations

Deux méthodes complètements différentes pour la récupération des informations :

• Question / Réponse
• Alertes (Traps)

Figure 2 - Question / Réponse

Avec cette méthode, c'est le manager qui prend l'initiative d'aller demander (GetRequest / SetRequest) une information aux éléments du réseau. Ensuite, l'agent SNMP qui reçoit la requête va aller récupérer ou modifier l'information dans la MIB pour ensuite retourner un GetResponse au manager qui traitera l'information comme bon lui semble.

Figure 3 - Alertes (Traps)

Dans cette méthode, les alertes sont envoyées quand un événement non attendu se produit sur l'agent SNMP. Celui-ci en informe le manager via une trap. Il existe plusieurs types d'alertes, comme :

• ColdStart : L'équipement est trop froid
• WarmStart : L'équipement est trop chaud
• LinkDown : Un des liens de l'équipement est tombé
• ...

Requêtes & Réponses

Il existe quatre types de requêtes SNMP :

• GetRequest : Recherche d’une variable sur un agent
• GetNextRequest : Recherche de la variable suivante
• GetBulkRequest : Recherche d’un ensemble de variables regroupées
• SetRequest : Change la valeur d’une variable sur un agent

Quel que soit la requête, l’agent répond toujours avec GetResponse. Si la variable demandée n’existe pas, la réponse sera accompagnée d’une erreur noSuchObjet.

Management Information Base

La MIB (Management Information base) est la base de données des informations maintenue par l'agent, auprès de laquelle le manager va venir pour s'informer.

Un fichier MIB est un document texte écrit en langage ASN.1 (Abstract Syntax Notation 1) qui décrit les variables, les tables et les alarmes gérées au sein d'une MIB. Le problème des MIB est qu’elles diffèrent en fonction du constructeur et de l’équipement que l’on souhaite administrer. Cela peut donc devenir compliquer lorsque l’on souhaite récupérer des informations un peu « exotiques ».

La MIB est une structure arborescente dont chaque noeud est défini par un nombre ou OID (Object Identifier). Cette OID est très utile car il permet d’accéder à une information grâce à la suite de tous les index.

Figure 4 - Exemple de structure de MIB

Dans une MIB, il existe deux sortes d’objets :

• Les objets simples : L’agent va retourner une seule et unique variables (Ex : Nom de l’équipement, description de l’équipement, …)
• Les objets complexes : L’agent va retourner un tableau de variables (Ex : La liste des ports UP sur l’équipement, la liste des adresses IP de l’équipement)

Si vous souhaitez accéder à un objet simple comme, par exemple, la description d’un équipement, vous pouvez utiliser la méthode GetRequest qui a été présentée plus haut dans l’exposé. Sur des postes de travail (Windows, Unix, …), la commande snmpget permet d’utiliser cette méthode.

> _server$ snmpget -v 1 -c COMMUNITY @IP .1.3.6.1.2.1.1.1.0
system.sysDescr.0 : DISPLAY STRING- (ascii): Cisco IOS Software, Catalyst 4500 L3 Switch Software (cat4500e-IPBASE-M), Version 15.1(2)SG, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2012 by Cisco Systems, Inc.
Compiled Wed 05-Dec-12 05:55 by prod_

Si vous souhaitez accéder à un objet complexe, comme, par exemple, la liste des interfaces d’un équipement avec leurs états (UP, Down, …), vous pouvez utiliser la méthode GetBulkRequest (Elle est plus optimisée que la méthode GetNextRequest). Sur des postes de travail, la commande snmpwalk permet d’utiliser cette méthode.

> _server$ snmpwalk -v 2c -c COMMUNITY @IP .1.3.6.1.2.1.2.2.1.7
interfaces.ifTable.ifEntry.ifAdminStatus.2 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.3 : INTEGER: down
interfaces.ifTable.ifEntry.ifAdminStatus.4 : INTEGER: down
interfaces.ifTable.ifEntry.ifAdminStatus.5 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.6 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.7 : INTEGER: down
interfaces.ifTable.ifEntry.ifAdminStatus.8 : INTEGER: down
interfaces.ifTable.ifEntry.ifAdminStatus.153 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.154 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.155 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.156 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.157 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.158 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.159 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.160 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.161 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.162 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.163 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.164 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.169 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.170 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.171 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.173 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.174 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.179 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.180 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.181 : INTEGER: up
interfaces.ifTable.ifEntry.ifAdminStatus.182 : INTEGER: up

SNMPv1 & SNMPv2

Trame

Figure 5 - Trame SNMP

La trame SNMP ce décompose en 3 parties :

• Version SNMP : Correspond au numéro de la version utilisée pour la requête. Peut-être 1, 2p, 2c, 2u, 2* ou 3. Si aucune version n’est précisée, alors la version qui est utilisée par défaut est SNMPv3 puisqu’elle est devenue le nouveau standard SNMP en 2002.
• Communauté : C'est le contrôle d’accès utilisée par SNMP. Pour les version SNMPv1 et SNMPv2, la communauté est transportée en clair sur le réseau, ce qui pose de gros problèmes de sécurité. La communauté permet de créer des domaines d’administration.
• PDU (Packet Data Unit) : Il contient toutes les informations utiles (les valeurs demandées ou les réponses à ces demandes).

Le Packet Data Unit est lui aussi décomposé en plusieurs parties qui sont expliqués une à une ci-dessous.

Le PDU Type décrit le type de requête, réponse ou d'alerte.

Le Request ID permet à au manager d'associer les réponses à ses requêtes.

Le Error Status est l'indicateur du type d'erreur. Si aucune erreur ne s'est produite, ce champ est mis à zéro.

Le Error Index indique, en cas d'erreur, ou celle-ci se situe dans la requête.

La Varbin List est une séquence constituée d’une ou plusieurs paires OID-Valeur. Le contenu du champs Value change en fonction du PDU Type :

• SetRequest : La valeur correspond à celle de l’OID spécifiée
• GetRequest : La valeur est NULL
• GetResponse : La valeur correspond à celle de l’OID demandé

Faiblesses de SNMPv1

La principale faiblesse de SNMPv1 est l'absence d'un mécanisme adéquat pour assurer la confidentialité et la sécurité des fonctions des informations transmises sur le réseau. En effet, la communauté circule en clair sur le réseau, et donc n’importe qu’elle personne mal intentionnée pourrais facilement la récupérer, et par la suite, récupérer ou modifier des données sur les équipements du réseau. De plus, les données renvoyés par les agents ne sont pas cryptés, il est donc très facile de lire ces informations si on arrive à récupérer un paquet SNMP.

Une autre lacune de SNMPv1 est l’utilisation de la méthode GetNextRequest qui est très mal optimisée. En effet, si un manager souhaite récupérer un objet complexe, il va demander les variables du tableau une à une, ce qui fait énormément de requêtes pour récupérer un objet complexe.

Figure 6 - Exemple d'utilisation de GetNextRequest

Améliorations de SNMPv2

SNMPv2 n’a pas comblé les lacunes sécuritaires de SNMPv1, mais par contre elle a comblée les lacunes fonctionnelles dues à l’utilisation de la méthode GetNextRequest. SNMPv2 a introduit la nouvelle opération GetBulkRequest qui permet de retourner un « tableau » (l’agent remplis le PDU du paquet SNMP jusqu'à ce qu'il n'y ai plus de place) lorsque le manager demande un objet complexe.

Figure 7 - Exemple d'utilisation de GetBulkRequest

SNMPv3

Nouveautés

SNMPv3, qui est pour l’instant la dernière version de SNMP, a inclue un tout nouveau mécanisme de sécurité des transactions. La sécurité comprend l'identification des machines qui communiquent et la confidentialité des paquets.

Cette sécurité est basée sur 2 concepts :

• USM (User-based Security Model)
• VACM (View-based Access Control Model)

User-based Security Model

L'USM gère toute la sécurisation des paquets de l’envoi à la réception.

Pour mettre en place toute cette sécurisaion, l'USM utilise 3 différents mécanismes :

• L’Authentification : Utilisation d’un mot de passe pour la transmission d’un paquet
• Le Cryptage : Personne ne peut lire les informations contenues dans les paquets
• L’estampillage du temps : Un paquet SNMPv3 déjà transmis dispose d’une durée de vie

L'Authentification doit faire en sorte que le paquet reste inchangé pendant la transmission. Pour cela elle utilise un mécanisme de cryptage (MD5 ou SHA-1) combiné à un mot de passe.

L'authentification ne vise pas à cacher l'existence du paquet ou à le crypter. Si l'on utilise uniquement l'authentification et qu’une personne malveillante récupère un paquet passant sur le réseau, alors il sera capable d’en voir le contenu. Toutefois, cette personne serai dans l’incapacité de changer le contenu du paquet sans connaître le mot de passe.

Figure 8 - Authentification

Le cryptage (DES) a pour but d'empêcher que quelqu'un n'obtienne les informations contenues dans les paquets SNMP. Il utilise un mot de passe connus seulement par les managers et les agents.

Contrairement à l'authentification qui est appliquée à tout le paquet, le cryptage est seulement appliqué sur le PDU.

Figure 9 - Cryptage

Le mot de passe utilisé par le mécanisme d'authentification et le mot de passe utilisé par le mécanisme de cryptage sont différents.

Avec l’estampillage du temps, la durée de vie d’un paquet SNMPv3 est définie à un certain nombre de secondes (150 secondes par défaut) et au-delà de ce temps, le paquet est détruit.

Grâce à cette méthode, il est impossible de récupérer un paquet sur le réseau pour le réutiliser plus tard.

View-based Access Control Model

Il restreint les accès à la MIB en lecture et/ou en écriture pour un groupe d’utilisateur.

LDAP

Pourquoi LDAP ?

Dès la sortie d’internet, le besoin d’un annuaire électronique est apparu pour pouvoir centraliser un grand nombre d’informations sur des utilisateurs, des ressources, ... Depuis, beaucoup de solutions ont été développées et proposés. On peut par exemple citer :

• Le stockage des utilisateurs sous UNIX
• YelloPages
• Microsoft SAM
• ...

Le problème, avec toutes ces solutions propriétaire, est pour les applications qui souhaitent communiquer avec un ou plusieurs de ces annuaires. En effet, à chaque fois qu’une application souhaitait communiquer avec un nouvel annuaire, il lui fallait mettre en place une couche de communication supplémentaire spécifique à ce nouvel annuaire.

Afin de simplifier la communication avec tous ces annuaires, un effort d’uniformisation a été fait, ce qui a donné naissance à la norme X.500, qui est l’ancêtre de LDAP.

Lightweight Directory Access Protocol

LDAP un protocole qui adapte la norme X.500 au protocole TCP/IP pour faciliter les échanges Client / Serveur.

Il existe 3 versions du protocole LDAP, qui sont :

• LDAPv1 (1993 & RFC1487)
• LDAPv2 (1995 & RFC1777)
• LDAPv3 (1997 & RFC2251)

LDAP permet un stockage hiérarchique des informations et la modélisation d’objets (Personne, Entreprise, Matériel Réseau, …).

Les avantages de ce protocole sont :

• La centralisation des informations
• La rapidité d’accès aux informations
• La possibilité de mettre en place des mécanismes de sécurité
• La possibilité de mettre en place une redondance des informations

Pourquoi pas une base de données ?

LDAP et les bases de données relationnelles sont deux systèmes qui n’ont clairement pas le même objectif et qui ont chacun leurs avantages.

Figure 10 - Différences avec une base de données

Communication

Détails

LDAP propose deux méthodes de communications :

• Une communication de type client/serveur qui permet au client d’accéder aux informations du serveur
• Une communication de type serveur/serveur qui permet aux serveurs du dupliquer ou de synchroniser leurs informations.

Figure 11 - Communication Client / Serveur avec LDAP

Chacune de ces méthodes proposes d’initialiser une connexion TLS pour plus de sécurité dans les échanges.

Figure 12 - Communication Client / Serveur avec LDAP & TLS

Modèle de données

Introduction

Le modèle de données de LDAP s’apparente très fortement au langage orienté objet.

Les informations d’un annuaire LDAP sont stockées sous forme d’une arborescence d’informations hiérarchiques (Directory Information Tree). A chaque nœud de cette arborescence, on retrouve l’instance d’un classe, qui elle-même va contenir un ensemble d’attributs représentent la donnée.

Figure 13 - Exemple de Directory Information Tree

Distinguished Name

Le Distinguished Name (DN) est un nom distinct qui permet d’identifier de façon unique une entrée de l’annuaire électronique. Si on en revient à notre comparaison avec les bases de données relationnelles, cette notion est très proche de la notion de Primary Key.

Figure 14 - Exemple de Distinguished Name

On pourrait, par exemple, prendre d’un étudiant dans une université (voir figure ci-dessus). Dans notre cas, le Distinguished Name est : dn: cn=Valentin GOT,ou=personnes,dc=esipe,dc=fr

Pour lire un Distinguished Name, il faut le lire en partant de la fin :

+ dc=esipe,dc=fr
|
+--+ ou=personnes
    |
    +-- cn=Valentin GOT

Comme on peut le voir, le séparateur utilisé pour différencier les différentes parties du DN est la virgule « , ». Il est facile de comparer le DN du protocole LDAP avec le chemin d’accès vers un fichier, qui lui aussi est unique, mais qui utilise un séparateur slash « / ». Toutes les entrées d'un DIT (même les nœuds intermédiaires) possèdent un DN.

Classe

LDAP possède déjà un certain nombre de classes et d’attributs pour représenter un utilisateur, une machine, … En plus des classes déjà proposés par LDAP, l’administrateur du serveur LDAP à la possibilité d’en créer de nouvelles pour qu’elles correspondent plus au modèle de données qu’il souhaite mettre en place.

Une classe, c’est :

• Un numéro d’objet unique (OID) qui la définit et qui précise la classe d’attribut à laquelle elle appartient.
• Un nom permettant d’identifier la classe (NAME)
• Une description (DESC)
• Un type représentant le type de classe implémenté. Ce type peut être :
  • Abstract : C’est une classe dont une autre classe peut hériter pour utiliser la liste des attributs qu’elle fournit. Une classe abstraite ne peut pas être instanciée et ne peut pas hériter d’une autre classe abstraite.
  • Structural : C’est une classe qui a pour objectif d’être instanciée. Une classe structurelle doit hériter directement ou indirectement de la classe top, qui est la classe mère de toutes les autres classes.
  • Auxiliary : On peut utiliser ce type de classes pour augmenter le nombre d’attribut d’une autre classe.
• Une liste d’attributs optionnels (MAY) ou obligatoires (MUST)

De plus, une classe à la possibilité d'hériter d’une ou plusieurs autres classes (définies ou non par LDAP) à l’aide de l’attribut SUP.

Le format d’une classe tel qu’il est définit dans la RFC :ObjectClassDescription = "(" whsp
          numericoid whsp     ; ObjectClass identifier
          [ "NAME" qdescrs ]
          [ "DESC" qdstring ]
          [ "OBSOLETE" whsp ]
          [ "SUP" oids ]           ; Superior ObjectClasses
          [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] ; Default STRUCTURAL
          [ "MUST" oids ]        ; AttributeTypes
          [ "MAY" oids ]          ; AttributeTypes
whsp ")"

Classe représentant un groupe d'élèves à l'ESIPE :#group
objectclass ( 2.5.4.42.2.1
          NAME 'group'
          DESC 'ESIPE Group'
          SUP organizationalRole
          STRUCTURAL
          MUST (
                    esipeGroupName $
                    esipeGroupMember $
                    esipeGroupDelegate
          )
)

Attribut

Un attribut représente un élément d’une classe. De même que pour les classes, il possède un numéro d’identification unique (OID), un nom (NAME), une description (DESC) et peut hériter des propriétés d’un autre attribut (SUP).

Un attribut possède aussi un type (SYNTAX), précisant si cet attribut est une chaine de caractère, un entier, ... Ce type est défini par un OID.

De plus, un attribut peut :

• Etre monovalué ou multivalué (SINGLE-VALUE)
• Définir des comportements à adopter lors d’une recherche (EQUALITY, ORDERING, SUBSTR)
• Définir sa visibilité (COLLECTIVE)
• Définir si l’utilisateur de l’annuaire LDAP à ou non le droit de le modifier (NO-USER-MODIFICATION)

Le format d’un attribut tel qu’il est définit dans la RFC :AttributeTypeDescription = "(" whsp
          numericoid whsp                                 ; AttributeType identifier
          [ "NAME" qdescrs ]                               ; Name used in AttributeType
          [ "DESC" qdstring ]                               ; Description
          [ "OBSOLETE" whsp ]
          [ "SUP" woid ]                                      ; Derived from this other
          [ "EQUALITY" woid ]                            ; Matching Rule name
          [ "ORDERING" woid ]                            ; Matching Rule name
          [ "SUBSTR" woid ]                                ; Matching Rule name
          [ "SYNTAX" whsp noidlen whsp ]         ; Syntax OID
          [ "SINGLE-VALUE" whsp ]                    ; Default multi-valued
          [ "COLLECTIVE" whsp ]                        ; Default not collective
          [ "NO-USER-MODIFICATION" whsp ]     ; Default user modifiable
          [ X-ORDERED whsp type ]                   ; Non-standard - default not X-ORDERED
          [ "USAGE" whsp AttributeUsage ]       ; Default userApplications
whsp ")"

Attribut représentant le nom d'un groupe d'élèves à l'ESIPE :#groupName
attributetype ( 2.5.4.42.1.1
          NAME 'esipeGroupName'
          DESC

Ajout et Recherche

Ajout d'une entrée

Il existe deux formats pour l’importation de données dans un annuaire LDAP :

• LDAP Interchange Format (LDIF)
• Directory Services Markup Language (DSML)

Figure 15 - Ajout d'une entrée au format DSML

Figure 16 - Ajout d'une entrée au format LDIF

Recherche d'une entrée

Pour rechercher des données dans un annuaire LDAP, on peut utiliser la commande ldapsearch qui est fournis avec le serveur OpenLDAP.

Par exemple, si on souhaite récupérer toutes les entrées qui contiennent :

• La classe inetOrgPerson
• Dont le Common Name commence par "V"
• Dont la localisation n'est PAS Marseille

Alors il faut utiliser la commande suivante :

> _Computer$ ldapsearch –x ‘(&(objectclass=inetOrgPerson)(cn=V*)(!(l=Marseille)))’ objectClass cn l

# Valentin GOT, addressbook, example.com
dn: cn=Valentin GOT,ou=addressbook,dc=example,dc=com
objectClass: top
objectClass: inetOrgPerson
cn: Valentin GOT
l: Champs-sur-marne

On peut remarquer que dans la commande ci-dessus, nous avons aussi choisis d'afficher seulement l'objectClass, le Common Name et la Localisation dans les entrées qui seront retournées. 'Group of person'
          EQUALITY caseIgnoreMatch
          SUBSTR caseIgnoreSubstringMatch
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{5}
)

Liens

Sources

Voici les source que j'ai utilisé pour réaliser cette exposé.

• http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol
• http://www.frameip.com/snmp/
• http://tools.cisco.com/Support/SNMP/do/BrowseOID.do
• http://deptinfo.cnam.fr/new/spip.php?pdoc6723

• http://fr.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
• http://www.brennan.id.au/20-Shared_Address_Book_LDAP.html
• http://oav.net/mirrors/LDAP-ObjectClasses.html
• http://www.oid-info.com/