NCPA, un agent pour Nagios

Posté par  . Édité par Ysabeau 🧶, gUI et Benoît Sibaud. Modéré par ted. Licence CC By‑SA.
Étiquettes : aucune
18
29
juin
2022
Supervision

Nagios est un logiciel de supervision qui possède de nombreux plugins, parmi ces plugins, il y en a certains qui permettent d’envoyer des commandes de vérifications locales sur une machine distante.

Nagios communique donc avec un agent qui va faire des vérifications localement sur la machine cliente. Au début, NRPE (agent Linux) et winNrpe (agent Windows), semblaient être les agents parfait pour Nagios, mais les évolutions de Nagios ont fait qu’à moment donné, il y a eu des incohérences winnrpe et nsclient++ (désactivation de la couche SSL/TLS).

Finalement, après quelques recherches, il semblerait que Nagios suggère un agent : NCPA (Nagios Cross Platform Agent ou, en français agent Nagios multiplateforme).

Sommaire

Historique de NCPA (selon le site de Nagios)

Les origines de la NCPA remontent à la conférence mondiale Nagios de 2012, où un administrateur réseau a déclaré :

Je n’ai aucune idée de la raison pour laquelle les agents sont si difficiles. Après avoir réfléchi à cette déclaration, nous n’avions pas de réponse. L’idée de faire de NCPA un agent de surveillance unique, sécurisé, simple et facile à gérer a été formée.

En 2014, la première version de NCPA a été publiée avec les fonctionnalités de base qui sont au cœur du projet, comme l’API multiplateforme.

Aujourd’hui, NCPA a parcouru un long chemin depuis l’idée initiale de 2014. Il comprend d’innombrables fonctionnalités supplémentaires, avec beaucoup d’autres en cours de développement.

À propos des agents

Les agents peuvent fonctionner sous deux modes :

  • Active Checks : c’est Nagios qui, via check_ncpa, demande l’exécution d’une vérification (sujet traité dans cette publication).
  • Passive Checks (NRDP) : l’agent exécute des vérifications définies dans son fichier de configuration et envoie le résultat à un serveur de supervision doté du module NRDP. Ce module NRDP est inclus dans Nagios XI. Pour plus d’information sur les passive checks, la documentation « getting started » explique comment configurer l’agent et Nagios pour réalise ce type de supervision.

Note : si on veut comparer NCPA par rapport à NRPE, NCPA ne contient pas de ligne de configuration de check prêt à être utilisé.

Autre point, dans NRPE, il y avait un module ou fonction qui permettait d’avoir le loadavg du système, ce n’est plus possible avec NCPA, il faut utiliser les fonctions liées au CPU.

Check_ncpa

C’est le plugin qui doit être installé sur le serveur Nagios. Il s’agit d’un script python.

Attention, sous CentOS 8, il y a un problème de version de python.

En effet, l’exécutable s’appelle python2 sur CentOS 8 et non python donc, il faut adapter le script python check_ncpa pour qu’il appelle python2.

#!/usr/bin/env python

SYNOPSIS

vers

#!/usr/bin/env python2

SYNOPSIS

NdM : la documentation du script stipulant qu'il est compatible python2 et 3, il semblerait que cet avertissement ne soit plus d'actualité.

Sinon, pour la partie serveur, le check_ncpa est installé, il ne reste plus qu’à l’appeler ou plutôt l’utiliser.

Mais avant de l’appeler, il faut installer les agents sur les serveurs à superviser.

Installation de l’agent

Pour l’installation de l’agent sur le serveur, il y a un exécutable 32-bits pour Windows et un RPM 64-bits sous Linux ainsi qu’une version pour MacOS.

Durant l’installation sous Windows, un community_string est demandé, ce n’est pas le cas sous Linux. Ce community_string est très important, car c’est la clé d’authentification entre l’agent et check_ncpa (Nagios).

L’installation de l’agent va soit créer un service sous Windows, soit un daemon sous Linux. Ainsi, sous Linux, pour activer, démarrer, arrêter ncpa, on utilisera systemctl avec comme nom de process : ncpa_listener. Et, sous Windows, il suffit d’aller dans services.msc.

