Surveillance de Linux en mode hérité

Vous trouverez une description détaillée de l'installation à partir des paquets deb ou rpm dans l'article « Monitoring Linux » ; nous nous contenterons donc ici de vous présenter brièvement la procédure.

Dans Checkmk Community, vous trouverez les paquets Linux de l’agent via Setup > Agents > Linux. Dans les éditions commerciales, vous accédez d’abord à l’Agent Bakery dans le menu Setup via Agents > Windows, Linux, Solaris, AIX, où vous trouverez les paquets précompilés. De là, l’option de menu Related > Linux, Solaris, AIX files vous mènera à la liste des fichiers de l’agent.

Vous pouvez télécharger ces fichiers via le navigateur ou utiliser wget ou curl pour les télécharger directement sur l’hôte dans la surveillance :

Sur RHEL, SLES et les distributions apparentées, le paquet RPM est installé sous le nom root à l'aide de la commande rpm -U :

À noter que l'option -U signifie « mise à jour », mais elle permet également d'effectuer correctement une installation initiale.

L'installation du paquet DEB sur Debian, Ubuntu ou des distributions apparentées s'effectue en tant qu'root, à l'aide de la commande dpkg -i :

Pour une installation pratique indépendante de la distribution, vous aurez besoin de l'agent Linux au format d'archive TGZ (« Tarball »), que vous pouvez télécharger à partir des éditions commerciales dans le menu Configuration via Agents > Windows, Linux, Solaris, AIX. L'archive TGZ contient la structure de répertoires complète de l'agent Linux à décompresser dans le répertoire racine de l'hôte surveillé.

Le paramètre « -C » (« changer de répertoire ») est essentiel lors de la décompression afin de garantir que tous les chemins d'accès aux fichiers sont corrects. Nous utilisons également « --no-overwrite-dir » afin que les permissions des répertoires existants ne soient pas modifiées :

Si vous avez tout fait correctement, le script de l'agent devrait désormais s'exécuter simplement en tant que commande et produire sa sortie habituelle. L'| heade tout ce qui suit la 11e ligne de sortie :

Si un numéro de version inférieur à 2.2.0 s'affiche ici, vous avez probablement encore une ancienne version du script de l'agent installée en tant que /usr/local/bin/check_mk_agent. Déplacez cet ancien script ou renommez-le, par exemple en ajoutant .bak à la fin du nom de fichier.

Une installation manuelle du script de l'agent est rarement nécessaire, mais elle n'est pas très difficile non plus. Dans ce type d'installation, seul le script de l'agent est installé dans un premier temps, mais aucune configuration de l'accès n'est encore effectuée. Pour cela, vous avez besoin de la boîte Agents disponible sur la page des fichiers de l'agent. Vous y trouverez le fichier check_mk_agent.linux :

Chargez ce fichier sur le système cible et copiez-le dans un répertoire accessible à l'root. Le répertoire /usr/local/bin/est un bon choix, car il se trouve dans le chemin de recherche et est destiné aux extensions personnalisées. Vous pouvez également utiliser le répertoire /usr/bin ou un sous-répertoire de /opt. Nous utilisons le répertoire /usr/bin afin que tous les tests correspondent aux autres méthodes d'installation. Vous pouvez également effectuer l'installation directement à l'aide de wget si celui-ci est disponible :

N'oubliez pas les deux dernières commandes : elles supprimeront l'extension .linux et rendront le fichier exécutable. L'agent devrait désormais être exécutable en tant que commande et produire sa sortie habituelle. L'| heade tronque tout ce qui suit la 10e ligne de sortie :

Si vous souhaitez configurer ou étendre l'agent, vous devrez créer vous-même les répertoires nécessaires. L'emplacement des trois répertoires obligatoires est codé en dur dans l'agent dans des variables commençant par MK_ et est également fourni aux plug-ins via l'environnement système :

Vous devez créer ces trois répertoires (avec les permissions par défaut 755 et root comme propriétaire) :

Si vous souhaitez utiliser d'autres chemins d'accès, il vous suffit de modifier le fichier /usr/bin/check_mk_agent.

Pour configurer un service existant utilisant le répertoire /etc/xinetd.d/, l’archive TGZ ainsi que les paquets DEB et RPM sont fournis avec un script qui automatise les deux étapes nécessaires : il installe d’abord la configuration, puis force xinetd à relire les paramètres modifiés. Vous devez exécuter le script en indiquant les chemins d’accès complets :

Si vous installez le script de l'agent manuellement, créez le fichier de configuration /etc/xinetd.d/check-mk-agent à l'aide de l'éditeur. Le contenu suivant suffit :

Nous avons ajouté ici une ligne (commentée) limitant l'accès à deux serveurs Checkmk. Vous pouvez consulter d'autres options de configuration en examinant le fichier ~/share/check_mk/agents/scripts/super-server/1_xinetd/check-mk-agent sur votre serveur Checkmk.

