Sur les systèmes basés sur RHEL, ajoutez un hôte virtuel à la configuration Apache (/etc/httpd/conf/httpd.conf) et définissez une redirection permanente de la racine du document vers l’URL SSL de Zabbix. Notez que example.com doit être remplacé par le nom réel du serveur.

# Ajoutez les lignes suivantes :

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

Redémarrez 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 le frontend Zabbix contre les attaques de rétrogradation de protocole, nous recommandons d’activer la politique HSTS sur le serveur web.

Pour activer la politique HSTS pour votre frontend Zabbix dans la configuration Apache, suivez ces étapes :

1. Localisez le fichier de configuration de votre hôte virtuel :

/etc/httpd/conf/httpd.conf sur les systèmes basés sur RHEL
/etc/apache2/sites-available/000-default.conf sur Debian/Ubuntu

2. Ajoutez la directive suivante au fichier de configuration de votre hôte virtuel :

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

3. Redémarrez le service Apache pour appliquer les modifications :

# Sur les systèmes basés sur RHEL :
systemctl restart httpd.service

# Sur Debian/Ubuntu
systemctl restart apache2.service

Application des cookies de session Secure et SameSite dans Zabbix

Lors de la configuration de Zabbix, il est essentiel d’appliquer les attributs Secure et SameSite aux cookies de session afin de renforcer la sécurité et de prévenir les attaques de falsification de requête intersites (CSRF). Cependant, l’application de SameSite=Strict peut poser des problèmes dans certains scénarios, tels que :

Les widgets d’URL du tableau de bord affichent « utilisateur non connecté » lors de l’intégration d’iframes du même domaine.
Les utilisateurs accédant au tableau de bord via HTTP au lieu de HTTPS peuvent rencontrer des problèmes de connexion.
L’impossibilité de partager des URL vers des sections spécifiques du menu Zabbix ou vers des hôtes.

Pour atténuer ces problèmes, les utilisateurs doivent disposer d’un moyen d’ajuster la politique SameSite.

1. Cookies Secure

Le paramètre secure garantit que les cookies ne sont transmis que via HTTPS, évitant ainsi leur exposition sur des connexions non chiffrées.

Pour activer les cookies Secure dans Zabbix, ajoutez ou modifiez le paramètre suivant dans la configuration du serveur web :

Pour Apache :

Header always edit Set-Cookie ^(.*)$ $1;Secure

Pour Nginx :

proxy_cookie_path / "/; Secure";

Assurez-vous que l’interface web de Zabbix est accessible via HTTPS ; sinon, les cookies avec l’attribut Secure ne seront pas envoyés.

2. Configuration de l’attribut SameSite

Les paramètres du serveur web peuvent également imposer l’attribut SameSite :

Pour Apache :

<IfModule mod_headers.c>
    Header onsuccess edit Set-Cookie (.*) "$1; SameSite=Strict"
</IfModule>

Pour Nginx (version 1.19.3+) :

proxy_cookie_flags ~ samesite=Strict; # Remplacez ~ par 'zbx_session' pour plus de précision

Activation de la Content Security Policy (CSP) sur le serveur web

Pour protéger l’interface Zabbix contre les attaques de type Cross Site Scripting (XSS), l’injection de données et d’autres attaques similaires, nous recommandons d’activer la Content Security Policy sur le serveur web. Pour ce faire, configurez le serveur web afin qu’il renvoie l’en-tête HTTP.

La configuration d’en-tête CSP suivante s’applique uniquement à l’installation par défaut de l’interface Zabbix et aux cas où tout le contenu provient du domaine du site (à l’exclusion des sous-domaines). Une configuration d’en-tête CSP différente peut être nécessaire si, par exemple, vous configurez le widget URL pour afficher du contenu provenant des sous-domaines du site ou de domaines externes, si vous remplacez OpenStreetMap par un autre moteur de carte, ou si vous ajoutez des widgets ou des feuilles de style CSS externes. Si vous utilisez la méthode d’authentification multifacteur Duo Universal Prompt, veillez à ajouter "duo.com" à la directive CSP dans le fichier de configuration de votre hôte virtuel.

