Une sorte de bug que vous pouvez rencontrer avec une configuration apache avancée, qui utilise de nombreuses règles pour interdire et autoriser fichiers et dossiers, le site se retrouve interdit aux IP que vous vouliez expressément autoriser.
Le comportement qui suit n’est pas évident à expliquer, je l’ai mis en évidence dans des cas de figure de sites privés et sécurisés pour n’autoriser que certaines adresses IP amies. Ces sites se mettaient à interdire expressément les adresses IP définies comme amies, l’effet inverse !
Description de la configuration fautive
La configuration en question met en jeu apache 2.4.10-10+deb8u5 avec un site délivré par HTTPS grâce à mod_ssl et un certificat payant. La compression des pages est activée par mod_deflate. le log d’erreur qui suit n’est visible qu’en configurant LogLevel debug .
La configuration se fait dans plusieurs fichiers qui se trouvent dans les répertoires conf-enabled et sites-enabled mais cela n’a pas grande importance.
Etape 1 : sur tous les sites, on interdit l’accès aux les fichiers PHP à tout le monde (sauf index.php)
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<Directory /var/www/> Options -Indexes AllowOverride None <FilesMatch ".+\.ph(p[345]?|t|tml)$"> deny from all </FilesMatch> <Files "index.php"> allow from all </Files> </Directory> |
Etape 2 : sur le site voulu, on autorise l’accès aux utilisateurs authentifiés ou les IP amies
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<Directory /var/www/site> AuthUserFile /etc/apache2/htdigest AuthType Digest AuthName "domaine" Require valid-user Order Deny,Allow Deny from all Allow from 1.2.3.4 Satisfy any </Directory> |
Log d’erreur
|
1 2 3 4 5 6 7 |
==> /var/log/apache2/site.fr.error.log <== [Mon Dec 05 09:50:55.409020 2016] [ssl:debug] [pid 18508] ssl_engine_kernel.c(243): [client 1.2.3.4:49347] AH02034: Initial (No.1) HTTPS request received for child 1 (server site.fr:443) [Mon Dec 05 09:50:55.409284 2016] [authz_core:debug] [pid 18508] mod_authz_core.c(809): [client 1.2.3.4:49347] AH01626: authorization result of Require valid-user : denied (no authenticated user yet) [Mon Dec 05 09:50:55.409294 2016] [authz_core:debug] [pid 18508] mod_authz_core.c(809): [client 1.2.3.4:49347] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet) ==> /var/log/apache2/site.fr.access.log <== 1.2.3.4 - - [05/Dec/2016:09:50:55 +0100] "GET / HTTP/1.1" 401 780 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0" |
Correction de la configuration
La première étape reste inchangée dans la configuration modifiée, on se contente d’intercaler une directive <Files>.
Etape 2 : sur le site voulu, on autorise l’accès aux utilisateurs authentifiés ou les IP amies
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<Directory /var/www/site> <Files *> AuthUserFile /etc/apache2/htdigest AuthType Digest AuthName "domaine" Require valid-user Order Deny,Allow Deny from all Allow from 1.2.3.4 Satisfy any </Files> </Directory> |
Log d’autorisation qui fonctionne
|
1 2 3 4 5 6 7 8 |
==> /var/log/apache2/site.fr.error.log <== [Mon Dec 05 09:53:37.333296 2016] [ssl:debug] [pid 18730] ssl_engine_kernel.c(243): [client 1.2.3.4:49388] AH02034: Initial (No.1) HTTPS request received for child 1 (server site.fr:443) [Mon Dec 05 09:53:37.333728 2016] [authz_core:debug] [pid 18730] mod_authz_core.c(809): [client 1.2.3.4:49388] AH01626: authorization result of Require all granted: granted [Mon Dec 05 09:53:37.333739 2016] [authz_core:debug] [pid 18730] mod_authz_core.c(809): [client 1.2.3.4:49388] AH01626: authorization result of <RequireAny>: granted [Mon Dec 05 09:53:37.673912 2016] [deflate:debug] [pid 18730] mod_deflate.c(855): [client 1.2.3.4:49388] AH01384: Zlib: Compressed 92261 to 16803 : URL /php5-fcgi-site/index.php ==> /var/log/apache2/site.fr.access.log <== 1.2.3.4 - - [05/Dec/2016:09:53:37 +0100] "GET / HTTP/1.1" 200 22353 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0" |
Conclusion
Il semblerait que l’élément fautif dans cette configuration soit le fait d’interdire un ensemble de fichiers via la directive <FilesMatch>, et de chercher à contrecarrer cette interdiction via la directive <Directory>. En conclusion je pense qu’à une règle <FilesMatch> il faut opposer une règle identique ou équivalente comme <Files>. Idem pour <Directory> et <DirectoryMatch>. Et pourtant, on pourrait croire que le <Files *> n’a aucune signification concrète puisqu’il cible tous les fichiers !
A creuser : il me semble bien que si on limite les règles de restriction de fichiers à du Deny,Allow à base d’IP, le problème ne se pose pas même en l’absence de <Files *> .
Ajout postérieur (2019) : je pense que l’utilisation du module apache access_compat (et sa syntaxe Order allow,deny ) en lien avec l’authentification Digest est responsable de pas mal de difficultés de ce type. Il est donc préférable de passer à 100% sur le module authz_host car sa syntaxe de type Require est tout à fait compatible avec l’authentification Digest ou autre.
De plus, le module access_compat est déprécié par le manuel Apache.
