Tag Archives: tutoriel snmp

Configuration avancée de SNMP sur Linux : redémarrer un service à distance en utilisant le protocole SNMP

 

Le démon SNMP fourni par Net-SNMP vous permet de redémarrer des services à distance en utilisant le protocole SNMP. Nous allons voir comment le configurer pour:

  1. connaître l’état d’un service
  2. obtenir un détail de statut
  3. redémarrer le service concerné.

Le terme « service » est utilisé mais il est, en réalité, mal employé. Sur Linux, un service peut lancer plusieurs processus. C’est le cas du service postfix par exemple ou MySQL qui lance un script shell mysqld_safe et un processus mysqld. Avec Net-SNMP, nous allons pouvoir visualiser le nombre de processus correspondant à un nom donné. En fonction de cela, nous allons redémarrer un service donné.

Pourquoi permettre de redémarrer un service à l’aide du protocole SNMP? Il est généralement préférable de réaliser cette action en se connectant en SSH sur le serveur et en redémarrant directement le service concerné. Cela apporte une plus grande souplesse et un meilleur contrôle : on obtient le code de retour mais aussi un affichage textuel qui fournit de plus amples détails permettant de comprendre le code de retour. En SNMP, avec Net-SNMP, seul le code de retour sera fourni. Pourquoi alors utiliser SNMP? En réalité, ce n’est pas mis en place. Pas avec l’aide du protocole SNMP. Sauf dans un cas précis : lorsque les administrateurs ne donnent aucun « accès direct » (comprendre : pas de compte Unix) aux serveurs pour toute personne extérieure. L’équipe supervision est parfois extérieure à l’équipe des administrateurs. Ce qui a des avantages comme des inconvénients (tiens… il faudrait que j’écrive un article sur ce sujet…..). Dès lors, il est possible de s’entendre avec l’équipe d’administrateurs pour redémarrer certains services clairement identifiés, en utilisant le protocole SNMP. La configuration de ces services doit être réalisée sur les serveurs : elle peut être totalement contrôlée par l’équipe d’administration. L’équipe d’administration est donc rassurée sur les actions réalisées par l’équipe de supervision car c’est elle qui les contrôle totalement. Maintenant, nous allons voir comment configurer le démon Net-SNMP pour lui faire redémarrer un service à l’aide du protocole SNMP.

Continue reading Configuration avancée de SNMP sur Linux : redémarrer un service à distance en utilisant le protocole SNMP

Configuration avancée de SNMP sur Linux : envoi de trap SNMP

 

Le protocole SNMP n’est pas dédié à fournir une réponse à des requêtes SNMP. Le protocole permet aussi d’envoyer, sans avoir été sollicité, des informations à un récepteur. Ce mécanisme est connu sous le nom d’envoi de trap SNMP. Nous allons voir comment configurer l’envoi de trap SNMP à l’aide de Net-SNMP vers un récepteur donné.

Pourquoi envoyer des traps SNMP?

Le démon SNMPd s’auto-supervise. Comme nous l’avons vu dans un article précédent, il peut détecter des états anormaux de l’équipement. Lorsqu’un comportement est anormal, il peut envoyer des traps SNMP. Légitimement, on peut se demander pourquoi est il important de mettre en place des traps SNMP alors qu’un outil de supervision dédié est présent et réalise des tests récurrents. Les outils de supervision fonctionnent, généralement, sur le principe suivant: interrogation récurrente de l’équipement (par exemple « interrogation toutes les 5 minutes ») pour obtenir des informations données. L’intervalle de test est généralement amplement suffisant (qui peut dire qu’il peut répondre en moins d’une minute à toutes les pannes rencontrées? Vous? Sûr? Même lorsque vous êtes à la machine à café, à draguer la nouvelle stagiaire du service comptable qui ressemble beaucoup, par sa vivacité d’esprit mammaire et son intelligence croupiale, à la dernière starlette de la télé-réalité? (tiens?!? que devient la première starlette de la télé-réalité? Des nouvelles? Qui s’était déjà?!?)… Bref…). Cependant, il est possible d’améliorer la supervision sans avoir à saturer le serveur de supervision en demandant aux équipements supervisés d’envoyer des informations lorsqu’ils détectent une panne. Là est l’intérêt des traps SNMP : envoyer des « alertes » dès qu’une panne apparaît, sans avoir à saturer le serveur de supervision. De plus, certaines informations sont plus simples à récupérer par des traps SNMP que par des requêtes. Généralement, les traps SNMP sont plus faciles à analyser qu’un indicateur agrégé devant correspondre à plusieurs requêtes SNMP dans plusieurs MIBs différentes.

Nous partons du fichier de configuration et de l’utilisateur SNMPv3 précédents (contenu du fichier /etc/snmp/snmpd.conf) :

syscontact cedrictemple@cedrictemple.info
syslocation Europe/France/Paris/6 rue Beaubourg
load 16 8 4
includeAllDisks 10%
rouser ctemple

Continue reading Configuration avancée de SNMP sur Linux : envoi de trap SNMP

Configuration avancée de SNMP sur Linux : SNMPv3

 

Il existe plusieurs versions du protocole SNMP dont les principales sont :

  1. SNMPv1
  2. SNMPv2c
  3. SNMPv3

