SNMP est un protocole très répandu pour la supervision, notamment pour les équipements réseaux sur lesquels il n’est généralement pas possible d’installer d’agent logiciel comme sur un serveur ou un poste de travail Windows / Linux classique.

La version 3 du protocole SNMP se différencie de ses premières versions en incluant de la sécurité : chiffrement des données, authentification, contrôle d’accès granulaire… Pour en savoir plus sur les différences entre SNMPv1/2 et SNMPv3 ou plus globalement sur le fonctionnement de ce protocole, je vous invite à lire l’article IT-Connect “SNMPv2c vs SNMPv3 : comparaison de la sécurité avec Wireshark” rédigé par Mattéo BEZET-TORRES qui est très complet sur le sujet.

Ce tutoriel s’appuie sur un serveur Zabbix déjà installé et un équipement compatible SNMPv3. Pour ma part, voici le lab déployé par ce tutoriel :

• Un serveur Zabbix sur une VM Rocky Linux.
• Un switch Cisco disposant de l’image « Cisco viosl2 » émulé grâce à une VM GNS3

Retrouvez notre guide d’introduction pour bien débuter avec Zabbix :

• Guide complet : installer et configurer un serveur Zabbix

Différences entre polling SNMP et traps SNMP

Il existe deux manières d’utiliser le protocole SNMP à savoir : le polling SNMP ou interrogation SNMP en français, et les traps SNMP également appelé pièges SNMP.

En mode polling, le gestionnaire SNMP (Zabbix) envoie des requêtes de manière périodique aux agents SNMP, sur le port 161 en UDP, pour interroger des OID spécifiques de leur MIB et l’agent SNMP lui répond avec les informations demandées.

Dans le cas des traps SNMP, c’est l’agent SNMP qui envoie un message au gestionnaire SNMP sans sollicitation, pour l’informer d’événements prédéfinis (dépassement d’un seuil, panne d’une interface, échec d’authentification…). Les traps SNMP sont envoyées sur le serveur sur le port 162 en UDP.

Les deux méthodes peuvent être utilisées ensemble afin de combiner leurs avantages. Grâce au polling, vous aurez une vue complète de l’état et des performances du système dans le temps et avec les traps, vous disposerez d’alertes en temps réel.

Configuration SNMPv3 de l’équipement réseau

Configuration globale

Nous allons commencer par activer et configurer le protocole SNMPv3 sur le switch Cisco. L’ordre de configuration n’a pas d’importance en soi, car la supervision ne sera effective qu’une fois la configuration SNMPv3 appliquée des deux côtés.

Toutefois, en pratique, c’est généralement le client SNMP qui détermine les paramètres à utiliser dans Zabbix, notamment les algorithmes d’authentification et de chiffrement lors de la création de l’hôte.

Important : même si votre équipement n’est pas un switch Cisco, je vous invite à lire cette partie et à l’adapter à votre équipement, car j’y explique les éléments de configuration nécessaires à SNMPv3.

Voici la liste des commandes pour un switch doté d’une image Cisco IOS. Les commandes peuvent changer en fonction du constructeur ou/et du modèle.

On passe en utilisateur privilégié puis en mode de configuration globale :

L’agent SNMP attribue des numéros d’index aux interfaces de l’équipement réseau afin de référencer les ports de façon unique dans les tables SNMP et permettre aux outils de supervision de bien monitorer toutes les interfaces indépendamment l’une de l’autre.

Pour rendre l’attribution des persistante malgré un redémarrage ou un changement de configuration, utilisez la commande suivante :

Nous allons maintenant créer une « vue SNMP » qui permet de définir le niveau de lecture de la MIB, c’est-à-dire un périmètre d’OID autorisés ou interdits pour l’accès SNMP.

La commande pour créer la vue SNMP est composée du nom de la vue “MIB-ReadOnly”, du paramètre qui représente l’OID racine et signifie que cet OID (et tout ce qu’il contient) est autorisé.

Il faut ensuite créer un groupe SNMP à l’aide de la commande qui permet de créer des groupes avec différents niveaux de sécurité. Les utilisateurs membres de ce groupe devront respecter le niveau de sécurité défini par le groupe, à savoir :

