Monitoring d'une infrastructure informatique Linux sur base d'outils libres

Chapitre 7

Le protocole SNMP

7 Présentation du protocole SNMP

Le système de gestion de réseau est basé sur trois éléments principaux: un superviseur, des noeuds (ou nodes) et des agents. Dans la terminologie SNMP, le synonyme manager est plus souvent employé que superviseur. Le superviseur est la console qui permet à l'administrateur réseau d'exécuter des requêtes de management. Les agents sont des entités qui se trouvent au niveau de chaque interface, connectant l'équipement managé (noeud) au réseau et permettant de récupérer des informations sur différents objets.

Switchs, hubs, routeurs et serveurs sont des exemples d'équipements contenant des objets manageables. Ces objets manageables peuvent être des informations matérielles, des paramètres de configuration, des statistiques de performance et autres objets qui sont directement liés au comportement en cours de l'équipement en question. Ces objets sont classés dans une sorte de base de données appelée MIB (« Management Information Base »). SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets souhaités dans la MIB.

L'architecture de gestion du réseau proposée par le protocole SNMP est donc fondée sur trois principaux éléments :

Les équipements managés (managed devices) sont des éléments du réseau (ponts, hubs, routeurs ou serveurs), contenant des « objets de gestion » (managed objects) pouvant être des informations sur le matériel, des éléments de configuration ou des informations statistiques ;

Les agents, c'est-à-dire une application de gestion de réseau résidant dans un périphérique et chargé de transmettre les données locales de gestion du périphérique au format SNMP ; Les systèmes de management de réseau (network management systems notés NMS), c'està-dire une console à travers laquelle les administrateurs peuvent réaliser des tâches d'administration.

7.1 En pratique

Concrètement, dans le cadre d'un réseau, SNMP est utilisé:

pour administrer les équipements pour surveiller le comportement des équipements.

Une requête SNMP est un datagramme UDP habituellement à destination du port 161. Les schémas de sécurité dépendent des versions de SNMP (v1, v2 ou v3). Dans les versions 1 et 2, une requête SNMP contient un nom appelé communauté, utilisé comme un mot de passe. Il y a un nom de communauté différent pour obtenir les droits en lecture et pour obtenir les droits en écriture. Dans bien des cas, les colossales lacunes de sécurité que comportent les versions 1 et 2 de SNMP limitent l'utilisation de SNMP à la lecture des informations car la communauté circule sans chiffrement avec ces deux protocoles. Un grand nombre de logiciels libres et payants utilisent SNMP pour interroger régulièrement les équipements et produire des graphes rendant compte de l'évolution des réseaux ou des systèmes informatiques (MRTG, Cacti, Nagios,...).

Monitoring d'une infrastructure Linux sur base d'outils libres

Le protocole SNMP définit aussi un concept de Trap. Une fois défini, si un certain évènement se produit, comme par exemple le dépassement d'un seuil, l'agent envoie un paquet UDP à un serveur. Ce processus d'alerte est utilisé dans les cas où il est possible de définir simplement un seuil d'alerte. Dans nombre de cas, hélas, un alerte réseau ne devrait être déclenchée qu'en corrélant plusieurs événements.

7.2 Les trames

La trame SNMPv1 est complètement encodée en ASN.1 [ISO 87]. Les requêtes et les réponses ont le même format :

7.2-1 : Paquet SNMP

La version la plus utilisée est encore la version 1. Plusieurs versions 2 ont été proposées par des documents de travail, mais malheureusement, aucune d'entre elles n'a jamais été adoptée comme standard. La version 3 est actuellement en voie d'être adoptée. On place la valeur zéro dans le champ version pour SNMPv1, et la valeur 3 pour SNMPv3.

La communauté permet de créer des domaines d'administration. La communauté est décrite par une chaîne de caractères. Par défaut, la communauté est « PUBLIC ».

Le PDU (Packet Data Unit)

7.2-2 : Le PDU

7.3 Sa 3^ème version

Cette nouvelle version du protocole SNMP vise essentiellement à inclure la sécurité des transactions. La sécurité comprend l'identification des parties qui communiquent et l'assurance que la conversation soit privée, même si elle passe par un réseau public.

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

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

7.3.1 USM - User-based Security Model

Trois mécanismes sont utilisés. Chacun de ces mécanismes a pour but d'empêcher un type

d'attaque.

L'authentification : Empêche un intrus vienne changer le paquet SNMPv3 en cours de route et de valider le mot de passe de la personne qui transmet la requête.

7.3-1 : Schéma d'authentification du SNMPv3

1. Le transmetteur groupe des informations à transmettre avec le mot de passe.

2. On passe ensuite ce groupe dans la fonction de hachage à une direction.

3. Les données et le code de hachage sont ensuite transmis sur le réseau.

4. Le receveur prend le bloc des don nées, et y ajoute le mot de passe.

5. On passe ce groupe dans la fonction de hachage à une direction.