Pour activer CSP pour votre interface Zabbix dans la configuration Apache, suivez les étapes suivantes :

1. Localisez le fichier de configuration de votre hôte virtuel :

/etc/httpd/conf/httpd.conf sur les systèmes basés sur RHEL
/etc/apache2/sites-available/000-default.conf sur Debian/Ubuntu

2. Ajoutez la directive suivante au fichier de configuration de votre hôte virtuel :

<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. Redémarrez le service Apache pour appliquer les modifications :

# Sur les systèmes basés sur RHEL :
systemctl restart httpd.service

# Sur Debian/Ubuntu
systemctl restart apache2.service

Désactivation de l’exposition des informations du serveur web

Pour améliorer la sécurité, il est recommandé de désactiver toutes les signatures du serveur web.

Par défaut, le serveur web expose la signature du logiciel :

La signature peut être désactivée en ajoutant les paramètres suivants au fichier de configuration Apache :

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 (par défaut, la signature est désactivée) :

expose_php = Off

Un redémarrage du serveur web est nécessaire pour que les modifications du fichier de configuration soient appliquées.

Pour une sécurité supplémentaire, vous pouvez utiliser l’outil mod_security avec Apache (paquet libapache2-mod-security2). Cet outil permet de supprimer la signature du serveur au lieu de supprimer uniquement la version de la signature du serveur. La signature du serveur peut être remplacée par n’importe quelle valeur en définissant "SecServerSignature" sur la valeur souhaitée après l’installation de mod_security.

Veuillez consulter la documentation de votre serveur web pour savoir comment supprimer/modifier les signatures logicielles.

Désactivation des pages d’erreur par défaut du serveur web

Pour éviter toute divulgation d’informations, il est recommandé de désactiver les pages d’erreur par défaut.

Par défaut, un serveur web utilise des pages d’erreur intégrées :

Ces pages d’erreur par défaut doivent être remplacées/supprimées. Par exemple, la directive « ErrorDocument » peut être utilisée pour définir une page/un texte d’erreur personnalisé pour le serveur web Apache.

Veuillez consulter la documentation de votre serveur web pour savoir comment remplacer/supprimer les pages d’erreur par défaut.

Suppression de la page de test du serveur web

Pour éviter toute divulgation d’informations, il est recommandé de supprimer la page de test du serveur web.

Par défaut, la racine web du serveur web Apache contient la page de test index.html :

Veuillez consulter la documentation de votre serveur web pour savoir comment supprimer les pages de test par défaut.

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

Par défaut, Zabbix est configuré avec le paramètre Use X-Frame-Options HTTP header défini sur SAMEORIGIN. Cela signifie que le contenu ne peut être chargé que dans un cadre ayant la même origine que la page elle-même.

Les éléments du frontend Zabbix qui récupèrent du contenu à partir d’URL externes (à savoir le widget de tableau de bord URL) affichent le contenu récupéré dans un bac à sable avec toutes les restrictions de sandboxing activées.

Ces paramètres renforcent la sécurité du frontend Zabbix et offrent une protection contre les attaques XSS et de clickjacking. Les utilisateurs Super admin peuvent modifier les paramètres Use iframe sandboxing et Use X-Frame-Options HTTP header selon les besoins. Veuillez évaluer attentivement 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 des iframes ou l’en-tête HTTP X-Frame-Options.

Masquage du fichier contenant la liste des mots de passe courants

Pour augmenter la complexité des attaques par force brute sur les mots de passe, il est recommandé de limiter l'accès au fichier ui/data/top_passwords.txt. Ce fichier contient une liste des mots de passe les plus courants et spécifiques au contexte, et empêche les utilisateurs de définir de tels mots de passe (si le paramètre Éviter les mots de passe faciles à deviner est activé dans la politique de mot de passe).

Pour limiter l'accès au fichier top_passwords.txt, modifiez la configuration de votre serveur web.

Sous Apache, l'accès au fichier peut être limité à l'aide du fichier .htaccess :

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

Sous NGINX, l'accès au fichier peut être limité à l'aide de la directive location :

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

What’s next?

2 Bonnes pratiques de configuration

Docs

3 Serveur web

Vue d'ensemble

Activation de Zabbix à la racine de l’URL