• Noauth : Aucune authentification requise et aucun chiffrement des paquets.
• Auth : Authentification requise (SHA/MD5) et aucun chiffrement des paquets.
• Priv : Authentification requise (SHA/MD5) et chiffrement des paquets (DES, 3DES, AES-128, AES-192, AES-256).

En production, il est fortement recommandé de choisir le niveau de sécurité , sinon tous les paquets SNMP circuleront en clair sur le réseau.

Dans mon cas, le groupe se nomme . On précise également que l’on souhaite utiliser SNMP dans sa version 3 et le niveau d’authentification pour tous les utilisateurs du groupe.

Il faut ensuite créer un utilisateur en le plaçant dans le groupe précédemment créé. On lui définit également un mot de passe pour s’authentifier auprès de l’agent SNMP et une clé de chiffrement pour chiffrer les échanges SNMP conformément au niveau de sécurité « private » (authentification + chiffrement).

Pour l’authentification, mon image Cisco propose les algorithmes de hachage suivants pour générer le hash du mot de passe : MD5 (Message Digest 5) ou SHA1 (Secure Hash Algorithm), les deux couplés à HMAC. MD5 étant complètement obsolète, il est préférable d’utiliser SHA-1.

Remarque : SHA-1 est aussi un algorithme déprécié, les standards d’aujourd’hui portant plutôt sur SHA256/384/512. Utilisez-les si vous en avez la possibilité !

Concernant l’algorithme de chiffrement, mon image Cisco m’offre le choix de la famille DES : DES et 3DES et AES : AES-128, AES-192, AES-256. La famille DES étant dépréciée, je me suis orientée sur l’algorithme AES. Concernant la longueur de la clé AES (128, 192 ou 256 bits), le choix dépendra du niveau de sécurité que vous souhaitez.

Toutefois, plus la clé sera longue, plus les performances de l’équipement seront impactées, tout en sachant qu’une clé AES-128 s’avère résistante à la majorité des attaques (à l’heure où j’écris ces lignes évidemment).

La commande ci-dessous va donc créer l’utilisateur Zabbix, en l’ajoutant au groupe , son mot de passe sera hashé par l’algorithme HMAC-SHA1 et les paquets seront chiffrés à l’aide d’une clé de longueur 128 bits AES.

Si des ACL sont configurées (ce qui n’est pas le cas par défaut), autorisez le serveur à l’aide de la commande suivante. Cette commande est optionnelle si vous ne souhaitez faire que de la supervision par traps SNMP.

Enfin, enregistrez votre configuration :

L’équipement est prêt à être supervisé, du moins via le mode polling. Si vous ne souhaitez pas utiliser les traps SNMP, allez à la partie “Configuration du polling SNMPv3 dans Zabbix“.

Configuration spécifique aux Traps

Sur la plupart des équipements prenant en charge du SNMP, il est possible de définir les types d’alertes à envoyer via des traps au serveur SNMP : changement de configuration, échec de connexion, changement d’état…

Dans l’environnement Cisco, il existe beaucoup de types d’alertes possibles que vous pouvez consulter avec la commande :

Il est recommandé de ne pas activer l’envoi de toutes les traps et d’effectuer un tri sur les éléments utiles à votre monitoring et à votre contexte pour éviter de tuer votre supervision avec des remontées superflues.

Dans le cadre de ce tutoriel, je vais seulement activer les traps de Cisco. Si vous souhaitez tout activer, retirez le à la fin de la commande.

Avec ma configuration, les événements suivants seront envoyés au serveur :

Nom	Description
authentication	Mauvaise tentative de connexion SNMP
coldstart	Redémarrage complet
warmstart	Redémarrage du processus SNMP
linkdown	Interface down
linkup	Interface up

On va ensuite définir l’IP du serveur Zabbix et le compte à utiliser pour envoyer les informations SNMP au serveur Zabbix.

Le paramétrage est fini du côté du switch, n’oubliez pas d’enregistrer la configuration avec .

Configuration du polling SNMPv3 dans Zabbix

Ajout d’un modèle