Comme pour les autres types d’agent, il y a un fichier de configuration, fichier où est stocké notamment le community_string. Il s’agit du fichier ncpa.cfg.

Le fichier est localisé :

  • sous Linux : /usr/local/ncpa/etc/ncpa.cfg.
  • sous Windows : c:\program files (x86)\Nagios\ncpa\etc\ncpa.cfg.

Étrangement, il n’est pas actif par défaut. Par sécurité, je recommanderais donc d’activer la ligne admin_auth_only = 1.

En mettant admin_auth_only = 1, on active la demande d’un mot de passe sur l’interface GUI. Et il y a bien sur dans ce fichier ncpa.cfg, le paramètre community_string = xxxxxxxxxxxx.

Si on veut changer le token (community_string) après installation, il faut redémarrer les services ou process installé sur le serveur.

Pour les exemples, je vais partir du principe que Nagios est installé dans /usr/local/nagios.

Pour tester que l’agent fonctionne bien, on peut aller sur le serveur Nagios et exécuter la commande suivante :

/usr/local/nagios/libexec/check_ncpa.py -H <host> -t '<token>' -P 5693 -M system/agent_version

Exemples de check

Voici un exemple d’appel décrit dans les fichiers de Nagios. Il faut préalablement décrire le plugin dans le fichier command.cfg de Nagios :

    define command {
        command_name    check_ncpa
        command_line    $USER1$/check_ncpa.py -H $HOSTADDRESS$ $ARG1$
    }

Check CPU :

check_ncpa!-t '<token>' -M 'cpu/percent' -q  aggregate=avg -w 90 -c 99

Check DISK :

Les \ et / doivent être représentés par un | (barre verticale).

Windows :

check_ncpa !-t '<token>' -P 5693 -M 'disk/logical/C:|/used_percent' --warning 90 --critical 95

Linux :

check_ncpa !-t '<token>' -P 5693 -M 'disk/logical/|/used_percent' --warning 90 --critical 95

Check Memory :

check_ncpa !-t '<token>' -P 5693 -M 'memory/virtual' --warning 90 --critical 95

Check Services (Windows):

check_ncpa ! -t '<token>' -P 5693 -M 'services' -q 'service=<nom du service>,check=1'

Check Process (Linux):

check_ncpa !-t '<token>' -P 5693 -M 'processes' -q 'name=<nom du process>'

OU

check_ncpa -t '<token>' -P 5693 -M 'processes' -q 'cmd=<nom du process>, match=search' -c 1:1

Attention, il faut faire quelques tests, et de plus, avec un Windows en Français, il y a un risque de message d’erreurs (en tout cas sur le fait d’avoir la liste complète des process). C’est un problème constaté et signalé.

L’interface web de l’agent permet de voir les essais ou checks effectués.

Pour les tests, il est toujours possible de faire des essais via la ligne de commande.

Ex :

/opt/nagios/libexec/check_ncpa.py -H <host> -t '<token>' -P 5693 -M 'processes' -q 'cmd=robotProm.jar,match=search' -c 1:1

Plugins

Il est possible de faire des plugins, des scripts Windows ou Linux à mettre dans le répertoire plugins de l’agent ncpa.

Exemple :

#!/bin/bash

nbProcess=`ps aux | grep java | grep tomcat | wc -l`

echo $nbProcess

if [ $nbProcess -eq 1 ]; then
  ret=0
  comment="Tomcat process is running"
else
  ret=2
  comment="No tomcat process"
fi;

if [[ -z $ret ]]; then
  echo "No exit code was supplied, aborting!"
  exit
fi

if [[ -z $comment ]]; then
  echo "No dummy message was supplied, aborting!"
  exit
fi

echo $comment
exit $ret

Si, lors des premiers checks, il y a le message : CRITICAL: Incorrect credentials given →, il faudra vérifier l’orthographe du token.

Conclusion

Cet article ne couvre pas tout NCPA, mais permet de présenter le produit et les usages les plus communs.

Il faut constater qu’il y a presque autant de type d’agent (NRPE, NCPA, nsclient++…) qu’il y a de serveur de supervision (Nagios, Centreon, Shinken…) mais, si on suit Nagios, NCPA est l’agent recommandé.

