Ce paragraphe est un rapide survol des éléments que vous devez conserver à l’esprit au moment d’installer Nagios®, afin que l’installation soit sécurisée. Ce document est nouveau et si quelqu’un a des éléments à y ajouter, qu’il m’envoie un courrier à l’adresse nagios@nagios.org [NdT : mail à envoyer en anglais].
Ne pas lancer Nagios® en tant que Root!
Il n’est pas nécessaire d’être root pour faire lancer Nagios®. Même si vous lancez Nagios® au démarrage à l’aide d’un init script, vous pouvez l’obliger à abandonner des privilèges après le lancement et à fonctionner avec les droits d’un autre utilisateur/groupe en utilisant les directives nagios_user et nagios_group dans le fichier principal de configuration.
Si vous avez besoin d’exécuter le gestionnaire d’événements ou des plugins en tant que root, essayez d’utiliser sudo.
Par défaut, les commandes externes sont désactivées. Cela a pour but d’empêcher un administrateur de lancer Nagios® et de laisser involontairement l’interface de commande ouverte à la disposition "d’autres"… Si vous pensez avoir besoin des gestionnaires d’événements ou d’exécuter des commandes à partir de l’interface web, il faudra autoriser l’usage des commandes externes. Si vous pensez n’être dans aucun des cas précédents, je vous conseille de désactiver les commandes externes.
Si vous permettez l’utilisation des commandes externes, assurez-vous que le répertoire /usr/local/nagios/var/rw dispose des permissions adéquates. Vous souhaitez que seulement l’utilisateur Nagios® (habituellement nagios) et l’utilisateur du serveur web(habituellement nobody) aient l’autorisation d’écrire dans le fichier de commandes. Si vous avez installer Nagios® sur une machine dédiée et qu’elle n’a pas de comptes d’utilisateurs, cela doit être suffisant.
Si vous avez installé Nagios® sur une machine multi-utilisateur publique, permettre l’accès au fichier de commande via le serveur web peut causer des problèmes de sécurité. Après tout, je ne pense pas que vous souhaitiez permettre à tout le monde de contrôler nagios. ans ce cas, je vous recommande de n’accorder l’accès au fichier de commande qu’à l’utilisateur nagios et d’utiliser quelque chose comme CGIWrap pour exécuter les CGIs comme l’utilisateur nagios plutôt que l’utilisateur nobody.
Les instructions pour configurer les autorisations à donner au fichier de commandes externes se trouvent ici.
Je vous recommande fortement de protéger l’accès aux CGI 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 CGI par la commande use_authentication dans le fichier de configuration des CGI, 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 vôtre Nagios® ?
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.
Les CGI 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 une macro $USERn$ pour le cacher. 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$.
Utilisez la directive illegal_macro_output_chars pour filtrer les caractères dangereux des chaînes issues des macros $OUTPUT$ et $PERFDATA$ 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 $OUTPUT$ et/ou $PERFDATA$, 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® comme l’utilisateur root).