Pour rappel, un modèle, également appelé « template », permet d’indiquer au serveur Zabbix les éléments à monitorer sur un hôte et à quelle fréquence. En effet, tous les équipements sont différents et les informations remontées par SNMP dépendront directement de la MIB.

Zabbix fournit de nombreux modèles adaptés en fonction du type d’équipements et de la technologie de supervision voulue (agent, SNMP, http…). Pour trouver le modèle qui pourrait vous correspondre, allez dans « Collecte de données » puis « Modèles » et dans le champ « Groupes de modèles », cliquez sur « Sélectionner » :

Vous retrouverez tous les modèles concernant des applications, des systèmes d’exploitation, des bases de données, des équipements réseaux ou encore des serveurs physiques.

Choisissez le groupe de modèles correspondant à votre équipement à superviser, ici, il s’agit d’un équipement réseau.

Puis dans « Nom », tapez le nom du fabricant et faites « Appliquer ». Une liste de modèles devrait apparaître.

Pour vous aider dans votre choix, il y a trois possibilités :

• Un modèle existe avec la référence exacte de votre équipement, typiquement dans l’exemple ci-dessus, on a « Cisco Catalyst 3750v2-48P ». C’est en théorie la meilleure situation, car en principe, les éléments présents dans le modèle correspondent exactement à la MIB de votre équipement.

• Un modèle dit « générique » existe comme « Cisco IOS by SNMP ». Avec ce modèle, les informations remontées seront communes aux équipements Cisco disposant d’une image IOS. Dans ce cas, la plupart des éléments devraient remonter, mais certains ne seront pas forcément disponibles.

• Aucun modèle n’existe ou les modèles ne vous conviennent pas : dans ce cas, il faudra utiliser un utilitaire comme « mib2zabbix » pour convertir la MIB fournie par votre fournisseur en modèle compatible avec Zabbix pour superviser votre équipement.

Vous pouvez regarder les éléments supervisés par un modèle, en cliquant sur le bouton « éléments ». Pour le modèle Cisco IOS by SNMP, il y a vingt-trois éléments supervisés associés à trois déclencheurs permettant de récupérer des informations d’identification, des métriques réseaux (débit, % de ping perdus…) et de disponibilité du système. Des déclencheurs sont également présents par défaut.

Il est possible de désactiver des éléments si vous ne souhaitez pas les monitorer ou si des modules ne sont pas actifs en cliquant sur le bouton vert « Activé » :

Pour les déclencheurs, vous pouvez procéder de la même manière en cliquant sur « Modèles » pour revenir à la page d’avant, puis cette fois, cliquez sur le bouton « Déclencheurs » :

Vous pouvez ensuite voir les déclencheurs configurés dans le modèle pour les activer et les désactiver, adapter la criticité ou encore en créer d’autres adaptés à vos besoins et vos envies en termes de supervision.

Configuration des macros SNMP

On peut définir une macro comme étant une variable stockant une valeur. Il est possible de paramétrer des macros à plusieurs échelles : uniquement pour un hôte spécifique, pour un modèle afin que tous les hôtes de ce modèle héritent des macros ou même au niveau global dans Zabbix. Je vous propose de configurer des macros globales pour les identifiants SNMP afin de mieux comprendre le concept.

Allez dans l’onglet « Administration » puis « Macros ».

Cliquez sur « Ajouter ». Dans le nom de la macro, renseignez , puis le nom d’utilisateur renseigné dans votre équipement. Faites de même pour le mot de passe d’authentification (SHA) de votre utilisateur et pour la clé de chiffrement (AES) :

Cependant, les informations sont en clair, ce qui n’est vraiment pas optimal en termes de sécurité. Cliquez sur l’icône « T » et choisissez « Texte secret » (ou coffre secret si vous en disposez un).

Cette action anonymisera le contenu de la macro du côté de l’interface WEB et côté base de données également.

Cliquez sur « Actualiser ». À partir de ce moment-là, il ne sera plus possible de voir la valeur de vos macros, même en passant de « Texte secret » à « Texte » :

Nous pouvons donc maintenant utiliser ces macros dans Zabbix afin de configurer nos hôtes et nos paramètres sans devoir renseigner les identifiants en clair.