Aller plus loin

  • # Utilisation des Custom Object Variables recommandée

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    Merci, c'est super !

    À noter, depuis la version 3 de Nagios, il est recommandé d'utiliser les Custom Object Variables plutôt que les $ARGn. C'est très triste que la documentation officielle de NCPA (et de Nagios) ne mette pas en avant cela mais les avantages sont importants :

    • les Custom Object Variables ont une portée (sur le host, le service, …)
    • les Custom Object Variables sont nommés et plus facile à identifier (_MAC_ADDRESS est plus signifiant que ARG1)
    • l'héritage des Custom Object Variables permet de définir les paramètres communs dans des modèles d'host et de service

    Grâce aux Custom Object Variables, il est beaucoup plus simple de définir une stratégie de configuration efficace et surtout, maintenable dans le temps. Lorsqu'on a quelques dizaines de serveurs à superviser, on peut s'en passer (et encore), mais lorsqu'on dépasse la centaine, elles deviennent vite indispensables.

  • # Attention à la licence

    Posté par  . Évalué à 7.

    La licence de NCPA est très loin d’être une licence libre.

    Extrait : «The Software may not be Forked. "Forking" and "to Fork" means to create or distribute a product or a derivative work of the object or source code of the Software under a new or different brand.»

    Source : https://github.com/NagiosEnterprises/ncpa/blob/master/LICENSE.rst

    Un changement de licence à été promis, mais jamais réalisé :
    https://github.com/NagiosEnterprises/ncpa/issues/642

  • # Et la sécurité ?

    Posté par  (site web personnel) . Évalué à 3.

    Merci pour cette présentation !

    J'ai quelques questions qui me restent, notamment au regard des dégâts qu'ont pu avoir la faille solarwinds où un logiciel de supervision compromis permettait à l'intrus de prendre le contrôle de la totalité du parc :

    • si je comprends bien, la supervision peut faire exécuter au système supervisé des commandes arbitraires (dans le but de remonter des infos), exact ?
    • Avec quels privilèges l'agent exécute-t'il ces checks ?
    • les échanges entre la supervision et l'agent semblent authentifiés par la "community string". Est-ce la même pour tous les systèmes supervisés ? Du coup, un système supervisé X peut interroger de la même manière son voisin Y supervisé lui aussi ?
    • Ces échanges sont-ils chiffrés ? i.e. un attaquant qui snifferait le lien ethernet peut-il extraire la community string ?
    • [^] # Re: Et la sécurité ?

      Posté par  . Évalué à 3.

      Très bonne questions…

      NCPA propose deux types de commandes
      Il y a les commandes disponibles par défaut: CPU, mémoire, espace disques.
      Et il y a les plugins qui sont sur la machine cliente et écris par un admin ou quelqu'un d'autres.

      Donc, oui, si le plugin est détérioré ou compromis, oui, il y a un problème de sécurité.

      Par défaut, sous Windows, c'est : "local system" et sous Linux: c'est nagios

      Le community-string étant défini sur l'agent, on peut gérer autant de community-string que l'on veut. C'est dans la supersivion que l'on doit alors faire correspondre le community-string au bon serveur

      La communication est cryptée avec comme version SSl par défaut: ssl_version = TLSv1_2

      • [^] # Re: Et la sécurité ?

        Posté par  (site web personnel) . Évalué à 1.

        Il y a les commandes disponibles par défaut: CPU, mémoire, espace disques.
        Et il y a les plugins qui sont sur la machine cliente et écris par un admin ou quelqu'un d'autres.

        Du coup le serveur ne peut pas reconfigurer l'agent ou lui faire exécuter une commande arbitraire, exact ? (sauf plugin mal écrit…)

        La communication est cryptée avec comme version SSl par défaut: ssl_version = TLSv1_2

        Merci de la précision ! Mais du coup, ça nécessite d'avoir une autorité de certification interne (ou d'en créer une pour cet usage), exact ?

        • [^] # Re: Et la sécurité ?

          Posté par  . Évalué à 3.

          Je ne sais pas comment est géré la couche SSL entre l'agent et le serveur Nagios, mais je suppose qu'il utilise un certificat self-signed. Concernant, le premier point, le serveur ne peut pas reconfigurer l'agent ou lui faire exécuter une commande arbitraire (sauf plugin mal écrit…).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.