Cette section contient les bonnes pratiques à suivre pour configurer Zabbix de manière sécurisée.
Les pratiques expliquées ici ne sont pas obligatoire pour faire fonctionner Zabbix. Elles sont recommandées pour une meilleure sécurité du système.
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 à base de données), l’agent devrait s’exécuter avec un utilisateur différent :
Sur RHEL/Centos, installez le package mod_ssl :
Créez un repertoire pour les clés SSL :
Ajoutez les paramètres SSL :
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) []:localhost
Email Address []:
Éditez la configuration SSL Apache :
/etc/httpd/conf.d/ssl.conf
DocumentRoot "/usr/share/zabbix"
ServerName localhost:443
SSLCertificateFile /etc/httpd/ssl/apache.crt
SSLCertificateKeyFile /etc/httpd/ssl/apache.key
Redémarrez le service Apache pour appliquer les changements :
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. Remplacez localhost par le nom réel du serveur.
/etc/httpd/conf/httpd.conf
#Add lines
<VirtualHost *:*>
ServerName localhost
Redirect permanent / http://localhost
</VirtualHost>
Redémarrez le service Apache pour appliquer les modifications :
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) :
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) :
Le redémarrage du serveur Web est obligatoire pour qur 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.
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.
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.
It is recommended to disable all web server signatures as part of the web server hardening process. The web server is exposing software signature by default:
The signature can be disabled by adding two lines to the Apache (used as an example) configuration file:
PHP signature (X-Powered-By HTTP header) can be disabled by changing the php.ini configuration file (signature is disabled by default):
Web server restart is required for configuration file changes to be applied.
Additional security level can be achieved by using the mod_security (package libapache2-mod-security2) with Apache. mod_security allows to remove server signature instead of only removing version from server signature. Signature can be altered to any value by changing "SecServerSignature" to any desired value after installing mod_security.
Please refer to documentation of your web server to find help on how to remove/change software signatures.
It is recommended to disable default error pages to avoid information exposure. Web server is using built-in error pages by default:
Default error pages should be replaced/removed as part of the web server hardening process. The "ErrorDocument" directive can be used to define a custom error page/text for Apache web server (used as an example).
Please refer to documentation of your web server to find help on how to replace/remove default error pages.
It is recommended to remove the web server test page to avoid information exposure. By default, web server webroot contains a test page called index.html (Apache2 on Ubuntu is used as an example):
The test page should be removed or should be made unavailable as part of the web server hardening process.
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.
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.
In Zabbix Java gateway with logback version 1.2.7 and prior versions, an attacker with the required privileges to edit configuration files could craft a malicious configuration allowing to execute arbitrary code loaded from LDAP servers.
Vulnerability to CVE-2021-42550 has been fixed since Zabbix 5.4.9. However, as an additional security measure it is recommended to check permissions to the /etc/zabbix/zabbix_java_gateway_logback.xml
file and set it read-only, if write permissions are available for the "zabbix" user.