Création de l’hôte

Il est temps de créer l’équipementSNMP dans Zabbix pour tester la bonne connectivité SNMP. Allez dans « Collecte de données » puis « Hôtes » et cliquez sur « Créer un hôte » :

Remplissez les informations suivantes :

• Nom de l’hôte
• Le ou les modèle(s) à associer
• Un ou plusieurs groupes d’hôtes

Cliquez ensuite sur « Ajouter » dans l’onglet « Interface » et choisissez « SNMP ». Renseignez ensuite les informations suivantes :

• Version SNMP : SNMPv3
• Nom de la sécurité : ce n’est pas un paramètre explicite, mais il s’agit de votre utilisateur. Utilisez la macro paramétrée dans la partie précédente .
• Niveau de sécurité : authPriv
• Protocole d’authentification : il s’agit de l’algorithme de hachage utilisé, pour ma part, il s’agissait de SHA1.
• Phrase d’authentification : correspond au mot de passe de l’utilisateur Zabbix, utilisez la macro .
• Protocole de confidentialité : il s’agit du protocole de chiffrement. Pour ma part, il s’agissait de AES128.
• Phrase de passe de confidentialité : ce paramètre correspond à la clé de chiffrement, utilisez également la macro paramétrée .

Cliquez ensuite sur « Ajouter » et allez dans « Surveillance » puis « Hôtes ». Patientez quelques minutes, des données devraient commencer à apparaître en cliquant sur « Dernières données ».

On remarque que des données sont bien remontées et elles sont triées par tag, notamment pour les interfaces.

Toutefois, on peut observer des éléments « non supportés » accompagnés par un ! rouge.

Si l’on passe la souris sur les éléments non supportés, on remarque un message d’erreur. Typiquement pour les éléments « Hardware model name » et « Hardware serial number », il n’y a pas de valeur inscrite dans ces OID. Ce qui est plutôt logique, car j’émule une image de Cisco IOS sur GNS3.

Certains éléments peuvent ne pas être supportés ou non présents dans la MIB de l’équipement, notamment si vos éléments sont issus d’un template générique comme c’est le cas ici.

Remarque : Si l’erreur survient, cliquez sur le nom de l’élément puis sur « Exécuter maintenant ». Il s’agit en général d’un bug de synchronisation.

Afficher le contenu de la MIB SNMP

Si vous souhaitez vérifier ou voir les éléments contenus dans la MIB de votre équipement, vous pouvez utiliser les commandes et en installant le paquet sur le serveur Zabbix.

Concrètement, permet de récupérer la valeur d’un OID et permet de parcourir toute une branche d’OID et renvoie les valeurs en dessous.

Exemple avec snmpget :

On obtient bien une seule valeur, à savoir le modèle du switch.

Exemple avec snmpwalk :

On obtient une série de valeurs dont le nom d’hôte dont l’OID se trouve en dessous de .

N’hésitez pas à vous en servir, ils pourront grandement vous aider sur les problématiques SNMP.

Une fois que vous avez identifié les éléments qui ne sont pas supportés ou qui ne vous intéressent pas, faites le ménage sur le modèle et sur l’hôte en les désactivant.

Découverte automatique

Cette partie est optionnelle, cependant elle me semble importante dans un objectif d’automatisation. Si vous ne disposez que de quelques hôtes, les créer manuellement ne pose pas vraiment de problème en soi, mais sur le long terme, ce serait une perte de temps non négligeable.

La découverte automatique permet de découvrir des hôtes dans le réseau pour ensuite les intégrer automatiquement dans Zabbix avec des règles spécifiques. L’objectif est assez simple et va consister à créer les hôtes dans Zabbix en y ajoutant des groupes et les paramètres SNMP associés de manière automatique.

Allez dans « Collecte de données » puis « Découverte » puis cliquez sur « Créer une règle de découverte ».

Renseignez un nom et la plage d’adresses IP à laquelle va s’appliquer votre règle.

Dans l’onglet « Vérifications », cliquez sur « Ajouter » puis pour le type, mettez « agent SNMPv3 ».

Une fenêtre va alors apparaître avec différentes informations à remplir :

