Cet article est consacré aux fonctionnalités de surveillance des équipements réseau utilisant le protocole SNMPv3. Nous parlerons de SNMPv3, je partagerai mon expérience dans la création de modèles à part entière dans Zabbix et je montrerai ce qui peut être réalisé lors de l'organisation d'alertes distribuées dans un grand réseau. Le protocole SNMP est le principal lors de la surveillance des équipements réseau, et Zabbix est idéal pour surveiller un grand nombre d'objets et résumer de gros volumes de métriques entrantes.
Quelques mots sur SNMPv3
Commençons par le but du protocole SNMPv3 et les fonctionnalités de son utilisation. Les tâches de SNMP consistent à surveiller les périphériques réseau et à les gérer de base en leur envoyant des commandes simples (par exemple, activer et désactiver les interfaces réseau ou redémarrer le périphérique).
La principale différence entre le protocole SNMPv3 et ses versions précédentes réside dans les fonctions de sécurité classiques [1-3], à savoir :
- Authentification, qui détermine que la demande a été reçue d'une source fiable ;
- cryptage (Encryption), pour empêcher la divulgation des données transmises lorsqu'elles sont interceptées par des tiers ;
- l'intégrité, c'est-à-dire une garantie que le paquet n'a pas été altéré lors de la transmission.
SNMPv3 implique l'utilisation d'un modèle de sécurité dans lequel la stratégie d'authentification est définie pour un utilisateur donné et le groupe auquel il appartient (dans les versions précédentes de SNMP, la requête du serveur à l'objet de surveillance était comparée uniquement à « communauté », un texte chaîne avec un « mot de passe » transmis en texte clair (plain text)).
SNMPv3 introduit le concept de niveaux de sécurité - niveaux de sécurité acceptables qui déterminent 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 d'un paquet SNMP [4].
Le tableau décrit les combinaisons de modèles et de niveaux de sécurité SNMPv3 (j'ai décidé de laisser les trois premières colonnes telles que dans l'original) :
En conséquence, nous utiliserons SNMPv3 en mode d'authentification utilisant le cryptage.
Configuration de SNMPv3
La surveillance des équipements réseau nécessite la même configuration du protocole SNMPv3 sur le serveur de surveillance et sur l'objet surveillé.
Commençons par configurer un périphérique réseau Cisco, sa configuration minimale requise est la suivante (pour la configuration nous utilisons la 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 le droit d'accès du groupe snmpv3group pour visualiser certaines branches de l'arborescence MIB de l'objet de surveillance (snmpv3name puis dans le la configuration spécifie à quelles branches de l'arborescence MIB le groupe peut accéder (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 cryptage des (le mot de passe pour des est des56v3v3v3). Bien sûr, il est préférable d’utiliser aes plutôt que des ; je le donne ici à titre d’exemple. De plus, lors de la définition d'un utilisateur, vous pouvez ajouter une liste d'accès (ACL) qui régule les adresses IP des serveurs de surveillance qui ont le droit de surveiller cet appareil - c'est aussi la meilleure pratique, mais je ne compliquerai pas notre exemple.
La vue snmp-server de troisième ligne définit un nom de code qui spécifie les branches de l'arborescence 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'arborescence MIB de l'objet de surveillance.
Une configuration similaire pour les équipements Huawei (également dans la CLI) ressemble à ceci :
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 périphériques réseau, vous devez vérifier l'accès depuis le serveur de surveillance via le protocole SNMPv3, j'utiliserai 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 demander des objets OID spécifiques à l'aide de fichiers MIB est snmpget :
Passons maintenant à la configuration d'un élément de données typique pour SNMPv3, dans le modèle Zabbix. Pour plus de simplicité et d'indépendance 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 du modèle. Vous pouvez les définir dans un modèle, si tous les périphériques réseau de votre réseau ont les mêmes paramètres SNMPv3, ou dans un nœud de réseau, si les paramètres SNMPv3 des différents objets de surveillance sont différents :
Veuillez noter que le système de surveillance ne dispose que d'un nom d'utilisateur et de mots de passe pour l'authentification et le cryptage. Le groupe d'utilisateurs et la portée des objets MIB auxquels l'accès est autorisé sont spécifiés sur l'objet de surveillance.
Passons maintenant au remplissage du modèle.
Modèle de sondage Zabbix
Une règle simple lors de la création de modèles d’enquête est de les rendre aussi détaillés que possible :
J'accorde une grande attention à l'inventaire pour faciliter le travail avec un grand réseau. Nous en parlerons plus tard, mais pour l'instant – déclencheurs :
Pour faciliter la visualisation des déclencheurs, les macros système {HOST.CONN} sont incluses dans leurs noms afin que non seulement les noms des appareils, mais également les adresses IP soient affichés sur le tableau de bord dans la section d'alerte, bien que ce soit plus une question de commodité que de nécessité. . Pour déterminer si un périphérique est indisponible, en plus de la demande d'écho habituelle, j'utilise une vérification de l'indisponibilité de l'hôte via le protocole SNMP, lorsque l'objet est accessible via ICMP mais ne répond pas aux requêtes SNMP - cette situation est possible par exemple , lorsque les adresses IP sont dupliquées sur différents appareils, en raison de pare-feu mal configurés ou de paramètres SNMP incorrects sur les objets de surveillance. Si vous utilisez la vérification de la disponibilité de l'hôte uniquement via ICMP, au moment de l'enquête sur les incidents sur le réseau, les données de surveillance peuvent ne pas être disponibles, leur réception doit donc être surveillée.
Passons à la détection des interfaces réseau - pour les équipements réseau, il s'agit de la fonction de surveillance la plus importante. Puisqu'il peut y avoir des centaines d'interfaces sur un périphérique réseau, il est nécessaire de filtrer celles qui sont inutiles afin de ne pas encombrer la visualisation ou d'encombrer la base de données.
J'utilise la fonction de découverte SNMP standard, avec des paramètres plus 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]
Avec cette découverte, vous pouvez filtrer les interfaces réseau par leurs types, descriptions personnalisées et statuts des ports administratifs. Les filtres et expressions régulières pour le filtrage dans mon cas ressemblent à ceci :
Si elles sont détectées, les interfaces suivantes seront exclues :
- désactivé manuellement (adminstatus<>1), grâce à IFADMINSTATUS ;
- sans description textuelle, grâce à IFALIAS ;
- avoir le symbole * dans la description du texte, grâce à IFALIAS ;
- qui sont de service ou techniques, grâce à IFDESCR (dans mon cas, dans les expressions régulières IFALIAS et IFDESCR sont vérifiés par un seul alias d'expression régulière).
Le modèle de collecte de données à l'aide du protocole SNMPv3 est presque prêt. Nous ne nous attarderons pas plus en détail sur les prototypes d’éléments de données pour interfaces réseaux ; passons aux résultats.
Résultats du suivi
Pour commencer, faites l’inventaire d’un petit réseau :
Si vous préparez des modèles pour chaque série de périphériques réseau, vous pouvez obtenir une présentation facile à analyser des données récapitulatives sur les logiciels actuels, les numéros de série et la notification de l'arrivée d'un nettoyeur sur le serveur (en raison d'une faible disponibilité). Un extrait de ma liste de modèles est ci-dessous :
Et maintenant - le panneau de surveillance principal, avec des déclencheurs répartis par niveaux de gravité :
Grâce à une approche intégrée des modèles pour chaque modèle d'appareil du réseau, il est possible de garantir que, dans le cadre d'un système de surveillance, un outil de prévision des pannes et des accidents sera organisé (si des capteurs et des métriques appropriés sont disponibles). Zabbix est bien adapté à la surveillance des infrastructures de réseau, de serveur et de service, et la tâche de maintenance des équipements réseau démontre clairement ses capacités.
Liste des sources utilisées:1. Hucaby D. Guide de certification officiel du commutateur de routage et de commutation CCNP 300-115. Cisco Presse, 2014. p. 325-329.
2. RFC3410.
3. RFC3415.
4. Guide de configuration SNMP, Cisco IOS XE version 3SE. Chapitre : SNMP version 3.
Source: habr.com