Table of Contents

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

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.

Access control

Principle of least privilege

The principle of least privilege should be used at all times for Zabbix. This principle means that user accounts (in Zabbix frontend) or process user (for Zabbix server/proxy or agent) have only those privileges that are essential to perform intended functions. In other words, user accounts at all times should run with as few privileges as possible.

Giving extra permissions to 'zabbix' user will allow it to access configuration files and execute operations that can compromise the overall security of the infrastructure.

When implementing the least privilege principle for user accounts, Zabbix frontend user types should be taken into account. It is important to understand that while a "Admin" user type has less privileges than "Super Admin" user type, it has administrative permissions that allow managing configuration and execute custom scripts.

Some information is available even for non-privileged users. For example, while Administration → Scripts is not available for non-Super Admins, scripts themselves are available for retrieval by using Zabbix API. Limiting script permissions and not adding sensitive information (like access credentials, etc) should be used to avoid exposure of sensitive information available in global scripts.

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 :

Créer un utilisateur sécurisé
Indiquer cet utilisateur dans le fichier de configuration de l'agent (paramètre : ’User’).
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.

Zabbix Security Advisories and CVE database

See Zabbix Security Advisories and CVE database.

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

Web server hardening

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

Enabling HTTP Strict Transport Security (HSTS) on the web server

HSTS is enforced by Zabbix frontend in versions 4.0.0 - 4.0.2.

Starting with 4.0.3 to protect Zabbix frontend against protocol downgrade attacks, we recommend to enable HSTS policy on the web server.

For example, to enable HSTS policy for your Zabbix frontend in Apache configuration:

/etc/httpd/conf/httpd.conf

add the following directive to your virtual host's configuration:

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

Restart the Apache service to apply the changes:

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.

Set X-Frame-Options HTTP response header

By default, Zabbix is configured with X-Frame-Options HTTP response header set to SAMEORIGIN, meaning that content can only be loaded in a frame that has the same origin as the page itself.

Zabbix frontend elements that pull content from external URLs (namely, the URL dashboard widget) display retrieved content in a sandbox with all sandboxing restrictions enabled.

These settings enhance the security of the Zabbix frontend and provide protection against XSS and clickjacking attacks. Super Admins can modify iframe sandboxing and X-Frame-Options HTTP response header parameters as needed. Please carefully weigh the risks and benefits before changing default settings. Turning sandboxing or X-Frame-Options off completely is not recommended.

Hiding the file with list of common passwords

To increase the complexity of password brute force attacks, it is suggested to limit access to the file ui/data/top_passwords.txt by modifying web server configuration. This file contains a list of the most common and context-specific passwords, and is used to prevent users from setting such passwords if Avoid easy-to-guess passwords parameter is enabled in the password policy.

For example, on NGINX file access can be limited by using the location directive:

location = /data/top_passwords.txt {
           deny all;
           return 404;
       }

On Apache - by using .htacess file:

<Files "top_passwords.txt">  
         Order Allow,Deny
         Deny from all
       </Files>

Displaying URL content in the sandbox

Since version 4.0.22, some Zabbix frontend elements (for example, the URL widget) are preconfigured to sandbox content retrieved from the URL. It is recommended to keep all sandboxing restrictions enabled to ensure protection against XSS attacks.

Zabbix Windows agent with OpenSSL

Zabbix Windows agent compiled with OpenSSL will try to reach the SSL configuration file in c:\openssl-64bit. The "openssl-64bit" directory on disk C: can be created by non-privileged users.

So for security hardening, it is required to create this directory manually and revoke write access from non-admin users.

Please note that the directory names will be different on 32-bit and 64-bit versions of Windows.

Documentation