• Port : laissez 161, le port par défaut.
• OID SNMP : Il s’agit de l’OID présent dans la MIB que Zabbix va interroger pour pouvoir identifier le nom d’hôte. Pour connaître le numéro de l’OID, allez dans les éléments de votre modèle et cherchez ceux qui permettent d’identifier le nom et l’OS.

Cliquez ensuite sur l’élément et copiez-collez la valeur trouvée (sans le get et les crochets) :

Renseignez ensuite les champs en fonction de votre configuration et l’OID SNMP trouvé.

Le résultat devrait être similaire à la capture ci-dessous :

Configurez ensuite une deuxième vérification du type « agent SNMPv3 » pour avoir le nom du système d’exploitation (pensez à remplacer l’OID).

Laissez le critère d’unicité de l’équipement à « Adresse IP » et changez le nom de l’hôte par l’OID permettant de récupérer le nom d’hôte de l’équipement. Décochez la case « Activé », puis cliquez sur « Ajouter » :

Avant d’activer la règle de découverte, nous allons paramétrer des actions de découverte afin de lier automatiquement les hôtes à un modèle et un groupe d’hôtes.

Dans l’onglet « Alertes », cliquez sur « Actions » puis « Actions de découverte » :

Cliquez, en haut à droite, sur « Créer une action ».

Dans l’onglet « Actions », il faut configurer les conditions nécessaires pour identifier l’équipement Cisco. J’ai paramétré deux conditions qui devront être remplies pour identifier l’équipement Cisco, les voici :

Je vous invite à explorer les différentes conditions existantes, elles pourraient être très pertinentes selon votre contexte. Par exemple, la condition « IP hôte » permet de spécifier une plage d’adresses IP à laquelle appartient votre hôte, donc si votre réseau est segmenté par typologie d’équipements, c’est un gros plus pour la découverte automatique.

Dans l’onglet « Opérations », définissez les actions à effectuer. Par exemple, si mes conditions sont validées : l’hôte est créé dans Zabbix puis lié au modèle « Cisco IOS by SNMP » et ajouté aux groupes : « PROD, Équipement réseau et Cisco ».

Retournez « Collecte de données » et « Découverte » pour activer votre règle de découverte.

Remarque : j’ai supprimé mon hôte « S1 » créé manuellement dans la partie précédente pour valider le fonctionnement de la découverte automatique.

La création de votre hôte ne devrait pas tarder, car la règle de découverte s’active dès que la règle est activée. Vous pouvez surveiller que la découverte fonctionne en allant dans « Surveillance » et « Découverte » :

Allez ensuite dans « Collecte de données » puis « Hôtes ». L’hôte devrait apparaître avec son nom d’hôte et son modèle.

Configuration des traps SNMPv3 dans Zabbix

Dans le cas où vous souhaitez superviser vos équipements uniquement via des traps SNMP, il faut que vos hôtes soient déjà créés avec une interface disposant d’une IP. En effet, lorsque Zabbix va recevoir une trap, il va l’associer à une IP et si cette IP n’est pas présente, la trap sera rejetée.

Snmptrapd

Comme vu en introduction, lorsqu’une trap est envoyée au serveur Zabbix, l’équipement l’envoie en UDP sur le port 162. Cela signifie que dans un premier temps, ce n’est pas Zabbix qui va recevoir la trap, mais le système d’exploitation du serveur Zabbix.

Sur Linux, c’est le daemon qui va se charger de recevoir la trap et de la renvoyer dans un fichier de log via un trap handler.

Un trap handler est un programme ou script exécuté automatiquement lorsqu’une trap SNMP est reçue. Zabbix fournit un script Bash et un script Perl dans ses dépôts pour jouer le rôle de trap handler, toutefois le mieux serait d’implémenter SNMPTT qui est capable de traduire les OID via les MIB.

Pour mieux illustrer le concept, voici le résultat d’une trap reçue par Zabbix avec un script Bash :

Et un format de trap possible reçu par Zabbix via SNMPTT :

Pour ma part et pour limiter la complexité du tutoriel, je suis parti sur un script Bash fourni dans les dépôts de Zabbix.

