1. Introduction▲
1-1. Les différents tutoriels▲
Initialement, je voulais tout mettre dans un seul tutoriel, mais comme il y a énormément de choses à dire au sujet de SNMP et du paquetage Net-SNMP, j'ai préféré simplifier votre tâche de compréhension (et aussi ma tâche de rédaction) en scindant cette étude en plusieurs articles :
- le premier article, celui-ci, présentera quelques généralités sur SNMP et ne parlera que de SNMP en version 1 ;
- le deuxième article présentera les notifications et la supervision toujours en SNMP en version 1 ;
- le contenu des articles suivants n'est pas encore connu.
Bien sûr, ces différents articles s'appuieront sur de vrais exemples et pour cela, j'utiliserai une machine virtuelle sous Linux. La distribution que j'utiliserai tout au long de ces articles est une distribution « Debian » parce que j'ai l'habitude de cette distribution. En ce qui concerne l'implémentation SNMP, j'utiliserai le paquetage Net-SNMP.
La majeure partie de la documentation est issue des pages du manuel Unix (man pages) ou alors du site WWW de Net-SNMP. Le but de ces tutoriels n'est pas non plus d'expliquer le rôle de tous les OID de la MIB. Pour cela, on se référera aux RFC ou alors aux documents des constructeurs.
1-2. Dans cet article▲
Dans cet article, j'aborde les aspects suivants :
- quelques rappels sur le fonctionnement de SNMPÂ ;
- la configuration d'un agent SNMP basique ;
- l'utilisation des outils Net-SNMP en ligne de commande.
Cet article, pas plus que les autres, ne fournira la liste complète et exhaustive des arguments ni des options que l'on peut trouver dans les différents fichiers de configuration. Il fournira les principaux et les expliquera, le but étant de vous donner les clés d'entrée et ensuite que vous alliez chercher le complément dans les pages du manuel ou sur le site de Net-SNMP qui est très complet.
2. Fonctionnement de SNMP▲
Le protocole SNMP existe en trois versions et chacune de ces versions apporte son lot d'améliorations au protocole.
Les trois versions de SNMP sont traditionnellement appelées :
- SNMPv1Â ;
- SNMPv2c ;
- SNMPv3.
Il faut signaler qu'il y a eu d'autres versions intermédiaires du protocole, mais que celles-ci ont été trop éphémères, trop académiques et trop peu suivies par les constructeurs. Elles n'existent qu'à titre historique.
2-1. Un peu de vocabulaire▲
Il y a quelques termes, certains spécifiques à l'environnement SNMP, d'autres plus généraux, qu'il faut absolument comprendre pour savoir de quoi l'on parle lorsque l'on aborde le sujet SNMP :
- Protocole : en informatique, un protocole est l'ensemble de règles définissant le mode de communication entre deux ordinateurs. Un protocole ne s'intéresse donc qu'à la partie « communication » sur le réseau. Un protocole définit entre autres, qui doit parler en premier et dans quels cas, le type de réponse que l'on peut apporter et le format des trames de requêtes et de réponses ;
- ASN.1 (Abstrac Syntax Number One) : c'est un standard international spécifiant une notation destinée à décrire des structures de données dans le secteur des télécommunications et des réseaux informatiques. La description en ASN.1 d'une structure de données a pour but d'obtenir une spécification de la structure qui est indépendante d'un encodage lié à un matériel particulier et sans ambiguïté ;
- SNMP (Simple Network Management Protocol) : c'est un protocole de communication qui permet aux administrateurs réseau de gérer les équipements du réseau, de superviser et de diagnostiquer des problèmes réseau et matériel à distance ;
- MIB (Management Information Base) : c'est un ensemble structuré d'informations sur une entité réseau, par exemple un routeur, un commutateur ou un serveur. Ces informations peuvent être récupérées, ou parfois modifiées, par un protocole comme SNMP. La structure de la MIB est hiérarchique, les informations sont regroupées sous la forme d'un arbre. Chaque information possède un Object IDentifier, une suite de chiffres séparés par des points, qui l'identifie de façon unique et un nom, indiqué dans le document qui décrit la MIB ;
- SMI (Structure of Management Information) : c'est la syntaxe utilisée pour écrire les fichiers MIB. Cette syntaxe est un sous-ensemble de ASN.1 et elle est déclinée actuellement en trois versions, la version SMIv1 (définie par la RFC 1155), la version SMIv2 (définie par la RFC 2579) et la version SMI-ng encore à l étude (le dernier draft date du 19 septembre 2003).
- OID (Object IDentifier) : c'est un identifiant universel, représenté sous la forme d'une suite d'entiers (1.3.6.1.4.2.11 par exemple). Il est organisé sous la forme hiérarchique. Ainsi seul l'organisme 2.999 peut dire quelle est la signification de l'OID 2.999.1 ;
- Agent : dans le monde SNMP, un agent est un programme qui tourne en tâche de fond sur une machine à superviser. Ce programme est chargé d'instancier les différents objets de la MIB qu'il doit implémenter, d'entretenir les valeurs dynamiques de ces objets et de répondre aux différentes requêtes protocolaires SNMP ;
- Manager : dans le monde SNMP, un manager est un programme qui permet d'interroger un agent SNMP. Il est chargé de présenter les informations recueillies auprès de cet agent et aussi de réagir de manière automatisée à certains événements ;
- Superviseur : dans le monde SNMP, un superviseur est un alias pour un manager.
2-2. Les requêtes SNMP▲
SNMP est un protocole réseau. Comme on ne peut pas parler d'un protocole sans parler de ses trames protocolaires, je ne dérogerai pas à cette règle. Ce paragraphe présente les différentes trames SNMP.
Par contre, je ne présenterai pas le format de ces requêtes, car d'une part, le codage ASN.1 (avec SNMP, tout est ASN.1) rend cet exercice délicat et d'autre part, tout est expliqué dans les différentes RFC qui traitent de SNMP. Mon but n'est pas de faire doublon avec ces documents qui spécifient complètement le format des trames.
Le tableau suivant synthétise les différentes requêtes existant pour la version 1 de SNMP :
| Requêtes SNMP | Rôle de la requête. |
| GetRequest | Ce message permet au superviseur d'interroger un agent sur les valeurs d'un objet de la MIB. |
| GetNextRequest | Ce message permet au superviseur d'interroger un agent pour obtenir la valeur de l'objet suivant dans l'arbre des objets de l'agent. Ce message permet de balayer des objets indexés de type tableau. |
| GetResponse | Ce message est utilisé par l'agent pour répondre aux messages « Get Request », « Get Next Request » et « Set Request » envoyés par le superviseur. |
| SetRequest | Ce message permet au superviseur de positionner ou modifier la valeur d'un objet dans l'agent. |
| Trap | Ce message est envoyé par l'agent à son superviseur de manière asynchrone pour le notifier d'un événement, un changement d'état ou un défaut. L'agent n'attend pas d'acquittement de la part du superviseur. |
Le format des trames SNMPv1 est spécifié par la RFC 1157.
2-3. Les échanges protocolaires SNMP▲
Traditionnellement, un agent SNMP est à l'écoute sur le port 161 en UDP pour recevoir des requêtes SNMP (GetRequest, GetNextRequest et SetRequest) en provenance d'un manager SNMP. Le manager SNMP doit donc connaître toutes les adresses IP des différents agents qu'il doit superviser.
Toujours traditionnellement, un manager SNMP est en écoute sur le port 162 en UDP pour recevoir les notifications (trap en anglais) qui pourraient être envoyées par un agent SNMP. Un agent SNMP doit donc connaître l'adresse IP de son manager afin de pouvoir lui envoyer ces notifications.
Les échanges protocolaires en SNMPv1 sont synthétisés par le schéma suivant :
2-4. La sécurité SNMP▲
La sécurité SNMP a longtemps été critiquée, car elle était jugée trop faible. En effet, pour la version SNMPv1, cette authentification repose uniquement sur la connaissance partagée entre le manager SNMP et l'agent SNMP d'une chaîne de caractères appelée « Community String » ou encore « nom de communauté » :
- le nom de communauté par défaut en lecture est très souvent « public ». Cette communauté en lecture est utilisée pour les requêtes SNMP GetRequest ;
- le nom de communauté par défaut en écriture est très souvent « private ». Cette communauté en écriture est utilisée pour les requêtes SNMP SetRequest.
L'expérience montre qu'il y a encore beaucoup (énormément ?) d'équipements sur le réseau qui sont configurés avec ces noms de communauté par défaut et donc, adieu la sécurité. SNMP est un protocole qui gère un très grand nombre d'informations parfois très sensibles (les tables de routage ou les tables ARP par exemple). Ce protocole, s'il n'est pas sécurisé un tant soit peu, est une véritable aubaine pour un « hacker ».
2-5. Les types de données SNMP▲
Les variables de la MIB instanciées par les agents peuvent avoir les types de base suivants :
| INTEGER | Le type INTEGER est un nombre entier arbitraire. Les valeurs d'un INTEGER peuvent être positives, négatives ou nulles et peuvent avoir n'importe quelle grandeur. |
| OCTET STRING | Le type OCTET STRING représente une chaîne arbitraire d'octets (des valeurs sur huit bits). Une valeur OCTET STRING peut avoir une longueur quelconque, y compris zéro. Ce type est un type chaîne de caractères. |
| BIT STRING | Le type BIT STRING représente une chaîne arbitraire de bits (uns et zéros). Une valeur BIT STRING peut avoir une longueur quelconque, y compris zéro. Ce type est un type chaîne de caractères. |
| OBJECT IDENTIFIER | Le type OBJECT IDENTIFIER désigne un identificateur d'objet, une séquence de composants entiers qui identifie un objet comme un algorithme, le type d'un attribut ou encore une autorité d'enregistrement qui définit d'autres identificateurs d'objets. Une valeur OBJECT IDENTIFIER peut avoir n'importe quel nombre de composants et les composants peuvent généralement avoir une valeur positive ou nulle. Ce type n'est pas un type chaîne de caractères. Les valeurs OBJECT IDENTIFIER sont fixées par les autorités d'enregistrement. Chaque autorité d'enregistrement est responsable de toutes les séquences de composants en commençant par une séquence donnée. Une autorité d'enregistrement en général délègue la responsabilité de sous-ensembles des séquences dans son domaine à d'autres autorités d'enregistrement, ou pour certains types d'objets. Il y a toujours au moins deux composants. |
| NULL | Le type NULL représente une valeur nulle. |
Ces types sont des éléments natifs du langage ASN.1 et de la syntaxe SMI. À partir de ces types de base, la syntaxe SMI permet de décliner des types plus complexes et l'on trouve par exemple :
| IpAddress | Ce type applicatif représente une adresse Internet sur 32 bits. Il est représenté comme un OCTET STRING de quatre octets dans l'ordre « réseau ». |
| Counter | Ce type applicatif représente un nombre entier non négatif qui augmente de façon monotone jusqu'à une valeur maximale. Quand il atteint cette valeur maximale, il se met à croître à nouveau à partir de zéro. Cette note précise une valeur maximale de 2^32-1 (4 294 967 295 en décimal) pour les compteurs. |
| Gauge | Ce type applicatif représente un nombre entier non négatif qui peut augmenter ou diminuer, mais qui se verrouille à sa valeur maximale. Cette note précise une valeur maximale de 2^32-1 (4 294 967 295 décimal) pour les jauges. |
| TimeTicks | Ce type applicatif représente un nombre entier non négatif qui compte le temps en centièmes de seconde depuis une certaine époque. Lorsque des types d'objets sont définis dans la MIB et utilisent ce type ASN.1, la description du type de l'objet identifie l'époque de référence. |
| Opaque | Ce type applicatif prend en charge la capacité de passer une syntaxe ASN.1 arbitraire. Une valeur est codée en utilisant les règles de base ASN.1. Celle-ci, à son tour, est encodée comme une OCTET STRING ce qui provoque un « double-emballage » de la valeur ASN.1 originelle. Notez que pour une mise en œuvre conforme, il suffit d'être en mesure d'accepter et de reconnaître les données opaques encodées. Il n'a pas besoin d'être en mesure de déballer les données et ensuite d'interpréter leur contenu. |
Ces types (IpAddress, Gauge, Counter…) ne sont pas des éléments du langage et de la syntaxe SMI, ils sont spécifiés par différentes MIB. « IpAddress » par exemple est complètement spécifié dans la MIB nommée RFC1155-SMI comme un OCTET STRING de quatre octets.
Il faut signaler aussi que le langage ASN.1 et donc la syntaxe SMI permettent de spécifier des données plus complexes encore comme des tableaux d'objets, des structures (équivalent en C du type « struct »), des unions (équivalent en C du type « union »).
3. Avant de pouvoir commencer▲
Voilà , la partie théorique est maintenant terminée, on va pouvoir passer aux choses sérieuses et mettre un peu les mains dans le « cambouis ». Ce paragraphe va s'intéresser à l'installation et la configuration minimale des outils et démons Net-SNMP. Pour cela, nous allons :
- installer la suite Net-SNMPÂ ;
- créer un utilisateur et un groupe d'utilisateurs utilisés par les démons de la suite Net-SNMP ;
- créer les répertoires des fichiers de configuration et de log ;
- créer le fichier de configuration /etc/snmp/snmp.conf ;
- créer le fichier de configuration /etc/snmp/snmpd.conf ;
- créer le fichier de configuration /etc/snmp/snmptrapd.conf ;
- créer le script de démarrage du démon snmpd ;
- créer le script de démarrage du démon snmptrapd ;
- démarrer les démons snmpd et snmptrapd ;
- et enfin redémarrer la machine afin de vérifier que tout est bon.
Toutes ces opérations se feront avec l'identité « root ». Toutes les commandes présentées dans ce paragraphe sont exécutées sur une machine possédant une distribution « Debian ». Il sera peut-être nécessaire d'adapter ces commandes à votre distribution.
3-1. Installation de la suite Net-SNMP▲
Avant de faire quoi que ce soit, nous allons commencer par compiler et installer la dernière version de Net-SNMP. Lors de l'écriture de cet article, la dernière version stable est la version 5.7.2. Elle est téléchargeable sur le site Net-SNMP ou encore ici, liée à cet article.
Les options proposées par défaut sont acceptées.
Les différents binaires sont installés dans le répertoire « /usr/local/bin », les bibliothèques partagées sont installées dans le répertoire « /usr/local/lib ». Il conviendra peut-être de modifier la variable d'environnement PATH pour ajouter le répertoire « /usr/local/bin » dans le chemin de recherche des binaires. Il conviendra peut-être aussi de modifier le fichier « /etc/ld.so.conf » afin que le répertoire « /usr/local/lib » figure dedans.
Une fois que l'installation est terminée, un petit test permet de vérifier que tout est bon. La commande « snmpd -v » doit afficher la version de la suite Net-SNMP :
Les outils installés sont :
| /usr/local/bin/snmpbulkget | Programme de communication avec un agent SNMP utilisant des requêtes SNMP GETBULK. |
| /usr/local/bin/snmpbulkwalk | Programme de récupération d'une partie de l'arbre des valeurs d'un agent SNMP utilisant des requêtes SNMP GETBULK. |
| /usr/local/bin/snmpconf | Permet de créer et de modifier les fichiers de configuration SNMP. |
| /usr/local/bin/snmpd | Agent SNMP. Il s'agit d'un démon. |
| /usr/local/bin/snmpdelta | Affiche les différences des valeurs de compteurs SNMP. |
| /usr/local/bin/snmpdf | Affiche l'utilisation de l'espace disque d'une machine en utilisant SNMP. |
| /usr/local/bin/snmpget | Programme de communication avec un agent SNMP utilisant des requêtes SNMP GET. |
| /usr/local/bin/snmpgetnext | Programme de communication avec un agent SNMP utilisant des requêtes SNMP GETNEXT. |
| /usr/local/bin/snmpinform | Programme de communication avec un manager SNMP utilisant des requêtes SNMP INFORM. |
| /usr/local/bin/snmpnetstat | Affiche l'état réseau et les informations de configuration d'une machine en utilisant SNMP. |
| /usr/local/bin/snmpset | Programme de communication avec un agent SNMP utilisant des requêtes SNMP SET. |
| /usr/local/bin/snmpstatus | Récupère quelques informations de configuration d'une machine en SNMP. |
| /usr/local/bin/snmptable | Récupère une table SNMP pour l'afficher sous la forme de tableau. |
| /usr/local/bin/snmptest | Il s'agit d'un shell SNMP qui permet de passer, de manière interactive, différentes commandes SNMP sur la machine à laquelle on est connecté. |
| /usr/local/bin/snmptranslate | Programme permettant de traduire des OID entre leur forme numérique et leur forme textuelle. |
| /usr/local/bin/snmptrap | Programme de communication avec un manager SNMP utilisant des requêtes SNMP TRAP. |
| /usr/local/bin/snmptrapd | Démon de relayage des traps SNMP. |
| /usr/local/bin/snmpusm | Gère les utilisateurs SNMPv3 sur une machine SNMP. |
| /usr/local/bin/snmpvacm | Gère les entrées VACM (View-based Access Control Model) SNMPv3 sur une machine SNMP. |
| /usr/local/bin/snmpwalk | Programme de récupération d'une branche complète de la MIB d'un agent en utilisant des requêtes SNMP GETNEXT. |
| /usr/local/bin/traptoemail | Script de conversion permettant de transformer des TRAP SNMP en mails. |
3-2. Création des utilisateurs et groupes d'utilisateurs▲
Nous allons créer le groupe d'utilisateurs « snmp » utilisé par les démons Net-SNMP avec la commande suivante :
Une petite vérification :
Nous allons créer l'utilisateur « snmp » membre du group « snmp » utilisé par les démons Net-SNMP avec la commande suivante :
Une autre petite vérification :
3-3. Création des répertoires▲
Nous allons créer le répertoire des fichiers de configuration :
Une petite vérification :
Nous allons aussi créer le répertoire des fichiers de log :
Une autre petite vérification :
3-4. Création du fichier « /usr/local/share/snmp/snmp.conf »▲
Le fichier de configuration général de Net-SNMP est « /usr/local/share/snmp/snmp.conf. » Pour des raisons de facilité, nous allons créer un lien symbolique « /etc/snmp/snmp.conf » vers ce fichier :
Nous allons maintenant créer un fichier de configuration « /etc/snmp/snmp.conf » complet qui explicite tous les paramètres que l'on peut trouver dans ce fichier. Pour vous simplifier la tâche, je vous encourage à utiliser celui-ci.
Appliquons des droits corrects sur ce fichier de configuration :
Une petite vérification :
3-5. Création du fichier « /etc/snmp/snmpd.conf »▲
Nous allons créer un fichier de configuration « /etc/snmp/snmpd.conf » minimal pour le démon « snmpd ». Ce fichier de configuration sera mis à jour dans cet article au fur et à mesure de notre découverte de Net-SNMP et de ses fonctionnalités :
Appliquons des droits corrects à ce fichier de configuration :
Une petite vérification :
3-6. Création du fichier « /etc/snmp/snmptrapd.conf »▲
Nous allons créer un fichier de configuration « /etc/snmp/snmpd.conf » minimal pour le démon « snmptrapd ». Ce fichier de configuration sera mis à jour dans cet article au fur et à mesure de notre découverte de Net-SNMP et de ses fonctionnalités :
Appliquons des droits corrects à ce fichier de configuration :
Une petite vérification :
3-7. Création du script de démarrage du démon « /etc/init.d/snmpd »▲
Nous allons créer le script de démarrage « /etc/init.d/snmpd » du démon « snmpd ». Pour vous simplifier la tâche, je vous encourage à utiliser celui-ci.
Remarque : ce script de démarrage est spécifiquement adapté à la distribution Debian. Il vous faudra peut-être le « retravailler » en fonction de votre distribution.
Appliquons des droits corrects à ce script de démarrage :
Une petite vérification :
Création des liens de démarrages :
Une petite vérification :
3-8. Création du script de démarrage du démon « /etc/init.d/snmptrapd »▲
Nous allons créer le script de démarrage « /etc/init.d/snmptapd » du démon « snmptrapd ». Pour vous simplifier la tâche, je vous encourage à utiliser celui-ci.
Remarque : ce script de démarrage est spécifiquement adapté à la distribution Debian. Il vous faudra peut-être le « retravailler » en fonction de votre distribution.
Appliquons des droits corrects à ce script de démarrage :
Une petite vérification :
Création des liens de démarrages :
Une petite vérification :
3-9. Démarrage des démons « snmpd » et « snmptrapd »▲
Le démarrage des démons se fait avec les commandes suivantes :
Un examen des fichiers /var/log/snmp/snmpd.log et /var/log/snmp/snmptrapd.log permet de voir le bon démarrage des démons :
3-10. Redémarrage de la machine et vérification▲
Une fois que toutes ces opérations sont terminées, nous pouvons redémarrer la machine avec la commande « reboot » afin de vérifier que tout repart correctement.
- Redémarrage de la machine :
- Contrôle des processus :
- Contrôle des ports :
- Contrôle de la version :
Cette installation, encore une fois « minimale », permet de disposer d'un agent SNMP basique sur lequel il va pouvoir être possible d'essayer les différents outils en ligne de commande.
Il est possible de voir les logs générés par le démon « snmpd » dans le fichier « /var/log/snmp/snmpd.log » ainsi que les logs générés par le démon « snmptrapd » dans le fichier « /var/log/snmp/snmptrapd.log ».
Les paramètres de configuration de l'agent SNMP seront vus en détail dans les paragraphes suivants.
3-11. Suppression des fichiers MIB▲
Nous allons aussi supprimer les fichiers MIB issus de l'installation, nous en réinstallerons d'autres plus tard :
3-12. Suppression des données persistantes▲
Les démons « snmpd » et « snmptrapd » entretiennent des données persistantes d'un démarrage à l'autre ou d'un reboot à l'autre. Pour que ces données restent persistantes, elles sont stockées dans un répertoire. Par défaut, ce répertoire est « /var/net-snmp ».
Même si ces fichiers sont au format texte et sont lisibles, il ne faut absolument pas les modifier manuellement. Ils sont sous la responsabilité des démons « snmpd » et « snmptrapd ». Toutefois, il est possible de les supprimer, mais au préalable, il faut arrêter les démons :
Ces trois commandes ont pour effet de complètement supprimer les données persistantes.
4. Les paramètres des outils en ligne de commande▲
La forme générale d'une commande SNMP en ligne de commande est la suivante :
- <snmpcmd> [OPTIONS] AGENT [PARAMETERS]
La plupart des programmes en ligne de commande supportent les options suivantes :
| -3[MmKk] 0xHEXKEY | Définit les clés à utiliser pour les opérations SNMPv3. Ces options vous permettent de définir la clé d'authentification et la clé de chiffrement (-3m et-3M respectivement) ou de définir la clé l'authentification localisée et la clé de chiffrement localisée (-3k et-3K respectivement). Les clés SNMPv3 peuvent être soit passées à la main en utilisant ces options ou par l'utilisation de clés générées à partir des mots de passe en utilisant les options -A et -X décrites ci-dessous. Pour plus de détails sur les protocoles SNMPv3 et l'utilisation des clés, consultez le site tutoriel Net-SNMP. Ces options remplacent respectivement les mots-clés defAuthMasterKey (-3m), defPrivMasterKey (-3M), defAuthLocalizedKey (-3k) ou defPrivLocalizedKey (-3K) du fichier snmp.conf, voir snmp.conf(5). |
| -a authProtocol | Définit le protocole d'authentification (MD5 ou SHA) utilisé pour les messages authentifiés SNMPv3. Remplace l'option defAuthType dans le fichier snmp.conf. |
| -A authPassword | Définit le mot de passe d'authentification utilisé pour les messages authentifiés SNMPv3. Remplace l'option defAuthPassphrase dans le fichier snmp.conf. Il n'est pas sécurisé de spécifier les mots de passe en ligne de commande, voir snmp.conf (5). |
| -c community | Définit la chaîne de communauté pour les transactions SNMPv1/v2c. Remplace l'option defCommunity dans le fichier snmp.conf. |
| -d | Dump (en hexadécimal) les paquets bruts SNMP envoyés et reçus. |
| -D TOKEN[,...] | Active le débogage pour les options données. Essayez ALL pour une sortie très verbeuse. |
| -e engineID | Définit l'autorité (de sécurité) engineID utilisé pour les messages SNMPv3 REQUEST à partir d'une chaîne hexadécimale (précédée optionnellement par "0x"). Il n'est généralement pas nécessaire de spécifier cet engineID, car il est généralement découvert automatiquement. |
| -E engineID | Définit le contexte de l'engineID utilisée pour les messages SNMPv3 REQUEST scopedPdu à partir d'une chaîne hexadécimale. S'il n'est pas spécifié, ce sera l'autorité engineID. |
| -h --help |
Afficher un court message d'aide et quitte. |
| -H | Afficher la liste des directives du fichier de configuration compris par la commande et quitte. |
| -I [brRhu] | Spécifie les options d'entrée. Voir ci-dessous. |
| -l secLevel | Définit le niveau de sécurité utilisé pour les messages SNMPv3 (noAuthNoPriv | authNoPriv | authPriv). Les mots de passe appropriés doivent être fournis lorsque vous utilisez un niveau plus élevé que noAuthNoPriv. Remplace l'option defSecurityLevel dans le fichier snmp.conf. |
| -L [eEfFoOsS] | Définit les options de journalisation. Voir ci-dessous. |
| -m MIBLIST | Définit une liste, séparée par ':', de modules MIB (pas de fichiers) à charger pour cette application. Ceci remplace (ou augmente) la variable d'environnement MIB, la directive MIB dans le fichier snmp.conf et la liste des MIB codées en dur dans la bibliothèque Net-SNMP. Si MIBLIST commence par les caractères '-' ou '+', alors les modules MIB indiqués sont chargés en plus de la liste par défaut, avant ou après cette liste respectivement. Dans le cas contraire, les modules MIB indiqués sont chargés à la place de cette liste par défaut. Le mot-clé ALL est utilisé pour charger tous les modules MIB dans la liste de recherche des répertoires MIB. Chaque fichier dont le nom ne commence pas par '.' sera analysé comme s'il s'agissait d'un fichier MIB. |
| -M DIRLIST | Définit une liste, séparée par ':', de répertoires de recherche de MIB. Ceci remplace (ou augmente) la variable d'environnement MIBDIRS, la directive MIBDIRS lue dans le fichier snmp.conf, ainsi que le répertoire par défaut codé en dur dans la bibliothèque Net-SNMP (/usr/share/snmp/mibs). Si MIBDIRS commence par les caractères '-' ou '+', alors les répertoires indiqués sont ajoutés à la liste par défaut, avant ou après cette liste respectivement. Dans le cas contraire, les répertoires spécifiés sont chargés à la place de cette liste par défaut. Notez que les répertoires qui apparaissent en dernier ont priorité sur les premiers. Pour éviter de rechercher tous les répertoires MIB, définissez la variable d'environnement MIBDIRS avec la chaîne vide (""). Notez que les modules MIB spécifiés en utilisant l'option -m ou l'option mibs dans le fichier snmp.conf seront chargés à partir de l'un des répertoires listés par l'option -M (ou équivalents). La directive mibfile prend un chemin complet vers le fichier MIB spécifié, il n'a donc pas besoin d'être dans la liste des répertoires de recherche des MIB. |
| -n contextName | Définit le contextName utilisé pour les messages SNMPv3. Le contextName par défaut est la chaîne vide "". Remplace l'option defContext dans le fichier snmp.conf. |
| -O [abeEfnqQsStTuUvxX] | Spécifie les options d'affichage. Voir ci-dessous. |
| -P [cdeRuwW] | Spécifie les options d'analyse des modules MIB. Voir ci-dessous. |
| -r retries | Spécifie le nombre d'essais dans les requêtes. La valeur par défaut est 5. |
| -t timeout | Spécifie le délai d'attente en secondes entre deux tentatives. La valeur par défaut est 1. |
| -u secName | Définit le securityName utilisé pour les messages SNMPv3 authentifiés. Remplace l'option defSecurityName dans le fichier snmp.conf. |
| -v 1 | 2c | 3 | Définit la version du protocole à utiliser : 1 (RFC 1155-1157), 2c (RFC 1901-1908), ou 3 (RFC 2571-2574). La valeur par défaut est généralement la version 3. Remplace l'option defVersion dans le fichier snmp.conf. |
| -V --version |
Affiche les informations de version de l'application et quitter. |
| -x privProtocol | Définit le protocole (DES ou AES) utilisé pour chiffrer les messages SNMPv3. Remplace l'option defPrivType dans le fichier snmp.conf. Cette option n'est valable que si le logiciel Net-SNMP a été construit pour utiliser OpenSSL. |
| -X privPassword | Spécifie le mot de passe pour chiffrer les messages SNMPv3. Remplace l'option defPrivPassphrase dans le fichier snmp.conf. Il n'est pas sécurisé de spécifier les mots de passe en la ligne de commande, voir snmp.conf (5). |
| -Z boots,time | Spécifie engineBoots et engineTime utilisés pour les messages authentifiés SNMPv3. Il n'est généralement pas nécessaire de spécifier cette option, car ces valeurs seront généralement découvertes automatiquement. |
| -Yname="value" --name="value" |
Permet de spécifier n'importe quelle option "nom" prise en charge dans le fichier snmp.conf et de lui affecter la valeur "value". Remplace l'option correspondant dans le fichier snmp.conf. Voir snmp.conf (5) pour la liste complète des options. |
4-1. Les options d'analyse des fichiers MIB▲
L'analyseur de modules MIB Net-SNMP sait décoder la syntaxe SMI. Comme cette syntaxe a changé au fil du temps et connaissant la diversité (ahem) dans le respect de cette syntaxe des fichiers MIB, des options supplémentaires offrent plus de souplesse pour la lecture des fichiers MIB (en fait, ces options permettent de lire des fichiers MIB qui ne respectent pas totalement la syntaxe SMI).
| -Pc | Bascule si les commentaires ASN.1 doivent s'étendre jusqu'à la fin de la ligne de source de la MIB. Strictement parlant, une deuxième apparition de "-" doit terminer le commentaire, mais cela perturbe certains fichiers MIB. Le comportement par défaut (à interpréter les commentaires correctement) peut également être réglé avec l'option (mal nommée) strictCommentTerm. |
| -Pd | Désactive le chargement des descriptions d'objets MIB lors du traitement des fichiers MIB. Cela réduit la quantité de mémoire utilisée par l'application en cours d'exécution. |
| -Pe | Bascule pour montrer les erreurs rencontrées lors de l'analyse des fichiers MIB. Il s'agit notamment des références aux modules importés et les objets MIB qui ne peuvent pas être situés dans la liste des répertoires de recherche des MIB. Le comportement par défaut peut également être défini avec l'option showMibErrors. |
| -PR | Si le même objet MIB (nom du parent et sous-identifiant) apparaît plusieurs fois dans la liste des modules MIB chargés, utilisez le dernier objet lu. Par défaut, le premier objet sera utilisé et tout doublon sera ignoré. Ce comportement peut également être réglé avec l'option mibReplaceWithLatest. Cette option n'est pertinente que s'il y a deux fichiers MIB avec des définitions d'objets contradictoires pour le même OID (ou des révisions différentes pour le même objet). |
| -Pu | Bascule pour autoriser ou non le caractère de soulignement dans les noms d'objets MIB et aussi les autres symboles. Strictement parlant, ce n'est pas autorisé par la syntaxe SMI, mais certains fichiers fournisseurs de modules MIB définissent de tels noms. Le comportement par défaut peut également être défini avec l'option de configuration mibAllowUnderline. |
| -Pw | Affiche les messages d'avertissement lors de l'analyse des divers fichiers MIB et la construction de l'arbre global OID. Peut aussi être défini avec l'option mibWarningLevel 1. |
| -PW | Affiche des messages d'avertissement supplémentaires, la plupart du temps liés à l'analyse des objets MIB individuels. Peut également être réglé avec l'option mibWarningLevel 2 |
4-2. Les options de contrôle de l'affichage▲
Le format de sortie des commandes SNMP peut être contrôlé en utilisant différents paramètres de l'option -O. Les effets de ces sous-options peuvent être vus en comparant avec la sortie par défaut (sauf indication contraire) :
La plupart de ces options peuvent également être configurées par des options dans le fichier snmp.conf. Voir la page du manuel snmp.conf(5) pour plus de détails.
| -Oa | Affiche les valeurs chaîne de caractères sous la forme ASCII (sauf s'il y a une option DISPLAY-HINT définie pour l'objet MIB correspondant). Par défaut, la bibliothèque tente de déterminer si la valeur est une chaîne imprimable ou binaire, et l'affiche en conséquence. Cette option n'affecte pas les objets qui ont une option DISPLAY-HINT. |
| -Ob | Affiche les index des tables sous la forme de nombres plutôt que d'essayer de les interpréter comme chaîne de caractères ou OID : $ snmpgetnext -c public -v 1 localhost vacmSecurityModel SNMP-VIEW-BASED-ACM-MIB::vacmSecurityModel.0."wes" = xxx $ snmpgetnext -c public -v 1 -Ob localhost vacmSecurityModel SNMP-VIEW-BASED-ACM-MIB::vacmSecurityModel.0.3.119.101.115 = xxx. |
| -Oe | Supprime les étiquettes symboliques des valeurs d'énumération : $ snmpget -c public -v 1 localhost ipForwarding.0 IP-MIB::ipForwarding.0 = INTEGER: forwarding(1) $ snmpget -c public -v 1 -Oe localhost ipForwarding.0 IP-MIB::ipForwarding.0 = INTEGER: 1. |
| -OE | Modifie les chaînes d'index pour échapper les guillemets : $ snmpgetnext -c public -v 1 localhost vacmSecurityModel SNMP-VIEW-BASED-ACM-MIB::vacmSecurityModel.0."wes" = xxx $ snmpgetnext -c public -v 1 -OE localhost vacmSecurityModel SNMP-VIEW-BASED-ACM-MIB::vacmSecurityModel.0.\"wes\" = xxx Cela permet à la sortie d'être réutilisée dans des commandes shell. |
| -Of | Inclut la liste complète des objets MIB lors de l'affichage d'un OID : .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0 = Timeticks: (14096763) 1 day, 15:09:27.63. |
| -On | Affiche les OID sous la forme numérique : .1.3.6.1.2.1.1.3.0 = Timeticks: (14096763) 1 day, 15:09:27.63. |
| -Oq | Supprime le signe égal et l'information de type lors de l'affichage des valeurs varbind : SNMPv2-MIB::sysUpTime.0 1:15:09:27.63. |
| -OQ | Supprime l'information de type lors de l'affichage des valeurs varbind : SNMPv2-MIB::sysUpTime.0 = 1:15:09:27.63. |
| -Os | Afficher le nom de l'objet MIB (ainsi que les instances ou autres sous-identifiants)Â : sysUpTime.0 = Timeticks: (14096763) 1 day, 15:09:27.63. |
| -OS | Affiche le nom de la MIB, ainsi que le nom de l'objet : SNMPv2-MIB::sysUpTime.0 = Timeticks: (14096763) 1 day, 15:09:27.63 C'est le format de sortie par défaut des OID. |
| -Ot | Affiche les valeurs TimeTicks sous la forme de chiffres bruts : SNMPv2-MIB::sysUpTime.0 = 14096763. |
| -OT | Si les valeurs sont imprimées sous la forme de chaînes hexadécimales, affiche aussi une version imprimable. |
| -Ou | Affiche l'OID dans le style traditionnel UCD (hérité du code original CMU). Cela signifie la suppression d'une série de préfixes « standards » de l'OID et l'affichage de la liste restante des noms d'objets MIB (et les autres sous-identifiants) : system.sysUpTime.0 = Timeticks: (14096763) 1 day, 15:09:27.63. |
| -OU | Ne pas imprimer le suffixe unités à la fin de la valeur. |
| -Ov | Affichage de la valeur varbind seulement et non l'OIDÂ : $ snmpget -c public -v 1 -Ov localhost ipForwarding.0 INTEGER: forwarding(1). |
| -Ox | Affiche les valeurs chaîne de caractères sous la forme hexadécimale (sauf s'il y a une option DISPLAY-HINT définie pour l'objet MIB correspondant). Par défaut, la bibliothèque tente de déterminer si la valeur est une chaîne imprimable ou binaire, et l'affiche en conséquence. Cette option n'affecte pas les objets qui ont une option DISPLAY-HINT. |
| -OX | Afficher les index des tables plus à la manière d'un programme la sortie, imitant un format d'index de tableau de style traditionnel : $ snmpgetnext -c public -v 1 localhost ipv6RouteTable IPv6-MIB::ipv6RouteIfIndex.63.254.1.0.255.0.0.0.0.0.0.0.0.0.0.0.64.1 = INTEGER: 2 $ snmpgetnext -c public -v 1 -OX localhost ipv6RouteTable IPv6-MIB::ipv6RouteIfIndex[3ffe:100:ff00:0:0:0:0:0][64][1] = INTEGER: 2. |
4-3. Les options de journalisation▲
Le mécanisme et la destination à utiliser pour l'enregistrement des messages d'erreur et d'avertissement peuvent être commandés en utilisant différents paramètres -L.
| -Le | Enregistre les messages dans le flux d'erreur standard. |
| -Lf FILE | Enregistre les messages dans le fichier spécifié. |
| -Lo | Enregistre les messages dans le flux de sortie standard. |
| -Ls FACILITY | Enregistre les messages via Syslog en utilisant la fonctionnalité spécifiée ('d' pour LOG_DAEMON, 'u' pour LOG_USER, '0' à '7' pour LOG_LOCAL0 à LOG_LOCAL7). |
| -LE pri | Enregistre les messages de priorité 'pri' et au-dessus dans le flux d'erreur standard. |
| -LE p1-p2 | Enregistre les messages de priorité comprise entre 'p1' et 'p2' (inclusive) dans le flux d'erreur standard. |
| -LF pri | Enregistre les messages de priorité 'pri' et au-dessus dans un fichier. |
| -LF p1-p2 | Enregistre les messages de priorité comprise entre 'p1' et 'p2' (inclusive) dans un fichier. |
| -LS pri | Enregistre les messages de priorité 'pri' et au-dessus avec Syslog. |
| -LS p1-p2 | Enregistre les messages de priorité comprise entre 'p1' et 'p2' (inclusive) avec Syslog. |
La sortie normale est (ou sera !) enregistrée avec un niveau de sévérité de LOG_NOTICE.
Pour -LE, -LF et -LS, la spécification de la priorité vient avant le fichier ou l'option de sévérité. Les sévérités identifiées sont :
| 0 ou ! | LOG_EMERG |
| 1 ou a | LOG_ALERT |
| 2 ou c | LOG_CRIT |
| 3 ou e | LOG_ERR |
| 4 ou w | LOG_WARNING |
| 5 ou n | LOG_NOTICE |
| 6 ou i | LOG_INFO |
| 7 ou d | LOG_DEBUG |
4-4. Les options de gestion des entrées▲
L'interprétation des noms des objets en entrée et les valeurs à attribuer peuvent être contrôlées en utilisant différents paramètres de l'option -I. Le comportement par défaut est décrit à la fin de ce paragraphe.
| -Ib | Indique que le nom donné doit être considéré comme une expression régulière, pour faire correspondre (en respectant la casse) avec les noms d'objets dans l'arborescence MIB. La "meilleure" correspondance sera utilisée, calculée comme celle qui correspond le mieux avec le début du nom du nœud et le plus haut dans l'arbre. Par exemple, l'objet MIB vacmSecurityModel pourrait correspondre à l'expression la vacmsecuritymodel (nom complet, mais avec une casse différente), ou encore avec VACM.*Model (expression régulière). Notez que '.' est un caractère spécial dans les expressions régulières, ainsi cette expression régulière ne peut pas spécifier de sous-identifiants par exemple ni plus d'un nom d'objet. Une expression "meilleure correspondance" sera seulement appliquée avec des noms simples d'objets MIB. Par exemple, l'expression sys*ontact.0 ne correspondrait pas à l'instance sysContact.0 (bien que sys*ontact corresponde sysContact). De même, spécifier un nom de module MIB ne réussira pas (ainsi SNMPv2-MIB::sys.*Ontact ne correspondra pas non plus). |
| -Ih | Désactive l'utilisation des informations DISPLAY-HINT lors de l'assignation de valeurs. Il faut alors les saisir en valeur brute : snmpset ... HOST-RESOURCES-MIB::hrSystemDate.0 x "07 D2 0C 0A 02 04 06 08" instead of a formatted version: snmpset ... HOST-RESOURCES-MIB::hrSystemDate.0 = 2002-12-10,2:4:6.8. |
| -Ir | Désactive la vérification des index de table et des valeurs en fonction des définitions issues des MIB. Cela devrait se traduire (on l'espère) par une requête invalide reportée par l'agent distant plutôt que par une vérification locale (et un rejet) avant qu'il ne soit envoyé à l'agent distant. Les contrôles locaux sont plus efficaces (et les diagnostics fournis ont également tendance à être plus précis), mais désactiver ce comportement est particulièrement utile pour tester l'agent distant. |
| -IR | Permet une recherche des noms dans les MIB par "accès aléatoire". Plutôt que de fournir un OID complet de l'objet MIB désiré (ou de qualifier cet objet avec un nom explicite de module MIB), l'arborescence MIB sera analysée pour rechercher le nom de l'objet correspondant. Ainsi. iso.org.dod.internet.mib-2.system.sysDescr.0 (ou SNMPv2-MIB::sysDescr.0) peut être spécifié simplement comme sysDescr.0. Attention, étant donné que les noms des objets MIB ne sont pas uniques au monde, cette approche peut retourner un objet MIB différent selon les fichiers MIB qui ont été chargés. La syntaxe MIB-MODULE::objectName a l'avantage d'identifier de manière unique un objet MIB particulier et ainsi d'être un peu plus efficace (en plus de charger automatiquement le fichier MIB nécessaire le cas échéant). |
| -Is SUFFIX | Ajoute le suffixe spécifié à chaque OID textuel donné sur la ligne de commande. Ceci peut être utilisé pour récupérer des objets multiples à partir de la même ligne d'une table, en spécifiant une valeur d'index commun. |
| -IS PREFIX | Ajoute le préfixe spécifié pour chaque OID textuel de la ligne de commande. Cela peut être utilisé pour spécifier un nom explicite de module MIB module pour tous les objets en cours de récupération (ou pour les dactylographes incurablement paresseux). |
| -Iu | Autorise le style 'UCD traditionnel pour la méthode d'interprétation des OID en entrée. Cela suppose que les OID sont attachés au point « mib-2 » dans l'arborescence (à moins qu'ils ne commencent avec un '.' explicit ou un nom de module MIB). Ainsi, l'instance sysDescr devrait être référencée comme system.sysDescr.0. |
Les noms d'objets spécifiés avec un '.' au début sont toujours interprétés comme des OID "pleinement qualifiés", énumérant la séquence des objets MIB à partir de la racine de l'arborescence MIB. Ces objets et ceux qualifiés par un nom explicite de module MIB ne sont pas affectés par les options -Ib, -IR et -Iu.
Sinon, si aucune des options de saisie ci-dessus n'est spécifiée, le comportement par défaut pour un OID "relatif" est d'essayer de l'interpréter comme un OID (implicitement) complet, puis d'appliquer la méthode par "accès aléatoire" de recherche (-IR), suivi par "meilleure correspondance" (-Ib).
4-5. Les options de spécification d'un agent▲
La chaine de caractères « AGENT » spécifie l'entité SNMP distante avec lequel communiquer. Cette spécification prend la forme :
[<transport-specifier>:]<transport-address>
Au plus simple, la spécification de l'AGENT peut consister en un nom de machine ou une adresse IPv4 en notation pointée standard. Dans ce cas, les communications vont être tentées en UDP sur IPv4 à destination du port 161 de la machine indiquée. Sinon, la partie <transport-address> de ce qui est indiqué est analysée en accord avec la table suivante :
| <transport-specifier> | <transport-address> format |
| udp | hostname[:port] ou IPv4-address[:port] |
| tcp | hostname[:port] ou IPv4-address[:port] |
| unix | Pathname |
| ipx | [network]:node[/port] |
| aal5pvc ou pvc | [interface.][VPI.]VCI |
| udp6 ou udpv6 ou udpipv6 | hostname[:port] ou IPv6-address:port ou '['IPv6-address']'[:port] |
| tcp6 ou tcpv6 ou tcpipv6 | hostname[:port] ou IPv6-address:port ou '['IPv6-address']'[:port] |
À noter que la chaîne de caractères <transport-specifier> est non sensible à la casse et ainsi, "tcp" et "TCP" sont équivalents. Voici quelques exemples et leur interprétation :
| hostname:161 | Effectue la requête en utilisant des datagrammes UDP/IPv4 à destination de hostname sur le port 161. La commande ":161" est redondante ici puisque c'est le port SNMP par défaut dans tous les cas. |
| udp:hostname | Identique à la spécification précédente. Le "udp" ici est redondant ici depuis UDP/IPv4 est le transport par défaut. |
| TCP:hostname:1161 | Se connecte à la machine hostname sur le port 1161 en utilisant TCP/IPv4 et effectue des requêtes sur cette connexion. |
| ipx::00D0B7AAE308 | Effectue la requête en utilisant des datagrammes IPX à destination du nœud 00D0B7AAE308 sur le réseau par défaut et en utilisant le port IPX par défaut 36 879 (900F en hexadécimal) comme suggéré dans la RFC 1906. |
| ipx:0AE43409:00D0B721C6C0/1161 | Effectue la requête en utilisant des datagrammes IPX sur le port 1161 sur le numéro de nœud 00D0B721C6C0 sur le numéro de réseau 0AE43409. |
| unix:/tmp/local-agent | Connecte au socket /tmp/local-agent du domaine Unix et exécute la requête sur cette connexion. |
| /tmp/local-agent | Identique à la spécification précédente, puisque le domaine Unix est le transport par défaut si le premier caractère de <transport-address> est un '/'. |
| AAL5PVC:100 | Exécute la requête en utilisant des PDU AAL5 transmis sur le circuit virtuel permanent avec VPI=0 et VCI=100 (en décimal) sur la première carte ATM dans la machine. |
| PVC:1.10.32 | Effectue la requête en utilisant des PDU AAL5 envoyées sur le circuit virtuel permanent avec VPI=10 (décimal) et VCI=32 (décimal) sur la deuxième carte ATM dans la machine. Notez que « PVC » est un synonyme de "AAL5PVC". |
| udp6:hostname:10161 | Effectue la requête en utilisant des datagrammes UDP/IPv6 sur le port 10161 de la machine hostname (qui sera cherchée comme un enregistrement AAAA). |
| UDP6:[fe80::2d0:b7ff:fe21:c6c0] | Effectue la requête en utilisant des datagrammes UDP/IPv6 vers le port 161 de l'adresse fe80::2D0:B7FF:fe21:c6c0. |
| tcpipv6:[::1]:1611 | Se connecter au port 1611 sur la machine locale (::1 dans le langage IPv6) en utilisant TCP/IPv6 et effectuer la requête sur cette connexion. |
Notez que tous les domaines de transport énumérés ci-dessus seront toujours disponibles. Par exemple, les machines sans support IPv6 ne seront pas en mesure d'utiliser des adresses de transport IPv6, et tenter de le faire se traduira par l'erreur "Unknown host". De même, puisque le support des circuits virtuels AAL5 n'est actuellement disponible que sur Linux, il échouera avec la même erreur sur d'autres plateformes.
4-6. Les variables d'environnement▲
Les variables d'environnement suivantes sont utilisées :
| PREFIX | Le préfixe standard pour les identificateurs d'objets (en utilisant le style de sortie UCD). La valeur par défaut est iso.org.dod.internet.mgmt.mib-2. |
| MIBS | La liste des modules MIB à charger. Par défaut, SNMPv2-TC, SNMPv2-MIB, IF-MIB, IP-MIB, TCP-MIB, UDP-MIB, SNMP-VACM-MIB. Remplacé par l'option-m. |
| MIBDIRS | La liste des répertoires de recherche de MIB. Par défaut, /usr/share/snmp/mibs. Remplacé par l'option-M. |
5. Les outils en ligne de commande▲
Le but de ce paragraphe n'est pas de présenter tous les outils du paquetage Net-SNMP, mais plutôt de présenter les plus importants et les plus utiles lors des investigations sur un environnement SNMP.
Les premiers outils que nous allons utiliser sont snmpget, snmpwalk et snmpset :
- le programme snmpget permet de récupérer une variable (un OID donc) quelconque de l'agent ;
- le programme snmpwalk permet d'afficher tout l'arbre des OID de l'agent ;
- le programme snmpset permet de modifier une variable de l'agent.
5-1. Le programme « snmpget »▲
Le programme « snmpget » est situé dans le répertoire « /usr/local/bin/ ». Il permet d'envoyer une requête SNMP GetRequest et d'afficher la réponse retournée par l'agent.
La première requête que nous allons effectuer est de demander à l'agent SNMP son OID sysDescr. Pour information, la définition de l'OID sysDescr trouvée dans la RFC 1213 est la suivante :
Son OID sous la forme numérique est .1.3.6.1.2.1.1.1.
La commande à effectuer est la suivante :
La commande retourne bien la chaine de caractères descriptive de la machine.
À ce stade, il convient d'apporter une précision. Bien que l'OID de la variable MIB sysDescr soit .1.3.6.1.2.1.1.1 ou encore iso(1) . org(3) . dod(6) . internet(1) . mgmt(2) . mib-2(1) . system(1) . sysDescr(1), il a tout de même fallu demander l'OID .1.3.6.1.2.1.1.1.0 en ajoutant le suffixe (ou numéro d'instance ou indice) « .0 ».
Si on ne fournit pas ce suffixe, la commande retourne une erreur :
Lorsque l'on récupère une valeur, il est obligatoire avec SNMP de spécifier le numéro d'indice dans la table (SNMP parle plutôt de numéro d'instance). Même pour une variable scalaire (sysDescr est une variable scalaire, ce n'est pas une table), il est tout de même obligatoire d'effectuer la requête avec un numéro d'instance et dans ce cas, il faut demander le numéro d'instance 0.
5-2. Le programme « snmpwalk »▲
Le programme « snmpwalk » est situé dans le répertoire « /usr/local/bin/ ». Il permet d'afficher l'arbre complet des OID de l'agent en envoyant des requêtes SNMP GetNextRequest et en affichant les résultats retournés par l'agent.
La commande à effectuer est la suivante :
Dans cet exemple, il s'agit d'un petit arbre, certains agents SNMP peuvent retourner plusieurs milliers de lignes avec une commande snmpwalk.
Il est aussi possible de ne parcourir qu'une partie de l'arbre des OID en spécifiant la branche de départ :
Cette requête n'affiche que les OID commençant par .1.3.6.1.2.1.1.9 ou encore iso(1) . org(3) . dod(6) . internet(1) . mgmt(2) . mib-2(1) . system(1) . sysORTable(9).
Pour information, l'OID .1.3.6.1.2.1.1.9 est défini dans la RFC 1907. Sa définition est la suivante :
5-3. Le programme « snmpset »▲
Le programme snmpset, comme sont nom l'indique, sert à positionner une valeur à un OID donné. Bien sûr, pour écrire une valeur, encore faut-il que cet OID ait un attribut en lecture et écriture. Ce n'est pas le cas de tous les OID, seuls quelques-uns peuvent être écrits. Il faut consulter la MIB de ces OID pour obtenir cette information.
Pour tester ce programme, nous allons modifier la variable de l'agent sysContact. En effet, cette variable est accessible en lecture, mais aussi en écriture.
Pour information, l'OID de la variable sysContact est 1.3.6.1.2.1.1.4. Il est défini dans la RFC 1907. Sa définition est la suivante :
La commande de lecture de la variable sysContact est la suivante :
Le résultat affiché montre que la variable sysContact n'est pas positionnée. La prochaine commande va lui donner une valeur :
Une nouvelle lecture permet de confirmer que la valeur est bien positionnée :
Une remarque concernant les OID sysLocation, sysContact et sysName. Ces OID sont normalement en lecture et écriture (regardez la MIB 1213 pour vous en convaincre). Toutefois, si vous spécifiez des valeurs pour ces OID dans le fichier de configuration snmpd.conf (avec les clauses sysLocation, sysContact et sysName), Net-SNMP utilisera les valeurs spécifiées, mais ne permettra plus que vous les modifiez avec la commande snmpset, elles deviendront automatiquement en lecture seule.
5-4. Conclusions▲
Voilà , c'est terminé pour ce paragraphe, nous avons configuré un agent SNMP, il fonctionne et nous pouvons lui envoyer des requêtes, il nous répond. Mais ce n'est qu'un début, il reste encore plein de choses à faire pour avoir une configuration « aux petits oignons » et c'est ce que nous allons voir et faire avec les chapitres suivants qui vont tous ajouter de nouvelles fonctionnalités.
6. Installation de nouvelles MIBS▲
Lors de l'utilisation des commandes précédentes, nous avons vu que les OID sous la forme de nombre (vous savez, 1.3.6.1.2.1.1.4.0) étaient utilisés aussi bien dans nos requêtes que dans l'affichage des valeurs retournées.
6-1. Petite digression▲
Qui donc peut se rappeler sans hésitation et immédiatement que 1.3.6.1.2.1.1.4, c'est l'OID qui correspond à sysDescr ? Personne, d'autant plus qu'il existe des milliers d'OID (plusieurs centaines de milliers même). Il serait bien de passer à une forme plus textuelle de ces OID afin d'aider notre pauvre cerveau défaillant. Et c'est ce que nous allons voir et faire dans ce chapitre.
Tout d'abord, il faut bien comprendre une chose, au niveau SNMP, tout n'est qu'OID sous la forme de nombres. Le protocole, pas plus que l'agent, ne connaissent de variable MIB qui s'appelle « sysDescr ». Ils connaissent 1.3.6.1.2.1.1.4 (en n'oubliant pas le suffixe .0 pour l'instance) et c'est tout. La transposition de 1.3.6.1.2.1.1.4 vers sa forme textuelle sysDescr est donc une convention et cette convention est décrite par le fichier MIB.
Si l'on regarde d'un peu plus près un tel fichier MIB (sysDescr dans la RFC 1213 par exemple), on trouve des définitions d'objets comme cela :
Cela signifie que sysContact est un objet dont l'OID est « system.4 ». Maintenant, il reste plus qu'à découvrir l'OID de « system ».
Toujours dans la RFC 1213, si on cherche « system », on trouvera une définition comme cela :
Donc pour « sysDescr » (qui vaut « system.4 »), si on remplace « system » par sa valeur « mib-2.1 », on obtient une valeur plus précise de sysDescr maintenant avec « mib-2.1.4 ».
Si on répète récursivement cette opération, on finit par trouver que « sysDescr » vaut 1.3.6.1.2.1.1.4 c'est-à -dire sous la forme textuelle : « iso . org . dod . internet . mgmt . mib-2 . system . sysDescr ». Je vous laisse refaire complètement cette opération afin de comprendre le mécanisme.
Sachez toutefois que, par exemple, vous ne trouverez pas la définition de « mgmt » dans la RFC 1213. Par contre, en début de fichier, vous avez une indication, l'objet « mgmt » est importé dans la RFC 1213 depuis le fichier MIB RFC1155-SMI. Cet import vous indique que pour finir la résolution, il faut changer de fichier.
À titre d'exemple, voici les imports de la MIB RFC 1213 :
Ce mécanisme d'import est très courant avec les MIB et il est parfois nécessaire de lire une dizaine de fichiers MIB pour décoder totalement l'OID d'un objet ou même son type (pour l'instant, les types que l'on voit ne sont que des types simples, mais il y a des types beaucoup plus complexes (l'équivalent des structures en C) qui peuvent nécessiter aussi plusieurs fichiers MIB pour être entièrement connus.
Les fichiers MIB, on vient de le voir, sont très importants pour la compréhension des informations SNMP. Mais combien y a-t-il donc de fichiers MIB ? Il est très difficile de répondre à cette question. Entre les MIB « officielles » issues des RFC et des organismes officiels (IETF, Iana…) et celles issues des constructeurs eux-mêmes, il est difficile d'obtenir une liste détaillée d'autant plus que les constructeurs ne cessent de rajouter de nouvelles MIB au fur et à mesure que de nouveaux équipements voient le jour. À titre d'information, le site circitor référence plus de 6 000 MIBS.
6-2. Revenons à nous moutons▲
L'objectif de ce chapitre est toujours d'afficher les OID sous une forme un peu plus parlante en affichant les OID avec une valeur textuelle plutôt que sous la forme de suite de chiffres.
Pour cela, nous allons faire deux choses :
- ajouter de nouveaux fichiers MIB (Net-SNMP n'est livré qu'avec quelques MIB qui ne permettent pas de résoudre tous les objets).
- indiquer à Net-SNMP où se trouvent ces nouveaux fichiers pour qu'il les utilise.
Pour importer de nouveaux fichiers, je vous propose d'utiliser ceux-ci. Je les ai regroupés pour vous dans un seul fichier. Nous allons les mettre dans un nouveau répertoire, le répertoire « /usr/local/share/snmp/mibs ». Pour cela :
- copiez le fichier « mibs.tar.gz » dans le répertoire « /usr/local/share/snmp/mibs » (un autre répertoire ferait tout aussi bien l'affaire, mais tâchons de respecter les conventions) par FTP ou tout autre moyen ;
- décompressez l'archive à l'aide de la commande « cd /usr/local/share/snmp/mibs ; gunzip /usr/share/mibs/mibs.tar.gz » ;
- dépaqueter l'archive à l'aide la commande « cd /usr/local/share/snmp/mibs ; tar -xvf /usr/local/share/snmp/mibs/mibs.tar » ;
- et enfin supprimer l'archive devenue inutile par la commande « rm /usr/local/share/snmp/mibs/mibs.tar.gz ».
Maintenant, nous allons modifier le fichier de configuration afin d'indiquer le nouveau répertoire dans lequel se trouvent les nouveaux fichiers MIB. Pour cela, il faut éditer le fichier « /etc/snmp/snmp.conf » et modifier la clause « mibdirs » pour qu'elle ressemble maintenant à ceci :
La clause « mibdirs » indique la liste des répertoires séparés par le caractère « : » dans lesquels rechercher les fichiers MIB.
Après cette première modification, il faut aussi indiquer à Net-SNMP quels fichiers MIB il doit charger et cela se passe avec la clause « mibs », mais nous allons faire simple en lui disant de charger tous les fichiers avec la clause « ALL » comme ceci :
En fait, la clause « mibs » indique plutôt les noms des modules à charger et non pas les noms des fichiers. En syntaxe SMI, un fichier MIB peut contenir plusieurs modules MIB différents (bien que cela ne soit pas très fréquent).
6-3. Rejoue encore !▲
Après ces quelques modifications (qui ne nécessitent pas le redémarrage des démons snmp), voyons le résultat :
Tout d'abord une lecture avec snmpget :
C'est beaucoup plus lisible comme ceci, non ?
Et comment fait-on lorsque deux modules décrivent deux objets différents qui portent le même nom ? Il y a une ambiguïté et ce n'est pas interdit par la syntaxe SMI. Dans ce cas, on lève l'ambiguïté en spécifiant le nom du module désiré comme ceci :
Et si on faisait maintenant une écriture :
Une relecture pour confirmer :
C'est quand même mieux non ? Et avec snmpwalk, cela donne quoi ?
Alors d'autres questions ? Vous voulez le format numérique, mais vous ne voulez pas remodifier le fichier de configuration « /etc/snmp/snmp.conf » ? Facile, jouez avec les options de la ligne de commande :
root@debian:~# snmpwalk -v 1 -c public -On localhost
.1.3.6.1.2.1.1.1.0 = STRING: Linux debian 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686
.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.8072.3.2.10
.1.3.6.1.2.1.1.3.0 = Timeticks: (208753) 0:34:47.53
.1.3.6.1.2.1.1.4.0 = STRING: nouveau contact@home.org
.1.3.6.1.2.1.1.5.0 = STRING: debian
.1.3.6.1.2.1.1.6.0 = STRING: My current location
.1.3.6.1.2.1.1.7.0 = INTEGER: 72
.1.3.6.1.2.1.1.8.0 = Timeticks: (14) 0:00:00.14
.1.3.6.1.2.1.1.9.1.2.1 = OID: .1.3.6.1.6.3.10.3.1.1
.1.3.6.1.2.1.1.9.1.2.2 = OID: .1.3.6.1.6.3.11.3.1.1
.1.3.6.1.2.1.1.9.1.2.3 = OID: .1.3.6.1.6.3.15.2.1.1
.1.3.6.1.2.1.1.9.1.2.4 = OID: .1.3.6.1.6.3.1
.1.3.6.1.2.1.1.9.1.2.5 = OID: .1.3.6.1.2.1.49
.1.3.6.1.2.1.1.9.1.2.6 = OID: .1.3.6.1.2.1.4
.1.3.6.1.2.1.1.9.1.2.7 = OID: .1.3.6.1.2.1.50
.1.3.6.1.2.1.1.9.1.2.8 = OID: .1.3.6.1.6.3.16.2.2.1
.1.3.6.1.2.1.1.9.1.3.1 = STRING: The SNMP Management Architecture MIB.
.1.3.6.1.2.1.1.9.1.3.2 = STRING: The MIB for Message Processing and Dispatching.
.1.3.6.1.2.1.1.9.1.3.3 = STRING: The management information definitions for the SNMP User-based Security Model.
.1.3.6.1.2.1.1.9.1.3.4 = STRING: The MIB module for SNMPv2 entities
.1.3.6.1.2.1.1.9.1.3.5 = STRING: The MIB module for managing TCP implementations
.1.3.6.1.2.1.1.9.1.3.6 = STRING: The MIB module for managing IP and ICMP implementations
.1.3.6.1.2.1.1.9.1.3.7 = STRING: The MIB module for managing UDP implementations
.1.3.6.1.2.1.1.9.1.3.8 = STRING: View-based Access Control Model for SNMP.
.1.3.6.1.2.1.1.9.1.4.1 = Timeticks: (13) 0:00:00.13
.1.3.6.1.2.1.1.9.1.4.2 = Timeticks: (13) 0:00:00.13
.1.3.6.1.2.1.1.9.1.4.3 = Timeticks: (13) 0:00:00.13
.1.3.6.1.2.1.1.9.1.4.4 = Timeticks: (14) 0:00:00.14
.1.3.6.1.2.1.1.9.1.4.5 = Timeticks: (14) 0:00:00.14
.1.3.6.1.2.1.1.9.1.4.6 = Timeticks: (14) 0:00:00.14
.1.3.6.1.2.1.1.9.1.4.7 = Timeticks: (14) 0:00:00.14
.1.3.6.1.2.1.1.9.1.4.8 = Timeticks: (14) 0:00:00.146-4. La commande « snmptable »▲
Maintenant que de nouvelles MIB sont installées, nous allons pouvoir utiliser une nouvelle commande, la commande « snmptable » qui comme son nom l'indique permet d'afficher une table.
Tout d'abord, nous allons regarder dans les fichiers SMI comment sont déclarées les tables et nous allons appuyer notre exemple sur l'OID « tcpConnTable ». Que nous disent les MIB à son sujet ? « tcpConnTable » est défini dans la MIB « RFC1213-MIB » comme ceci :
En décodant un peu la MIB, on peut voir que « tcpConnTable » (dont l'OID est « tcp.13 », c'est-à -dire .1.3.6.1.2.1.6.13) est une table (mot-clé SEQUENCE OF) de « tcpConnEntry », que « tcpConnEntry » (dont l'OID est « tcpConnTable.1 c'est-à -dire .1.3.6.1.2.1.6.13.1) est de type « TcpConnEntry » et que « TcpConnEntry » est une structure (mot-clé SEQUENCE) composée :
- d'un INTEGER, le champ tcpConnState, les valeurs que peut prendre ce champ sont définies plus bas ;
- d'un IpAddress (un OCTET STRING de quatre octets), le champ tcpConnLocalAddress ;
- d'un INTEGER (compris entre 0 et 65 535), le champ tcpConnLocalPort ;
- d'un IpAddress (un OCTET STRING de quatre octets), le champ tcpConnRemAddress ;
- d'un INTEGER (compris entre 0 et 65Â 535), le champ tcpConnRemPort.
La commande « snmptable » ne peut être exécutée que sur une table et c'est pour cela qu'il faut que les MIB soient présentes et chargées afin que la commande puisse connaitre la structure de cette table :
6-5. Le programme « snmptranslate »▲
Depuis le début de cet article, je vous présente des OID (1.3.6.1.2.1.1.4.0 par exemple) et je vous donne sans sourciller leur transcription textuelle. Bon d'accord, comme c'est moi qui écris, j'ai tout le temps que je veux pour rechercher, mais il est aussi possible de se faire aider par la commande « snmptranslate » dont le rôle est justement de transformer des OID sous la forme de nombres en forme textuelle et l'inverse aussi :
ou encore
ou encore
Ce programme peut être très utile lors de l'analyse de trames SNMP sur le réseau.
7. Conclusions▲
Voilà , c'en est fini avec ce premier module concernant SNMP version 1 et Net-SNMP. À l'issue de cet article, vous devriez avoir un démon SNMP opérationnel. Je vous engage à regarder en détail toutes les informations retournées avec la commande « snmpwalk ». Il y a une foule d'informations dont certaines dont vous n'avez même pas idée. Je vous engage aussi à parcourir les différents fichiers MIB, leur lecture est intéressante.
La suite dans un prochain article, c'est promis, on parlera des notifications SNMP.
Je tiens à remercier Nicolas Vallée pour son aide lors de la relecture technique ainsi que Claude Leloup et son œil acéré lors de la relecture orthographique de cet article.
Votre avis et vos suggestions sur cet article m'intéressent ! Alors après votre lecture, n'hésitez pas : 4 commentaires