NAGIOS – Supervision avec SNMP

Introduction à SNMP

SNMP (Simple Network Management Protocol) est un protocole de communication réseau proposé par l’IETF. Ce protocole est utilisé pour gérer et superviser les équipements réseau comme les switchs et les routeurs et aussi les machines connectées à un réseau comme les serveurs, les applications et les bases de données. Bien qu’il soit un protocole relativement simple, il offre un ensemble de fonctionnalités permettant aux administrateurs système et réseau de gérer facilement un réseau hétérogène et de grande taille. Un réseau de gestion SNMP est composé de trois éléments principaux qui sont une station de gestion de réseau aussi appelée gestionnaire SNMP, des nœuds connectés au même réseau et des agents de collecte d’informations. Les différents éléments d’un réseau de gestion SNMP sont les suivants :

  • Le gestionnaire SNMP

    Le gestionnaire SNMP est une machine connectée au réseau configurée pour interroger l’agent SNMP pour information. Cette station de gestion de réseau peut être une machine qui peut envoyer des requêtes d’interrogation aux agents SNMP avec les informations d’identification correctes. Parfois, cela est mis en œuvre à travers un logiciel de surveillance et à l’aide d’utilitaires simples exécutés par l’administrateur pour élaborer une demande rapide. Dans un réseau, nous pouvons avoir plusieurs stations de gestion. Dans notre cas, le serveur Nagios joue le rôle d’un gestionnaire SNMP.

  • Le nœud

    Un nœud est tout équipement ou logiciel que nous cherchons à gérer avec le protocole SNMP. Chaque nœud doit disposer d’un agent de collecte SNMP qui répond aux requêtes envoyées par le gestionnaire. Ce nœud peut être un serveur, routeur, etc. La plupart des systèmes d’exploitation et équipements réseau possèdent un agent SNMP préconfiguré et ils sont livrés avec divers utilitaires permettant la communication avec d’autres périphériques via le protocole SNMP.

  • L’agent de collecte SNMP

    Un agent SNMP est un module installé sur le nœud. Sa fonction principale est de collecter les informations sur le nœud où il est installé et de les stocker dans un format qui peut être interrogé comme une base de données appelée MIB (Management Information Base).

La MIB est une base de données avec une structure hiérarchique, prédéfinie pour stocker les informations pouvant être interrogées ou définies dans une machine. Elle est disponible pour répondre aux requêtes SNMP provenant d’un gestionnaire SNMP après authentification avec les informations d’identification correctes. L’agent est configuré pour répondre uniquement aux gestionnaires habilités.

D’une manière générale, nous pouvons dire que le gestionnaire SNMP agit comme une interface entre l’administrateur et le nœud de réseau contrôlé. De même, l’agent SNMP agit comme une interface entre le gestionnaire SNMP et le nœud de réseau surveillé.

Le protocole SNMP fonctionne en mode non connecté en utilisant le protocole de transport UDP. Ce dernier n’exige pas une procédure de connexion entre les nœuds et il consomme moins de ressources que le protocole TCP. Cela permet à SNMP d’être relativement simple surtout dans sa configuration.

Deux modes de fonctionnements sont présents dans SNMP :

  • Le mode actif : dans ce mode, le gestionnaire interroge l’agent pour avoir une information. Dans ce cas, le gestionnaire envoie des requêtes SNMP en utilisant le port 161 pour lesquelles l’agent retourne des réponses.

  • Le mode passif : dans ce mode, l’agent envoie une notification au gestionnaire à propos d’un événement anormal détecté sur la machine. Dans ce cas, l’agent envoie des messages SNMPTRAP vers le gestionnaire en utilisant le port 162.

L’illustration ci-dessous représente une architecture d’un réseau de gestion SNMP avec les différents types de communications :

images/06EP01.PNG

1. Fichier MIB

