Introduction

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 [Anglais]

Ne pas lancer Nagios en tant que Root!

Il n'est pas indispensable d'être root pour faire fonctionner Nagios, aussi vaut-il mieux s'en abstenir totalement. Même si vous lancez Nagios au moment du boot à l'aide d'un init script, vous pouvez l'obliger à abandonner des privilèges après le démarrage et à fonctionner avec les droits d'un autre utilisateur et groupe en utilisant les directives nagios_user et nagios_group dans le fichier principal de configuration.

Autoriser les commandes externes seulement si c'est nécessaire

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.

Donner les autorisations adaptées au fichier des 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. Seul un nombre restreint d'utilisateurs (vraisemblablement Nagios et le serveur web) a besoin de 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 à quiconque de contrôler nagios. Dans 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 [Anglais] pour exécuter les CGIs comme l'utilisateur nagios plutôt que l'utilisateur nobody.

Les instructions relatives aux autorisations à donner au fichier de commandes externes se trouvent ici.

Accéder aux CGI via une authentification

Je vous recommande fortement de protéger l'accès aux CGI par une authentification. Ceci fait, lisez la documentation relative aux droits par défaut dont disposent les contacts autorisés et n'accordez qu'exceptionnellement une autorisation à des contacts spécifiques. Les instructions relatives à l'authentification et à 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 Nagios à votre place ?

Utiliser 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.

Cacher les informations sensibles à l'aide des macros $USERn$

Les CGI parcourent le fichier de configuration principal et le(s) fichier(s) de configuration des hôtes, 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 fichier de ressource. 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$.

Eliminer les caractères dangereux des macros

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)