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. Bien entendu, le premier pas est de Sécuriser Apache et de configurer Apache pour utiliser une connection sécurisée par https.
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$
Authentication avec des certificats SSL
Configuration d'Apache
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl/nagios-hostcert.pem
SSLCertificateKeyFile /etc/apache2/ssl/nagios-hostkey.pem
SSLCACertificatePath /etc/grid-security/certificates
SSLCACertificateFile /etc/apache2/ssl/cacert.crt
SSLOptions +ExportCertData +CompatEnvVars +StdEnvVars
SSLVerifyClient require
SSLVerifyDepth 2
SSLUserName SSL_CLIENT_S_DN
<Location /nagios>
SSLRequire %{SSL_CLIENT_S_DN} eq "/C=UK/O=eScience/OU=Manchester/L=HEP/CN=colin morey" \
or %{SSL_CLIENT_S_DN} eq "/C=UK/O=eScience/OU=Manchester/L=HEP/CN=Someone Else"
</Location>
Nagios 3 can use SSL client certificate authentication, but it is poorly documented. The authentication itself is done by the webserver (apache?) and nagios only reads the username from the SSL variables. Unfortunately, the nagios documentation does not state which variable is read, or if it can be configured. After a quick source code review (thank god nagios is open source!) I figured what's going on.
In /etc/nagios3/cgi.conf you'll find
use_ssl_authentication = 0
Setting this value to 1 will cause nagios to treat SSL_CLIENT_S_DN_CN as the username. If you want to use some other variable (E.G. SSL_CLIENT_S_DN_Email) you need to set use_ssl_authentication to 0 even though you are using SSL authentication, and set SSLUserName or the equivalent directive in the webserver to the variable you want. SSLUserName will set REMOTE_USER, which is what nagios is checking when use_ssl_authentication is 0.
Now you can just add the username to the authorization directives in /etc/nagios3/cgi.conf. Spaces shouldn't be a problem because nagios uses , as the delimiter.
It doesn't mean what you think it does.
Longer explanation The webserver (apache, nginx or whatever) does the actual authentication and should set CGI variables accordingly. Usually the REMOTE_USER variable is set with the name of the authenticated user. When using X509 authentication in Apache (for example), the SSL module allows setting arbitrary SSL variable to REMOTE_USER. Nagios in normal authentication mode checks REMOTE_USER and the use_ssl_authentication config causes it to check SSL_CLIENT_S_DN_CN instead. This may be what you want, busupt if you want to use some other SSL variable you need to ditch Nagios SSL auth support and work with Apache's SSL module to set REMOTE_USER. This is convenient because SSL_CLIENT_S_DN_CN is long and annoying as username (and can contain possibly invalid character such as spaces).
A common pitfall is Apache's FakeBasicAuth SSL option - it will set REMOTE_USER to SSL_CLIENT_S_DN which is probably not what want.
Sécuriser nrpe
This sections we will look at ways you can make NRPE more secure. This remote agent is used to execute programs on an remote host for doing checks like the load or disk usage. Since we don't want any programs or users being able to execute commands on our remote machines it's important to spend some time to make NRPE more secure.
Since NRPE come with support for TCP wrappers we can define which hosts have access to it.
Example /etc/hosts.allow
nrpe:192.168.1.91
This will allow only 192.168.1.91 to be able to use this remote agent on this host. You should replace this with the IP address of your Nagios client. Note this should be used on both your Nagios server and client.
NRPE should never run as root or any other superusers it should only be run as a nagios user in the group nagios. In /etc/nagios/nrpe.cfg you can check weather or not it's running as nagios.
Example part of /etc/nagios/nrpe.cfg
nrpe_user=nagios nrpe_group=nagios
Another part of NRPE that can be a security hole is allowing command arguments. We don't want attacks to send malicious arguments that can compromise our system. Some times we need to allow Nagios to send command arguments but if you don't need it to be enable which most times they are not needed then you should definitely disable them.
To disable them edit /etc/nagios/nrpe.cfg and make sure that you have the below line:
dont_blame_nrpe=0
Make user you restart nrpe to if you make any changes to nrpe.cfg. For more information on how to secure NRPE please read the file called SECURITY in the packages source file.