TL;DR : Le serveur Apache est dorénavant livré en version 2.4 dans les distributions modernes comme Debian 10. Tout apache récent devrait se passer de directives de type allow from [...] ou deny from [...] car elles ont été supplantées depuis longtemps par des directives de type Require allow from [...] ou Require deny from [...]. Je conseille de désactiver le module apache mod_access_compat et de vous débarrasser de sa syntaxe dépréciée au profit de mod_authz_host.
Sommaire
État des lieux access_compat et authz_host
Si je donne l’extrait de configuration Apache suivant (déprécié) qui utilise mod_access_compat avec des directives comme deny from all :
|
1 2 3 4 |
<Directory "/dir"> Order Deny,Allow Deny from all </Directory> |
Est-ce que cela ressemble à quelque chose sur votre serveur ? Si oui, il est temps de vous en débarrasser au profit de la syntaxe suivante utilisant mod_authz_host :
|
1 2 3 |
<Directory "/dir"> Require all denied </Directory> |
Pourquoi opérer un tel changement ?
- Tout d’abord parce que c’est la documentation Apache officielle qui le dit ;
- Ensuite, parce que le mélange des deux entraîne des comportements imprévisibles (voir mes déboires à ce sujet) ;
- Pour finir, parce que la nouvelle syntaxe est meilleure car elle unifie les contrôles d’accès et les méthodes d’authentification selon une même logique comme avec auth_basic et auth_digest.
Vous êtes convaincus ? Allons-y !
Se passer de access_compat
Pour commencer je vous propose de désactiver le module apache access_compat grâce à a2dismod access_compat suivi d’un rechargement de Apache service apache2 reload . Préalablement il faudra retirer toutes les lignes utilisant la syntaxe dépréciée car elle ne sera plus supportée par votre serveur.
Attention, le rechargement de Apache ne sera pas possible tant que vos fichiers de configuration ne seront pas nettoyés de la syntaxe dépréciée.
Mettre en place authz_host
Le module authz_host et sa dépendance authz_core sont activés pour toute installation récente de Apache, il ne sera pas nécessaire de les activer.
Pour mettre à jour vos fichiers de configuration avec la nouvelle syntaxe je vous propose de vous fier à l’article suivant qui propose un tableau de conversions.
Pour aller plus loin…
Un exemple de configuration adaptative
Certains framework comme Symfony ou certains modules de Prestashop déploient une configuration capable de s’adapter à l’existant sur le serveur d’hébergement.
Exemple ici avec l’interdiction du fichier composer.lock. Si le module mod_authz_core est absent on utilise la syntaxe Apache 2.2 ou Apache 2.4 avec access_compat . Si le module mod_authz_core est présent on l’utilise.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<Files composer.lock> # Apache 2.2 <IfModule !mod_authz_core.c> Order deny,allow Deny from all </IfModule> # Apache 2.4 <IfModule mod_authz_core.c> Require all denied </IfModule> </Files> |
Un exemple d’utilisation mixte de mod_authz_core avec auth_digest
La configuration qui suit nécessite soit d’avoir une IP amie, soit de connaître le mot de passe de l’authentification auth_digest.
Vous pouvez voir que mod_authz_core et auth_digest utilisent une même logique, une même syntaxe et que les règles d’accès mixtes sont ainsi très proprement configurées.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<Directory /var/www/mon-site.fr/mon-dossier> <RequireAny> # Aucun AuthType, et restrictions par IP AuthType None Require ip mon-ip-amie # AuthType permis par le module auth_digest, et restriction par mot de passe AuthType Digest AuthName "Halte" AuthBasicProvider file AuthUserFile /etc/apache2/htdigest Require valid-user </RequireAny> </Directory> |
