Sidebar

fr:manual:installation:requirements:best_practices

Bonnes pratiques pour la configuration sécurisée de Zabbix

Aperçu

Cette section contient les bonnes pratiques à suivre pour configurer Zabbix de manière sécurisée.

Les pratiques expliquées ici ne sont pas obligatoires pour faire fonctionner Zabbix. Elles sont recommandées pour une meilleure sécurité du système.

Principe du moindre privilège

Le principe de moindre privilège devrait être utilisé à tout moment pour Zabbix. Ce principe signifie que les comptes utilisateurs (dans l'interface web Zabbix) ou les utilisateurs au niveau des processus (pour le serveur/proxy Zabbix ou l'agent) ne disposent que des privilèges indispensables à l'exécution des fonctions souhaitées. En d'autres termes, les comptes utilisateurs doivent à tout moment fonctionner avec le moins de privilèges possible.

Donner des autorisations supplémentaires à l'utilisateur 'zabbix' lui permettra d'accéder aux fichiers de configuration et d'exécuter des opérations pouvant compromettre la sécurité globale de l'infrastructure.

Lors de la mise en œuvre du principe du moindre privilège pour les comptes utilisateurs, les types d'utilisateurs de l'interface web de Zabbix doivent être pris en compte. Il est important de comprendre que même si un type d'utilisateur "Zabbix Admin" a moins de privilèges que le type "Zabbix Super Admin", il dispose d'autorisations administratives permettant de gérer la configuration et exécuter des scripts personnalisés.

Certaines informations sont disponibles même pour les utilisateurs non privilégiés. Par exemple, alors que AdministrationScripts n'est pas disponible pour les administrateurs autres que les super administrateurs, les scripts eux-mêmes peuvent être récupérés à l'aide de l'API Zabbix. Limiter les autorisations de script et ne pas ajouter d'informations sensibles (telles que les informations d'identification d'accès, etc.) doit être utilisé pour éviter l'exposition d'informations sensibles disponibles dans les scripts globaux.

Utilisateur sécurisé pour l'agent Zabbix

Dans la configuration par défaut, les processus du serveur et de l'agent Zabbix partage le même utilisateur 'zabbix'. Si vous voulez être sûr que l'agent ne puisse pas accéder à certains détails sensibles de la configuration du serveur (ex : informations de connexion à la base de données), l’agent devrait s’exécuter avec un utilisateur différent :

  1. Créer un utilisateur sécurisé
  2. Indiquer cet utilisateur dans le fichier de configuration de l'agent (paramètre : ’User’).
  3. Redémarrer l'agent avec des droits administrateurs. Les droits seront transférés à l'utilisateur indiqué.

Encodage UTF-8

UTF-8 est le seul encodage supporté par Zabbix. Il est connu pour fonctionner sans aucun défaut de sécurité. Les utilisateurs doivent être conscients qu'il existe des problèmes de sécurité connus s'ils utilisent certains des autres encodages.

Mettre en place le SSL pour l'interface Web

Sur RHEL/Centos, installez le package mod_ssl :

yum install mod_ssl

Créez un répertoire pour les clés SSL :

mkdir -p /etc/httpd/ssl/private
chmod 700 /etc/httpd/ssl/private

Créez le certificat SSL :

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/httpd/ssl/private/apache-selfsigned.key -out /etc/httpd/ssl/​apache-selfsigned.crt 

Remplissez les invites de manière appropriée. La ligne la plus importante est celle qui demande le nom commun. Vous devez entrer le nom de domaine que vous souhaitez associer à votre serveur. Vous pouvez plutôt entrer l'adresse IP publique si vous n'avez pas de nom de domaine. Nous allons utiliser example.com ci dessous.

Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:example.com
Email Address []:

Éditez la configuration SSL Apache :

/etc/httpd/conf.d/ssl.conf
DocumentRoot "/usr/share/zabbix"
ServerName example.com:443
SSLCertificateFile /etc/httpd/ssl/apache-selfsigned.crt
SSLCertificateKeyFile /etc/httpd/ssl/private/apache-selfsigned.key

Redémarrez le service Apache pour appliquer les changements :

systemctl restart httpd.service

Activation de Zabbix dans le répertoire racine de l'URL

Ajoutez un hôte virtuel à la configuration Apache et définissez une redirection permanente pour le document racine vers l'URL sécurisée de Zabbix. N'oubliez pas de remplacer example.com par le nom réel du serveur.

/etc/httpd/conf/httpd.conf

#Add lines

<VirtualHost *:*>
    ServerName example.com
    Redirect permanent / http://example.com
</VirtualHost>

Redémarrez le service Apache pour appliquer les changements :

systemctl restart httpd.service

Activer HTTP Strict Transport Security (HSTS) sur le serveur web

HSTS est appliqué sur l'interface web Zabbix dans les versions 4.0.0 à 4.0.2.

À partir de 4.0.3 pour protéger l'interface web de Zabbix contre les attaques de rétrogradation de protocole, il est recommandé d'activer la politique HSTS sur le serveur web.

Par exemple, pour activer la politique HSTS pour votre interface Zabbix dans la configuration Apache :

/etc/httpd/conf/httpd.conf

ajoutez la directive suivante à la configuration de votre hôte virtuel :

<VirtualHost *:443>
   Header set Strict-Transport-Security "max-age=31536000"
</VirtualHost>

Redémarrez le service Apache pour appliquer les modifications :

systemctl restart httpd.service

Désactiver l'exposition des informations du serveur Web

Il est recommandé de désactiver toutes les signatures de serveur Web dans le cadre du processus de renforcement du serveur Web. Le serveur Web expose la signature logicielle par défaut :

La signature peut être désactivée en ajoutant deux lignes au fichier de configuration Apache (utilisé comme exemple) :

ServerSignature Off
ServerTokens Prod

La signature PHP (X-Powered-By HTTP header) peut être désactivée en changeant le fichier de configuration php.ini (la signature est désactivée par défaut) :

expose_php = Off

Le redémarrage du serveur Web est obligatoire pour que les changements dans le fichier de configuration soient appliqués.

Un niveau de sécurité supplémentaire peut être atteint en utilisant le mod_security (package libapache2-mod-security2) avec Apache. mod_security permet de supprimer la signature du serveur au lieu de supprimer uniquement la version de la signature du serveur. La signature peut être modifiée en n'importe quelle valeur en changeant “SecServerSignature” après l'installation de mod_security.

Reportez-vous à la documentation de votre serveur Web pour obtenir de l'aide sur la suppression/modification des signatures logicielles.

Désactiver les pages d'erreurs par défaut du serveur web

Il est recommandé de désactiver les pages d'erreur par défaut pour éviter toute exposition d'informations. Le serveur Web utilise par défaut les pages d'erreur intégrées :

Les pages d'erreur par défaut doivent être remplacées/supprimées dans le cadre du processus de renforcement du serveur Web. La directive “ErrorDocument” peut être utilisée pour définir une page/texte d'erreur personnalisé pour le serveur web Apache (utilisé comme exemple).

Reportez-vous à la documentation de votre serveur Web pour obtenir de l'aide sur la façon de remplacer/supprimer les pages d'erreur par défaut.

Suppression de la page de test du serveur web

Il est recommandé de supprimer la page de test du serveur Web pour éviter toute exposition d'informations. Par défaut, le webroot du serveur web contient une page de test appelée index.html (Apache2 sur Ubuntu est utilisé comme exemple) :

La page de test doit être supprimée ou doit être rendue indisponible dans le cadre du processus de renforcement du serveur Web.