Si votre fichier xinetd utilise l'ancien schéma de configuration avec un seul grand fichier /etc/xinetd.conf, transférez l'exemple de configuration de /etc/check_mk/xinetd-service-template.cfg vers /etc/xinetd.conf.

Une fois la configuration d'xinetd terminée, redémarrez-le :

Vous êtes désormais prêt pour le test de connexion.

Vérifiez d'abord si votre fichier /etc/services contient déjà une entrée pour le port 6556 :

Si ce n'est pas le cas, Checkmk doit être enregistré en tant que service. Pour ce faire, ajoutez la ligne suivante. La notation utilisée ici est exactement la même que celle stockée dans la table IANA, avec un seul tiret :

Le format du fichier de configuration d'/etc/inetd.confs diffère selon les variantes. Reportez-vous aux commentaires dans le fichier de configuration et à la page de manuel (man 5 inetd.conf) pour connaître le format correspondant à votre inetd. Voici la configuration correspondant à openbsd-inetd, avec deux lignes pour la prise en charge d'IPv4 et d'IPv6. Une fois encore, il est important de noter la notation correcte :

Après avoir modifié le fichier de configuration, redémarrez l'inetd, par exemple avec :

Selon le système d'initialisation utilisé et le super-serveur installé, cette commande peut varier.

Vérifiez d'abord si l'xinetd ou l'inetd a pu être (re)démarré :

Vous pouvez désormais vous connecter à telnet ou nc (netcat) sur le port TCP 6556 — d'abord depuis l'hôte lui-même, puis depuis le serveur Checkmk :

Si vous recevez une notification de connexion refusée alors que le service (x)inetd est actif, vérifiez les paramètres de votre pare-feu.

SSH fonctionne avec l'« authentification par clé publique ». Pour ce faire, vous devez d'abord générer une paire de clés appariées, dont l'une est publique et l'autre privée. Lors du choix de l'algorithme, vous pouvez choisir entre rsa, ecdsa ou ed25519. Dans l'exemple ci-dessous, vous utilisez la commande ssh-keygen -t ed25519 en tant qu'utilisateur du site :

Laissez le champ du nom de fichier vide pour utiliser le nom de fichier suggéré. Vous pouvez bien sûr spécifier un autre chemin d'accès, par exemple si vous souhaitez utiliser des clés distinctes pour chaque hôte.

Important : ne spécifiez pas de phrase de passe ! Chiffrer le fichier avec la clé secrète ne servirait à rien, après tout, vous ne souhaitez certainement pas devoir saisir la phrase de passe à chaque fois que vous démarrez le serveur Checkmk…​

Le résultat est deux fichiers dans le répertoire .ssh :

La clé privée s’appelle id_ed25519 et n’est lisible que par l’utilisateur du site (-rw-------) — et c’est une bonne chose ! La clé publique id_ed25519.pub ressemble à ceci :

L'étape suivante doit maintenant être effectuée sur (chacun des) hôtes Linux surveillés via SSH. Connectez-vous en tant qu'root et créez le sous-répertoire .ssh dans son répertoire personnel (/root), s'il n'existe pas déjà. Avec la commande suivante, les privilèges d'accès seront immédiatement définis correctement sur 700 :

Ouvrez maintenant le fichier authorized_keys à l'aide d'un éditeur de texte (en mode console) de votre choix. Si ce fichier n'existe pas encore, l'éditeur le créera automatiquement :

Copiez le contenu des clés publiques dans ce fichier. Vous pouvez le faire, par exemple, à l'aide de la souris et de la fonction copier-coller. Soyez précis ! Chaque espace compte. Veillez également à ce qu'il n'y ait jamais deux espaces sur une même ligne. Et : le tout doit tenir sur une seule ligne ! Si le fichier existe déjà, ajoutez simplement une nouvelle ligne en dessous.

Ce qui suit est très important ! La clé SSH doit être utilisée exclusivement pour l'exécution de l'agent. SSH propose une fonctionnalité de ce type sous le nom de « restriction de commande ». Pour ce faire, insérez le texte « command="/usr/bin/check_mk_agent" » au début de la ligne que vous venez de créer — séparé du reste par un seul espace. Cela ressemblera à quelque chose comme ceci :

Enregistrez le fichier et vérifiez les droits d'accès. Seul le propriétaire doit disposer des droits d'écriture sur ce fichier.

Ensuite, testez l'accès à l'agent à l'aide de la commande ssh :

La première fois, vous devrez confirmer l'empreinte digitale de la clé en saisissant yes. Tous les accès suivants pourront alors être effectués sans intervention de l'utilisateur, y compris l'interrogation automatique du script de l'agent par le serveur Checkmk toutes les minutes.

Si cela ne fonctionne pas, veuillez vérifier :

Sur les systèmes cibles très anciens, il est également possible que les clés utilisant les courbes elliptiques (ed25519 et ecdsa) soient inconnues. Dans ce cas, générez une clé RSA supplémentaire et saisissez-la également dans l'authorized_keys. SSH utilisera alors automatiquement la clé la plus forte connue pour la connexion.

