Utilisez un serveur de supervision dédié. Je vous recommande d'installer Nagios sur un serveur dédié à la supervision (et à d'autres tâches d'administration éventuellement). Protégez votre serveur de supervision comme si c'était l'un des plus importants de votre réseau. Maintenez le nombre de services à tourner le plus bas possible et protégez leurs accès avec des wrappers TCP, des pares-feu, etc. Vu que le serveur Nagios est autorisé à discuter avec vos serveurs et peut traverser des pares-feu, autoriser des accès utilisateurs sur votre serveur de supervision peut représenter un risque de sécurité. Gardez à l'esprit qu'il est plus facile d'obtenir des privilèges root au travers d'un trou de sécurité quand vous avez un compte local est disponible sur une machine.

Ne pas faire fonctionner Nagios en tant que root !. Il n'est pas nécessaire d'être root pour faire fonctionner Nagios, alors ne le faîtes pas. Vous pouvez obliger Nagios à abandonner des privilèges après le lancement et à fonctionner avec les droits d'un autre utilisateur/groupe en utilisant les paramètres nagios_user et nagios_group dans le fichier principal de configuration. Si vous avez besoin d'exécuter des gestionnaires d'événements ou des plugins qui requièrent des accès root, vous pouvez essayer d'utiliser sudo.

Verrouillez le répertoire des résultats de contrôle. Assurez-vous que seul l'utilisateur nagios à le droit de lecture/écriture sur le répertoire des résultats de contrôle. Si d'autres utilisateurs que nagios (ou root) sont capables d'écrire dans ce répertoire, ils peuvent potentiellement envoyer des résultats de contrôles erronées au démon Nagios. Cela pourrait vous valoir quelques désagréments comme des notifications erronées ou des problèmes de sécurité (gestionnaires d'événements déclenchés).

Verrouillez le fichier des commandes externes. Si vous activez les commandes externes, assurez-vous d'avoir les permissions appropriées sur le répertoire /usr/local/nagios/var/rw. Vous voulez uniquement que les utilisateurs Nagios (habituellement nagios) et web (habituellement nobody, http, apache2 ou www-data) puissent écrire dans le fichier des commandes. Si vous avez installé Nagios sur une machine dédiée à la supervision et aux tâches d'administration qui n'a pas de comptes publics, cela devrait aller. Si vous l'avez installé sur une machine publique ou multi-utilisateurs (pas recommandé), autoriser l'utilisateur du serveur web peut être un problème de sécurité. Après tout, vous ne souhaitez pas que n'importe quel utilisateur du système puisse contrôler Nagios à partir du fichier des commandes externes. Dans ce cas, je vous suggère de donner les droits uniquement à l'utilisateur nagios et d'utiliser quelque chose comme CGI Wrap pour faire fonctionner les CGIs avec l'utilisateur nagios plutôt que nobody.

Authentification requise pour les CGIs. Je vous recommande fortement de protéger l'accès aux CGIs par une authentification. Ceci fait, lisez la documentation sur les droits par défaut dont disposent les contacts autorisés et n'accordez qu'exceptionnellement une autorisation à des contacts spécifiques. Les instructions pour la configuration des droits se trouvent ici. Si vous désactivez l'authentification préalable à l'accès aux CGIs par la commande use_authentication dans le fichier de configuration des CGIs, le CGI de commande refusera d'écrire la moindre commande dans le fichier des commandes externes. De toutes façons, vous ne souhaitez pas que tout le monde puisse contrôler votre Nagios ?

Implémentez les mesures renforcées de sécurité des GCIs. Je vous recommande chaudement de considérer l'implémentation des mesures de sécurité pour les CGIs comme indiqué ici. Ces mesures peuvent aider à s'assurer que l'utilisateur/mot de passe que vous utilisez pour accéder à l'interface web de Nagios ne puissent intercepter par de tierces parties.

Utilisez les chemins complets dans la définition des commandes. Lorsque vous définissez des commandes, assurez-vous d'avoir bien précisé le chemin d'accès complet de tous les scripts ou binaires que vous exécutez.

Cachez les informations sensibles à l'aide des macros $ARGn$. Les CGIs parcourent le fichier de configuration principal et le(s) fichier(s) de configuration des objets, n'y laissez donc pas d'informations sensibles (noms d'utilisateur, mots de passe, etc.). Si vous avez besoin de préciser un mot de passe ou un nom d'utilisateur dans une définition de commande, utilisez $USERn$ macro pour le cacher. $USERn$ Les macros $USERn$ sont définies dans un ou plusieurs fichiers de ressources. Les CGIs ne parcourant pas les fichiers de ressources, vous pouvez leur donner des permissions beaucoup plus restrictives (600 ou 660). Consultez le fichier resource.cfg dans la distribution de base de Nagios, il vous donnera un exemple de définition de la macro $USERn$.

Éliminez les caractères dangereux des macros. Utilisez le paramètre illegal_macro_output_chars pour filtrer les caractères dangereux des chaînes issues des macros $HOSTOUTPUT$, $SERVICEOUTPUT$, $HOSTPERFDATA$ et $SERVICEPERFDATA$ avant qu'elles ne soient utilisées pour des notifications, etc. Des caractères dangereux peuvent être tout caractère qui peut être interprété par un shell, ouvrant ainsi un trou de sécurité. Un bon exemple est la présence de la quote inverse (`) dans $HOSTOUTPUT$, $SERVICEOUTPUT$, $HOSTPERFDATA$, et/ou $SERVICEPERFDATA$ qui pourrait permettre à un attaquant d'exécuter un commande arbitraire comme l'utilisateur nagios (une autre bonne raison pour ne pas exécuter Nagios avec l'utilisateur root).

Sécurisez l'accès aux agents distants. Assurez-vous d'avoir verrouiller l'accès aux agents (NRPE, NSClient, SNMP, etc.) sur les sytèmes distants en utilisant des pares-feu, des listes d'accès, etc. Vous ne voulez pas que n'importe qui soit capable d'interroger vos systèmes sur leurs états. Cette information peut être utilisée par un attaquant pour exécuter des gestionnaires d'événements distants ou pour déterminer une fenêtre de temps pour une attaque discrète.

Sécurisez vos canaux de communication. Assurez-vous d'avoir chiffré les canaux de communication entre vos différents serveurs Nagios et entre Nagios et les agents de supervision quand cela est possible. Vous ne voulez pas que quelqu'un puisse sniffer les informations d'états lorsqu'elles transitent sur le réseau. Ces informations peuvent être utilisées par un attaquant pour déterminer un intervalle de temps pour une attaque discrète.