Security/Services/Nagios

Idées sur la sécurisation du service nagios

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.

Par défaut, Nagios ne contrôle, ni ne traite les commandes externes. Si vous voulez autoriser le traitement des commandes externes, il faut effectuer les choses suivantes...

• Activer le contrôle des commandes externes à l'aide de l'option check_external_commands
• Régler la fréquence des contrôles de commande à l'aide de l'option command_check_interval
• Préciser l'emplacement du fichier de commande à l'aide de l'option command_file
• configurer les bonnes autorisations pour le répertoire contenant les fichiers de commande.

Configurer les bonnes autorisations pour le répertoire contenant les fichiers de commande

Créez le répertoire dans lequel le fichier de commande devra être stocké. Par défaut, c'est /var/lib/nagios/rw, bien qu'il puisse être changé en modifiant le chemin specifié dans le répertoire command_file.

mkdir -p /var/lib/nagios/rw

Configuration des permissions du répertoire

Ensuite, changez le propriétaire du répertoire qui va être utilisé pour garder le fichier de commande...

chown nagios.nagios /var/lib/nagios/rw

Assurez-vous que l'utilisateur Nagios dispose de toutes les permissions sur ce répertoire...

chmod u+rwx /var/lib/nagios/rw

Assurez-vous que le groupe que vous avez créé a les permissions de lecture et d'écriture sur le répertoire.

chmod g+rw /var/lib/nagios/rw

Pour forcer les fichiers nouvellement créés dans le répertoire a hériter des permissions de groupe du répertoire, il nous faut activer le bit de rappel [sticky bit] du groupe sur le répertoire...

chmod g+s /var/lib/nagios/rw

Vérification des permissions

Vérifiez les permissions sur le sous-répertoire rw/ en tapant ls -al /var/lib/nagios/rw. Vous devriez voir quelque chose ressemblant à :

drwxrws---   2 nagios nagios     1024 Aug 11 16:30 rw

Notez que l'utilisateur nagios est le propriétaire du répertoire et que le groupe nagios est le groupe propriétaire du répertoire. L'utilisateur nagios a les permissions rwx et le groupe nagios a les permissions rw sur le répertoire. Notez également que le bit de rappel du groupe est activé. C'est ce que nous voulons...

Redémarrez votre serveur Http

Une fois que vous avez mis des permissions correctes sur le répertoire contenant les fichiers de commande externe, assurez vous que vous avez redémarrer votre serveur http. Si vous ne le faites pas, apache ne sera pas autorisé à écrire dans le fichier de commandes externes, meme si l'utilisateur qui fait tourner celui-ci est membre du groupe nagios.

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 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)

Caractères illégaux dans les noms d'objets

Format: 	illegal_object_name_chars=<chars...>
Exemple: 	illegal_object_name_chars=`~!$%^&*"|'<>?,()=

Cette option vous permet de spécifier quels sont les caractères illégaux dans les noms d'objets, tels que hotes, services et autres. Nagios vous autorisera la plupart des caractères dans les définitions d'objets, mais je recommande de ne pas utiliser les caractères ci-dessus. Le faire est s'exposer à des problèmes dans l'interface web, les notifications de commandes, etc.

Caractères illégaux dans la sortie des macros

Format: 	illegal_macro_output_chars=<chars...>
Exemple: 	illegal_macro_output_chars=`~$^&"|'<>

Cette option vous permet de spécifier les caractères illégaux qui seront filtrés dans les macros, avant qu'elles soient utilisées dans les notifications, les gestionnaires d'évènements et autres commandes. Ceci n'affecte pas les macros utilisées dans les controles des services ou des hotes. Vous pouvez choisir de ne pas filtrer les caractères donnés en exemple ci-dessus, mais je ne vous recommande pas de le faire. Quelques uns d'entre eux sont interprètés par le shell ( par exemple, le ` ) et peuvent poser des problèmes de sécurité. Les macros suivantes sont débarassées des caractères spécifiés: $OUTPUT$, $PERFDATA$