« Installation de configuration du serveur web Apache 2.4 sous Debian Bullseye » : différence entre les versions

Aller à la navigation Aller à la recherche
(47 versions intermédiaires par le même utilisateur non affichées)
Ligne 11 : Ligne 11 :
=Considérations de sécurité=
=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 : <Directory> avant htaccess avant <file> et en dernier <Location>
* 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.
* De manière globale, préférez la directive <Directory> a <Location> quand vous sécurisez des chemins du système de fichier de votre machine
* 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).
* 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>
* '''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)
* Faites attention aux directives Include fournies par certains paquets. Lisez toujours tout fichier que vous incluez a la configuration de apache ou d'une vhost !
* 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).
* De même, faites attentions a certains paquets qui ont tendance à ajouter par défaut un fichier de configuration et a l'activer dans  <code>conf-enabled/</code>
* 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 !
* 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 a réactiver l'accès au cas par cas.
* 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.


== Exemple d'erreur a ne pas faire ==
== 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.
<pre>
<pre>
DocumentRoot /srv/http/
DocumentRoot /srv/http/
Ligne 31 : Ligne 34 :
</Location>
</Location>
</pre>
</pre>
Ici, 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.
 
* Dans cet exemple, l'utilisation de la directive location rendra accessible le fichier /srv/http/.htaccess malgré l'utilisation d'un FilesMatch antérieur.
<pre>
<FilesMatch ".htaccess">
        Require all denied
</FilesMatch>
DocumentRoot /srv/http/
<Location />
  require all granted
</Location>
</pre>


=Configuration=
=Configuration=
Ligne 60 : 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
# Disable access to /usr/share by default
<Directory /usr/share>
<Directory /usr/share>
         AllowOverride None
         AllowOverride None
Ligne 71 : Ligne 84 :
</Directory>
</Directory>


#disable access to svt tree
# Disable access to svt tree
<DirectoryMatch "/\.svn">
<DirectoryMatch "/\.svn">
   Require all denied
   Require all denied
</DirectoryMatch>
</DirectoryMatch>


#disable access to git tree
# Disable access to git tree
<DirectoryMatch "/\.git">
<DirectoryMatch "/\.git">
   Require all denied
   Require all denied
</DirectoryMatch>
</DirectoryMatch>


<IfModule php5_module>
# 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/
   php_admin_value open_basedir /var/www/
</IfModule>
</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>
</pre>
</pre>


Ligne 89 : Ligne 127 :
<pre>a2enconf zzz_localsecurity.conf
<pre>a2enconf zzz_localsecurity.conf
/etc/init.d/apache2 reload</pre>
/etc/init.d/apache2 reload</pre>
==Imbrications des directives==
Pour la directive <code>Location</code>, le mappage se fait du moins spécifique au plus spécifique :
<pre>
<Location "/foo">
</Location>
<Location "/foo/bar">
</Location>
</pre>
Pour les alias et les proxy, le mappage se fait dans le sens inverse, du plus spécifique au moins spécifique :
<pre>
Alias "/foo/bar" "/srv/www/uncommon/bar"
Alias "/foo" "/srv/www/common/foo"
</pre>
<pre>
ProxyPass "/special-area" "http://special.example.com"
ProxyPass "/" "http://www.example.com"
</pre>


==Vérifier la configuration de apache==
==Vérifier la configuration de apache==
Ligne 97 : Ligne 156 :


<pre>
<pre>
aptitude install libapache2-mod-php5
aptitude install libapache2-mod-php
a2enmod php5
a2enmod php7*
</pre>
</pre>


Ligne 104 : Ligne 163 :


* open_basedir avec une règle par défaut définie dans [[#Configuration_de_sécurité_en_sus|/etc/apache2/mods-enabled/zzz_localsecurity.conf]]
* open_basedir avec une règle par défaut définie dans [[#Configuration_de_sécurité_en_sus|/etc/apache2/mods-enabled/zzz_localsecurity.conf]]
* libapache2-mpm-itk afin de pouvoir lancer les scripts php avec les permissions utilisateurs
* le mpm itk afin de pouvoir lancer les scripts php avec les permissions utilisateurs


=la gestion des virtualhosts=
=la gestion des virtualhosts=
Ligne 149 : Ligne 208 :
AllowOverrideList Redirect RedirectMatch RedirectTemp RedirectPermanent RewriteEngine RewriteOptions RewriteBase RewriteCond RewriteRule ErrorDocument
AllowOverrideList Redirect RedirectMatch RedirectTemp RedirectPermanent RewriteEngine RewriteOptions RewriteBase RewriteCond RewriteRule ErrorDocument
</pre>
</pre>
===Gestion des index et autoindex===
DirectoryIndex, c'est ce petit machin qui permet (à condition d'avoir le module <code>dir</code> 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 :
<pre>DirectoryIndex disabled</pre>
<code>mod_autoindex</code> 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é.
<pre>Options -Indexes</pre>


===AssignUserId===
===AssignUserId===
Ligne 157 : Ligne 224 :


==Activer server-status / vhost d'admin==
==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é <code>.htpasswd</code> é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 <code>.htpasswd</code> 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 (<code>AuthMerging</code> à 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
<br>
Création du fichier contenant les mots-de-passe :
<pre>htpasswd -c .htpasswd pfoo
New password:
Re-type new password:
Adding password for user pfoo
</pre>
Pour ajouter un nouvel utilisateur, ou modifier le mot-de-passe d'un utilisateur existant, la commande est la même sans l'argument <code>-c</code>
<pre>htpasswd .htpasswd pfoo</pre>
Le fichier <code>.htgroup</code> 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) :
<pre>admin: pfoo plop
user: blah</pre>
Pour que tous les utilisateurs valides (qui sont présent dans le .htpasswd) aient accès au dossier :
<pre>
AuthUserFile /path/to/.htpasswd
AuthName "Accès Restreint"
AuthType Basic
require valid-user
</pre>
Accès pour l'utilisateur pfoo et l'ensemble du groupe user uniquement :
<pre>
AuthUserFile /path/to/.htpasswd
AuthGroupFile /path/to/.htgroup
AuthName "Accès Restreint"
AuthType Basic
require user pfoo
require group user
</pre>
==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 (<small>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)</small>
* 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)
<br>
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.
<pre>htdigest -c .htpasswd "votre realm" username</pre>
Pour ajouter un nouvel utilisateur, ou modifier le mot-de-passe d'un utilisateur existant, la commande est la même sans l'argument <code>-c</code> :
<pre>htdigest .htpasswd "votre realm" pfoo</pre>
Le fichier <code>.htgroup</code> 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) :
<pre>admin: pfoo plop
user: blah</pre>
Pour que tous les utilisateurs valides (qui sont présent dans le .htpasswd) aient accès au dossier :
<pre>
AuthType Digest
AuthName "votre realm"
AuthDigestDomain /
AuthDigestProvider file
AuthUserFile /path/to/.htpasswd
AuthGroupFile /path/to/.htgroup
Require valid-user
</pre>
Accès pour l'utilisateur pfoo et l'ensemble du groupe user uniquement :
<pre>
AuthType Digest
AuthName "votre realm"
AuthDigestDomain /
AuthDigestProvider file
AuthUserFile /path/to/.htpasswd
AuthGroupFile /path/to/.htgroup
require user pfoo
require group user
</pre>
=HTTPS=
==Redirection HTTP vers HTTPs==
* Solution avec le module Rewrite, applicable à la fois dans une vhost écoutant sur les port 80 ou 443 :
<pre>
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R=301,L]
</pre>
Il peut être intéressant de ne pas rewrite certaine URLs. Dans l'exemple ci dessous, les urls en lien avec les challenges letsencrypt :
<pre>
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
</pre>
* Solution avec le module Alias, à ne surtout pas appliquer dans une vhost écoutant sur le port 443 (redirection infinie) :
<pre>
Redirect permanent / https://domain.tld/
</pre>
=Tests de sécurité divers=
https://observatory.mozilla.org/ <br>
https://tls.imirhil.fr/ <br>
https://www.ssllabs.com/ssltest/
4 203

modifications

Menu de navigation