« Installation de configuration du serveur web Apache 2.4 sous Debian Bullseye » : différence entre les versions
(→php) |
|||
(3 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 14 : | Ligne 14 : | ||
* Encore une fois, prenez garder à la manière dont les directives se chaînent. Cela peut conduire à de graves défaut de sécurité étant donné que la directive [http://httpd.apache.org/docs/2.4/fr/mod/mod_authz_core.html#authmerging authmerging] est par défaut à off dans apache. En gros, si vous interdisez l'accès au répertoire "config" avec une directive <Directory> puis que vous autorisez l'accès au répertoire parent à l'aide d'une directive <Location>, le répertoire config deviendra accessible en lecture et ce pour deux raisons : l'ordre d'application des directives (Location appliqué après Directory) et le fait que les autorisations d'accès s'annulent les unes les autres (authmerging à off). | * Encore une fois, prenez garder à la manière dont les directives se chaînent. Cela peut conduire à de graves défaut de sécurité étant donné que la directive [http://httpd.apache.org/docs/2.4/fr/mod/mod_authz_core.html#authmerging authmerging] est par défaut à off dans apache. En gros, si vous interdisez l'accès au répertoire "config" avec une directive <Directory> puis que vous autorisez l'accès au répertoire parent à l'aide d'une directive <Location>, le répertoire config deviendra accessible en lecture et ce pour deux raisons : l'ordre d'application des directives (Location appliqué après Directory) et le fait que les autorisations d'accès s'annulent les unes les autres (authmerging à off). | ||
* '''De manière globale, préférez la directive <Directory> (et ses dérivés comme <files> <DirectoryMatch> ou <FilesMatch>) a la directive <Location> (et ses dérivés comme <LocationMatch>) quand vous sécurisez des chemins du système de fichier de votre machine.''' N'utilisez <Location> que si vous définissez les règles d'accès à une ressource qui ne se situe pas sur le système de fichier (page générée par une base de donnée par exemple) | * '''De manière globale, préférez la directive <Directory> (et ses dérivés comme <files> <DirectoryMatch> ou <FilesMatch>) a la directive <Location> (et ses dérivés comme <LocationMatch>) quand vous sécurisez des chemins du système de fichier de votre machine.''' N'utilisez <Location> que si vous définissez les règles d'accès à une ressource qui ne se situe pas sur le système de fichier (page générée par une base de donnée par exemple) | ||
* La configuration de apache sous debian est modulaire, pensez cependant à lire l'ensemble de cette configuration, vous pourriez y trouver des surprises (y compris /etc/apache2/apache2.conf !). N'oubliez pas non l'ordre de lecture qui peut changer la manière dont les règles s'appliquant : <code>/etc/apache2/apache2.conf</code>, puis <code>conf-enabled/*.conf</code>, puis <code>sites-enabled/*.conf</code> | * La configuration de apache sous debian est modulaire, pensez cependant à lire l'ensemble de cette configuration, vous pourriez y trouver des surprises (y compris /etc/apache2/apache2.conf !). N'oubliez pas non l'ordre de lecture qui peut changer la manière dont les règles s'appliquant : <code>/etc/apache2/apache2.conf</code>, puis <code>conf-enabled/*.conf</code> (ordre alphanumérique), puis <code>sites-enabled/*.conf</code> (ordre alphanumérique). | ||
* Faites attention aux directives Include fournies par certains paquets. Lisez toujours tout fichier que vous incluez à la configuration de apache ou d'une vhost ! | * Faites attention aux directives Include fournies par certains paquets. Après installation, ils sont parfois automatiquement chargés, parfois il faudra passer par <code>a2enconf</code>. Lisez toujours tout fichier que vous incluez à la configuration de apache ou d'une vhost ! | ||
* De même, faites attentions à certains paquets qui ont tendance à ajouter par défaut un fichier de configuration et à l'activer dans <code>conf-enabled/</code> | * De même, faites attentions à certains paquets qui ont tendance à ajouter par défaut un fichier de configuration et à l'activer dans <code>conf-enabled/</code> | ||
* Par défaut, debian autorise l'accès à <code>/usr/share</code>. Il peut être bon de désactiver globalement ce comportement en créant un fichier de configuration dans conf-enabled, quitte à réactiver l'accès au cas par cas. | * Par défaut, debian autorise l'accès à <code>/usr/share</code>. Il peut être bon de désactiver globalement ce comportement en créant un fichier de configuration dans conf-enabled, quitte à réactiver l'accès au cas par cas. | ||
Ligne 73 : | Ligne 73 : | ||
Créez le fichier /etc/apache2/conf-available/zzz_localsecurity.conf (le faire commencer par zzz devrait vous assurer qu'il soit lu en dernier) | Créez le fichier /etc/apache2/conf-available/zzz_localsecurity.conf (le faire commencer par zzz devrait vous assurer qu'il soit lu en dernier) | ||
<pre> | <pre> | ||
# | # Disable access to /usr/share by default | ||
<Directory /usr/share> | <Directory /usr/share> | ||
AllowOverride None | AllowOverride None | ||
Ligne 84 : | Ligne 84 : | ||
</Directory> | </Directory> | ||
# | # Disable access to svt tree | ||
<DirectoryMatch "/\.svn"> | <DirectoryMatch "/\.svn"> | ||
Require all denied | Require all denied | ||
</DirectoryMatch> | </DirectoryMatch> | ||
# | # Disable access to git tree | ||
<DirectoryMatch "/\.git"> | <DirectoryMatch "/\.git"> | ||
Require all denied | Require all denied | ||
</DirectoryMatch> | </DirectoryMatch> | ||
# | # Disable access to .htaccess and .htpasswd files | ||
<FilesMatch "^\.ht"> | <FilesMatch "^\.ht"> | ||
Require all denied | Require all denied | ||
</FilesMatch> | </FilesMatch> | ||
# | # Disable access to htpasswd and htdigest files as some user don't make them hidden | ||
<FilesMatch "htpasswd"> | <FilesMatch "htpasswd"> | ||
Require all denied | Require all denied | ||
Ligne 111 : | Ligne 111 : | ||
</IfModule> | </IfModule> | ||
# | # For mpm itk | ||
<IfModule mpm_itk_module> | <IfModule mpm_itk_module> | ||
# first uid need to be 33 for www-data (default uid/gid, can be tuned) | # first uid need to be 33 for www-data (default uid/gid, can be tuned) | ||
Ligne 157 : | Ligne 157 : | ||
<pre> | <pre> | ||
aptitude install libapache2-mod-php | aptitude install libapache2-mod-php | ||
a2enmod php7 | a2enmod php7* | ||
</pre> | </pre> | ||
Version du 4 novembre 2020 à 10:20
Les différents mpm
Les différents mpm de apache sont fournis sous forme de modules et ce dès l'installation du paquet apache2
. La seule exception est le mpm ITK qui nécessite l'installation du paquet libapache2-mpm-itk
Installation
aptitude install apache2
Considérations de sécurité
- Même si les directives sont lues dans l'ordre dans lequel vous les inscrivez, certaines restent appliqués avant les autres (cf https://httpd.apache.org/docs/2.4/sections.html#merging). L'ordre d'application de apache est <Directory> -> htaccess -> <DirectoryMatch> -> <files> et <filesmatch> -> <Location> et <LocationMatch>. La dernière directive appliquée prendra le dessus sur les autres.
- Encore une fois, prenez garder à la manière dont les directives se chaînent. Cela peut conduire à de graves défaut de sécurité étant donné que la directive authmerging est par défaut à off dans apache. En gros, si vous interdisez l'accès au répertoire "config" avec une directive <Directory> puis que vous autorisez l'accès au répertoire parent à l'aide d'une directive <Location>, le répertoire config deviendra accessible en lecture et ce pour deux raisons : l'ordre d'application des directives (Location appliqué après Directory) et le fait que les autorisations d'accès s'annulent les unes les autres (authmerging à off).
- De manière globale, préférez la directive <Directory> (et ses dérivés comme <files> <DirectoryMatch> ou <FilesMatch>) a la directive <Location> (et ses dérivés comme <LocationMatch>) quand vous sécurisez des chemins du système de fichier de votre machine. N'utilisez <Location> que si vous définissez les règles d'accès à une ressource qui ne se situe pas sur le système de fichier (page générée par une base de donnée par exemple)
- La configuration de apache sous debian est modulaire, pensez cependant à lire l'ensemble de cette configuration, vous pourriez y trouver des surprises (y compris /etc/apache2/apache2.conf !). N'oubliez pas non l'ordre de lecture qui peut changer la manière dont les règles s'appliquant :
/etc/apache2/apache2.conf
, puisconf-enabled/*.conf
(ordre alphanumérique), puissites-enabled/*.conf
(ordre alphanumérique). - Faites attention aux directives Include fournies par certains paquets. Après installation, ils sont parfois automatiquement chargés, parfois il faudra passer par
a2enconf
. Lisez toujours tout fichier que vous incluez à la configuration de apache ou d'une vhost ! - De même, faites attentions à certains paquets qui ont tendance à ajouter par défaut un fichier de configuration et à l'activer dans
conf-enabled/
- Par défaut, debian autorise l'accès à
/usr/share
. Il peut être bon de désactiver globalement ce comportement en créant un fichier de configuration dans conf-enabled, quitte à réactiver l'accès au cas par cas.
Exemple d'erreur a ne pas faire
- Dans cet exemple, on autorise l'accès a /srv/http/, puis on interdit l'accès a /srv/http/admin, puis on réautorise l'accès a l'ensemble de l'arborescence avec la dernière directive Location. Résultat : votre interface d'admin est accessible de l'extérieur.
DocumentRoot /srv/http/ <Directory /srv/http/> require all granted </Directory> <Directory /srv/http/admin> require all denied </Directory> <Location /> require all granted </Location>
- Dans cet exemple, l'utilisation de la directive location rendra accessible le fichier /srv/http/.htaccess malgré l'utilisation d'un FilesMatch antérieur.
<FilesMatch ".htaccess"> Require all denied </FilesMatch> DocumentRoot /srv/http/ <Location /> require all granted </Location>
Configuration
Configuration par défaut de apache
/etc/apache2/apache2.conf
Le fichier de configuration par défaut de apache. Il défini quelques variables dont vous ne devriez, dans la majorité des cas, pas avoir à vous soucier. Plus important, c'est grâce a lui que les autres fichiers de configuration sont chargés.
A noter cependant, ce fichier défini par défaut la variable AllowOverride None
pour la totalité de votre arborescence linux (ce qui empêche un éventuel fichier htaccess
quelque part dans votre arborescence de modifier la configuration de sécurité d'un dossier) et interdit l'accès à toute votre arborescence à l'exception de /usr/share
Evitez de faire des modifications dans ce fichier, nous le feront plus loin dans les fichiers de configuration indépendants.
/etc/apache2/ports.conf
Ce fichier se charge de définir les ports sur lesquels apache écoutera. Si vous souhaitez utiliser apache sur d'autres ports sur 80 et 443, il faudra jouter des lignes Listen
pour chaque port.
/etc/apache2/mods-enabled/*.conf
: fichiers chargés dans l'ordre numérique puis alphabétique
Charge les différents modules installés ainsi que leur configuration. Dans la majorité des cas, la configuration par défaut des modules est tout à fait convenable d'un point de vue sécurité.
Gardez cependant en mémoire les fichiers mpm_event.conf
et mpm_prefork.conf
qui peuvent vous permettre de d'optimiser les performances de apache.
A noter le fichier status.conf
qui restreint l'utilisation de module status a l'ip locale du serveur.
/etc/apache2/conf-enabled/*.conf
: fichiers chargés dans l'ordre numérique puis alphabétiquesecurity.conf
: passez principalement la variableServerTokens prod
javascript-common.conf
: fichier à surveiller étant donné qu'il créé un alias global /javascript, cependant, l'accès ne sera pas autorisé par défaut (voir plus loin)serve-cgi-bin.conf
: un trou de sécurité à part entière qui active les scripts cgi installés dans toutes les vhosts ... je vous conseille rapidement de désactiver ce script tout simplement et d'activer les scripts cgi a la demande dans les vhosts le necessitant. Attention cependant, désactiver ce script rendra potentiellement inutilisable les configurations par défaut fournis avec certains paquets (smokeping par exemple). Pour le désactiver, rien de plus simple :a2disconf serve-cgi-bin.conf
Configuration de sécurité en sus
Nous allons créer un fichier afin d'interdire l'accès à certains dossiers qu'apache autorise en général par défaut. Notez qu'activer ces options empêchera la configuration par défaut de nombreux paquets debian de fonctionner.
Créez le fichier /etc/apache2/conf-available/zzz_localsecurity.conf (le faire commencer par zzz devrait vous assurer qu'il soit lu en dernier)
# Disable access to /usr/share by default <Directory /usr/share> AllowOverride None Require all denied </Directory> <Directory /usr/lib/cgi-bin/> AllowOverride None Require all denied </Directory> # Disable access to svt tree <DirectoryMatch "/\.svn"> Require all denied </DirectoryMatch> # Disable access to git tree <DirectoryMatch "/\.git"> Require all denied </DirectoryMatch> # Disable access to .htaccess and .htpasswd files <FilesMatch "^\.ht"> Require all denied </FilesMatch> # Disable access to htpasswd and htdigest files as some user don't make them hidden <FilesMatch "htpasswd"> Require all denied </FilesMatch> <FilesMatch "htdigest"> Require all denied </FilesMatch> <IfModule php7_module> php_admin_value open_basedir /var/www/ </IfModule> # For mpm itk <IfModule mpm_itk_module> # first uid need to be 33 for www-data (default uid/gid, can be tuned) LimitUIDRange 33 2000 LimitGIDRange 33 2000 # Drop most root capabilities in the parent process. # Instead run as the user given by the User/Group directives with some extra capabilities # Somewhat more secure. EnableCapabilities on </IfModule>
Activez ce fichier de configuration :
a2enconf zzz_localsecurity.conf /etc/init.d/apache2 reload
Imbrications des directives
Pour la directive Location
, le mappage se fait du moins spécifique au plus spécifique :
<Location "/foo"> </Location> <Location "/foo/bar"> </Location>
Pour les alias et les proxy, le mappage se fait dans le sens inverse, du plus spécifique au moins spécifique :
Alias "/foo/bar" "/srv/www/uncommon/bar" Alias "/foo" "/srv/www/common/foo"
ProxyPass "/special-area" "http://special.example.com" ProxyPass "/" "http://www.example.com"
Vérifier la configuration de apache
apache2ctl configtest
php
aptitude install libapache2-mod-php a2enmod php7*
Sécurité
- open_basedir avec une règle par défaut définie dans /etc/apache2/mods-enabled/zzz_localsecurity.conf
- le mpm itk afin de pouvoir lancer les scripts php avec les permissions utilisateurs
la gestion des virtualhosts
L'architecture de configuration modulaire de apache sous debian propose de créer les fichiers de configuration des vhosts dans /etc/apache2/sites-available/
puis de les activer avec a2ensite
afin qu'ils soient lus via le dossier /etc/apache2/sites-enabled
Je vous conseille cependant de créer, en plus, un dossier /etc/apache2/sites-config
afin de créer des fichiers de configuration pouvant être utilisé dans plusieurs vhosts (par exemple, le même site, l'un en https, l'autre non) :
mkdir /etc/apache2/sites-config
Configuration recommandée dans toute virtualhost
open_basedir
open_basedir permet de limiter le champ d'action des fichiers php en terme de dossiers. Etant donné que nous avons défini un open_basedir restrictif un peu plus haut, si vous utilisez php, il est obligatoire de rédéfinir open_basedir pour correspondre aux dossiers auxquelles vos fichiers php doivent pouvoir accéder. En général, c'est tout simplement le même dossier que votre DocumentRoot
php_admin_value open_basedir /votre/documentroot
AllowOverride
AllowOverride permet de définir les règles autorisées à être modifiées par un fichier .htaccess
La configuration apache que nous avons vu plus tôt désactive complètement les fichiers .htaccess
dans la totalité du système de fichier. Le problème de ce comportement est que les fichiers htaccess seront tout simplement ignoré, or, de nombreux projets utilisent les fichiers htaccess pour protéger de la lecture certains répertoires sensibles (fichiers de configurations, etc).
Si vous êtes certain que votre projet n'utilise pas de fichiers .htaccess, la question ne se pose même pas, gardez les fichiers htaccess désactivés ! Même s'ils sont pratiques, ils restent des fichiers relativement faciles à modifier (un peu de code foireux dans un module externe d'un CMS par exemple) et offrent donc une sécurité bien moindre que les directives définies directement dans la configuration de votre virtualhost apache ! Ils ont par ailleurs un impact sur les performances de apache.
Notez que cette directive doit obligatoirement être définie dans un champ <Directory>
Dans tous les cas :
- Évitez absolument d'allowoverride fileinfo (permet de modifier l'handler par défaut d'un fichier)
- Évitez si possible d'allowoverride options (car permet principalement d'activer l'execution CGI)
- Si vous êtes certains que votre projet n'utilise pas de fichiers .htaccess :
AllowOverride none
- Le cas échéant, la configuration minimale suivante est recommandée, étant donné que de nombreux projets utilisent des fichiers .htaccess afin de limiter l'accès a des répertoires :
AllowOverride Limit AllowOverrideList Require
- Si jamais le projet en question necessite les directives d'authentifications, on pourra définir comme cela :
AllowOverride Limit AuthConfig
- Si vous faites de l'hosting, de nombreux utilisateurs auront besoin des directives AuthConfig, Indexes, mais aussi des règles de redirections et de rewrite :
AllowOverride AuthConfig Indexes Limit Options=Indexes AllowOverrideList Redirect RedirectMatch RedirectTemp RedirectPermanent RewriteEngine RewriteOptions RewriteBase RewriteCond RewriteRule ErrorDocument
Gestion des index et autoindex
DirectoryIndex, c'est ce petit machin qui permet (à condition d'avoir le module dir
activé) à apache de recherche automatiquement un fichier d'index (index.html, index.php, ...) pour afficher la page si le client n'en précise pas (quand vous chargez https://www.online.net/ c'est https://www.online.net/index.php qui est affiché). Si vous ne souhaitez pas bénéficier de cette fonctionnalité (par exemple si le client doit de toute façon charge une page précise sans passer par un quelconque index, désactivez le :
DirectoryIndex disabled
mod_autoindex
est un petit module qui permet à apache d'afficher l'arborescence fichier. Cela peut être très pratique, mais aussi délétère et peut rendre votre site plus facile à scanner. Si vous n'en avez pas besoin, pensez à le désactiver ou a ne l'activer que dans les dossiers que vous voulez rendre visible totalement au publiques. Notez que la configuration par défaut de apache sous debian jessie laisse le module désactivé.
Options -Indexes
AssignUserId
name-based
Ip-based
Activer server-status / vhost d'admin
Authentification
Authentification Basic
- C'est le mode d'authentification HTTP le plus fréquement utilisé
- le mot-de-passe est stocké de manière cryptée sur le serveur
- le client envoi le mot-de-passe en clair au serveur (en base64 en fait, mais c'est du pareil au même), ce qui rend ce mode non sécurisé si la connexion n'est pas effectuée en HTTPS
- Préférez la création d'un fichier nommé
.htpasswd
étant donné que ces fichiers sont interdits de lecture par la configuration par défaut de apache (/etc/apache2/apache2.conf). Dans la mesure du possible, ne créez des fichiers.htpasswd
que dans un dossier de toute façon inaccessible au serveur web (donc en dehors du documentroot et de tout alias). En effet, les directives d'autorisations de apache d'une section supérieure annulent les directives d'autorisations précédentes de apache (AuthMerging
à off par défaut), donc si vous autorisez l'accès complet à un repertoire (require all granted), vous risquez de supplanter la directive interdisant l'accès aux fichiers protégés
Création du fichier contenant les mots-de-passe :
htpasswd -c .htpasswd pfoo New password: Re-type new password: Adding password for user pfoo
Pour ajouter un nouvel utilisateur, ou modifier le mot-de-passe d'un utilisateur existant, la commande est la même sans l'argument -c
htpasswd .htpasswd pfoo
Le fichier .htgroup
permet de rassembler plusieurs utilisateurs dans un même groupe. Il suffit de créer un fichier (.htgroup) texte contenant par exemple (pour créer un groupe admin et un groupe user) :
admin: pfoo plop user: blah
Pour que tous les utilisateurs valides (qui sont présent dans le .htpasswd) aient accès au dossier :
AuthUserFile /path/to/.htpasswd AuthName "Accès Restreint" AuthType Basic require valid-user
Accès pour l'utilisateur pfoo et l'ensemble du groupe user uniquement :
AuthUserFile /path/to/.htpasswd AuthGroupFile /path/to/.htgroup AuthName "Accès Restreint" AuthType Basic require user pfoo require group user
Authentification Digest
- le mot-de-passe est stocké en clair sur le serveur ce qui le rend plus vulnérable à une fuite de données côté serveur (en clair ou sous forme condensée, sans salage possible, donc un pirate obtenant l'accès au fichier contenant la base de donnée digest aura un accès complet aux ressources du serveur et sans étape de décryptage)
- le client envoi le mot-de-passe hashé avec un nonce et un realm, ce qui assure que le mot-de-passe ne circule jamais en clair sur le réseau et ce même sans HTTPS
- Préférez la création d'un fichier nommé .htpasswd étant donné que ces fichiers sont interdits de lecture par la configuration par défaut de apache (/etc/apache2/apache2.conf)
L'outil htdigest permet de créer un fichier .htpasswd utilisant cette méthode d'authentification. Vous pouvez entrer ce que vous voulez en realm.
htdigest -c .htpasswd "votre realm" username
Pour ajouter un nouvel utilisateur, ou modifier le mot-de-passe d'un utilisateur existant, la commande est la même sans l'argument -c
:
htdigest .htpasswd "votre realm" pfoo
Le fichier .htgroup
permet de rassembler plusieurs utilisateurs dans un même groupe. Il suffit de créer un fichier (.htgroup) texte contenant par exemple (pour créer un groupe admin et un groupe user) :
admin: pfoo plop user: blah
Pour que tous les utilisateurs valides (qui sont présent dans le .htpasswd) aient accès au dossier :
AuthType Digest AuthName "votre realm" AuthDigestDomain / AuthDigestProvider file AuthUserFile /path/to/.htpasswd AuthGroupFile /path/to/.htgroup Require valid-user
Accès pour l'utilisateur pfoo et l'ensemble du groupe user uniquement :
AuthType Digest AuthName "votre realm" AuthDigestDomain / AuthDigestProvider file AuthUserFile /path/to/.htpasswd AuthGroupFile /path/to/.htgroup require user pfoo require group user
HTTPS
Redirection HTTP vers HTTPs
- Solution avec le module Rewrite, applicable à la fois dans une vhost écoutant sur les port 80 ou 443 :
RewriteEngine on RewriteCond %{HTTPS} off RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]
Il peut être intéressant de ne pas rewrite certaine URLs. Dans l'exemple ci dessous, les urls en lien avec les challenges letsencrypt :
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
- Solution avec le module Alias, à ne surtout pas appliquer dans une vhost écoutant sur le port 443 (redirection infinie) :
Redirect permanent / https://domain.tld/
Tests de sécurité divers
https://observatory.mozilla.org/
https://tls.imirhil.fr/
https://www.ssllabs.com/ssltest/