Le système cible est désormais prêt. Il ne reste plus qu’à configurer Checkmk lui-même. Cela s’effectue via le jeu de règles Setup > Agents > Other integrations> Custom integrations > Individual program call instead of agent access. Créez ici une règle pour les hôtes concernés et saisissez ssh -T root@$HOSTNAME$ ou ssh -C -T root@$HOSTNAME$ (pour une compression supplémentaire des données de l’agent) comme commande :

Vous pouvez exécuter le test de connexion dans l’interface graphique sous « Setup > Hosts > Properties of host > Test connection to host » à l’aide du bouton « Run tests ». Si le test échoue en raison d’un délai d’attente ou d’un accès refusé, vérifiez si vous avez utilisé le nom d’hôte avec la même orthographe que lors du test en ligne de commande — OpenSSH fait la distinction entre le nom d’hôte court, le nom de domaine complet (FQDN) et l’adresse IP. Vous pouvez également accéder à l’hôte en utilisant son adresse IP. Dans ce cas, vous devez utiliser la macro $HOSTADDRESS$, qui est remplacée par l'adresse IP de l'hôte mise en cache (par Checkmk).

Après avoir enregistré et exécuté « Activer les modifications », l’hôte est ajouté à la surveillance. Dans la surveillance, le service Check-MK Agent s’affiche désormais avec la mention « Transport via SSH ». Pour des diagnostics plus approfondis, vous pouvez utiliser les commandes cmk -D et cmk -d, qui sont expliquées dans l’article consacré à la ligne de commande.

Vous pouvez également utiliser plusieurs clés SSH. Placez les clés dans n’importe quel répertoire. Dans la règle Individual program call instead of agent access, vous devez ensuite spécifier le chemin d’accès à la clé privée correspondante à l’aide de l’option -i. Il est préférable d’utiliser ici $OMD_ROOT à la place du chemin d’accès au répertoire du site (/omd/sites/mysite). La commande complète pourrait alors être ssh -i $OMD_ROOT/.ssh/my_key -T root@$HOSTADDRESS$, ce qui permettrait également d’exécuter la configuration sur un site portant un nom différent :

Cela vous permet d'utiliser différentes clés SSH pour différents groupes d'hôtes en utilisant plusieurs règles distinctes.

Afin d'éviter de fournir à des attaquants potentiels des données en clair malgré les tunnels SSH, vous devez désactiver tout accès au port 6556 qui pourrait encore être disponible dans la surveillance sur l'hôte. Si la commande ss -tulpn | grep 6556 ci-dessus n'a trouvé aucun processus à l'écoute sur le port TCP 6556, la configuration du tunnel SSH est terminée. Si une ligne s'affiche, le processus qui a été trouvé doit être désactivé de manière permanente.

Dans tous les cas, n'oubliez pas d'effectuer un dernier test. Il ne devrait désormais plus être possible de se connecter au port 6556 :

La configuration du chiffrement avec Agent Bakery se déroule comme suit : Avec la première étape, la création de la règle « Symmetric encryption (Linux, Windows) », vous avez presque terminé. Il ne vous reste plus qu’à générer et à distribuer les nouveaux agents. Le fichier « /etc/check_mk/encryption.cfg » est créé automatiquement pour vous et sera inclus dans les paquets d’agents. Il ne reste plus que la troisième étape, à savoir la création de la règle « Enforce agent data encryption ».

Même si un attaquant ne peut exécuter aucune commande, les données de surveillance de l’agent pourraient tout de même lui être utiles, car elles contiennent, entre autres, une liste de tous les processus en cours d’exécution sur le système. Il est donc préférable que ces données ne soient pas facilement accessibles à quiconque.

Si vous partagez l’agent Checkmk via xinetd, il est très simple et efficace de restreindre l’accès à des adresses IP spécifiques — et à celles du serveur de surveillance, bien sûr. Cela peut être rapidement mis en place via la directive only_from dans votre fichier de configuration xinetd. Saisissez les adresses IP ou les plages d’adresses (sous la forme 12.34.56.78/29 ou 1234::/46) séparées par des espaces. Les noms d’hôtes sont également autorisés. Dans ce cas, le système vérifie si le nom d’hôte déterminé par la résolution inverse de l’adresse IP de l’hôte demandeur correspond à celui saisi :

Dans les éditions commerciales, les utilisateurs d’Agent Bakery peuvent configurer les adresses IP autorisées via le jeu de règles « Allowed agent access via IP address (Linux, Windows) ». Ce jeu de règles est accessible via Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Generic Options.

Bien sûr, un attaquant peut très facilement usurper son adresse IP et ainsi se connecter à l’agent. Mais il est alors très probable qu’il ne reçoive pas de réponse, car celle-ci sera envoyée au serveur de surveillance légitime. Ou bien l’attaquant reçoit effectivement une réponse, mais le serveur Checkmk ne reçoit aucune donnée et signalera rapidement une erreur.