6. Si le code de hachage est identique à celui transmis, le transmetteur est authentifié.

Monitoring d'une infrastructure Linux sur base d'outils libres

Le cryptage : Empêche quiconque de lire les informations de gestions contenues dans un paquet SNMPv3.

Avec SNMPv3, le cryptage de base se fait sur un mot de passe « partagé » entre le manager et l'agent. Ce mot de passe ne doit être connu par personne d'autre. Pour des raisons de sécurité, SNMPv3 utilise deux mots de passe : un pour l'authentification et un pour le cryptage. Ceci permet au système d'authentification et au système de cryptage d'être indépendants. Un de ces systèmes ne peut pas compromettre l'autre.

SNMPv3 se base sur DES (Data Encryption Standard) pour effectuer le cryptage.

7.3-2 : Schéma du cryptage des données du SNMPv3

On utilise une clé de 64 bits (8 des 64 bits sont des parités, la clé réelle est donc longue de 56 bits) et DES encrypte 64 bits à la fois. Comme les informations que l'on doit encrypter sont plus longues que 8 octets, on utilise du chaînage de blocs DES de 64 bits.

Une combinaison du mot de passe, d'une chaîne aléatoire et d'autres informations forme le « Vecteur d'initialisation ». Chacun des blocs de 64 bits est passé par DES et est chaîné avec le bloc précédent avec un XOR. Le premier bloc est chaîné par un XOR au vecteur d'initialisation. Le vecteur d'initialisation est transmis avec chaque paquet dans les « Paramètres de sécurité », un champ qui fait partie du paquet SNMPv3.

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

L'estampillage du temps : Empêche la réutilisation d'un paquet SNMPv3 valide déjà transmis par quelqu'un.

Par exemple, si l'administrateur effectue l'opération de remise à jours d'un équipement, quelqu'un peut saisir ce paquet et tenter de le retransmettre à l'équipement à chaque fois que cette personne désire faire une mise à jour illicite de l'équipement. Même si la personne n'a pas l'autorisation nécessaire, elle envoie un paquet, authentifié et encrypté correctement pour l'administration de l'équipement.

On appelle ce type d'attaques le « Replay Attack ». Pour éviter ceci, le temps est estampillé sur chaque paquet. Quand on reçoit un paquet SNMPv3, on compare le temps actuel avec le temps dans le paquet. Si la différence est plus que supérieur à 150 secondes, le paquet est ignoré.

SNMPv3 n'utilise pas l'heure normale. On utilise plutôt une horloge différente dans chaque agent. Ceux-ci gardent en mémoire le nombre de secondes écoulées depuis que l'agent a été mis en circuit.

Monitoring d'une infrastructure Linux sur base d'outils libres

