Les modules de Apache2

De Wiki Amis SH
Aller à la navigation Aller à la recherche



Le wiki : Accueil - Administrateur - Bureautique - Développeur - Intégrateur - Marketing - Multimédia - Objets numériques - Jeux - We make Hack


Les modules de Apache2

Consulter les modules installés

# Consulter la liste des modules installés, mais pas forcément utilisés, pour Apache2 :
ls /etc/apache2/mods-available/
# Apache2 dispose de nombreux modules complémentaires dont le nom de paquet débute généralement par libapache2.
# Le répertoire /etc/apache2/mods-available/ est alimenté par l'installation de paquets "libapache2-mod-...".
# Obtenir la liste des modules disponibles pour Apache2 :
apt-cache search libapache2
# Pour chaque module existe le couple de fichier .load et .conf qui informe Apache2 sur la façon de charger le module.
# Exemple : Si on installe libapache2-mod-php5, un fichier "php5.load" et "php5.conf" devrait apparaître dans ce répertoire.

Consulter la liste des modules activés

# Consulter la liste des modules activés
sudo ls /etc/apache2/mods-enabled/
# Ce répertoire contient les liens symboliques qui pointent vers les fichiers ".conf" et ".load" des modules devant être chargés au démarrage de Apache2.
# Il suffit de créer les bons liens symboliques pour indiquer à apache2 quels modules charger, et supprimer les liens symboliques des modules qu'on ne souhaite pas charger.
# On utilisera de préférence les deux commandes suivantes pour créer ou supprimer les liens symboliques :
a2enmod : (Apache2 enable module.) : Active un module Apache2.
a2dismod : (Apache2 disable module.) : Désactive un module Apache2.

Optimiser Apache2 en désactivant les modules inutiles

Les modules qui ne sont pas nécessaires n'ont pas besoin de rester activés.
Désactiver par exemple les modules concernant sqlite, quand c'est mysql ou mariadb qui est utilisé.

Activer un module

# La commande suivante active un module pour Apache2.
# Un lien symbolique va être ajouté dans le dossier /etc/apache2/mods-enabled et pointera vers le fichier de définition du module.
a2enmod Nom_du_module
# Redémarrer Apache2 pour prendre en compte l'activation d'un module.
sudo systemctl restart apache2
# Les modules utilisent leur configuration par défaut depuis le répertoire /etc/apache2/mods-available.
# En général deux fichiers existent pour chaque module installé sur le système :
# Un fichier avec une extension .load contient la directive de chargement du module réel, généralement contenu dans le répertoire /usr/lib/apache2/modules/.
# Un fichier avec une extension .conf qui contient la configuration par défaut du module.
# Il est possible de modifier cette configuration par défaut en ajoutant de nouvelles directives.
# Les distributions basée sur Debian proposent un répertoire /etc/apache2/conf.d pour ajouter de nouvelles configurations personnalisées. 
# Créer un nouveau fichier nommé à notre convenance pour ajouter une configuration personnalisée.
# L’ensemble des fichiers sont concaténés à la fin de la configuration de Apache2.
# Tout ce qui concerne Apache2 dans cet article a été testé avec Debian Stretch.
# Il est utile de préciser que a2enmod ne fait pas parti du projet apache et /etc/apache2 n'est pas utilisé sur toutes les distributions.
# Il existe notamment /etc/httpd.

Module Apache2 mod_auth_basic

 Source : https://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html

Module Apache2 mod_auth_digest

 Source : https://httpd.apache.org/docs/2.4/mod/mod_auth_digest.html

Module Apache2 mod_info

# Activer le module :
sudo a2enmod info
# Éditer la configuration du module info :
cd /etc/apache2/mods-available
sudo nano info.conf

# Cette configuration du module mod_info fonctionne pour tous les VirtualHosts.
<Location /server-info>
SetHandler server-info
# Autoriser l'accès à une adresse IP, sinon, la page retournera une erreur 403 :
Require ip xx.xx.xxx.xx
Require ip yy.yy.yyy.yy
</Location>

Interdire la réécriture effectuée par un CMS

# Avec Joomla :
# Arrêter la réécriture du mod rewrite pour certaines adresses URL qui ne doivent pas être réécrites par Joomla.
# Ajouter les deux lignes suivantes au dessous de la dernière redirection dans le fichier .htaccess de Joomla.
# Ne pas effectuer de redirection sur l'adresse server-info utilisée avec le mod_info de Apache2 :
RewriteCond %{REQUEST_URI} !^/server-(info|status)
RewriteRule .* index.php [L]

# Avec WordPress :
# Arrêter la réécriture du mod rewrite pour certaines adresses URL qui ne doivent pas être réécrites par WordPress.
# Ajouter les deux lignes suivantes au dessous de la dernière redirection présente dans le fichier .htaccess de Wordpress.
# Ne pas effectuer de redirection sur l'adresse server-info utilisée avec le mod_info de Apache2 :
RewriteCond %{REQUESTURI} !=/server-info
# Chaque site devra intégrer l'exception de redirection dans son propre fichier .htaccess, pour Joomla, WordPress, ...
# Consulter les statuts du domaine sur une URL de ce format :
https://www.visionduweb.fr/server-info (Sur le VPS1 l'adresse URL server-info est limitée à la consultation depuis le fichier /etc/apache2/mods-available/info.conf.)
# Les outils comme Mediawiki ou Redmine ne nécessiteront pas de modifier une règle de réécriture pour autoriser la consultation de la page server-info. La page sera immédiatement fonctionnelle.
https://redmine.visionduweb.fr/server-info (Sur le VPS1 l'adresse URL server-info est limitée à la consultation depuis le fichier /etc/apache2/mods-available/info.conf.)
https://wiki.visionduweb.fr/server-info (Sur le VPS2 - mod_info n'est pas configurée, server-info ne sera jamais affiché.)
Obtenir l'affichage des dates d'expiration des certificats : https://github.com/icing/mod_md/issues/196
Source officielle : https://httpd.apache.org/docs/2.4/fr/mod/mod_info.html
Source complémentaire : https://github.com/icing/mod_md

Module Apache2 mod_authz_owner

 Source : https://httpd.apache.org/docs/2.4/mod/mod_authz_owner.html

Module Apache2 mod_authz_user

 Source : https://httpd.apache.org/docs/2.4/mod/mod_authz_user.html

Module Apache2 mod_file_cache

Le module mod_file_cache est le plus simple des deux mécanismes de mise en cache entre mod_file_cache et mod_cache.
On préférera mod_cache qui est d'avantage paramétrable.
Tout type de mise en cache peut améliorer les performances d'un site.
Tester le site par après pour vérifier son bon fonctionnement.
Le module mod_file_cache sert a mettre en cache le contenu qui est demandé fréquemment et qui change peu souvent.
Les fichiers ne changeront pas pendant la durée de vie de l'instance Apache actuelle.
Les techniques utilisées avec ce module empêchent la prise en compte des modifications ultérieures jusqu'au redémarrage du serveur.
Ce mécanisme de mise en cache ne peut être utilisé qu'avec des fichiers normaux.
Aucun contenu généré dynamiquement ni aucun fichier généré par des gestionnaires de contenu spéciaux ne fonctionneront ici.
Connaître les répercussions d'une mise en cache mal configurée :
Il est parfois nécessaire de réévaluer vos pratiques de sécurité après la mise en œuvre de la mise en cache.
Vérifier que les ressources privées ne sont pas accidentellement mises en cache pour la consommation publique.
Le module mod_file_cache fournit deux directives utilisées pour effectuer la mise en cache de différentes manières.

Directive MMapFile

MMapFile est une directive utilisée pour créer une liste de fichiers, puis mapper ces fichiers en mémoire.
Il est essentiel qu'aucun des fichiers configurés pour utiliser ce type de mise en cache ne soit modifié.
La création du cache se fait uniquement au démarrage du serveur !
Configurer ce type de mise en cache depuis le fichier de configuration du serveur.
Spécifier les fichiers à mettre en cache en mémoire dans une liste séparée par des espaces :
MMapFile /var/www/index.html /var/www/otherfile.html var/www/static-image.jpg
Ces fichiers seront conservés en mémoire et servis à partir de là lorsque la ressource sera demandée.
Si l'un des fichiers est modifié, vous devez redémarrer le serveur.

Directive CacheFile

Il gère un tableau de ces descripteurs de fichiers ouverts et l'utilise pour réduire le temps nécessaire à l'ouverture de ces fichiers.
Les modifications apportées au fichier pendant le fonctionnement du serveur ne seront pas reconnues par le cache.
Le contenu d'origine continuera d'être servi jusqu'au redémarrage du serveur, pour une nouvelle mise en cache.
Cette directive est utilisée en spécifiant une liste de fichiers séparés par des espaces qui doivent être mis en cache avec cette méthode :
CacheFile /this/file.html that/file.html other/file/to/server.html

Module Apache2 mod_cache

