I. Pourquoi
Si vous ne connaissez pas Zabbix, rendez-vous sur l’article de présentation 😉
Tout d’abord, nous allons voir l’utilité d’une telle action. Pourquoi est-il souhaitable, dans certains cas, d’exécuter une commande shell sur un client ayant déclenché une alerte.
Pour bien illustrer cela, nous allons prendre un exemple très simple :
Imaginons que nous surpervisions une machine, en particulier, la température de cette machine. Nous avons donc créé un objet (item) température processeur ainsi qu’un déclencheur (trigger) qui s’active lorsque la température du processeur dépasse 100°C.
Au cas où ce déclencheur viendrait à s’activer, il serait plutôt intéressant de dire : "En plus de m’envoyer une alerte sur l’interface d’administration, je voudrais que tu éteignes la machine concernée avant que le processeur ne grille". (je sais il y a des sécurités pour cela mais c’est un exemple).
Concrètement, lorsque le trigger "Température processeur trop haute" se déclenche, en plus d’avoir un avertissement sur le panel web, on exécute la commande halt sur la machine qui surchauffe.
Voila un cas où il est souhaitable d’exécuter une commande à distance. Si vous en avez d’autres, je suis curieux de les connaître 🙂
II. Comment
"Ok, j’ai compris, mais comment on fait ?"
Lorsqu’un agent zabbix est installé depuis les dépôts sur la machine à surveiller, cela créé automatiquement un utilisateur zabbix qui va être utilisé pour faire tourner cet agent. Pour voir cela, nous pouvons exécuter cette commande :
ps aux|grep zabbix
-
zabbix 3317 0.0 0.0 5132 620 ? SN 10:30 0:00 /usr/sbin/zabbix_agentd *
C’est grâce à cet utilisateur que nous allons exécuter une commande à distance sur cette machine. Si vous avez installé l’agent à partir des sources, vous devrez, de toutes façons, créer cet utilisateur zabbix .
Premièrement, il faut autoriser l’exécution des commandes à distance sur l’agent. Pour ce faire, dans son fichier de configuration, il faut décommenter la ligne suivante :
-
EnableRemoteCommands=1 *
Puis nous allons allouer un shell à l’utilisateur zabbix car, par défaut, il n’en a pas. Nous allons donc modifier le fichier /etc/passwd :
- zabbix:x:101:102::/var/run/zabbix-server/: /bin/false *
nous allons le modifier en -
zabbix:x:101:102::/var/run/zabbix-server/: /bin/bash *
Certes, ce n’est pas la manière la plus propre mais c’est de loin la plus rapide 🙂
Ensuite on va paramétrer l’action à effectuer dans le panel. Pour cela, rendez-vous dans l’onglet "Actions" du menu "Configuration" :
Dans mon screenshot, vous pourrez remarquer que j’exécute la commande lorsque le fichier /etc/passwd a été modifié (c’était juste pour faire mes tests).
Dans l’onglet Operation Type, choisissez "Remote command" puis dans le rectangle "Remote command", ajoutez y une commande par ligne en respectant cette syntaxe :Host:Commande
Par exemple, je paramètre cette commande :eeepc:sudo /sbin/halt
Dans cet exemple, on demande d’exécuter sudo halt sur la machine eeepc .
On utilise sudo car on cherche à exécuter une commande qui nécessite les droits root (car, rappelez vous, on lance les commandes avec le compte utilisateur zabbix sur l’agent en question).Dans ce cas, il faut penser à bien renseigner le fichier /etc/sudoers de cette machine (grâce à la commande visudo ). Exemple :
-
zabbix ALL=(ALL) NOPASSWD: ALL *
Là on autorise l’utilisateur Zabbix à exécuter toutes les commandes en root et sans mot de passe (attention à ne surtout pas demander de mot de passe).III. Sécurité
Certain ont du bondir de leur chaise en voyant que je laissais tous les droits root à l’utilisateur Zabbix. Ils ont raison.
En effet, si une personne mal intentionnée avait accès au serveur Zabbix, il pourrait faire exécuter un trigger et donc n’importe quelle commande sur la machine concernée, c’est un risque que nous ne pouvons pas prendre, nous allons donc sécuriser cette méthode.- Limiter les commandes autorisées à l’utilisateur zabbix
Si nous voulons uniquement utiliser la commande halt, nous devons autoriser l’utilisateur zabbix à n’exécuter que cette commande. Pour ce faire, nous allons ré-éditer le fichier /etc/sudoers (grâce à la commande visudo ).
Au lieu de mettre cette ligne :
- Limiter les commandes autorisées à l’utilisateur zabbix
- zabbix ALL=(ALL) NOPASSWD: ALL *
nous allons mettre celle-ci : -
zabbix ALL=(ALL) NOPASSWD: /sbin/halt *
Ainsi,on autorise l’utilisateur zabbix à n’exécuter que la commande halt avec les droits root.
Pour plus d’informations sur la gestion de sudo et des sudoers, je vous invite à aller voir mon cours sur le sujet .
- Allouer un shell sécuriser à l’utilisateur zabbix
Au lieu d’allouer le shell /bin/bash à l’utilisateur zabbix (dans le fichier /etc/passwd), nous allons lui allouer le shell /bin/rbash .
rbash (pour restricted bash) est un shell identique à bash mais chez qui on à désactiver certaines fonctionnalités (par mesures de sécurité). Avec ce shell, il est impossible de :
- changer de répertoire avec cd
- Allouer un shell sécuriser à l’utilisateur zabbix
- créer ou détruire les valeurs de SHELL, PATH, ENV ou BASH_ENV
- indiquer des noms de commandes contenant un /
- indiquer un nom de fichier contenant un / comme argument de la commande interne .
- spécifier un nom de fichier contenant une barre oblique comme argument de l’option -p de la commande interne hash
- importer une définition de fonction dans l’environnement au démarrage
- analyser les valeurs de SHELLOPTS au démarrage
- rediriger la sortie en utilisant les opérateurs de redirection >, >|, <>, >&, &> et >>
- utiliser la commande interne exec pour remplacer l’interpréteur par une autre commande
- ajouter ou supprimer des commandes internes avec les options -f et -d de la commande interne enable
- utiliser la commande interne enable pour activer les commandes internes de l’interpréteur désactivées
- indiquer l’option -p à la commande interne commande
-
supprimer le mode restreint avec set +r ou set +o restricted
Voila pour ce petit tutoriel, j’espère avoir été assez clair 🙂 D’autres tutoriels Zabbix viendront certainement, si vous en voulez un en particulier, demandez-moi 😉