Comme nous venons de le voir, la MIB est une base de données qui stocke des informations de gestion d’un nœud réseau. Ces informations peuvent être récupérées et traitées par un gestionnaire en utilisant le protocole SNMP. La MIB est organisée dans une structure normalisée et hiérarchique dont les informations sont regroupées sous la forme d’un arbre. Chaque information possède un identifiant unique nommé un OID (Object Identifier). OID est représenté par une séquence de chiffres séparés par un point. Par exemple, le nom d’interface réseau sur Linux eth0 est identifié par l’OID 1.3.6.1.2.1.2.2.1.2. L’arborescence d’un OID est organisée comme suit :

images/06EP02.PNG

Deux versions de MIB sont publiées et normalisées : MIB I et MIB II. La version MIB I est initialement définie dans le RFC 1156 et elle a été utilisée avec CMOT et non pas avec SNMP. La version MIB II est décrite dans le RFC 1213 et elle est quasiment installée sur tous les équipements réseau.

Il existe deux types de MIB.

Les MIB standards sont constituées par des OID standardisés qui sont communs entre plusieurs constructeurs d’équipements et de systèmes. Le chemin d’accès commun à cette branche est :

1.3.6.1.2.1

Ceci peut également être représenté par la chaîne suivante :

iso.org.dod.internet.mgmt.mib-2

La section 1.3.6.1 ou iso.org.dod.internet est l’OID qui définit les ressources Internet. Le 2 ou mgmt qui suit dans notre chemin de base est pour une sous-catégorie de gestion. Le 1 ou mib-2 définit la spécification MIB-2.

Le deuxième type de MIB correspond aux MIB propriétaires propres à chaque constructeur et souvent à chaque modèle d’équipement et système. Ce type de MIB est à récupérer auprès des constructeurs. Les objets de ces MIB sont attachés à la branche privée de l’arbre. Toutes les MIB propriétaires sont accessibles par le chemin :

1.3.6.1.4.1

Ceci peut également être représenté par la chaîne suivante :

iso.org.dod.internet.private.enterprises.xxx

Par exemple Cisco possède OID suivant :

1.3.6.1.4.1.9

Un fichier MIB est un fichier texte contenant les définitions de ces OID avec une description détaillée sur l’objet :

  • Un nom générique. Par exemple : ifDescr.

  • Une description de cet OID. Par exemple : “A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the hardware interface.”

  • Son type. Par exemple : DisplayString.

    Il existe différents types possibles de données :

  • INTEGER,

  • GAUGE,

  • COUNTER,

  • TIMESTAMP,

  • OCTET STRING,

  • OBJECT IDENTIFIER,

  • NULL,

  • DisplayString.

  • Son statut. Par exemple : mandatory. Les différents statuts possibles sont : mandatory, optional et obsolete.

  • Son mode d’accès. Par exemple read-only. Les différents modes d’accès sont : read-only, read-write, write-only et not-accessible.

Par exemple, l’objet ifDescr est définit comme suit :

ifDescr OBJECT-TYPE 
        SYNTAX  DisplayString (SIZE (0..255)) 
        ACCESS  read-only 
        STATUS  mandatory 
        DESCRIPTION 
        "A textual string containing information about the 
        interface.  This string should include the name of 
        the manufacturer, the product name and the version 
        of the hardware interface." 
        ::= { ifEntry 2 }

Parmi les fichiers MIB les plus utilisés, nous citons les fichiers IF-MIB, IP-MIB, IPv6-MIB, TCP-MIB, RFC1213-MIB, et UDP-MIB décrivent la configuration réseau d’une machine telle que les interfaces, la configuration IP, le routage, et les protocoles TCP et UDP.

Et les fichiers SNMPv2-MIB et HOST-RESOURCES-MIB décrivent les informations et les paramètres actuels d’un système donné. Cela peut inclure des informations sur la configuration matérielle utilisée comme l’espace disque, le CPU, la mémoire ainsi que la configuration logicielle comme les applications installées.

Il existe plusieurs logiciels open source et gratuits permettant de lire et manipuler graphiquement les fichiers MIB. Nous recommandons d’utiliser le logiciel ManageEngine MibBrowser qui peut être récupéré à partir de cette URL : https://www.manageengine.com/products/mibbrowser-free-tool/.

images/06EP03.PNG

2. Les requêtes et les messages SNMP

