[comment]: # translation:outdated

[comment]: # ({f4bccb67-40cfdec2})
# 3 Serveur web

[comment]: # ({/f4bccb67-40cfdec2})

[comment]: # ({2ff4365d-129e34f5})
#### Aperçu

Cette section contient les bonnes pratiques pour configurer le serveur web de manière sécurisée.

[comment]: # ({/2ff4365d-129e34f5})

[comment]: # ({a38dec5b-bb3706f4})
#### Forcer la redirection de l'URL racine vers Zabbix SSL

Sur les systèmes basés sur RHEL, ajoutez un hôte virtuel à la configuration d'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.

```ini
# Ajouter les lignes :

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

Redémarrez le service Apache pour appliquer les modifications :

```bash
systemctl restart httpd.service
```

[comment]: # ({/a38dec5b-bb3706f4})

[comment]: # ({3d62d250-c7ee0bb2})
#### 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 recommandons d'activer la politique [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) sur le serveur web.

Pour activer la politique HSTS pour votre interface Zabbix dans la configuration Apache, procédez comme suit :

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 l'instruction suivante au fichier de configuration de votre hôte virtuel :

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

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

```bash
# On RHEL-based systems:
systemctl restart httpd.service

# On Debian/Ubuntu
systemctl restart apache2.service
```

[comment]: # ({/3d62d250-c7ee0bb2})

[comment]: # ({09df8737-8057bf9f})
#### Application des cookies de session Secure et SameSite dans Zabbix

Lors de la configuration de Zabbix, il est essentiel d’imposer les attributs secure et SameSite pour les cookies de session afin d’améliorer la sécurité et de prévenir les attaques de type cross-site request forgery (CSRF). Cependant, l’application de ``SameSite=Strict`` peut poser des problèmes dans certains scénarios, par exemple :

-   Les widgets d’URL du tableau de bord affichent « user not logged in » 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.
-   Il est impossible 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 pouvoir ajuster la politique SameSite.

1\. Cookies sécurisés

La définition du drapeau ``secure`` garantit que les cookies ne sont transmis que via HTTPS, ce qui empêche leur exposition sur des connexions non chiffrées.

Pour activer les cookies sécurisés 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 votre interface Zabbix est accessible via HTTPS ; sinon, les cookies avec le drapeau ``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; # Replace ~ with 'zbx_session' for specificity

[comment]: # ({/09df8737-8057bf9f})

[comment]: # ({0291801e-55d3532e})
#### Activation de 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 les attaques similaires, nous recommandons d'activer Content Security Policy sur le serveur web.
Pour ce faire, configurez le serveur web afin qu'il renvoie l'[en-tête HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy).

::: noteimportant
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*](/manual/web_interface/frontend_sections/dashboards/widgets/url) pour afficher du contenu provenant des sous-domaines du site ou de domaines externes, si vous passez d'*OpenStreetMap* à un autre moteur de cartographie, ou si vous ajoutez du CSS externe ou des widgets.
Si vous utilisez la méthode d'authentification multifacteur [Duo Universal Prompt](/manual/web_interface/frontend_sections/users/authentication/mfa), 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, procédez comme suit :

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 :

```ini
<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 :

```bash
# On RHEL-based systems:
systemctl restart httpd.service

# On Debian/Ubuntu
systemctl restart apache2.service
```

[comment]: # ({/0291801e-55d3532e})

[comment]: # ({cc2b15aa-cd09dcd1})
#### 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 :

![](../../../../assets/en/manual/installation/requirements/software_signature.png)

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

```ini
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) :

```ini
expose_php = Off
```

Le 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 (package *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 modifiée pour 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 obtenir de l’aide sur la suppression ou la modification des signatures logicielles.

[comment]: # ({/cc2b15aa-cd09dcd1})

[comment]: # ({2053690e-720052da})
#### Désactivation des pages d'erreur par défaut du serveur web

Pour éviter toute exposition 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 :

![](../../../../assets/en/manual/installation/requirements/error_page_text.png)

Ces pages d'erreur par défaut doivent être remplacées/supprimées.
Par exemple, l'instruction "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 obtenir de l'aide sur la manière de remplacer/supprimer les pages d'erreur par défaut.

[comment]: # ({/2053690e-720052da})

[comment]: # ({5dd327a4-ba1547c0})
#### Suppression de la page de test du serveur web

Pour éviter toute exposition 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` :

![](../../../../assets/en/manual/installation/requirements/test_page.png)

Veuillez consulter la documentation de votre serveur web pour obtenir de l'aide sur la suppression des pages de test par défaut.

[comment]: # ({/5dd327a4-ba1547c0})

[comment]: # ({47163d34-7e4e4a45})
#### Définir l'en-tête de réponse HTTP X-Frame-Options

Par défaut, Zabbix est configuré avec le paramètre *Utiliser l'en-tête HTTP X-Frame-Options* 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 de l'interface Zabbix qui récupèrent du contenu à partir d'URL externes (à savoir le [widget de tableau de bord URL](/manual/web_interface/frontend_sections/dashboards/widgets/url)) affichent le contenu récupéré dans un sandbox avec toutes les restrictions de sandboxing activées.

Ces paramètres renforcent la sécurité de l'interface Zabbix et offrent une protection contre les attaques XSS et de clickjacking.
Les utilisateurs *super administrateur* peuvent [modifier](/manual/web_interface/frontend_sections/administration/general#security) les paramètres *Utiliser le sandboxing des iframes* et *Utiliser l'en-tête HTTP X-Frame-Options* selon les besoins.
Veuillez évaluer 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 des iframes ou l'en-tête HTTP X-Frame-Options.

[comment]: # ({/47163d34-7e4e4a45})

[comment]: # ({35ac3238-3f76ae70})
#### Masquer le 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](/manual/web_interface/frontend_sections/users/authentication#internal-authentication)).

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

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

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

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

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

[comment]: # ({/35ac3238-3f76ae70})
