Cet article traite des caractéristiques de la surveillance des équipements réseau à l'aide du protocole SNMPv3. Nous allons parler de SNMPv3, je partagerai mes expériences sur la création de modèles complets dans Zabbix et je montrerai ce qu'il est possible d'accomplir en organisant une alerte distribuée dans un grand réseau. Le protocole SNMP est essentiel pour la surveillance des équipements réseau, et Zabbix s'avère idéal pour surveiller un grand nombre d'objets et agréguer des volumes significatifs de métriques entrantes.
Quelques mots sur SNMPv3
Commençons par l'objectif du protocole SNMPv3 et les caractéristiques de son utilisation. Les fonctions de SNMP consistent à surveiller les dispositifs réseau et à gérer simplement ceux-ci en envoyant de simples commandes (par exemple, activer et désactiver des interfaces réseau, ou redémarrer un appareil).
La principale différence entre le protocole SNMPv3 et ses versions précédentes réside dans ses fonctions de sécurité classiques [1-3], à savoir :
- l'authentification (Authentication), qui détermine que la requête provient d'une source de confiance ;
- le chiffrement (Encryption), pour éviter la divulgation des données transmises si elles sont interceptées par des tiers ;
- l'intégrité (Integrity), c'est-à-dire la garantie que le paquet n'a pas été falsifié lors de la transmission.
SNMPv3 implique l'utilisation d'un modèle de sécurité, dans lequel la stratégie d'authentification est établie pour un utilisateur donné et le groupe auquel il appartient (dans les versions précédentes de SNMP, seule la « communauté », une chaîne de texte avec un « mot de passe », transmise en clair, était comparée dans la demande du serveur à l'objet de surveillance).
SNMPv3 introduit la notion de niveaux de sécurité — niveaux de sécurité acceptables qui définissent la configuration de l'équipement et le comportement de l'agent SNMP de l'objet de surveillance. La combinaison du modèle de sécurité et du niveau de sécurité détermine quel mécanisme de sécurité est utilisé lors du traitement du paquet SNMP [4].
Le tableau décrit les combinaisons de modèles et de niveaux de sécurité SNMPv3 (les trois premières colonnes ont été conservées comme dans l'original) :
Par conséquent, nous allons utiliser SNMPv3 en mode authentification avec chiffrement.
Configuration de SNMPv3
La surveillance des équipements réseau nécessite une configuration identique du protocole SNMPv3 à la fois sur le serveur de surveillance et sur l'objet surveillé.
Commençons par la configuration de l'appareil réseau Cisco, sa configuration minimale nécessaire est la suivante (pour la configuration, nous utilisons le CLI, j'ai simplifié les noms et mots de passe pour éviter toute confusion) :
snmp-server group snmpv3group v3 priv read snmpv3name
snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso includedLa première ligne snmp-server group définit le groupe d'utilisateurs SNMPv3 (snmpv3group), le mode de lecture (read) et les droits d'accès du groupe snmpv3group pour visualiser certaines branches de l'arbre MIB de l'objet surveillé (snmpv3name définit ensuite dans la configuration quelles branches de l'arbre MIB le groupe snmpv3group pourra accéder).
La deuxième ligne snmp-server user définit l'utilisateur snmpv3user, son appartenance au groupe snmpv3group, ainsi que l'utilisation de l'authentification md5 (le mot de passe pour md5 est md5v3v3v3) et du chiffrement des (le mot de passe pour des est des56v3v3v3). Évidemment, il est préférable d'utiliser aes au lieu de des, je l'inclus ici simplement à titre d'exemple. De plus, lors de la définition de l'utilisateur, vous pouvez ajouter une liste d'accès (ACL), régissant les adresses IP des serveurs de surveillance autorisés à surveiller cet appareil – cela fait également partie des meilleures pratiques, mais je ne vais pas compliquer notre exemple.
La troisième ligne snmp-server view définit le nom de code, qui spécifie les branches de l'arbre MIB snmpv3name, afin qu'elles puissent être interrogées par le groupe d'utilisateurs snmpv3group. ISO, au lieu de définir strictement une seule branche, permet au groupe d'utilisateurs snmpv3group d'accéder à tous les objets de l'arbre MIB de l'objet surveillé.
Une configuration similaire pour l'équipement Huawei (également via le CLI) est la suivante :
snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5
md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56
des56v3v3v3Après avoir configuré les appareils réseau, vous devez vérifier l'accès depuis le serveur de surveillance via le protocole SNMPv3, je vais utiliser snmpwalk :
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252 
Un outil plus visuel pour interroger des OID d'objets spécifiques, en utilisant des fichiers MIB – snmpget :
Passons maintenant à la configuration d'un élément de données standard pour SNMPv3 dans le cadre du modèle Zabbix. Pour plus de simplicité et d'indépendance des MIB, j'utilise des OID numériques :
J'utilise des macros personnalisées dans les champs clés, car elles seront les mêmes pour tous les éléments de données dans le modèle. Vous pouvez les définir au sein du modèle si tous les appareils de votre réseau ont des paramètres SNMPv3 identiques, ou au niveau du nœud réseau si les paramètres SNMPv3 pour différents objets de surveillance diffèrent :
Veuillez noter que le système de surveillance ne dispose que du nom d'utilisateur et des mots de passe pour l'authentification et le chiffrement. Le groupe d'utilisateurs et la portée des objets MIB auxquels l'accès est autorisé sont définis sur l'objet de surveillance.
Passons maintenant au remplissage du modèle.
Modèle de requête dans Zabbix
Une règle simple lors de la création de n'importe quel modèle de requête est de les rendre aussi détaillés que possible :
Je prête une grande attention à l'inventaire afin de faciliter la gestion d'un grand réseau. Nous en reparlerons un peu plus tard, mais pour l'instant, les déclencheurs :
Pour faciliter la visualisation des déclencheurs, j'ai intégré des macros système dans leurs noms {HOST.CONN}, afin que le tableau de bord dans la section d'alerte affiche non seulement les noms des appareils, mais aussi les adresses IP, même si cela relève davantage du confort que de la nécessité. Pour déterminer l'inaccessibilité d'un appareil, en plus de la requête echo habituelle, j'utilise un contrôle de l'inaccessibilité du nœud via le protocole SNMP, lorsque l'objet est accessible via ICMP mais ne répond pas aux requêtes SNMP – cette situation peut survenir, par exemple, en cas de duplication d'adresses IP sur différents appareils, en raison de pare-feu mal configurés, ou de paramètres SNMP incorrects sur les objets de surveillance. Si l'on se base uniquement sur le contrôle de l'accessibilité des nœuds par ICMP, en cas d'enquête sur des incidents réseau, les données de surveillance peuvent être absentes, il est donc nécessaire de contrôler leur arrivée.
Passons à la découverte des interfaces réseau – c'est la fonction de surveillance la plus importante pour le matériel réseau. Comme un appareil réseau peut avoir des centaines d'interfaces, il est nécessaire de filtrer celles qui ne sont pas pertinentes, afin d'éviter de surcharger la visualisation et d'encombrer la base de données.
J'utilise la fonction de découverte standard pour SNMP, avec un grand nombre de paramètres détectables, pour un filtrage plus flexible :
discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7] 
Lorsqu'une telle détection se produit, il est possible de filtrer les interfaces réseau en fonction de leurs types, descriptions utilisateur « description », et états administratifs des ports. Les filtres et expressions régulières pour le filtrage dans mon cas ressemblent à ceci :
Les interfaces suivantes seront exclues lors de la détection :
- manuellement désactivées (adminstatus<>1), grâce à IFADMINSTATUS ;
- sans description textuelle, grâce à IFALIAS ;
- ayant un caractère * dans la description textuelle, grâce à IFALIAS ;
- qui sont des services ou techniques, grâce à IFDESCR (dans mon cas, les expressions régulières IFALIAS et IFDESCR sont vérifiées par une seule expression régulière alias).
Le modèle pour collecter des données via le protocole SNMPv3 est presque prêt. Ne nous attardons pas sur les prototypes d'éléments de données pour les interfaces réseau, passons aux résultats.
Résultats de la surveillance
Pour commencer – l'inventaire d'un petit réseau :
Si l'on prépare des modèles pour chaque série d'appareils réseau – on peut obtenir une structure de données résumées facile à analyser concernant le logiciel actuel, les numéros de série, et l'alerte de l'arrivée d'un nettoyeur dans le serveur (en raison d'un faible Uptime). Voici un extrait de ma liste de modèles :
Et maintenant – le tableau de bord principal, avec des déclencheurs répartis par niveaux d'importance :
Grâce à une approche globale visant des modèles pour chaque modèle d'appareil dans le réseau, on peut faire en sorte que dans un même système de surveillance soit organisé un outil pour prédire les pannes et les urgences (sous réserve de capteurs et de métriques appropriés). Zabbix est bien adapté pour surveiller les infrastructures réseau, serveur et de services, et la gestion du matériel réseau démontre clairement ses capacités.
Liste des sources utilisées :1. Hucaby D. CCNP Routing and Switching SWITCH 300-115 Official Cert Guide. Cisco Press, 2014. p. 325-329.
2. RFC 3410.
3. RFC 3415.
4. SNMP Configuration Guide, Cisco IOS XE Release 3SE. Chapitre : SNMP Version 3.
Source : habr.com