La communication entre le gestionnaire et l’agent utilisant le protocole SNMP se déroule sous forme de requêtes et de messages de réponses.

Il existe quatre types de requêtes envoyées par le gestionnaire à l’agent:

  • Get Request : cette requête permet au gestionnaire d’interroger un agent sur les valeurs d’un ou plusieurs OID spécifiques.

  • Get Next Request : cette requête permet au gestionnaire d’interroger un agent sur la valeur de l’OID suivant dans l’arbre des objets de l’agent.

  • Get Bulk : cette requête combine les deux requêtes précédentes Get Request  et Get Next Request et elle permet d’obtenir les valeurs d’un ensemble d’objets regroupés.

  • Set Request : cette requête permet au gestionnaire de modifier la valeur d’un objet dans l’agent.

De l’autre côté, il existe quatre types de messages de réponses envoyées par l’agent gestionnaire à l’agent :

  • Get Response : ce message est utilisé par l’agent pour répondre aux requêtes envoyées par le gestionnaire Get Request, Get Next Request et Get Bulk Request. Dans le cas où l’objet demandé par le gestionnaire n’est pas disponible, le message Get Response est envoyé avec une erreur noSuchObject.

  • Trap : ce message est envoyé par l’agent quand un événement anormal est détecté sur l’agent. Aucun accusé de réception ne sera envoyé par le gestionnaire.

  • Inform : ce message est envoyé par l’agent quand un événement anormal est détecté sur l’agent et dans ce cas un accusé de réception sera envoyé par le gestionnaire vers l’agent. Il y aura un renvoi de message par l’agent en cas de non-acquittement de gestionnaire.

3. Les versions du protocole SNMP

Le protocole SNMP a évolué depuis son introduction et plusieurs versions ont été publiées. Toutes les évolutions ont comme objectif principal l’amélioration de la sécurité de ce protocole. Voici les différentes versions publiées pour SNMP :

  • SNMPv1 :

    C’est la première version publiée pour le protocole SNMP et elle a été définie dans le RFC 1157. Cette implémentation vient avec un niveau de sécurité très basique. En effet, tous les périphériques qui communiquent avec la version SNMPv1 utilisent une chaîne de caractères appelée “communauté” pour vérifier que les demandes peuvent être effectuées. Par défaut, la communauté private permet la lecture et l’écriture des informations, tandis que la communauté public permet seulement la lecture.

  • SNMPV2 :

    Afin de corriger les faiblesses de la version SNMPv1, notamment en termes de sécurité, une nouvelle version a été implémentée sous le nom SNMPV2. Les principales améliorations peuvent être résumées dans les points suivants :

  • Ajout des deux opérations de protocole :

    Les trois requêtes introduites avec SNMPV1 Get Request, Get Next Request et Set sont encore utilisées avec la version SNMPV2. Mais, SNMPv2 a ajouté deux nouvelles opérations de protocole qui sont GetBulk et Inform.

  • Amélioration du niveau de sécurité :

    Cette version a introduit un nouveau modèle de sécurité appelée « party-based » pour résoudre les problèmes de sécurité inhérents à la révision précédente. Ce modèle n’a pas été très populaire en raison de sa complexité de mise en œuvre.

  • SNMPV3 :

    Comme nous avons pu le voir avec les deux versions antérieures à SNMPv3, aucune technique de sécurisation n’a été implémentée avec les deux versions SNMPV1 et SNMPV2. La nouvelle version SNMPV3 introduit un mécanisme d’authentification basé sur l’un de ces modèles :

  • NoAuthNoPriv :

    Les utilisateurs qui se connectent en utilisant ce modèle n’ont aucune authentification mise en place et aucune intimité des messages qu’ils envoient et reçoivent.

  • AuthNoPriv :

    Les utilisateurs qui se connectent en utilisant ce modèle doivent s’authentifier, mais les messages sont envoyés sans cryptage.

  • AuthPriv :

    L’authentification est requise et les messages sont cryptés.

    En plus de l’authentification, un mécanisme de contrôle d’accès a été mis en œuvre pour autoriser l’accès sur les branches auxquelles un utilisateur peut accéder.