Security/Services/Nagios - Historique des versions

Didier : /* Authentication avec des certificats SSL */

2013-06-29T10:11:48Z

Authentication avec des certificats SSL

@@ Ligne 111 : / Ligne 111 : @@
 </Location>
 </syntaxhighlight>
 = Sécuriser nrpe =

Didier : /* Sécuriser nrpe */

2013-06-29T08:59:25Z

Sécuriser nrpe

@@ Ligne 91 : / Ligne 91 : @@
 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$
 = Sécuriser nrpe =

Didier : /* Eliminer les caractères dangereux des macros */

2013-01-19T15:44:31Z

Eliminer les caractères dangereux des macros

← Version précédente		Version du 19 janvier 2013 à 15:44
Ligne 91 :		Ligne 91 :
	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:		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$		$OUTPUT$, $PERFDATA$

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

Didier : /* Idées sur la sécurisation du service nagios */

2012-12-22T16:51:07Z

Idées sur la sécurisation du service nagios

← Version précédente		Version du 22 décembre 2012 à 16:51
Ligne 1 :		Ligne 1 :
	= Idées sur la sécurisation du service 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.		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 configurer Apache pour une '''connection sécurisée par https~~''', ainsi qu'une '''authentification par htaccess~~'''.		Bien entendu, le premier pas est de [[Security/Services/Apache\| Sécuriser Apache]] et de configurer Apache pour utiliser une '''connection sécurisée par https'''.

	== Ne pas lancer Nagios en tant que Root! ==		== Ne pas lancer Nagios en tant que Root! ==

Didier : /* Idées sur la sécurisation du service nagios */

2012-12-22T14:40:19Z

Idées sur la sécurisation du service nagios

← Version précédente		Version du 22 décembre 2012 à 14:40
Ligne 1 :		Ligne 1 :
	= Idées sur la sécurisation du service 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]~~		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 configurer Apache pour une '''connection sécurisée par https''', ainsi qu'une '''authentification par htaccess'''.

	== Ne pas lancer Nagios en tant que Root! ==		== Ne pas lancer Nagios en tant que Root! ==

Didier : /* Eliminer les caractères dangereux des macros */

2012-12-22T14:34:29Z

Eliminer les caractères dangereux des macros

← Version précédente		Version du 22 décembre 2012 à 14:34
Ligne 75 :		Ligne 75 :

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

Didier : /* Donner les autorisations adaptées au fichier des commandes externes */

2012-12-22T14:32:12Z

Donner les autorisations adaptées au fichier des commandes externes

← Version précédente		Version du 22 décembre 2012 à 14:32
Ligne 56 :		Ligne 56 :
	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 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.		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 [http://cgiwrap.unixtools.org 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.		Les instructions relatives aux autorisations à donner au fichier de commandes externes se trouvent ici.

Didier : /* Autoriser les commandes externes seulement si c'est nécessaire */

2012-12-22T14:30:24Z

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

← Version précédente		Version du 22 décembre 2012 à 14:30
Ligne 9 :		Ligne 9 :

	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, 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 <tt>ls -al /var/lib/nagios/rw</tt>. 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 ==		== Donner les autorisations adaptées au fichier des commandes externes ==

Didier : Page créée avec « = 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... »

2012-12-22T14:21:06Z

Page créée avec « = 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... »

Nouvelle page

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

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

Security/Services/Nagios - Historique des versions

Didier : /* Authentication avec des certificats SSL */

Didier : /* Sécuriser nrpe */

Didier : /* Eliminer les caractères dangereux des macros */

Didier : /* Idées sur la sécurisation du service nagios */

Didier : /* Idées sur la sécurisation du service nagios */

Didier : /* Eliminer les caractères dangereux des macros */

Didier : /* Donner les autorisations adaptées au fichier des commandes externes */

Didier : /* Autoriser les commandes externes seulement si c'est nécessaire */

Didier : Page créée avec « = 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... »

Didier : /* Authentication avec des certificats SSL */

Didier : /* Sécuriser nrpe */

Didier : /* Eliminer les caractères dangereux des macros */

Didier : /* Idées sur la sécurisation du service nagios */

Didier : /* Idées sur la sécurisation du service nagios */

Didier : /* Eliminer les caractères dangereux des macros */

Didier : /* Donner les autorisations adaptées au fichier des commandes externes */

Didier : /* Autoriser les commandes externes seulement si c'est nécessaire */

Didier : Page créée avec « = 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... »