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

Aperçu

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

Les pratiques contenues ici ne sont pas nécessaires au fonctionnement de Zabbix. Elles sont recommandées pour une meilleure sécurité du système.

Contrôle d'accès

Principe du moindre privilège

Le principe du moindre privilège doit être utilisé à tout moment dans Zabbix. Ce principe signifie que les comptes d'utilisateurs (dans l'interface Zabbix) ou les utilisateurs de processus (pour le serveur/proxy ou l'agent Zabbix) n'ont que les privilèges essentiels pour exécuter les fonctions prévues. En d'autres termes, les comptes d'utilisateurs doivent à tout moment fonctionner avec le moins de privilèges possible.

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

Utilisateur sécurisé pour l'agent Zabbix

Dans la configuration par défaut, les processus du serveur Zabbix et de l'agent Zabbix partagent un utilisateur 'zabbix'. Si vous souhaitez vous assurer que l'agent ne peut pas accéder aux détails sensibles dans la configuration du serveur (par exemple, les informations de connexion à la base de données), l'agent doit être exécuté en tant qu'utilisateur différent :

1. Créez un utilisateur sécurisé
2. Spécifiez cet utilisateur dans le fichier de configuration de l'agent (paramètre 'User')
3. Redémarrez l'agent avec des privilèges d'administrateur. Les privilèges seront abandonnés à l'utilisateur spécifié.

Encodage UTF-8

UTF-8 est le seul encodage pris en charge par Zabbix. Il est connu pour fonctionner sans aucune faille de sécurité. Les utilisateurs doivent être conscients qu'il existe des problèmes de sécurité si vous utilisez certains des autres encodages.

Chemins d'installation sur Windows

Lorsque vous utilisez des programmes d'installation Windows, il est recommandé d'utiliser les chemins par défaut fournis par le programme d'installation car l'utilisation de chemins personnalisés sans les autorisations appropriées pourrait compromettre la sécurité de l'installation.

Configuration de SSL pour l'interface Zabbix

Sur RHEL/Centos, installez le package mod_ssl :

yum install mod_ssl

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

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

Créer un 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

Remplir les invites de commande de manière appropriée. La ligne la plus importante est celle qui demande le nom commun. Vous devez saisir le nom de domaine que vous souhaitez associer à votre serveur. Vous pouvez saisir l'adresse IP publique à la place si vous n'avez pas de nom de domaine. Nous utiliserons example.com dans cet article.

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 []:

Editer la configuration SSL d'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émarrer le service Apache pour appliquer les modifications :

systemctl restart httpd.service

Renforcement du serveur Web

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

Ajouter un hôte virtuel à la configuration Apache et définissez une redirection permanente pour la racine du document vers l'URL SSL Zabbix. Ne pas oublier de remplacer example.com par le nom réel du serveur.

/etc/httpd/conf/httpd.conf
       
       #Ajouter les lignes 
       
       <VirtualHost *:*>
           ServerName example.com
           Redirect permanent / https://example.com
       </VirtualHost>

Redémarrer le service Apache pour appliquer les modifications :

systemctl restart httpd.service

Activation de HTTP Strict Transport Security (HSTS) sur le serveur Web

Pour protéger l'interface Zabbix contre les attaques de rétrogradation de protocole, nous vous recommandons d'activer la politique HSTS sur le serveur Web.

Par exemple, pour activer la politique HSTS pour votre frontend 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émarrer le service Apache pour appliquer les modifications :

systemctl restart httpd.service

Enabling Content Security Policy (CSP) on the web server

To protect Zabbix frontend against Cross Site Scripting (XSS), data injection, and similar attacks, we recommend enabling Content Security Policy on the web server. To do so, configure the web server to return the HTTP header.

To enable CSP for your Zabbix frontend in Apache configuration, follow these steps:

1. Locate your virtual host's configuration file:

• /etc/httpd/conf/httpd.conf on RHEL-based systems
• /etc/apache2/sites-available/000-default.conf on Debian/Ubuntu

2. Add the following directive to your virtual host's configuration file:

<VirtualHost *:*>
           Header set Content-Security-Policy: "default-src 'self' *.openstreetmap.org; script-src 'self' 'unsafe-inline' 'unsafe-eval'; connect-src 'self'; img-src 'self' data: *.openstreetmap.org; style-src 'self' 'unsafe-inline'; base-uri 'self'; form-action 'self';"
       </VirtualHost>

3. Restart the Apache service to apply the changes:

# On RHEL-based systems:
       systemctl restart httpd.service
       
       # On Debian/Ubuntu
       systemctl restart apache2.service

Désactivation de 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 d'Apache (utilisé comme exemple) :

ServerSignature Off
       ServerTokens Prod

La signature PHP (en-tête HTTP X-Powered-By) peut être désactivée en modifiant 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 nécessaire pour que les modifications du fichier de configuration soient appliquées.

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 à n'importe quelle valeur en changeant "SecServerSignature" après l'installation de mod_security.

Veuillez vous référer à la documentation de votre serveur Web pour trouver de l'aide sur la façon de supprimer/modifier les signatures logicielles.

Désactivation des pages d'erreur du serveur Web par défaut

Il est recommandé de désactiver les pages d'erreur par défaut pour éviter l'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/un texte d'erreur personnalisé pour le serveur Web Apache (utilisé comme exemple).

Veuillez vous référer à la documentation de votre serveur Web pour trouver 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 l'exposition d'informations. Par défaut, la racine 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 rendue indisponible dans le cadre du processus de renforcement du serveur Web.

Définir l'en-tête de réponse HTTP X-Frame-Options

Par défaut, Zabbix est configuré avec l'en-tête de réponse HTTP X-Frame-Options défini sur SAMEORIGIN, ce qui signifie que le contenu ne peut être chargé que dans un cadre (frame html) qui a la même origine que la page elle-même.

Les éléments du frontend de Zabbix qui extraient le contenu d'URL externes (à savoir, le widget de tableau de bord URL) affichent le contenu récupéré dans un sandbox avec toutes les restrictions de sandbox activées.

Ces paramètres améliorent la sécurité de l'interface Zabbix et offrent une protection contre les attaques XSS et de détournement de clic. Les super-administrateurs peuvent modifier les paramètres iframe sandboxing et X-Frame-Options HTTP response header selon les besoins. Veuillez peser soigneusement les risques et les avantages avant de modifier les paramètres par défaut. Il n'est pas recommandé de désactiver complètement le sandboxing ou X-Frame-Options.

Révoquer l'accès en écriture au fichier de configuration SSL dans Windows

L'agent Zabbix Windows compilé avec OpenSSL essaiera d'atteindre le fichier de configuration SSL dans c:\openssl-64bit. Le répertoire "openssl-64bit" sur le disque C: peut être créé par des utilisateurs non privilégiés.

Ainsi, pour renforcer la sécurité, il est nécessaire de créer ce répertoire manuellement et de révoquer l'accès en écriture aux utilisateurs non administrateurs.

Veuillez noter que les noms de répertoire seront différents sur les versions 32 bits et 64 bits de Windows.

Cryptographie

Masquer le fichier avec la liste des mots de passe communs

Pour augmenter la complexité des attaques par force brute de mot de passe, il est suggéré de limiter l'accès au fichier ui/data/top_passwords.txt en modifiant la configuration du serveur Web. Ce fichier contient une liste des mots de passe les plus courants et spécifiques au contexte, et est utilisé pour empêcher les utilisateurs de définir de tels mots de passe si le paramètre Avoid easy-to-guess passwords est activé dans la politique de mot de passe.

Par exemple, sur NGINX, l'accès aux fichiers peut être limité en utilisant la directive "location" :

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

Sur Apache - en utilisant le fichier .htaccess :

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

Avis de sécurité Zabbix et base de données CVE

Voir Avis de sécurité Zabbix et base de données CVE.