Pour résumer, voici un petit schéma qui explique le fonctionnement des traps SNMP dans Zabbix :

Avant d’installer le daemon, il faut ouvrir le port 162 en UDP sur le serveur :

Pour les distributions basées sur Red Hat, voici les commandes :

Pour les distributions basées sur Debian, voici les commandes :

Vous pouvez maintenant installer le paquet avec la commande suivante pour Red Hat :

Ou Debian :

Démarrez-le avec  tout en activant le démarrage automatique au passage :

Trap-Handler et snmptrapd.conf

Il nous faut maintenant récupérer le trap handler (script Bash) fourni par Zabbix dans leur dépôt pour écrire la trap reçue dans un fichier de logs. Utilisez la commande curl pour récupérer le fichier :

On rend le script exécutable en ajoutant le droit d’exécution à l’utilisateur et au groupe (root par défaut et qui exécute le service snmptrapd) :

Concernant le répertoire qui accueillera les logs, j’ai créé le chemin présent dans la documentation de Zabbix dans lequel sera hébergé le fichier . Il est également possible (et logique) de placer votre répertoire sous , si vous le souhaitez.

Créez donc le répertoire à l’emplacement de votre choix et donnez les droits en lecture seule et d’exécution à Zabbix :

Pas d’inquiétude concernant les droits, snmptrapd est en principe exécuté en tant que root donc il pourra écrire dans le fichier. L’utilisateur et le groupe Zabbix n’ont besoin que de consulter le fichier de log. Toutefois, si l’utilisateur qui exécute snmptrapd n’est pas root, il faudra donner les droits de lecture/écriture/exécution à l’utilisateur snmp et des droits en lecture/exécution à l’utilisateur Zabbix.

Modifiez ensuite la variable dans le script pour y mettre le chemin du fichier de log.

Nous allons ensuite modifier le fichier pour indiquer à snmptrapd d’exécuter notre script Bash lorsqu’une trap est reçue.

Ajoutez les lignes suivantes ci-dessous :

• La première ligne configure snmptrapd afin qu’il exécute le script spécifié lors de la réception d’une trap.
• La deuxième ligne crée un utilisateur SNMPv3 avec son engineID, ses paramètres d’authentification et de chiffrement.
• La troisième ligne autorise cet utilisateur SNMPv3 à écrire dans les logs et à déclencher l’exécution du script trap_handle.

L’engineID est un identifiant unique utilisé par SNMPv3 pour identifier un équipement. Snmptrapd l’utilise pour identifier la source réelle du trap. Il doit être précédé de dans le fichier de configuration pour indiquer qu’il s’agit d’un identifiant en hexadécimal.

Pour le récupérer, voici deux options :

• Une commande est incluse sur votre équipement, ici la commande Cisco permettant de le trouver.

• Utilisez la commande sur l’OID . Il s’agit d’un OID standard de SNMP donc la valeur de l’ se trouve toujours sur cet emplacement.

En utilisant cette méthode, la sécurité est optimale car seuls les équipements explicitement autorisés pourront remonter des traps au serveur. Cependant, cela signifie qu’il faudra, pour chaque équipement, créer un nouvel utilisateur avec même si le nom d’utilisateur et le mot de passe sont communs à tous vos équipements.

Pour éviter que les logs s’accumulent au fil du temps et provoquent la saturation de votre stockage, nous allons créer un fichier nommé snmptraps pour définir des règles de rétention dans le répertoire .

Logrotate est une tâche planifiée qui s’appuie sur cron pour exécuter des tâches de rotation de logs de manière automatisée et régulière.

Le contenu du fichier est le suivant :

• Le fichier auquel les paramètres suivants seront appliqués.
• Weekly permet de faire une rotation une fois par semaine.
• Rotate 12 garde 12 semaines d’historiques.
• Compress permet de compresser au format gzip les anciens logs.
• Delaycompress ne compresse pas le dernier fichier, il sera compressé au prochain cycle.
• Missingok ne provoque pas d’erreur si le fichier n’existe pas.
• Notifempty ne déclenche pas de rotation si le fichier est vide.

Redémarrez le daemon snmptrapd pour appliquer l’ensemble des modifications :