mod_deflate permet la compression des données envoyées au client.
mod_expires permet de configurer le cache côté navigateur client et le délai d'expiration des fichiers mis en cache.
mod_file_cache permet de configurer le cache côté serveur. (On privilégiera l'utilisation de mod_cache, plus puissant.)
mod_cache permet de configurer le cache côté serveur.

Les fichiers seront mis en cache conformément à une instruction qui spécifie la durée pendant laquelle une page peut être considérée comme "nouvelle".
Ces modèles sont plus utiles dans la plupart des cas que mod_file_cache :
Les mécanismes de mise en cache reposent sur le fait de servir des fichiers dans un état persistant.
Le module mod_cache peut gérer la modification du contenu en configurant la durée de validité d'un fichier pour la mise en cache.
Le module mod_cache s'appuie sur deux autres modules pour effectuer la majeure partie de la mise en œuvre du cache : mod_disk_cache et mod_mem_cache.
Pour le premier module le cache est conservé sur disque. Pour le deuxième module le cache est conservé en mémoire.
Les fichiers sont stockés et récupérés à l'aide de clés basées sur l'URI. Améliorer la mise en cache de votre site en activant le nommage canonique :
UseCanonicalName On

Objectif : Last-modified et code 304

Last-modified est une entête envoyée via des requêtes GET conditionnelles entre le serveur web du site et le navigateur, supporté par n’importe quel navigateur comme Google (Googlebot) et Bing (Bingbot).
Cette entête a un intérêt pour les moteurs de recherche et notamment dans le cadre de l’optimisation du crawl de Googlebot.
Les validateurs sont très importants :
Si aucune information de fraîcheur, Cache-Control ou Expires, n'est disponible, les caches ne stockeront rien.
Lorsqu'un document est demandé une première fois par un moteur de recherche, le serveur web renvoie une entête last-modified avec la date de la dernière modification.
Lorsqu'un document est demandé une deuxième fois, le moteur de recherche ajoute à sa requête une entête if-modified-since avec la dernière date qu’il connaît grâce au last-modified.
Si le document n’a pas changé depuis le if-modifed-since, le serveur envoie un code 304 not modifed sans le document.
Le moteur de recherche va utiliser la dernière version qu’il connaît. 
Cette requête GET conditionnelle est plus rapide à charger par le moteur de recherche que la réponse complète.
Si le document a changé, c’est à dire que le nouveau last-modified est supérieur au if-modified-since, alors le serveur répond normalement avec un code 200 et renvoie le nouveau document.
Je part du principe que si mod_expires est renseigné, last-modified et if-modifed-since sont renseignés, même si mod_cache n'est pas activé.
De ce fait, le code 304 serait correctement retourné au moteurs de recherches ?
# L'en-tête Expires basé sur la date de modification ne sera pas ajouté à un contenu qui ne provient pas directement d'un fichier sur disque.
# Pour que l'entête last-modified soit active sur Apache, il faut que le module mod_cache soit activé.

# Lire les headers retournés avec la commande cURL :
curl -I https://www.visionduweb.fr
# C'est un code 200 qui est retourné, donc, le document a été rechargé.
# J'observe bien une valeur last-modified mais pas de valeur if-modifed-since.
# Pourquoi la date d'expiration est t'elle en 2005 ?
HTTP/1.1 200 OK
Date: Sun, 03 Mar 2019 20:59:28 GMT
Server: Apache
Expires: Wed, 17 Aug 2005 00:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Set-Cookie: f4e8b27a5048454220760e16fe525d93=1u2o7k4masjbcgd5oortnmq5ev; path=/; HttpOnly;HttpOnly;Secure
X-Frame-Options: SAMEORIGIN
Referrer-Policy: no-referrer-when-downgrade
Feature-Policy: geolocation none;midi none;notifications none;push none;sync-xhr self;microphone none;camera none;magnetometer none;gyroscope none;speaker self;vibrate none;fullscreen self;payment none;
Last-Modified: Sun, 03 Mar 2019 20:59:29 GMT
Notes :
Pragma: no-cache : La valeur no-cache ne rend pas pour autant non cachable, elle traite les en-têtes de requête Pragma, les en-têtes envoyées au serveur par le navigateur.
Certains caches honorent cet en-tête, ce n'est pas le cas de la majorité, ce qui la rend sans effet.

Configurer la mise en cache avec mod_mem_cache

# Le répertoire /etc/apache2/mods-available permet de consulter la configuration par défaut des modules.
# Regarder la configuration de mod_mem_cache :
sudo nano /etc/apache2/mods-available/mem_cache.conf 
<IfModule mod_mem_cache.c>
# Indique à Apache de créer un cache mémoire pour le contenu stocké sous "/" donc, la racine, tout le contenu.
CacheEnable mem /
# Taille du cache au maximum.
MCacheSize 4096
# Nombre d'objets au maximum.
MCacheMaxObjectCount 100
# Les valeurs par défaut spécifient que les fichiers compris entre 1 octet et 2 kilo-octets seront pris en compte pour la mise en cache.
MCacheMinObjectSize 1
MCacheMaxObjectSize 2048
</IfModule>
# Activer mod mem_cache va également activer mod_cache :
sudo a2enmod mem_cache
# Redémarrer Apache2 :
sudo service apache2 restart

Configurer la mise en cache avec mod_disk_cache

# Le répertoire /etc/apache2/mods-available permet de consulter la configuration par défaut des modules.
# Regarder la configuration de mod_disk_cache :
sudo nano /etc/apache2/mods-available/disk_cache.conf
<IfModule mod_disk_cache.c>
# La directive "CacheRoot" spécifie où le contenu mis en cache sera conservé.
CacheRoot /var/cache/apache2/mod_disk_cache
# La directive "CacheEnable disk /" est désactivée par défaut. L'activer sur un hôte virtuel pour avoir une meilleure idée de ce qui sera mis en cache.
#CacheEnable disk /
# Les deux autres directives déterminent la structure de la mise en cache à la racine du cache.
# Chaque élément mis en cache est haché par son URL, puis le hachage est utilisé comme nom de fichier et chemin de répertoire.
# CacheDirLevel décide du nombre de répertoires à créer à partir de la chaîne de hachage.
CacheDirLevels 5
# CacheDirLength détermine le nombre de caractères contenus dans chaque nom de répertoire.
CacheDirLength 3
</IfModule>
Exemple :
Si vous avez un fichier dont le hachage est "abcdefghijklmnopqrstuvwxyz", alors un CacheDirLevel de 2 et une CacheDirLength de 4 entraîneront le stockage du fichier dans :
[path_of_cache_root] / abcd / efgh / ijklmnopqrstuv
# Activer le module mod_disk_cache pour charger la configuration :
sudo a2enmod disk_cache
# Redémarrer Apache2.
sudo service apache2 restart
 Apache Module mod_disk_cache : http://httpd.apache.org/docs/2.2/mod/mod_disk_cache.html
 Source complémentaire : http://careers.disneylandparis.com/manual/fr/mod/mod_cache_disk.html

Utilisation de CacheLock pour éviter de surcharger le backend

Un problème peut survenir sur un serveur occupé lorsqu'une ressource mise en cache expire.
Le cache qui doit être actualisé devra extraire à nouveau le fichier à partir de la ressource de fichier normale.
Cela peut créer une forte augmentation du nombre de demandes adressées au serveur principal lorsque la version mise en cache est en cours d'actualisation.
Activer un fichier de verrouillage qui indique que la ressource est en cours de reconnexion et que les demandes suivantes ne doivent pas aller au backend.
Ce verrou peut empêcher Apache d'essayer de mettre en cache la même ressource plusieurs fois lors de la première mise en cache.
Il servira également la ressource périmée jusqu'à la fin du cache actualisé.
Trois directives sont utilisées pour contrôler CacheLock :
# Active la fonctionnalité.
CacheLock [ On | Off ]
# Délai le plus long, en secondes, pendant lequel un fichier de verrouillage sera considéré comme valide.
# Ceci est important en cas d'échec ou de retard anormal d'actualisation d'une ressource.
CacheLockMaxAge [time_in_seconds]
# Définir le répertoire dans lequel les verrous de ressources seront créés.
CacheLockPath [/path/to/lock/directory]

Vider le cache Apache

La mise en cache stockée sur le disque peut devenir volumineuse en fonction des dates d'expiration du contenu.
Apache inclut un outil appelé "htcacheclean" pour réduire le cache à une taille configurée.
Htcacheclean - Nettoyage du cache sur disque : http://careers.disneylandparis.com/manual/fr/programs/htcacheclean.html
Htcacheclean - Nettoyage du cache sur disque : https://httpd.apache.org/docs/2.4/programs/htcacheclean.html

Module Apache2 mod_cache_socache

# Le cache des objets partagés du serveur HTTP Apache, le module Apache "mod_cache_socache".

Module Apache2 mod_deflate

# Activer la compression Gzip des fichiers en sortie de votre serveur.
# Activer le module.
sudo a2enmod deflate
# Activer la compression.
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
</IfModule>

# DEFLATE pour les navigateurs non compatibles.
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
# Il semble qu'il soit inutile de compresser des images avec DEFLATE car elles sont censées déjà être compressées.
# Cela consommerait du temps CPU pour un résultat nul. Il faudrait tout de même vérifier pour avoir un exemple des gains éventuels.
# Suivre le bon déroulement de la décompression depuis les propriétés de la page dans le navigateur.
# Depuis Firefox : Clic droit dans la page, Informations sur la page, Onglet Général, Taille.
# Comparer la taille du fichier original et la taille lue par le navigateur, à l'octet près.
# Les outils de développement intégrés au navigateur affichent les gains de performance depuis l'onglet Réseau ou Network.
# Ils mentionnent les en-têtes HTTP de compression ainsi que la quantité de données téléchargées.

Module Apache2 mod_evasive

Installer et configurer mod_evasive pour Apache2.

Module Apache2 mod_expires

# Pour les architectures PHP+MySQL, nous pouvons utiliser principalement 3 systèmes de cache :
# Le cache Apache situé au niveau du serveur.
# Le cache du navigateur qui copie sur la machine utilisateur les pages HTML, images, CSS, Javascript, pour les re-servir au client sans avoir à faire de nouvelles requêtes au serveur.
# Le cache MySQL qui garde en mémoire les résultats de requêtes SQL.
# L'en-tête HTTP Expires permet de préciser les types de fichiers pouvant rester en cache dans le navigateur du visiteur pendant une durée déterminée.
# Le navigateur n’a plus besoin de faire des requêtes pour vérifier la validité du cache ce qui diminue le nombre de requêtes sur le site.
# Il indique à tous les caches pour combien de temps la représentation associée reste valide.
# Après échéance les caches vérifieront auprès du serveur original si le document a changé.
# Les en-têtes Expires sont reconnues par pratiquement tous les caches.
# La gestion du cache rend le site plus réactif pour les utilisateurs.

# Les en-têtes de réponse Expires permettent en général :
# - de fixer une date d'expiration absolue.
# - de fixer une date basée sur celle de la dernière représentation vue par le client (Dernière date d'accès)
# - de fixer une date basée sur la dernière modification du document depuis le serveur (Dernière date de modification).

# Les en-têtes Expires conviennent parfaitement pour la mise en cache des images statiques, par exemple, pour les boutons de navigation.
# Les fichiers images n'ont pas de raison de changer de nom, la date d'expiration peut alors être éloignée dans l'avenir en permettant alors la durée de vie des images en cache.

# Les en-têtes Expires sont aussi utile pour contrôler la mise en cache d'une page qui change régulièrement.
# Pour une page quotidiennement mise à jour à cinq heures, fixer l'expiration du cache à cinq heures permet aux utilisateurs d'obtenir la nouvelle version à partir de cinq heures sans avoir à recharger la page.
# Activer le module mod_expires.
sudo a2enmod expires
# Mise en cache du navigateur.
<IfModule mod_expires.c>
ExpiresActive On
# Mise en cache par défaut du navigateur.
ExpiresDefault "access plus 1 month"
# Images.
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
AddType image/svg+xml .svg
ExpiresByType image/svg+xml "access plus 1 year"
AddType image/x-icon .ico
ExpiresByType image/ico "access plus 1 year"
ExpiresByType image/icon "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
# Structure du site.
ExpiresByType application/xhtml+xml "access plus 1 week"
ExpiresByType text/html "access plus 1 week"
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
ExpiresByType text/x-javascript "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType application/x-shockwave-flash "access plus 30 days"
# Documents.
ExpiresByType application/pdf "access plus 1 year"
# Polices.
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-ttf .ttf
AddType application/x-font-opentype .otf
AddType application/x-font-woff .woff
ExpiresByType application/vnd.ms-fontobject "access 1 year"
ExpiresByType application/x-font-ttf "access 1 year"
ExpiresByType application/x-font-opentype "access 1 year"
ExpiresByType application/x-font-woff "access 1 year"
</IfModule>
# Consulter différents types mime disponibles : https://fr.wikipedia.org/wiki/Type_de_m%C3%A9dias#Liste_des_types_de_m%C3%A9dia_courants
# Un simple en-tête Expires admet pour seule valeur une date HTTP.
# Tout autre valeur sera probablement interprété comme une date dans le passé, la contenu n'étant alors pas mis en cache.
# Les horloges du serveur Web et du cache doivent être synchronisées. Utiliser le protocole de date de réseau (NTP).
# L'heure d'une date HTTP est relative au temps GMT, non pas au temps local.
# Vérifier la syntaxe :
### -> ### Expires: Fri, 05 Mar 2021 12:00:00 GMT (???)
 Source : https://httpd.apache.org/docs/current/fr/mod/mod_expires.html

Module Apache2 mod_fastcgi

mod_fastcgi est un module cgi pour le serveur Web Apache qui peut se connecter à un serveur FASTCGI externe.
PHP doit s'exécuter en tant que utilisateur non root.
Exécuter les CGI PHP en tant qu’utilisateur non privilégié à l’aide de suEXEC ou mod_suPHP d’Apache.
Si PHP s'exécute en tant qu'utilisateur root ou utilisateur inférieur à 100, il peut accéder aux fichiers système et / ou les manipuler.
La fonctionnalité suEXEC offre aux utilisateurs Apache la possibilité d'exécuter des programmes CGI sous des ID utilisateur différents de ceux du serveur Web appelant.
# Vérifier l'utilisateur qui execute php-cgi :
su
ps aux | grep php-cgi
# Configurer le serveur pour qu'il utilise une interface FastCGI php externe s'exécutant sur le port 9000 à l'adresse IP 127.0.0.1 :
 https://www.cyberciti.biz/tips/rhel-fedora-centos-apache2-external-php-spawn.html
 https://www.cyberciti.biz/faq/freebsd-configure-nginx-php-fastcgi-server/

Module Apache2 mod_headers

# Activer le module mod_headers :
sudo a2enmod headers

HTTP Strict Transport Security

Introducation à HSTS
Sécurité
Optimiser la sécurité en activant HSTS : Header Strict Transport Security.
HSTS est une indication dans le header de la page visitée qui force le navigateur à charger immédiatement la page en https en ignorant tout appel http.
On minimise les risques de sécurité liés à une redirection effectuée de http vers https, l'échange crypté ne pouvant plus être détourné.
Il serait donc impossible pour les pirates de détourner l'échange crypté.
La première sollicitation du domaine depuis http sera traitée puis renvoyée vers https.
Les sollicitations suivantes seront envoyées directement vers https ce qui évitera des requêtes inutiles.
La première règle appliquée du serveur doit effectuer le changement de protocole de http vers https avant de charger le header de la page à consulter.
Cette méthode est donc complémentaire à la redirection mise en place depuis le fichier de configuration de l'hôte virtuel ou depuis le fichier .htaccess.
Sur un serveur VPS ou dédié, il est préférable de mettre la configuration du serveur ainsi que la ligne de configuration de HSTS directement dans le VirtualHost pour obtenir un gain de performance.
Performance
Avec HSTS activé et validé, les navigateurs forceront directement le chargement de la page via https même si l'utilisateur entre une adresse http.
On obtient un gain de performances minime lors du chargement de la page en évitant le temps de latence d'une redirection 301.
Optimisation
Il existe une liste de sites qui utilisent le pré-chargement directe vers https de certains sites qui ont validé la configuration de leur serveur.
La soumission de l'adresse URL sur https://hstspreload.org doit être faite sans le sous domaine www, que l'on choisisse ou non de conserver www.
Le test se fait globalement sur le domaine, le résultat à prendre en considération est donc celui obtenu suite au test de visionduweb.fr.
Pour faire partie de cette liste, il suffit simplement d'être validé après avoir réussi le test de hstspreload : https://hstspreload.org
Le site sera mis sur une liste d'attente et accepté si la configuration respecte toutes les conditions requises.
Consulter la liste : https://cs.chromium.org/chromium/src/net/http/transport_security_state_static.json
Vous pouvez annuler votre inscription par la suite mais cela peut prendre alors beaucoup plus de temps.
Cette liste a été mise en place par Chrome et est désormais utilisée par la plupart des navigateurs.
Faire partie de cette liste n'est pas obligatoire pour activer Header Strict Transport Security.
Consulter la liste des sites étant validés : https://caniuse.com/#feat=stricttransportsecurity
La directive preload est obligatoire uniquement si on souhaite être présent dans la liste.
Faire partie de cette liste informe le navigateur qu'il doit utiliser directement https.
Si le test effectuée sur hstspreload affiche "HTTP redirects to www first", il faut comprendre que la redirection vers l'url avec www est placé avant la redirection https, il est préférable de corriger cela.
Si le test effectuée sur hstspreload affiche le message : Status: nomdusite.fr is currently preloaded, cela signifie que le site validé est présent dans la liste, au moins pour celle du navigateur Chrome.
Tester également sur SSL Labs, et, faire le nécessaire pour obtenir une note A+ : https://www.ssllabs.com/ssltest/
La méthode de calcul est détaillée sur cette page : https://github.com/mozilla/http-observatory/blob/master/httpobs/docs/scoring.md
Une des deux informations suivantes doit être affichée suite au test sur SSL Labs :
- En preload sur chrome, en cours sur les autres navigateurs.
- Activé mais pas ajouté dans la liste preload.
SSL Labs affiche des informations complémentaires pouvant servir pour sécuriser d'avantage les sites internet, et, notamment, les sites marchands.
Sur des sites e-commerce, on active HSTS mais on limite également le certificat TLS en version 1.1 minimum, obligatoire depuis Juin 2018 pour rester conforme au standard PCI.
Il ne sera plus possible d'utiliser un ancien navigateur pour commander ou acheter sur le site de e-commerce, comme par exemple avec une vieille version d'internet explorer sous Windows XP.
En 2020, on peut utiliser la configuration suivante pour exclure TLS1 et TLS1.1 et inclure TLS 1.3 :
SSLProtocol ALL -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
Consulter cet exemple de configuration plus complet et fonctionnel en 2020.
Activer HSTS facilement et rapidement pour les administrateurs utilisant Cloudflare.
Les sites utilisant les services de Cloudflare peuvent activer HSTS même pour les utilisateurs d'un plan gratuit.
Déploiement
Si j'ajoute " env=HTTPS " à la fin de la ligne, la validation ne fonctionne pas avec un message d'erreur du type : Aucun entête HSTS n'a été trouvé.
Validation HSTS
Valider la vérification de hstspreload : https://hstspreload.org pour enregistrer le site dans la liste pour profiter du préchargement https.



Success
visionduweb.fr is now pending inclusion in the HSTS preload list!
Please make sure that visionduweb.fr continues to satisfy all preload requirement, or it will be removed. Please revisit this site over the next few weeks to check on the status of your domain.
Also consider scanning for TLS issues using SSL Labs.
Un B est obtenu avec SSL Labs : https://www.ssllabs.com/ssltest/analyze.html?d=visionduweb.fr
Un B+ est obtenu avec Observatory Mozilla : https://observatory.mozilla.org/analyze/visionduweb.fr
Au bout de quelques heures ou de quelques jours, le site sera bien ajouté dans la liste des sites préchargés.


Configuration du serveur
Redirection pour implémenter HSTS
# Pour implémenter HSTS, la première règle doit permettre de passer de http à https avant de charger le header de la page.
# La redirection vers www intervient après la redirection vers https. Lors de mes essais, je redirige en https, j'ajoute le header pour HSTS et je redirige alors vers www.
# Ne pas activer l'obligation de www pour les utilisateurs de Aesecure. La partie #AESECURE_WITHORNOTWWW_START du code de Aesecure doit être supprimée.
# Désactiver le forçage https dans l'admin Joomla, le serveur correctement configuré se chargera du passage en https.
# Redirection de http vers https.
# Cette règle fonctionne avec Apache 2.4 depuis le VirtualHost à l'écoute du port 80.
<VirtualHost *:80>
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
</IfModule>
</VirtualHost>

# Redirection de https non-www vers https www
# Cette règle fonctionne avec Apache 2.4 depuis le VirtualHost à l'écoute du port 443.
<VirtualHost *:443>
# Intégrer le header pour HSTS.
# Rediriger alors vers www.
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{SERVER_NAME} !^www\.(.*)$ [NC]
RewriteRule ^ https://www.%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]
# Ajouter d'autres règles, comme la protection par hotlinking.
</IfModule>
</VirtualHost>
Lors d'un test sur Google PageSpeed, Gtmetrix, ou d'autres outils en ligne d'analyse de la configuration du serveur, le message d'erreur suivant peut être indiqué : 
Éviter les redirections vers les pages de destination / Avoid landing page redirects.

Les sites qui affichent cette alerte ont tort à propos de ces redirections en ce qui concerne SSL et HSTS.
Ses sites traitent les redirections SSL comme toutes autres redirections, ce qui n’est pas la bonne approche.
Il est nécessaire de laisser ces redirections en l'état, comme proposé ci-dessus.
Autres propositions de redirection
# Les propositions suivantes peuvent être potentiellement utilisées depuis le fichier .htaccess pour rediriger le site.
# Analyser la configuration du site avec des outils d'analyse SSL pour vérifier si le HSTS est bien pris en compte.
# Tester le site pour vérifier qu'il soit bien fonctionnel.
# ATTENTION ! Les redirection proposées ci-dessous n'ont pas été fonctionnelles avec mon script de protection hotlinking.
# Rediriger vers https.
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
# Rediriger le domaine visionduweb.fr vers le sous domaine www.visionduweb.fr.
RewriteCond %{HTTP_HOST} ^visionduweb.fr$
RewriteRule ^(.*)   https://www.visionduweb.fr/$1  [R=301,L]
### ### ###
# Vérifier les drapeaux de Apache2.
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [QSA,R=301,L]
RewriteCond %{HTTP_HOST} ^visionduweb.fr  [NC]
RewriteRule ^(.*)   http://www.mondomaine.fr/$1 [L,R=301,NC]
### ### ###
# Ce code a l'avantage de ne pas avoir à modifier le nom de domaine.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
### ### ###
# Rediriger vers https.
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
# Rediriger vers www.
RewriteCond %{HTTP_HOST} ^nomdudomaine [NC]
RewriteRule ^(.*)$ https://www.nomdudomaine/$1 [L,R=301,NC]
### ### ###
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [R=301,L]
</IfModule>
Ajouter la configuration HSTS
# Ajouter les lignes suivantes dans son VirtualHost ou dans son fichier .htaccess pour charger l'entête HSTS.
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
</IfModule>
# Le code suivant est fonctionnel sur mon VPS avec Debian Stretch et Apache 2.4 et permet de charger HSTS et le site en preload.
# La directive "preload" n'est nécessaire que pour valider l'enregistrement du site dans la liste tenue par Chrome.
# Lors de mes essais, j'ai du retirer la valeur env=HTTPS qui m'empêchait de redémarrer Apache2.
# J'ai également du ajouter la valeur always.
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>
Tester avec hstspreload
Tester la bonne configuration de son site avec https://hstspreload.org
L'outil demande de forcer la redirection de http vers https directement.
Il indiquera un message d'erreur si on redirige directement http vers https://www.
Il faudrait donc mettre en place une règle de redirection de http vers https, et, seulement après, rediriger vers le sous domaine www.
Tester avec ssllabs
Cette étape devrait avoir été validée en même temps que la mise en place du certificat Let's Encrypt et devrait déjà retourner un score A+ :
Obtenir un A+ avec SSLLabs.
Effacer les paramètres HSTS dans Chrome et Firefox
Empêcher la collecte HSTS preload depuis Firefox :
about:config
network.stricttransportsecurity.preloadlist (False)
Effacer le cache HSTS de votre navigateur
Dans Chrome, taper chrome://net-internals/#hsts
Entrer le nom de domaine dans le champ texte de la section "Delete domain security policies"
Cliquer sur le bouton Delete
Entrer le nom de domaine dans le champ texte de la section "Query HSTS"
Cliquer sur le bouton Query
La réponse doit être "Not found" (non trouvé)
Avec Safari, commencer par fermer le navigateur
Effacer le fichier ~/Library/Cookies/HSTS.plist
Rouvrir Safari
Avec Firefox, fermez tous les onglets.
Ouvrir le menu de Firefox et cliquer sur Historique / Afficher l’historique. ( Ou avec un raccourci clavier CTRL MAJ H )
Rechercher la page dont vous voulez supprimer les préférences HSTS
Effectuer un clic droit sur une des entrées lui correspondant
Choisir Oublier ce site.
Ressources complémentaires
 Activer le HSTS : pourquoi et comment : https://forum.joomla.fr/forum/joomla-3-x/questions--g%C3%A9n%C3%A9rales/1991742-activer-le-hsts-pourquoi-et-comment
 Redirection https et www dans le bon ordre  : https://forum.joomla.fr/forum/joomla-3-x/questions--g%C3%A9n%C3%A9rales/1991735-redirection-https-et-www-dans-le-bon-ordre
 HTTP Strict Transport Security Cheat Sheet : https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet
 Configure HSTS (HTTP Strict Transport Security) for Apache2 and Nginx : https://linux-audit.com/configure-hsts-http-strict-transport-security-apache-nginx/
 Tour d’horizon sur HTTPS et les en-têtes de sécurité : https://www.alsacreations.com/article/lire/1723-tour-horizon-https-et-en-tetes-de-securite.html
 Qu’est-ce que le HSTS et comment le met-on en œuvre ? : https://www.globalsign.fr/fr/blog/qu-est-ce-que-le-hsts-comment-le-mettre-en-uvre/
 Fiabiliser les connexions sécurisées avec HSTS (HTTP Strict Transport Security) : https://blog.dareboost.com/fr/2017/09/hsts-fiabiliser-connexions-securisees/
 Proposition de htaccess par Cavo789 pour la CSP : https://github.com/cavo789/htaccess#csp---content-security-policy
 Proposition de htaccess par Cavo789 pour le HSTS : https://github.com/cavo789/htaccess#force-https-and-www-compatible-hstspreload

Sécuriser les Cookies

# Sécuriser les Cookies.
# Interdire l'utilisation du cookie côté client avec l'instruction HttpOnly.
# Interdire l'utilisation du cookie sans HTTPs avec le flag Secure.
Header always edit Set-Cookie (.*) "$1;HttpOnly;Secure"
# Noter que avec HSTS les cookies sont censés passer uniquement par https, mais, les outils de tests de serveurs en ligne demandent cette balise, alors, autant la rajouter.
Utiliser cookie-free
Use cookie-free domains
Avec chaque requête, le navigateur envoie les cookies liés au domaine recevant la requête.
Servir les fichiers statiques css, js, images, fonts, ..., à partir d'un domaine différent n'utilisant pas de cookie permet de réduire légèrement la taille des requêtes faites au serveur.
Reste à comprendre comment effectuer une telle configuration dans la situation suivante :
There are 33 components that are not cookie-free
https://www.visionduweb.fr/templates/etconference/css/bootstrap.min.css
https://www.visionduweb.fr/templates/etconference/css/font-awesome.min.css
https://www.visionduweb.fr/templates/etconference/css/default.css
https://www.visionduweb.fr/templates/etconference/css/j2store.css
https://www.visionduweb.fr/templates/etconference/css/legacy.css
https://www.visionduweb.fr/templates/etconference/css/template.css
https://www.visionduweb.fr/templates/etconference/css/presets/preset4.css
https://www.visionduweb.fr/templates/etconference/css/frontend-edit.css
https://www.visionduweb.fr/modules/mod_joomspirit_slider/assets/css/style.css
https://www.visionduweb.fr/media/jui/js/jquery.min.js?c7218b8dd405fbc5f1fd0e1819052f31
https://www.visionduweb.fr/media/jui/js/jquery-noconflict.js?c7218b8dd405fbc5f1fd0e1819052f31
https://www.visionduweb.fr/media/jui/js/jquery-migrate.min.js?c7218b8dd405fbc5f1fd0e1819052f31
https://www.visionduweb.fr/media/system/js/caption.js?c7218b8dd405fbc5f1fd0e1819052f31
https://www.visionduweb.fr/templates/etconference/js/bootstrap.min.js
https://www.visionduweb.fr/templates/etconference/js/jquery.sticky.js
https://www.visionduweb.fr/templates/etconference/js/main.js
https://www.visionduweb.fr/templates/etconference/js/wow.min.js
https://www.visionduweb.fr/templates/etconference/js/custom.js
https://www.visionduweb.fr/templates/etconference/js/jquery.easing.min.js
https://www.visionduweb.fr/templates/etconference/js/scroll.js
https://www.visionduweb.fr/templates/etconference/js/frontend-edit.js
https://www.visionduweb.fr/media/system/js/core.js?c7218b8dd405fbc5f1fd0e1819052f31
https://www.visionduweb.fr/media/system/js/keepalive.js?c7218b8dd405fbc5f1fd0e1819052f31
https://www.visionduweb.fr/images/banniere/visionduweb.png
https://www.visionduweb.fr/images/structure/logo-glider-48x48.png
https://www.visionduweb.fr/modules/mod_joomspirit_slider/assets/js/jquery.flexslider-min.js
https://www.visionduweb.fr/images/structure/hackerspace.jpg
https://www.visionduweb.fr/images/structure/crack.jpg
https://www.visionduweb.fr/images/structure/glider.png
https://www.visionduweb.fr/images/structure/debian.png
https://www.visionduweb.fr/images/structure/ubuntu.jpg
https://www.visionduweb.fr/images/structure/arch.jpg
https://www.visionduweb.fr/images/banniere/april.png
Utiliser un fournisseur CDN qui supprime les cookies ou configurer un domaine et/ou un sous-domaine séparé pour servir les cookies.
Cookie-free et CDN Cloudflare avec Joomla : https://forum.joomla.fr/forum/joomla-3-x/administration/2000825-configurer-le-domaine-des-cookies
Comment utiliser un CDN pour un domaine sans cookie : https://xlformation.com/8-les-tutos/30-jch-optimize-chapitre-3-8-comment-utiliser-un-cdn-un-domaine-sans-cookies.html
Ne pas utiliser les cookies de Youtube
# Utiliser le nom de domaine https://www.youtube-nocookie.com pour intégrer une vidéo sans utiliser les cookies de Youtube.
https://www.youtube-nocookie.com/embed//DEbZyIMeBxA
Serve Static Content From a Cookieless Domain
Exemple avec WordPress : https://kinsta.com/fr/base-de-connaissances/serve-static-content-from-a-cookieless-domain/
Avec Cloudflare les domaines ne sont pas cookieless.
Block Federated Learning of Cohorts (FLoC)
# Une nouvelle technologie est en cours de déploiement dans les navigateurs pour remplacer les cookies de suivi tiers.
# Cette technologie s'appelle Federated Learning of Cohorts (FLoC).
# À partir de Joomla! 3.9.27 votre site Web bloque cette technologie, vous pouvez la réactiver à partir de la configuration globale.
# De plus, pour désactiver cette technologie pour toutes les requêtes adressées à votre serveur, vous devez mettre à jour votre .htaccess.
En savoir plus : https://github.com/WICG/floc
En savoir plus : https://www.eff.org/deeplinks/2021/03/googles-floc-terrible-idea

Définir le contexte de sécurité avec les règles CSP : Content Security Policy

# Activer Mod Headers.
sudo a2enmod headers
Permet la mise en Liste blanche des sources de contenu de confiance pour le site Web.
Les CSP sont à ajouter dans la configuration des VirtualHosts ou depuis un fichier .htaccess.
Placer les CSP dans un fichier .htaccess pour permettre les modifications par les développeurs.
Atténue le risque d'attaques par scripts hébergés sur un autre serveur ou autres injections de contenu.
Exemple d'une règle minimaliste pour CSP : Content Security Policy
<IfModule mod_headers.c>
Header set Content-Security-Policy "script-src 'self' https://www.visionduweb.fr"
</IfModule>
Exemple d'une règle spécifique pour CSP : Content Security Policy
Autoriser le code JavaScript en ligne : <script>function myJsFunction()</script> est non recommandé car cela nuit à l’utilisation de CSP.
Utiliser la configuration suivante pour passer outre et tout de même utiliser un tel code : script-src 'self' 'unsafe-inline'
# Le message d'erreur suivant est affiché dans la console du navigateur : Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à inline (« script-src »).
# Avec la CSP précédente, l'administration de Joomla ne fonctionne pas correctement.
# J'adapte la CSP pour permettre à Joomla de fonctionner normalement sans alerte dans la console du navigateur web, en backend et frontend :
<IfModule mod_headers.c>
# Certaines adresses ne sont pas ajoutées comme étant autorisées, comme celle de https://static.doubleclick.net/instream/ad_status.js” appelée lors de la consultation de ma playlist de Youtube.
Header set Access-Control-Allow-Origin: "default-src 'self' https://www.visionduweb.fr"
## La directive frame-ancestror permet de créer une exception pour un domaine et d'ignorer la commande Header always set X-Frame-Options "SAMEORIGIN".
Header set Content-Security-Policy: "default-src 'self' https://www.visionduweb.fr; script-src 'self' 'unsafe-eval' 'unsafe-inline' https://www.visionduweb.fr https://www.youtube.com https://unpkg.com https://s.ytimg.com https://www.google.com https://www.gstatic.com; object-src 'self' https://www.visionduweb.fr; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' https://www.visionduweb.fr https://i.ytimg.com https://secure.gravatar.com https://avatars3.githubusercontent.com; media-src 'self' https://www.visionduweb.fr https://youtu.be; frame-src 'self' https://www.visionduweb.fr https://www.youtube.com https://www.coingecko.com https://hackbbs.org:7777 https://www.spreaker.com https://widget.spreaker.com https://www.google.com; font-src 'self' 'unsafe-inline' https://www.visionduweb.fr https://fonts.gstatic.com data:; connect-src 'self' https://www.visionduweb.fr https://api.github.com; frame-ancestors 'self'"

# Le module correspondant à X-Content-Security-Policy n'est pas chargé.
# X-Content-Security-Policy "default-src 'self' https://www.visionduweb.fr; script-src 'self' 'unsafe-inline' https://www.visionduweb.fr; object-src https://www.visionduweb.fr; style-src https://www.visionduweb.fr; img-src https://www.visionduweb.fr; media-src https://www.visionduweb.fr; frame-src https://www.visionduweb.fr; font-src https://www.visionduweb.fr; connect-src https://www.visionduweb.fr; report-uri https://www.visionduweb.fr"

# Le module correspondant à X-WebKit-CSP n'est pas chargé.
# X-WebKit-CSP "default-src 'self' https://www.visionduweb.fr; script-src 'self' 'unsafe-inline' https://www.visionduweb.fr; object-src https://www.visionduweb.fr; style-src https://www.visionduweb.fr; img-src https://www.visionduweb.fr; media-src https://www.visionduweb.fr; frame-src https://www.visionduweb.fr; font-src https://www.visionduweb.fr; connect-src https://www.visionduweb.fr; report-uri https://www.visionduweb.fr"
</IfModule>
# Upgrade Insecure Requests" est une directive CSP (Content Security Policy) vous permettant de signifier aux clients HTTP/Navigateurs que toutes les ressources doivent être accédées via HTTPS. 
# Vos ressources seront automatiquement récupérées en HTTPS par le client/navigateur, sans aucune alerte de contenu mixte (mixed content).
Header always set Content-Security-Policy "upgrade-insecure-requests;"
# Redémarrer Apache2 pour appliquer la nouvelle configuration :
sudo apache2ctl restart
Source :
 Pour faciliter la mise en place des règles CSP, utiliser un générateur d'en-tête CSP en ligne : https://www.cspisawesome.com
 Pour vérifier les règles CSP, utiliser un validateur d'en-tête CSP en ligne : https://cspvalidator.org
 Compatibilité des CSP avec les navigateurs : https://developer.mozilla.org/fr/docs/Web/HTTP/CSP
 Facilitez votre migration à HTTPS avec la directive CSP Upgrade Insecure Requests : https://www.tbs-certificats.com/FAQ/fr/upgrade-insecure-requests.html
Sécuriser les styles et les scripts de son site avec CSP SRI
# SubResource Integrity (SRI) apporte une sécurité supplémentaire non négligeable.
# Mozilla Observatory recommande son utilisation.
# Générer un hash SRI depuis le terminal pour un fichier spécifique :
openssl dgst -sha384 -binary FILENAME.js | openssl base64 -A
# Générer un hash SRI en PHP pour un fichier spécifique :
echo base64_encode(hash('sha384', $input, true));
# Générateur en ligne de hash SRI
SRI Hash : https://report-uri.com/home/sri_hash
# Ajouter le lien de la ressource dans le générateur :
https://www.visionduweb.fr/templates/etconference/css/bootstrap.min.css
# Le générateur propose le code à insérer :
<link rel="stylesheet" href="https://www.visionduweb.fr/templates/etconference/css/bootstrap.min.css" integrity="sha256-oFkm5SJ19oc3oyX8RTXsKalfTP2GSOqeaoXtlV1mK6Y= sha384-EpV4mdE0WcRELxHpSiyOTl6fB2WACKvnOq5e71v2LVoXYxfxUlr7dW7gR0NIoql2 sha512-WzzOzDn6/1FFoAFfR5z8AoZN5O2U2Go5RP/p2xTE+quOr1FPnRIdox3kDM1tDWUOYjdldriHOdNC85FXxTv1tQ==" crossorigin="anonymous">
# On peut définir les types de fichiers qui doivent utiliser l'intégrité des sous-ressources avec la politique de sécurité du contenu, ou CSP. 
# Si on souhaite que toutes les feuilles de style soient validées à l'aide de SRI, ajouter la règle suivante dans notre déclaration de CSP :
Content-Security-Policy: require-sri-for style;
# Si on souhaite que tous les fichiers JavaScript utilisent l'intégrité SRI, ajouter la règle suivante dans notre déclaration de CSP :
Content-Security-Policy: require-sri-for script;
# Combiner cette règle pour le script et le style en une seule règle :
Content-Security-Policy: require-sri-for style script;
# Récapitulatif des lignes, non obligatoires, une seule ligne est à ajouter dans sa politique de sécurité de contenu, CSP :
Content-Security-Policy: require-sri-for style;
Content-Security-Policy: require-sri-for script;
Content-Security-Policy: require-sri-for style script;
# Toute feuille de style ou élément de script sans intégrité SRI ne sera pas chargé.
# L'avenir de SRI :
# Une prochaine révision de cette spécification est susceptible d'inclure le support du contrôle d'intégrité pour toutes les sous-ressources possibles.
# C'est-à-dire, pour les éléments a, audio, embed, iframe, img, link, object, script, source, track, et video.
 Source : https://www.w3.org/TR/SRI/#verification-of-html-document-subresources
# Générer un hash SRI avec d'autres langages pour un fichier spécifique :
 Générer une somme de contrôle pour les sous ressources : https://tenzer.dk/generating-subresource-integrity-checksums/
# Vérifier un hash SRI avec le projet srisum-rs :
https://github.com/zkat/srisum-rs/
Ressources complémentaires
https://ole.michelsen.dk/blog/secure-your-website-with-content-security-policy.html
https://stackoverflow.com/questions/30280370/how-does-content-security-policy-work
https://www.sitepoint.com/improving-web-security-with-the-content-security-policy/
https://www.html5rocks.com/en/tutorials/security/content-security-policy/
https://www.owasp.org/index.php/Content_Security_Policy_Cheat_Sheet
https://content-security-policy.com

Politique de provenance

A new security header: Referrer Policy : https://scotthelme.co.uk/a-new-security-header-referrer-policy/

Politique des fonctionnalités

A new security header: Feature Policy : https://scotthelme.co.uk/a-new-security-header-feature-policy/
Introduction to Feature Policy : https://developers.google.com/web/updates/2018/06/feature-policy
# Identique à CSP mais au lieu de contrôler la sécurité c'est un contrôle des fonctionnalités.
Header always set Feature-Policy "geolocation none;midi none;notifications none;push none;sync-xhr self;microphone none;camera none;magnetometer none;gyroscope none;speaker self;vibrate none;fullscreen self;payment none;"

Protéger contre les attaques utilisant X-XSS X-Frame X-Content

<IfModule mod_headers.c>
# Protéger contre les attaques utilisant X-XSS X-Frame X-Content.
Header set X-XSS-Protection "1; mode=block"
# Le mieux serait même de refuser totalement les frames avec "DENY".
Header always set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options nosniff
</IfModule>

Ne pas envoyer l'entête en cas de passage de https vers http

<IfModule mod_headers.c>
# Le navigateur n'enverra pas l'en-tête du référent lors de la navigation de HTTPS vers HTTP.
Header always set Referrer-Policy 'no-referrer-when-downgrade'
</IfModule>

Contrôle du cache

# HTTP 1.1 a introduit la classe d'en-têtes de réponse Cache-Control pour donner plus de contrôle aux éditeurs Web sur leur contenu et pour répondre aux limitations de l'en-tête Expires.
# On détermine la durée du cache pour différents types de fichiers, pour une longue durée.
# Les fichiers dynamiques comme php ou cgi sont rarement mis en cache.
# Cache-Control et en-tête Expires sont complémentaires. 

<IfModule mod_headers.c>
# Contrôle du cache navigateur.
# Ne pas mettre en cache si ces fichiers le sont déjà.
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
# Désactiver le cache pour les scripts et fichiers dynamiques.
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
# Mettre en cache les éléments suivants.
<filesmatch "\.(gif|ico|jpe?g|png)$">
# Mise en cache de une année.
Header set Cache-Control "max-age=33566400, public"
</filesmatch>
<filesmatch "\.(html|htm|css)$">
# Mise en cache de une semaine.
Header set Cache-Control "max-age=604800, public"
</filesmatch>
<filesmatch "\.(js)$">
# Mise en cache de une semaine.
Header set Cache-Control "max-age=604800, private"
</filesmatch>
<filesmatch "\.(gz|pdf|ttf)$">
# Mise en cache de une année. (Je n'ai pas le type gz présent dans les entêtes Expires.)
Header set Cache-Control "max-age=33566400, public"
</filesmatch>
<filesmatch "\.(flv|swf)$">
# Mise en cache de une semaine.
Header set Cache-Control "max-age=33566400, public"
</filesmatch>

# Économiser les requêtes de cookies.
# Ouvrir des connexions http coûte du temps, et il n'est pas toujours efficace d'ouvrir davantage de connexions.
# Réduire le nombre de ressources est bien plus efficace que d’empiler de nombreuses connexions HTTP ouvertes.
# L'extension php n'est pas ajoutée, sinon, impossible de se connecter au site.
<filesMatch "\\.(ico|jpe?g|png|gif|svg|swf|gz|ttf|eot|woff|html|htm|css|js|pl|cgi|spl|scgi|fcgi)$">
RequestHeader unset Cookie
Header unset Cookie
Header unset Set-Cookie
</filesMatch>
</IfModule>
# Les en-têtes de réponse Cache-Control :
max-age=[secondes] - Indique la quantité de temps maximale où la représentation sera considérée fraîche. Similaire à Expires, cette directive est relative à l'heure de la requête au lieu d'être absolue.
s-maxage=[secondes] - Similaire à max-age, mais ne s'applique qu'aux caches partagés (Par exemple, un mandataire.).
public - Marque les réponses authentifiées comme cachables. Normalement, si une authentification HTTP est demandée, les réponses sont automatiquement non cachables.
no-cache - Force à chaque fois les caches à soumettre la requête au serveur original pour validation avant libération d'une copie cachée. Utile pour s'assurer du respect de l'authentification en combinaison avec public, ou pour maintenir une fraîcheur rigide, sans sacrifier les bénéfices de la mise en cache.
no-store - Les caches ne doivent pas garder de copie de la représentation dans toutes les conditions.
must-revalidate - HTTP permet aux caches de servir des représentations périmées sous certaines conditions. En indiquant cette en-tête, vous dites au cache que vous voulez un respect strict de vos règles.
proxy-revalidate - Similaire à must-revalidate sauf qu'elle ne s'applique qu'aux caches de mandataires.
private - Indique que les proxys n’ont pas l’autorisation de mettre en cache.
Forcer le header pour PHP afin de désactiver le cache
# Précédemment le cache pour les scripts et fichiers dynamiques a été désactivé.
# Il est possible de forcer la désactivation du cache depuis le header des fichiers PHP.
<FilesMatch "\.php$">
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Sat, 2 Aug 1980 15:15:00 GMT"
ExpiresActive On
ExpiresDefault "access plus 0 seconds"
</FilesMatch>

Les proxies doivent donner le bon contenu

# Les proxies doivent donner le bon contenu (?)
Ajouter au Virtual Host des domaines. ( Relire les options des Header et l'ordre d'implémentation. )

Header append Vary User-Agent env=!dont-vary

Désactiver Etag

# Un Etag permet de faire la différence entre deux versions d’un fichier.
# Il est transmis entre le serveur et le client lors des requêtes HTTP.
# Si le fichier est identique, le navigateur utilisera son cache.
# A chaque requête, les informations sont transmises inutilement.
# Le cache serveur doit être configuré avec d'autres commandes.
# Réduire le nombre de requêtes et la bande passante utilisée.
# Note complémentaire :
# Sur les serveurs Apache, l’identifiant est basé sur la date de dernière modification.
# Si le site est géré par un cluster de plusieurs serveurs. on aura parfois un identifiant différent à cause du Etag, même si le fichier n’a jamais été modifié.
# Désactiver Etag.
FileETag none

Module Apache2 mod_http2

# A la différence de HTTP/1 qui est en texte pur, HTTP/2 est un protocole binaire.
# HTTP/1 est lisible par un humain qui voudrait par exemple écouter le trafic réseau pour identifier un contenu, HTTP/2 n'est pas directement lisible par un humain puisque chiffré en binaire.
# Par défaut, Apache utilisera le MPM prefork.
# Ce MPM n'est pas compatible avec HTTP/2, nous devrons donc le remplacer par le module mpm_event plus moderne pour pouvoir activer http2 :
# Disable the "prefork" MPM:
sudo a2dismod mpm_prefork 
# Enable the "event" MPM:
sudo a2enmod mpm_event 
# Restart Apache and PHP 8.2 :
sudo service apache2 restart 
sudo service php8.2-fpm restart
# Activer le module HTTP2 :
sudo a2enmod http2
systemctl restart apache2
# Le paquet requis est déjà installé :
libnghttp2-14
# L'activation du module devrait suffire à généraliser l'activation de HTTP/2 sans même avoir à renseigner le VirtualHost.
# Wappanalyser indique que tous les sites du serveur sont en HTTP/2.
# Ajouter une configuration au niveau global de Apache2 pour activer HTTP/2 :
# Create a new http2.conf for entire Server HTTP2
sudo nano /etc/apache2/conf-available/http2.conf and add all the following rows:
<IfModule http2_module>
   ProtocolsHonorOrder On
   Protocols h2 h2c http/1.1
   H2Direct on
</IfModule>
# Enable the http2.conf by running
sudo a2enconf http2
# Ou ajouter dans la configuration principale de apache2 :
sudo nano /etc/apache2/apache2.conf
ProtocolsHonorOrder On
Protocols h2 h2c http/1.1
# Ajouter pour chaque VirtualHost la commande suivante pour activer HTTP/2 :
# h2 correspond à HTTP/2 sur TLS. (Négociation de protocole via ALPN.)
# h2c correspond à HTTP/2 sur TCP.
ProtocolsHonorOrder On
Protocols h2 h2c http/1.1
# Afficher toutes les lignes de Apache2 qui mentionnent "Protocols".
cd /etc/apache2
grep -r Protocols .
# Créer une page info.php contenant phpinfo(); affiche http2 à yes comme étant disponible.
# Erreur sur la vérification du domaine :
# Vérifier le protocole :
curl -I --http2 --head https://green.amis-sh.fr
# Doit répondre HTTP2 200 ! Ce n'est pas le cas :
HTTP/1.1 200 OK
Upgrade: h2,h2c
# Revérifier les étapes précédentes :
curl -I --http2 --head https://green.amis-sh.fr
HTTP/2 200
Source : https://gist.github.com/GAS85/990b46a3a9c2a16c0ece4e48ebce7300

Le module Apache2 mpm_prefork

# Il semble que le module Apache2 mpm_prefork ne soit pas toléré avec HTTP/2.
sudo a2dismod mpm_prefork 

Le module Apache2 mpm_worker

# D'après le tutoriel que j'ai suivi, le module suivant est également activé en plus de mpm_event mais dans mon cas, j'ai on conflit, et, je dois choisir l'un ou l'autre.
sudo a2enmod mpm_worker
sudo systemctl restart apache2

Le module Apache2 mpm_event

# Avec les MPM précédents, les connexions asynchrones nécessitaient un thread de travail dédié, mais, ce n'est plus le cas avec le MPM Event. 
Source : https://httpd.apache.org/docs/2.4/fr/mod/event.html
sudo a2enmod mpm_event 
systemctl restart apache2
# HTTP/2 est maintenant indiqué comme étant utilisé, depuis le rapport de Wappalyser.

Module Apache2 mod_log_config

Ce module apporte de la souplesse dans la journalisation des requêtes des clients.
Les journaux sont écrits sous un format personnalisable et peuvent être enregistrés directement dans un fichier ou redirigés vers un programme externe.
La journalisation conditionnelle est supportée, si bien que des requêtes individuelles peuvent être incluses ou exclues des journaux en fonction de leur caractéristiques.
 Source complémentaire : https://httpd.apache.org/docs/trunk/fr/mod/mod_log_config.html
 Source complémentaire : http://httpd.apache.org/docs/trunk/fr/mod/mod_log_config.html#formats

Module Apache2 mod_log_debug

Possibilité de journalisation supplémentaire à des fins de débogage.
 Source : https://httpd.apache.org/docs/trunk/fr/mod/mod_log_debug.html

Module Apache2 mod_log_forensic

Le module mod_log_forensic permet la journalisation à des fins d'investigation judiciaire des requêtes des clients.
La journalisation est effectuée avant et après le traitement de la requête. Ajoute deux entrées dans le journal.
Le générateur de journaux d'investigation est très strict et ne permet aucune personnalisation.
C'est un inestimable outil de débogage et de sécurité.
 Source : https://httpd.apache.org/docs/trunk/fr/mod/mod_log_forensic.html

Module Apache2 mod_logio

Ce module permet d'enregistrer le nombre d'octets reçus et envoyés pour chaque requête.
Ce nombre reflète le nombre réel d'octets transmis sur le réseau, et prend en compte les en-têtes et corps des requêtes et des réponses.
Le décompte est effectué avant SSL/TLS en entrée et après SSL/TLS en sortie, si bien que le résultat reflètera toute modification introduite par le chiffrement.
Pour fonctionner, ce module requiert le chargement du module mod_log_config.
 Source : https://httpd.apache.org/docs/trunk/fr/mod/mod_logio.html

Module Apache2 mod_cgi

Tout fichier pris en compte par le gestionnaire cgi-script sera traité en tant que script CGI et exécuté par le serveur, sa sortie étant renvoyée au client.
 Source : https://httpd.apache.org/docs/trunk/fr/mod/mod_cgi.html

Module Apache2 libapache2-mod-passenger

# Installer Mod Passenger.
sudo apt install libapache2-mod-passenger
# Activer Mod Passenger.
a2enmod passenger
# Désactiver Mod Passenger.
a2dismod passenger
# Désinstaller Mod Passenger et sa configuration.
sudo apt-get autoremove --purge libapache2-mod-passenger
# Références complémentaires sur Phusionpassenger et Apache2 :
Source : https://www.phusionpassenger.com/library/config/apache/reference/
Source : https://www.phusionpassenger.com/docs/references/config_reference/apache/
Source : http://rpm.repo.onapp.com/sources/rubygem-passenger-4.0.35/passenger-4.0.35/doc/Users%20guide%20Apache.html

Module Apache2 mod_md

# Ce module permet de gérer les propriétés courantes des domaines pour un ou plusieurs serveurs virtuels.
# Il fournit deux fonctionnalités principales :
# La première permet la supervision et le renouvellement des certificats https via le protocole ACME (RFC 8555).
# Le module effectue le renouvellement des certificats avant leur expiration afin d'éviter une interruption des services internet.
# Il est possible de monitorer l'état de tous les certificats gérés par mod_md et de configurer le serveur de façon à ce qu'il envoie des notifications de renouvellement, d'expiration ou d'erreur personnalisées.
# La seconde fournit une implémentation alternative de l'agrafage OCSP, et ceci aussi bien pour les certificats gérés par mod_md que pour les certificats que vous gérez vous-même.
# Composant nécessaire pour tout site https, l'agrafage OCSP influence la vitesse de chargement des pages et suivant la configuration, la disponibilité de ces dernières.
# L'autorité ACME par défaut pour la gestion des certificats est Let's Encrypt, mais il est possible de configurer une autre CA si cette dernière supporte le protocole.
# Un serveur ainsi configuré contactera Let's Encrypt au démarrage pour demander un certificat pour le domaine considéré.
# Si Let's Encrypt peut vérifier le propriétaire du domaine, le module obtiendra le certificat et sa chaîne de certification.
# Le module le stockera dans son système de fichiers (voir la directive MDStoreDir) et le proposera au prochain redémarrage à mod_ssl.
# Ce processus se déroule pendant l'exécution du serveur. Tous les autres serveurs virtuels continueront à fonctionner normalement.
# Tant que le certificat ne sera pas disponible, toute requête pour le domaine considéré génèrera une réponse du type '503 Service Unavailable'. 
# Pour pouvoir être utilisé, ce module nécessite le chargement préalable du module mod_watchdog.
# Pour que Let's Encrypt puisse signer et renouveler votre certificat, votre serveur doit, en général, être accessible depuis l'internet public sur le port 80 (http:) et/ou 443 (https:), à moins que le serveur ne soit configuré pour utiliser les vérifications DNS.
# Pour déterminer quelles méthodes sont disponibles, le module consulte les ports sur lesquels écoute Apache2.
# Si le port 80 en fait partie, le module supposera que la vérification http: nommée http-01 est disponible.
# Si le port 443 en fait aussi partie, la vérification https: nommée tls-alpn-01 sera ajoutée à la liste des méthodes disponibles.
# Si la directive MDChallengeDns01 est définie, la méthode de vérification dns-01 sera aussi ajoutée.
# Si vous ne souhaitez pas que l'un de vos sites soit accessible sur le port 80, laisser ce dernier ouvert et rediriger toutes les requêtes vers vos sites en https:.
# Pour ce faire, utilisez la directive MDRequireHttps décrite plus loin. Votre serveur pourra alors continuer à répondre au requêtes en http: en provenance de Let's Encrypt.
# Comme dans le cas du protocole HTTP/2, vous pouvez configurer ceci de la manière suivante, la méthode de vérification "tls-alpn-01" sera alors disponible :
Protocols h2 http/1.1 acme-tls/1
# Pour tester l'agrafage pour un seul domaine géré, utiliser la configuration suivante.
# Charger le module mod_status pour consulter la page 'server-status' ou utiliser MDMessageCmd et obtenir des informations.
# Vérifier si l'information d'agrafage est présente, sa durée de validité, son origine et à quel moment elle sera rafraîchie. 
<MDomain mydomain.net>
MDStapling on
</MDomain>
# Si vous redémarrez votre serveur alors que le service OCSP de votre CA est en panne, les utilisateurs ne pourront plus atteindre vos sites.
# Sans persistance des informations, votre serveur n'est plus en mesure de fournir au client les données nécessaires, et le navigateur client ne peut pas les obtenir lui-même car le service OCSP ne répond pas.
# Avec l'implémentation de mod_md, l'information d'agrafage est stockée de manière persistante, et elle peut donc être rechargée au démarrage du serveur et être ainsi disponible pour les connexions entrantes.
# Un jour ou deux avant expiration des informations, mod_md va les renouveler, ce qui permet de faire face à un temps d'indisponibilité du service OCSP assez long. 
Documentation Apache pour mod_md : https://httpd.apache.org/docs/2.4/fr/mod/mod_md.html
Code source de mod_md sur Github : https://github.com/icing/mod_md
# Activer mod_md :
sudo a2enmod md
# Suite à l'installation du module mod_md, les logs sur SSL en mode debug ne retournent plus le message qui indiquait que mod_md est manquant :
[ssl:debug] [pid 17666] ssl_engine_init.c(1750): AH10083: Init: (www.tiger-green.fr:443) mod_md support is unavailable.
Consulter l'issue suivante sur Github pour plus d'informations : https://github.com/icing/mod_md/issues/196
Consulter le tutoriel suivant, pour avancer sur le bon usage de mod_md : https://chez-oim.org/index.php?topic=1980.75

Module Apache2 negotiation

# Configurer les langues par défaut.
sudo nano /etc/apache2/mods-enabled/negotiation.conf
# Définir le français comme langue préférée :
LanguagePriority fr en ca cs da de el eo es et he hr it ja ko ltz nl nn no pl pt pt-BR ru sv tr zh-CN zh-TW

Module Apache2 proxy et proxy_http

# Activer Mod Proxy et Proxy HTTP.
sudo a2enmod proxy proxy_http
<VirtualHost *:80>
ServerAdmin mail@visionduweb.com
ServerName streaming.domaine.tld
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
ProxyRequests off
</VirtualHost>
Cette exemple permet de rediriger le trafic du port 80 vers le port 8000.

Module Apache2 proxy_fcgi

SCRIPT_FILENAME proxy:fcgi://localhost/srv/www/index.php
Whereas Apache 2.4.25 sets:
SCRIPT_FILENAME /srv/www/index.php
Apache documentation of mod_proxy_fcgi mentions a directive ProxyFCGIBackendType available since Apache 2.4.26 (not released yet as of 2017-05-02), which defaults to "FPM". There is a following note in the description:
One example of values that change based on the setting of this directive is SCRIPT_FILENAME. When using mod_proxy_fcgi historically, SCRIPT_FILENAME was prefixed with the string "proxy:fcgi://". This variable is what some generic FastCGI applications would read as their script input, but PHP-FPM would strip the prefix then remember it was talking to Apache. In 2.4.21 through 2.4.25, this prefix was automatically stripped by the server, breaking the ability of PHP-FPM to detect and interoperate with Apache in some scenarios.

Module Apache2 mod_reqtimeout

Source : https://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html
# Noter que l'activation de ce module pourrait entrainer des erreurs 521 sur les sites utilisant le CDN Cloudflare.
# Désactiver le module mod_reqtimeout :
sudo a2dismod reqtimeout

Module Apache2 mod_rewrite

# Activer Mod Rewrite.
sudo a2enmod rewrite

URL Rewriting

# Mod Rewrite permet d'utiliser la réécriture d'adresses URL, l'URL Rewriting.
# Rediriger un domaine http sans www vers un domaine http avec www.
# Rediriger par exemple http://visionduweb.fr vers http://www.visionduweb.fr
# Les sites n'utilisant que le protocole HTTP sont de moins en moins fréquents, suite au déploiement de HTTPS et de HSTS.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}$1 [R=301,L]
Autres exemples : https://web.archive.org/web/20170616211018/https://craym.eu/tutoriels/referencement/url_rewriting.html
Autres exemples : https://www.askapache.com/htaccess/modrewrite-tips-tricks/

Module Apache2 mod_security - Un pare-feu applicatif

Mod_security est un pare-feu applicatif, un WAF (Web Application Firewall.) qui agit sur la couche 7 du modèle OSI, la couche application. 
La plupart des Pare-feu travaillent sur la couche 3 et agissent au niveau des ports, port 22 pour SSH, port 80 pour le Web...
Il filtre et modifie la réponse renvoyées par le serveur web comme par exemple les erreurs 404 ou 500.
Il surveille le trafic HTTP en temps réel et protège les applications web des attaques Brute force.
Il sert également d'IDS/IPS pour les applications web.
# Configurer modsecurity, voir par la suite pour la configuration sous Debian Stretch :
cd /etc/modsecurity/
sudo nano modsecurity.conf
Le module Apache2 mod_security peut utiliser les règles très strictes de Open Web Application Security Project (OWASP) Core Rules Set (CRS).
Consulter le site officiel : https://www.modsecurity.org (Le site officiel semble avoir des liens obsolètes sur des documentations de 2007.)
Consulter le dépôt Github : https://github.com/SpiderLabs/ModSecurity/wiki#SecStatusEngine

Installer mod-security sur Debian Stretch depuis les dépôts officiels de ModSecurity

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#Installation_for_Apache

Installer mod-security depuis les dépôts de Debian Stretch

# Installer le module mod_security :
sudo apt install libapache2-mod-security2
Les paquets supplémentaires suivants seront installés : 
 liblua5.1-0 libyajl2
Paquets recommandés :
 modsecurity-crs
Les NOUVEAUX paquets suivants seront installés :
 libapache2-mod-security2 liblua5.1-0 libyajl2
# Vérifier que mod_security soit bien chargé par Apache2 :
sudo apachectl -M | grep --color sec
# Le module a été chargé :
# security2_module (shared)
# Sinon, activer Mod Security :
sudo a2enmod mod-security
# Ou plutôt :
sudo a2enmod security2_module
# Ou encore :
sudo a2enmod security2
# L'installation comprend un fichier de configuration recommandé qui doit être renommé avec la commande suivante :
sudo cp /etc/modsecurity/modsecurity.conf{-recommended,}
# Redémarrer Apache :
sudo systemctl restart apache2

Vérifier les logs de ModSecurity

cat /var/log/apache2/error.log | grep ModSecurity
# Ce warning est renvoyé :
[Mon Jul 29 00:00:52.932290 2019] [:notice] [pid 32144] ModSecurity: APR compiled version="1.6.3"; loaded version="1.6.5"
[Mon Jul 29 00:51:18.336161 2019] [:warn] [pid 2157] ModSecurity: Loaded APR do not match with compiled!
Cela signifie que la version de ModSecurity a été compilée avec une version donnée d'Apache Runtime (APR), mais qu'elle s'exécute maintenant avec une version différente d'APR.
Recompiler ModSecurity ou modifier la version d'APR (Cela peut être plus difficile à faire).
ModSecurity peut toujours fonctionner avec cette incohérence, mais vous pouvez être confronté à des problèmes de stabilité ou à des plantages.
Une issue est ouverte : https://github.com/SpiderLabs/ModSecurity/issues/2139

Désinstaller mod-security

sudo apt remove libapache2-mod-security2

Installer mod-security depuis le paquet 2.9.3-1

# Si durant l'installation effectuée avec le paquet du dépot Debbian, le message suivant est affiché :
[Mon Jul 29 00:00:52.932290 2019] [:notice] [pid 32144] ModSecurity: APR compiled version="1.6.3"; loaded version="1.6.5"
# Alors, utiliser la version du paquet Debian mentionné 2.9.3-1+b1 compilé pour APR 1.6.5.
sudo wget http://ftp.fr.debian.org/debian/pool/main/m/modsecurity-apache/libapache2-mod-security2_2.9.3-1_amd64.deb
sudo dpkg -i libapache2-mod-security2_2.9.3-1_amd64.deb
# Vérifier que mod_security soit bien chargé par Apache2 :
sudo apachectl -M | grep --color sec
# Le module a été chargé :
# security2_module (shared)
# Sinon, activer Mod Security :
sudo a2enmod mod-security
# Ou plutôt :
sudo a2enmod security2_module
# Ou encore :
sudo a2enmod security2
# L'installation comprend un fichier de configuration recommandé qui doit être renommé avec la commande suivante :
sudo cp /etc/modsecurity/modsecurity.conf{-recommended,}
# Redémarrer Apache :
sudo systemctl restart apache2

Configurer mod-security2

# Éditer le fichier de configuration :
sudo nano /etc/modsecurity/modsecurity.conf
# Remplacer :
SecRuleEngine DetectionOnly
# Par :
SecRuleEngine On
# SecResponseBodyAccess autorise ModSecurity a observer et mettre en mémoire tampon les corps de réponse.
# Cela n'est nécessaire que si une détection et une protection contre les fuites de données sont requises.
# Si activé, les ressources des serveurs seront utilisées et la taille du fichier journal augmentera également.
# La plupart des déploiements souhaitent se concentrer sur les menaces entrantes, ce qui réduit la consommation de mémoire.
# Remplacer :
SecResponseBodyAccess On
# Par :
SecResponseBodyAccess Off
# Limiter le maximum de données pouvant être publiées sur votre application Web.
# Si vous prenez en charge les téléchargements de fichiers, la valeur indiquée sur la première ligne doit être aussi grande que le fichier le plus volumineux que vous êtes prêt à accepter.
# La deuxième valeur fait référence à la taille des données, fichiers exclus. Vous voulez garder cette valeur aussi basse que possible.
# Si quelque chose de plus gros est envoyé par un client, le serveur répondra par une erreur "413 Request Entity Too Large".
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
On peut également utiliser des règles ModSecurity gratuites fournies par les sociétés de cybersécurité :
https://waf.comodo.com
https://www.atomicorp.com
https://www.owasp.org/index.php/Main_Page

Utiliser ModSecurity pour un développement en local

ModSecurity est un excellent module et une protection fiable.
Il peut être un peu extrême de l'utiliser lors d'un développement en local.
Le comportement de PHPmyAdmin peut être altéré, certains scripts retournerons une erreur car jugés dangereux.
Il est possible de contourner ce problème pour les étapes de développement.
Ajouter la règle suivante dans les options du virtualHost ou dans un fichier .htaccess pour désactiver mod-security :
SecRuleEngine Off
Rétablir la sécurité une fois le développement terminé.

Ressources complémentaires

 Source : https://www.hugeserver.com/kb/install-modsecurity-centos-debian-ubuntu/
 Source : https://www.skyminds.net/serveur-dedie-securiser-apache-2-avec-mod-security/
 Source : https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_security-with-apache-on-debian-ubuntu
 Source : https://phoenixnap.com/kb/setup-configure-modsecurity-on-apache
 Source : https://www.it-connect.fr/installation-de-mod_security-devant-un-serveur-web-apache/#III_Installation_de_mod_security
 Source : https://devops.profitbricks.com/tutorials/how-to-configure-modsecurity-and-mod_evasive-for-apache-on-centos-7/
 Source : https://samhobbs.co.uk/2016/03/getting-started-apache-modsecurity-debian-and-ubuntu
 Source : https://www.linode.com/docs/web-servers/apache-tips-and-tricks/configure-modsecurity-on-apache/
 How to Configure ModSecurity and mod_evasive for Apache2 on CentOS 7 : https://devops.profitbricks.com/tutorials/how-to-configure-modsecurity-and-mod_evasive-for-apache-on-centos-7/

Module Apache2 mod_ssl

# Activer Mod SSL.
a2enmod ssl

Module Apache2 mod_status

# Activer le module :
sudo a2enmod status
# Éditer la configuration :
cd /etc/apache2/mods-available
sudo nano status.conf

# Modifier les lignes :
<Location /server-status>
SetHandler server-status
# Autoriser l'accès à une unique adresse IP, sinon, la page retournera une erreur 403 :
Require ip xx.xx.xxx.xx
</Location>
#Keep track of extended status information for each request
ExtendedStatus On
# Pour arrêter le mod rewrite dans une configuration Joomla, ajouter les deux lignes suivantes au dessus de la dernière redirection présente dans le fichier .htaccess de Joomla.
# Ne pas effectuer de redirection sur l'adresse server-status utilisée avec mod_status de Apache2 :
RewriteCond %{REQUEST_URI} !^/server-(info|status)

# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]

# Sur le même principe :
# Pour arrêter le mod rewrite dans une configuration Wordpress, ajouter les deux lignes suivantes au dessus de la dernière redirection présente dans le fichier .htaccess de Wordpress.
# Ne pas effectuer de redirection sur l'adresse server-status utilisée avec mod_status de Apache2 :
RewriteCond %{REQUESTURI} !=/server-status
# Noter que la configuration du module fonctionne pour tous les VirtualHosts.
# Ainsi, chaque site devra intégrer l'exception de redirection dans son propre fichier .htaccess, pour Joomla, WordPress, ...
# Consulter les statuts du domaine sur une URL de ce format :
https://www.visionduweb.fr/server-status
# Les outils comme Redmine ou Mediawiki ne nécessiteront pas de voir une règle de réécriture être modifiée pour autoriser la consultation. Ils seront immédiatement fonctionnels.
https://redmine.visionduweb.fr/server-status
https://wiki.visionduweb.fr/server-status
Source officielle : https://httpd.apache.org/docs/2.4/fr/mod/mod_status.html
Source complémentaire : https://github.com/icing/mod_md
# Je tente d'afficher l'état du certificat depuis server-status mais sans succès : https://github.com/icing/mod_md/issues/196
# On me propose d'installer https://github.com/tlhackque/httpd-tools pour consolider la configuration.

Module Apache2 mod_userdir

Un espace web pour chaque utilisateur sur Apache2 avec le module mod_userdir.
[Debian 8] mod_userdir, un espace web pour chaque utilisateur sur Apache : https://computerz.solutions/debian-apache-espace-web-pour-chaque-user-mod_userdir/

Module Apache2 mod_watchdog

# Le module mod_watchdog définit des branchements (hooks) programmés pour permettre à d'autres modules d'exécuter des tâches périodiques.
# Ces modules peuvent enregistrer des gestionnaires (handlers) pour les branchements de mod_watchdog.
# Actuellement, seuls les modules suivants de la distribution Apache utilisent cette fonctionnalité :
mod_heartbeat
mod_heartmonitor
mod_md
mod_proxy_hcheck
Source : https://httpd.apache.org/docs/2.4/fr/mod/mod_watchdog.html
Source : https://documentation.help/httpd-2.4/mod_watchdog.html
# Activer mod_watchdog :
sudo a2enmod watchdog
ERROR: Module watchdog does not exist!
# Avec l'installation du paquet watchdog le module mod_watchdog ne semble malgré tout pas disponible pour Apache2.
sudo apt-get install watchdog
sudo service watchdog start
sudo service apache2 restart
sudo service watchdog status
# Watchdog is often directly part of the server and not an external module. Then there is no need to enable it.
# Suite à l'installation du module mod_md, les logs sur SSL en mode debug ne retournent plus le message qui indiquait que mod_md est manquant :
[ssl:debug] [pid 17666] ssl_engine_init.c(1750): AH10083: Init: (www.tiger-green.fr:443) mod_md support is unavailable.

Désactiver des modules

# Désactiver un module.
a2dismod nom_du_module
# Redémarrer Apache2 pour prendre en compte la désactivation d'un module.
sudo systemctl restart apache2

Bibliographie

 La gestion des modules : https://technique.arscenic.org/lamp-linux-apache-mysql-php/apache-le-serveur-http/article/la-gestion-des-modules

NAVIGATION

PARTICIPER ET PARTAGER

Bienvenue sur le wiki de Amis SH.
De nombreuses pages sont partagées sur ce wiki.
Créer un compte utilisateur pour participer sur le wiki.
Les pages présentées sur le wiki évoluent tous les jours.
Certaines recherches sont peu abouties et incluent des erreurs.
Utiliser la recherche interne du wiki pour trouver votre contenu.
La page de discussion de Amis SH vous permet de poser vos questions.
Consulter le site amis-sh.fr pour installer votre propre serveur web.
Améliorer le contenu des pages avec vos retours depuis l'onglet discussion.
Ce contenu ne doit pas servir à nuire à autrui ou à un système informatique.
Protéger votre système Linux ou Windows avec cette page dédiée à la sécurité.

SOUTENIR CE WIKI

Soutenir le wiki avec un don en monnaie numérique :
AEON - Bitcoins - Bitcoins Cash - Bitcoins Gold - Bitcore - Blackcoins - Basic Attention Token - Bytecoins - Clams - Dash - Monero - Dogecoins - Ğ1 - Ethereum - Ethereum Classique - Litecoins - Potcoins - Solarcoins - Zcash

OBTENIR DE LA MONNAIE NUMERIQUE

Obtenir gratuitement de la monnaie numérique :
Miner de la cryptomonnaie.