Bonjour,
La lecture des valeurs SNMP des différents appareils réseaux est une grande source d'informations. Mais les évolutions sécuritaires de nos systèmes imposent 2 axes:
- le cryptage des informations => SNMPV3
- une lecture étendue à tous les appareils => risque de charge serveur et réseau.
Concernant le SNMPV3, pas grand chose a dire; la norme est là, reconnue, implémentée dans beaucoup d'appareils... même si je trouve que les degrés de cryptage utilisées sont faibles, c'est toujours mieux que de l'info en clair. Et bien évidemment, PAS D'ACCES SNMP EN ECRITURE!
Concernant la charge de nos réseaux, la multiplication des mesures risquent d'augmenter significativement la charge, et une charge importante entraine des difficultés côté serveur ( c'est le + facile a contourner...) mais surtout, cela risque d'augmenter le 'bruit de nos mesures sur nos réseaux, ce qui n'est pas idéal... le but est de mesurer, pas de perturber nos réseaux.
Une méthode permettant de diminuer fortement l'empreinte de nos mesures est de passer par une logique inversée... ce n'est plus notre serveur qui cherche tous les x temps les informations sur un hôte, mais l'hôte qui pousse les informations vers le serveur... et cela apporte deux gros avantages:
1°) l'hôte ne transmets que les informations changeantes=> plus de mesures inutiles....donc chute du trafic
2°) plus de risque de louper une info par faute d'un intervalle de collecte pas assez resserré (cf théorème de Nyquist-Shannon); l'hôte détecte un changement et le notifie, indépendamment d'une fréquence de mesure.
J'ai donc voulu implémenter le snmptrap sur mon serveur centos8 et son zabbix 4.4.6... je ne pensais pas que ce serait si difficile!
Première lecture: 2 manières de faire; par snmptt ou par script perl de zabbix... lequel choisir????
J'ai essayé celle qui semblait le plus logique...snmptt... oui mais il n'y a plus de contributions depuis 2013.... j'ai donc préféré éviter de passer par le snmptt.
Cela devra donc passer par snmptrapd et le script perl de zabbix....
Oups! les packages centos8 avec le snmptrapd ne semblent pas implémentés.... il a fallu chercher pour trouver des packages. Pour les obtenir, il faut installer les net-snmp, net-snmp-agent-libs, net-snmp-libs,net-snmp-perl et net-snmp-utils... j'en ai trouvé des fonctionnels en 5.8-7.el8.2.x86_64
Une fois snmptrapd installé, il faut configurer le snmptrapd.conf.... et là, on lit la doc... c'est tout un monde!
Concernant le snmpV3, il faut trouver les bons types de codage (2 mots de passe qui sont souvent le même en fait sur certains switchs un peu vieillots...), et on nous parle d'un engineid... mais sans nous informer de comment l'acquérir...
Bon, les essais donnent la chose suivante: sans engineid, la conf passe... mais en fait rien ne remonte! => Il FAUT intégrer l'engineID....
Il faut donc déclarer chaque mode de connexion pour chaque élément qui va envoyer des trap, a l'aide de createUser -e <engineID> <Utilisateur> <Mode de cryptage> <mdpasse> <Mode de cryptage> <mdpasse> pffff!
Mais comment récupérer l'engineID de chaque élément? J'ai cherché... je suis même passé par un tcpdump de 2 jours pour intercepter les communications. Une fois ouverts dans un wireshark, on peut récupérer les engineid...
Mais si le matériel ne communique pas sur la période?
J'ai toute une pile de switchs alcatels a surveiller, et impossible de trouver l'engineid dessus... jusqu'à ce que je finisse par tomber sur un oid permettant de retourner l'engineid... apparemment, c'est du générique, donc cela devrait fonctionner sur beaucoup de matériels réseau: 1.3.6.1.6.3.10.2.1.1.0
Depuis mon linux, il me suffit donc de faire un snmpget -v 3 -u <user> -l authptiv -a <Crypt1> -A <MDP1> -x <Crypt2> -X <MDP2> <ip matériel> 1.3.6.1.6.3.10.2.1.1.0 pour que le matériel nous renvoie son engineID
Une fois ceci fait... il faut ajouter une ligne par élément à surveiller,dans snmptrapd.conf, comme décrit précédemment: createUser -e <engineID> <Utilisateur> <Mode de cryptage> <mdpasse> <Mode de cryptage> <mdpasse>
Pour la fin de snmptrapd.conf, lire les recommandations d'install fournies dans zabbix ( perl do "/usr/bin/zabbix_trap_receiver.pl", récup du fichier zabbix_trap_receiver.pl depuis les sources de zabbix, création du fichier /tmp/zabbix_traps.tmp et surtout la création du fichier manuellement car le process ne sait apparemment pas le créer tout seul...)
Une fois cela mis en place, vérifier que le fichier zabbix_traps.tmp se remplit bien des différents snmptrap envoyés...
Voilà, j'en suis là, je sais qu'il me reste à trouver les fichiers de définitions des OIDs pour que le trap consigné soit plus lisible, et mettre en place la lecture du fichier dans zabbix pour que les traps soient injectés régulièrement dans les hôtes concernés... et donc, après, revoir les templates pour me reposer plus sur les données qui remontent et limiter ainsi le trafic.
Je n'aurais jamais cru que passer du snmp au snmptrap puisse engendrer un tel travail, mais je sens que le jeu en vaut la chandelle....en espérant que cela serve a d'autres...
La lecture des valeurs SNMP des différents appareils réseaux est une grande source d'informations. Mais les évolutions sécuritaires de nos systèmes imposent 2 axes:
- le cryptage des informations => SNMPV3
- une lecture étendue à tous les appareils => risque de charge serveur et réseau.
Concernant le SNMPV3, pas grand chose a dire; la norme est là, reconnue, implémentée dans beaucoup d'appareils... même si je trouve que les degrés de cryptage utilisées sont faibles, c'est toujours mieux que de l'info en clair. Et bien évidemment, PAS D'ACCES SNMP EN ECRITURE!
Concernant la charge de nos réseaux, la multiplication des mesures risquent d'augmenter significativement la charge, et une charge importante entraine des difficultés côté serveur ( c'est le + facile a contourner...) mais surtout, cela risque d'augmenter le 'bruit de nos mesures sur nos réseaux, ce qui n'est pas idéal... le but est de mesurer, pas de perturber nos réseaux.
Une méthode permettant de diminuer fortement l'empreinte de nos mesures est de passer par une logique inversée... ce n'est plus notre serveur qui cherche tous les x temps les informations sur un hôte, mais l'hôte qui pousse les informations vers le serveur... et cela apporte deux gros avantages:
1°) l'hôte ne transmets que les informations changeantes=> plus de mesures inutiles....donc chute du trafic
2°) plus de risque de louper une info par faute d'un intervalle de collecte pas assez resserré (cf théorème de Nyquist-Shannon); l'hôte détecte un changement et le notifie, indépendamment d'une fréquence de mesure.
J'ai donc voulu implémenter le snmptrap sur mon serveur centos8 et son zabbix 4.4.6... je ne pensais pas que ce serait si difficile!
Première lecture: 2 manières de faire; par snmptt ou par script perl de zabbix... lequel choisir????
J'ai essayé celle qui semblait le plus logique...snmptt... oui mais il n'y a plus de contributions depuis 2013.... j'ai donc préféré éviter de passer par le snmptt.
Cela devra donc passer par snmptrapd et le script perl de zabbix....
Oups! les packages centos8 avec le snmptrapd ne semblent pas implémentés.... il a fallu chercher pour trouver des packages. Pour les obtenir, il faut installer les net-snmp, net-snmp-agent-libs, net-snmp-libs,net-snmp-perl et net-snmp-utils... j'en ai trouvé des fonctionnels en 5.8-7.el8.2.x86_64
Une fois snmptrapd installé, il faut configurer le snmptrapd.conf.... et là, on lit la doc... c'est tout un monde!
Concernant le snmpV3, il faut trouver les bons types de codage (2 mots de passe qui sont souvent le même en fait sur certains switchs un peu vieillots...), et on nous parle d'un engineid... mais sans nous informer de comment l'acquérir...
Bon, les essais donnent la chose suivante: sans engineid, la conf passe... mais en fait rien ne remonte! => Il FAUT intégrer l'engineID....
Il faut donc déclarer chaque mode de connexion pour chaque élément qui va envoyer des trap, a l'aide de createUser -e <engineID> <Utilisateur> <Mode de cryptage> <mdpasse> <Mode de cryptage> <mdpasse> pffff!
Mais comment récupérer l'engineID de chaque élément? J'ai cherché... je suis même passé par un tcpdump de 2 jours pour intercepter les communications. Une fois ouverts dans un wireshark, on peut récupérer les engineid...
Mais si le matériel ne communique pas sur la période?
J'ai toute une pile de switchs alcatels a surveiller, et impossible de trouver l'engineid dessus... jusqu'à ce que je finisse par tomber sur un oid permettant de retourner l'engineid... apparemment, c'est du générique, donc cela devrait fonctionner sur beaucoup de matériels réseau: 1.3.6.1.6.3.10.2.1.1.0
Depuis mon linux, il me suffit donc de faire un snmpget -v 3 -u <user> -l authptiv -a <Crypt1> -A <MDP1> -x <Crypt2> -X <MDP2> <ip matériel> 1.3.6.1.6.3.10.2.1.1.0 pour que le matériel nous renvoie son engineID
Une fois ceci fait... il faut ajouter une ligne par élément à surveiller,dans snmptrapd.conf, comme décrit précédemment: createUser -e <engineID> <Utilisateur> <Mode de cryptage> <mdpasse> <Mode de cryptage> <mdpasse>
Pour la fin de snmptrapd.conf, lire les recommandations d'install fournies dans zabbix ( perl do "/usr/bin/zabbix_trap_receiver.pl", récup du fichier zabbix_trap_receiver.pl depuis les sources de zabbix, création du fichier /tmp/zabbix_traps.tmp et surtout la création du fichier manuellement car le process ne sait apparemment pas le créer tout seul...)
Une fois cela mis en place, vérifier que le fichier zabbix_traps.tmp se remplit bien des différents snmptrap envoyés...
Voilà, j'en suis là, je sais qu'il me reste à trouver les fichiers de définitions des OIDs pour que le trap consigné soit plus lisible, et mettre en place la lecture du fichier dans zabbix pour que les traps soient injectés régulièrement dans les hôtes concernés... et donc, après, revoir les templates pour me reposer plus sur les données qui remontent et limiter ainsi le trafic.
Je n'aurais jamais cru que passer du snmp au snmptrap puisse engendrer un tel travail, mais je sens que le jeu en vaut la chandelle....en espérant que cela serve a d'autres...