Vérification de la réception des traps

Il nous reste une dernière étape avant de pouvoir effectuer la vérification.

Allez dans le fichier , recherchez la variable StartSNMPTrapper, mettez la valeur à “1” puis rajoutez le chemin de votre fichier de log à la variable SNMPTrapperFile.

Puis redémarrez le service :

Testons notre configuration pour vérifier qu’elle est fonctionnelle. Nous allons envoyer une trap SNMP fictive et vérifier qu’elle apparaît bien dans le fichier de log (adaptez l’OID en fonction de votre équipement) :

Si votre configuration est bonne, une trap doit apparaitre dans le fichier de log.

Pour tester que la réception de la trap fonctionne depuis un équipement extérieur, testez depuis votre équipement un événement qui déclenche l’envoi d’une trap SNMP et surveillez avec la commande tcpdump suivante sur le port 162 si des paquets sont transmis :

Dans mon cas, un lien down qui passe en up va générer un événement.

J’ai donc tapé les commandes suivantes sur le switch Cisco :

Puis j’ai branché un autre switch allumé à mon switch Cisco :

La trap a bien été réceptionnée sur le serveur :

Et a bien été écrit dans mon fichier de log :

Configuration d’une trap SNMP dans Zabbix

Allez dans « Collecte de données », « Hôtes », cliquez sur « éléments » sur votre équipement réseau puis « Créer un élément » en haut à droite  :

Dans Zabbix, il existe deux types de traps que nous pouvons créer dans les éléments :

•  : Cet élément permet de capturer uniquement les traps SNMP qui correspondent à une expression régulière (regexp).
•  : Cet élément sert à capturer toutes les traps SNMP qui n’ont été capturées par aucun autre élément snmptrap[regexp]. Il agit comme un mécanisme de récupération (fallback) permettant de ne perdre aucune trap.

On définit des expressions régulières dans snmptrap[regexp] pour filtrer et classer les traps SNMP selon le type d’événement. Par exemple, l’élément , dont est l’expression régulière, va permettre de récupérer les traps contenant : .

Cette méthode simplifie la lisibilité et la gestion des déclencheurs, car les traps sont filtrées par type d’événement. Cependant, la mise en place peut être plus ou moins lourde, dans le sens où il faudra créer un élément par trap que vous souhaitez superviser.

Nous allons donc dans un premier temps créer l’élément fallback pour observer les traps reçues. Par chance, mon modèle Cisco IOS by SNMP (lié à l’hôte lors de la configuration du polling) inclut déjà l’élément. Vous pouvez donc vous en inspirer pour créer le vôtre sur l’hôte :

Allez ensuite dans « Surveillances » et « Dernières données ». Filtrez par votre hôte puis dans « Nom », renseignez le nom de votre élément :

Cliquez sur le bouton « Historique » de votre élément, vous devriez voir vos traps.

J’ai généré différents événements pour que vous puissiez voir les messages reçus dans le fallback. Ce sont les mêmes messages reçus que dans les logs snmptrapd.

Nous allons récupérer les expressions se trouvant juste derrière pour faire nos éléments .

Création d’un modèle pour le traps SNMP

Je vous propose de créer un modèle spécifique pour les traps SNMP de vos équipements, qui contiendra nos éléments. De cette manière, vous pourrez appliquer ce modèle à vos hôtes pour qu’ils héritent automatiquement des éléments et des déclencheurs créés.

Allez dans « Collecte de données », « Modèles », et « Créer un modèle ». Donnez-lui un nom et attachez-lui un « Groupes de modèles ».

Sélectionnez votre modèle et cliquez sur « Éléments » puis « Créer un élément ». Vous pouvez ensuite créer vos éléments en fonction des expressions observées dans le snmp.fallback en choisissant comme type « Trap SNMP » et comme clé snmptrap[votreregex].

Pour construire vos expressions régulières, vous pouvez vous tourner vers la documentation si besoin.

Voici un exemple :

Créez ensuite vos éléments en fonction de votre contexte, sans oublier la .

Liez votre modèle à votre hôte.

Vos traps devraient ensuite arriver dans vos éléments précédemment créés :