Les versions v1 et v2c sont les versions les plus utilisées et les plus répandues. Cependant, ces deux versions ont toutes les deux les mêmes problèmes:

  1. les trames circulent en clair sur le réseau. Aucun chiffrement des trames n’est en place. Tout attaquant qui réussit à écouter le réseau à un endroit stratégique (pas sur le réseau bureautique en général) peut récupérer la communauté SNMP. La communauté SNMP ne suffit pas forcément : l’agent peut être configuré pour ne répondre qu’à des requêtes provenant de certaines adresses IP. De plus, un parefeu peut être mis en place et configuré pour n’autoriser les requêtes SNMP qu’aux serveurs de supervision. Mais le spoofing d’adresse IP est toujours possible.
  2. il n’y a pas de notion d’« utilisateur authentifié ». La communauté SNMP est généralement connue de tous les administrateurs systèmes et réseaux. Il est possible de scinder les équipements selon leur type et d’affecter une communauté SNMP différente selon le type de l’équipement (exemple : tous les serveurs Linux ont une communauté, celle-ci est différente des équipements réseaux) mais ce n’est pas pratique.

Généralement, lors d’un déploiement de SNMPv1 et SNMPv2c, aucune technique de sécurisation de ces protocoles n’est réalisée car aucun mécanisme ne le permet réellement. Alors, la sécurisation en périphérie du protocole doit être réalisée (filtrage à différents niveaux, mécanisme anti-spoofing, …).

Le protocole SNMPv3 permet de répondre à ces deux enjeux:

  1. les trames peuvent être chiffrées grâce à différents protocoles algorithmes (*).
  2. des utilisateurs peuvent être créés, chacun disposant d’un identifiant et d’un mot de passe personnel.

La sécurité de SNMPv3 est bien supérieure à celle de SNMPv1 et SNMPv2c. A contrario, sa mise en place est moins aisée. Nous allons voir les étapes pour configurer l’agent Net-SNMP sur Linux, tant sur Debian et CentOS/RedHat. Continue reading Configuration avancée de SNMP sur Linux : SNMPv3

Configuration avancée de SNMP sur Linux : les informations systèmes

 

Nous avons vu dans un article précédent comment configurer l’agent Net-SNMP afin qu’il réponde à nos requêtes. Nous allons voir maintenant comment configurer cet agent Net-SNMP pour qu’il supervise le serveur de lui-même.

Nous partons du fichier de configuration précédent à savoir:

rocommunity macommunaute
rwcommunity macommunauteRW 192.168.0.1
syscontact cedrictemple@cedrictemple.info
syslocation Europe/France/Paris/6 rue Beaubourg

Continue reading Configuration avancée de SNMP sur Linux : les informations systèmes

Configuration de base de SNMPD

 

Comment configurer le démon SNMPd de Net-SNMP afin qu’il réponde à nos requêtes? Nous verrons dans un second temps sa configuration avancée qui nous permettra d’envoyer des requêtes SNMP en cas de panne ou de redémarrer des services à distance. Mais voyons tout d’abord son utilisation basique. En effet, il est important de savoir que le fichier de configuration de SNMPd peut être très complexe. Sa configuration par défaut l’est d’ailleurs. Si vous regardez le fichier de configuration fourni par votre distribution Linux préférée, vous verrez qu’il est possible de définir des accessgroup, des views et autres subtilités. Je vous invite à partir d’un fichier vide. Ses fonctionnalités (view, accessgroup, …) sont assez peu utilisées en pratique. Elles sont relativement complexes à mettre en oeuvre pour un apport négligeable : peu de monde à besoin de filtrer les accès aux différents OIDs. En général, c’est du « tout ou rien » : soit vous avez accès à tous les OIDs, soit vous n’avez accès à rien. Il est peu probable que des personnes différentes ou des groupes de personnes différentes utilisent SNMP : c’est en effet le domaine des administrateurs des équipements. La seule subtilité, que nous allons voir d’ailleurs, correspond au filtrage sur l’accès en lecture ou en écriture.

Tout d’abord, il faut se rendre dans le répertoire de configuration de SNMP:

 cd /etc/snmp
 mv snmpd.cond snmpd.conf.ori
 vim snmpd.conf

Une fois le fichier d’origine sauvegardé, vous pouvez partir d’un fichier vide. La première ligne de ce fichier va vous permettre de saisir la communauté accessible en lecture seule:

 rocommunity macommunaute

Dès lors, vous pourrez interroger votre agent SNMPd avec la communauté « macommunaute ». Vous pouvez augmenter la sécurité en ajoutant la source autorisée à vous interroger:

 rocommunity macommunaute 192.168.0.1

Dès lors, seule l’adresse IP 192.168.0.1 sera autorisée à vous interroger avec la communauté correspondante. Cela ajoute (un peu) de sécurité en autorisant seulement le serveur de supervision à récupérer les informations.

Vous pouvez ajouter une communauté accessible en lecture et écriture en utilisant rwcommunity en lieu et place de rocommunity. Attention, vous ne devez pas utiliser la même communauté pour les lignes rocomunity et rwcommunity (c’est en effet un non sens : une communauté ne peut pas être à la fois en read-only et en read/write). En général, on met une communauté en Read-Only et une communauté différente en Read/Write.

Ensuite, il vous faut mettre les informations administratives. Ces informations n’ont pas vraiment une grande utilité mais je les utilise personnellement pour renseigner l’adresse à laquelle contacter les administrateurs et la localisation de mes équipements. Je prends une politique de nommage afin de découper la localisation en différentes parties afin de les réutiliser dans différentes cartes. Exemple:

syscontact admin@masociete.com
syslocation Europe/France/Paris/6 rue Beaubourg/Salle 3/Baie 4

Le fichier de configuration final :

 rocommunity macommunaute
 rocommunity macommunauteRW 192.168.0.1
 syscontact admin@masociete.com
 syslocation Europe/France/Paris/6 rue Beaubourg/Salle 3/Baie 4

Une fois ceci fait, vous pouvez redémarrer l’agent SNMP et faire quelques tests pour vérifier qu’il fonctionne correctement :

/etc/snmp/snmpd restart
snmpwalk -v 2c -c macommunaute <ip>