Ils gardent également un compteur pour connaître le nombre de fois où l'équipement a été mis en fonctionnement. On appelle ces compteurs BOOTS (Nombre de fois ou l'équipement a été allumé) et TIME (Nombre de secondes depuis la dernière fois que l'équipement a été mis en fonctionnement).

La combinaison du BOOTS et du TIME donne une valeur qui augmente toujours, et qui peut être utilisée pour l'estampillage. Comme chaque agent a sa propre valeur du BOOTS/TIME, la plate-forme de gestion doit garder une horloge qui doit être synchronisée pour chaque agent qu'elle contacte. Au moment du contact initial, la plateforme obtient la valeur du BOOTS/TIME de l'agent et synchronise une horloge distincte.

7.3.2 VACM - View- based Access Control Model

Permet le contrôle d'accès au MIB. Ainsi on a la possibilité de restreindre l'accès en lecture et/ou écriture pour un groupe ou par utilisateur.

7.4 La trame SNMPv3

Le format de la trame SNMPv3 est très différent du format de SNMPv1. Ils sont toutefois codés tous deux dans le format ASN.1 [ISO 87]. Ceci assure la compatibilité des types de données entres les ordinateurs d'architectures différentes.

Pour rendre plus facile la distinction entre les versions, le numéro de la version SNMP est placé tout au début du paquet. La figure suivante montre la trame SNMPv3:

7.4-1 : Trame SNMPv3

Ce schéma montre clairement les différents champs du paquet SNMPv3. Toutefois, le contenu de chaque champ varie selon la situation. Selon que l'on envoie une requête, une réponse, ou un message d'erreur, les informations placées dans le paquet respectent des règles bien définies dans le standard.

Monitoring d'une infrastructure Linux sur base d'outils libres 7.5 Son utilisation dans mon stage

Pour monitorer les différents équipements, j'utilise donc le protocole SNMP. Pour ce faire, il faut installer sur les machines Net-SNMP²⁹. Net-SNMP est une collection d'applications utilisées pour implémenter SNMP v1, SNMP v2c, SNMP v3 en utilisant à la fois IPv4 et IPv6.

J'ai rapatrié les packages Net-SNMP suivant via les dépôts de Red Hat :

Net-snmp

o Snmpd (daemon) : agent qui répondra aux requêtes SNMP

o Snmptrapd (daemon) : application qui recevra les notifications SNMP Net-snmp-utils : contient les divers outils (snmpwalk, snmpget, ?)

Une fois les packages installés, il suffit de lancer le daemon snmpd et on peut déjà interroger l'agent avec des petits utilitaires du genre de Getif³⁰.

7.6 Sa configuration

7.6.1 Création d'un utilisateur v3

Pour créer un utilisateur v3 (snmpd doit être arrêté). Il suffit d'ajouter les lignes suivantes au tout début du fichier /etc/snmp/snmpd.conf

createUser MonUtilisateur MD5 "MonMot2passe" DES MonMot2PasseDES rouser MonUtilisateur

MonUtilisateur : nom d'utilisateur MonMot2passe : authentication protocol pass phrase (qui se transformera en MD5) MonMot2PasseDES : privacy protocol pass phrase (qui servira pour le cryptage des don nées en DES)

7.6.2 Le fichier snmpd.conf Ensuite, modifier le fichier comme suit :

####

# First, map the community name "public" into a "security name"

# sec.name source community

com2sec Local monserveur.domain.tld ma_communaute_ro

####

# Second, map the security name into a group name:

# groupName securityModel securityName

group LocalGroup usm Local

####

# Third, create a view for us to let the group have rights to:

# Make at least snmpwalk -v 1 localhost -c public system fast again.

# name incl/excl subtree mask(optional)

view allview included .1.3.6

view systemview included .1.3.6.1.2.1.1

view systemview included .1.3.6.1.2.1.25.1.1

29 Net-SNMP : http://www.net-snmp.org

30 Getif : http://www.wtcs.org/snmp4tpc/getif.htm

####

# Finally, grant the group read-only access to the systemview view.

# group context sec.model sec.level prefix read write notif

access LocalGroup "" usm authPriv exact allview none none

chercher les mots : syslocation et syscontact et les modifier en conséquence : syslocation Rack 6, Armoire 9, Societe, Ville, Province, Pays syscontact Departement Informatique <[e-mail]> lancer le service snmpd ( # /etc/init.d/snmpd start ) rééditer le fichier précédent et supprimer la ligne « create user? »

7.6.3 Le test

Pour tester, nous pouvons lancer cette commande :

# snmp get -v 3 -u MonUtilisateur -l authPriv -a MD5 -A MonMot2passe -X MonMot2PasseDES localhost sysUpTime.0

Si on a l'heure (SNMPv2-MIB::sysUpTime.0 = Timeticks: (42388) 0:07:03.88 ) c'est bon, continuons avec ceci :

# snmpwalk -v 1 -c manex_ro localhost

Si Timeout: No Response from localhost apparait, tant mieux :o) Plus de SNMPv1.

7.7 Analyse avec WireShark

WireShark va nous permettre d'analyser les paquets et de voir que les informations demandées passent réellement en clair sur le réseau lorsqu'on utilise les versions 1 et 2c du protocole SNMP et

qu'elles sont cryptées avec la version 3 de SNMP.

7.7.1 Tests avec SNMPv2c

Voici une capture ã l'aide du logiciel Wireshark. Comme on peut le remarquer, la communauté passe

en clair vers l'agent que l'on souhaite interroger. Voici le get-request :

7.7-1 : get-request, SNMPv2c 7.7-2 : get-response ; SNMPv2c

Sur l'image de gauche, nous voyons donc la version utilisée (SNMPv2c), le nom de ma communauté (geolem_ro) et l'OID avec sa traduction des informations demandées.

Ensuite sur l'image de droite, la réponse de l'agent. Encore une fois la communauté est en clair, mais aussi ses informations. Sinon, dans ce cas-ci, j'avais demandé la localisation du serveur. Des informations tels que les services fonctionnant sur la machine peuvent être consulté avec parfois la version de ceuxci. Il ne reste plus qu'ã effectuer une petite recherche sur Internet pour trouver les failles de ce dernier.Voyons ce que cela donne avec le SNMPv3?

7.7.2 Test avec le SNMPv3

7.7-3 : get-request ; SNMPv3 7.7-4 : report ; SNMPv3

Ici, nous utilisons le SNMPv3. La procédure pour obtenir des informations est un peu différente. Pour obtenir le « syslocation » du test précédent, nous devons passer par 4 paquets au lieu de 2. Il s'agit en fait de la procédure d'authentification qui permettra d'obtenir le « msgAuthoritativeEngineID » qui, comme on le verra, reste le même tout le long des paquets.

7.7-5 : Demande des informations cryptées 7.7-6 : La réponse cryptée

A gauche, nous avons la demande, à droite la réponse. Le « msgAuthoritativeEngineID » est resté comme prévu le même. On peut apercevoir que le « UserName » passe en clair. Enfin, on peut voir les informations encryptées.