Remarque : Si vous avez suivi la partie « Découverte automatique » pour configurer le polling SNMP, vous pouvez ajouter le modèle nouvellement créé à vos hôtes en ajoutant une opération dans les actions de déclencheurs.

Au niveau du modèle, vous pouvez créer des déclencheurs pour créer automatiquement un problème dans Zabbix. Nous avons vu la création d’un déclencheur dans le tutoriel de présentation de la solution Zabbix, cependant, je vous propose de créer deux déclencheurs très simples avec la fonction .

Ces déclencheurs seront à adapter selon vos besoins, vos contextes et vos envies en termes de supervision. Il vous faudra sûrement vous armer de patience et de documentation.

Si des déclencheurs sont paramétrés sur votre modèle de polling SNMP et que vous souhaitez utiliser les traps, il faudra faire un ménage en désactivant les déclencheurs en commun sur les modèles pour éviter des doublons.

Les deux déclencheurs que je vais créer vont :

• Créer un problème avec une sévérité « Haute » lorsqu’une interface est devenue DOWN.
• Créer un problème avec une sévérité « Information » lorsqu’une interface est devenue UP.

Dans « Collecte de données », « Modèles », choisissez votre modèle, cliquez sur « Déclencheurs » puis « Créer un déclencheur ».

Plusieurs paramètres vont être importants :

• Nom de l’événement : Le but est que le nom dispose des informations pertinentes, à savoir : le problème en lui-même, l’interface concernée et l’hôte. Le problème est facilement descriptible, « Interface réseau DOWN » est un exemple et le nom d’hôte peut être affiché par la variable . Pour trouver le nom de l’interface, il faut extraire l’information directement depuis la trap envoyée :

• Il faut donc récupérer les chaînes de caractères se trouvant derrière . Nous pouvons utiliser la valeur de l’élément avec la fonction , qui permet, à l’aide d’une expression régulière, de remplacer une partie du contenu par une chaîne définie.

Si l’on décompose l’expression de , nous avons :

• n’importe quel texte
• cherche la présence de la chaîne exacte “”
• ignore ce qu’il y a entre et
• le signe égal
• capture tout ce qui suit
• ignore la suite
• renvoie le résultat

Ce qui nous donne :

• Expression : Il s’agit du cœur de votre déclencheur, c’est ce paramètre qui va permettre de créer votre problème. Les traps étant sous forme de texte, nous pouvons utiliser la fonction qui permet de chercher une chaîne de caractères dans la valeur d’un élément comme une trap « linkDown » par exemple. La fonction est assez simple d’utilisation et consiste à donner l’élément dans lequel vous cherchez l’information, un opérateur comme et la valeur que vous recherchez. Le =1 permet de spécifier que la condition doit être vraie.

• Mode de génération des événements PROBLEME : doit être mis sur « MULTIPLE », comme nous n’avons qu’un seul élément et non pas un élément par interface, il est nécessaire d’activer cette option. Sinon lorsqu’une interface sera DOWN, aucun autre problème ne sera créé tant que le premier n’est pas résolu. L’inconvénient est qu’il peut y avoir des doublons, notamment si les traps sont réémises (lors d’un redémarrage par exemple).

Vous pouvez également définir une expression de récupération pour fermer le problème automatiquement ou autoriser la fermeture manuelle du problème.

Globalement, votre déclencheur pourrait ressembler à cela :

J’ai ensuite cloné mon déclencheur en adaptant mes expressions pour générer un problème quand une interface devenait UP.

Voici le résultat lorsqu’une interface du switch est désactivée :

Le problème se déclenche correctement.

Et lorsqu’elle est réactivée :

Conclusion

Grâce à ce tutoriel, nous avons vu ensemble le fonctionnement et la configuration de la supervision SNMPv3 dans Zabbix.

Évidemment, ce tutoriel ne couvre pas (et ne peut pas couvrir) toutes les possibilités et vos besoins en supervision. Mon but était surtout de vous montrer les concepts de base et de vous armer au mieux pour superviser vos équipements compatibles SNMP en toute sécurité avec la version 3.

N’hésitez pas à laisser votre avis en commentaire de l’article et je vous remercie pour votre lecture.