Installation et configuration d'un serveur http apache 2.2
Tuto plus vraiment à jour
Nouveau wiki à jour (mais incomplet pour le moment)
Ce howto va vous montrer comment mettre en place un serveur web apache2 gérant les domaines virtuels et l'ipv6 sous debian squeeze.
Nous allons mettre en place trois sites : srv.domain.tld
, www.domain.tld
et webmail.domain.tld
.
srv.domain.tld
sera le site par défaut sur lequel tombera toute personne effectuant une requête http ne désignant aucun autre domaine virtuel.
www.domain.tld
et webmail.domain.tld
sont ce qu'on peut appeler des domaines virtuels : ils sont sur la même ip que srv.domain.tld
mais servent des domaines différents. Ces deux domaines disposeront d'un chiffrement ssl/tls actif.
Au niveau dns, srv.domain.tld
est le domaine identifiant la machine. Il possède l'adresse ipv4 213.186.47.110
et l'adresse ipv6 2001:41d0:1:d6e::110
.
www.domain.tld
et webmail.domain.tld
sont des alias pour srv.domain.tld
.
Les changements de permissions effectués dans ce howto supposent que vous êtes en umask 0027
Champs dns
La première étape est de mettre en place les champs dns pour les différents domaines qu'on va gérer. Éditez la zone dns de votre domaine (/srv/http/domain.tld.host
dans mon cas) et ajoutez ou modifiez les lignes suivantes :
domain.tld. IN A 213.186.47.110 domain.tld. IN AAAA 2001:41d0:1:d6e::110 srv.domain.tld. IN A 213.186.47.110 srv.domain.tld. IN AAAA 2001:41d0:1:d6e::110 www IN CNAME srv.domain.tld. webmail IN CNAME srv.domain.tld
Si vous ne disposez pas d'ipv6, vous n'avez pas besoin des champs AAAA
.
Installation de apache2
Utilisez aptitude pour installer apache2:
aptitude install apache2
Créez les dossier qui contiendront les vhosts et la configuration des sites :
mkdir /etc/apache2/vhosts mkdir /etc/apache2/sites
Créez le dossier /srv/http/
qui contiendra les sites internet :
mkdir /srv/http/ chown root:www-data /srv/http/
Configuration de apache2
Exemple de fichier de configuration
Voici un exemple de fichier apache2.conf. Nous verrons ensuite plus en détail les différentes directives de configuration utilisées.
ServerRoot /etc/apache2 Listen 213.186.47.110:80 Listen 213.186.47.110:443 Listen 127.0.0.1:80 Listen [::1]:80 Listen [2001:41d0:1:d6e::110]:80 Listen [2001:41d0:1:d6e::110]:443 User www-data Group www-data PidFile /var/run/apache2.pid ServerAdmin root@domain.tld ServerName www.domain.tld HostnameLookups Off ServerTokens Prod NameVirtualHost 213.186.47.110:80 NameVirtualHost 213.186.47.110:443 NameVirtualHost [2001:41d0:1:d6e::110]:80 NameVirtualHost [2001:41d0:1:d6e::110]:443 #NameVirtualHost 127.0.0.1:80 AcceptPathInfo On KeepAlive On KeepAliveTimeout 5 MaxKeepAliveRequests 100 <IfModule mpm_prefork_module> StartServers 2 MinSpareServers 2 MaxSpareServers 5 MaxClients 40 MaxRequestsPerChild 400 </IfModule> #<IfModule mpm_worker_module> # StartServers 3 # MaxClients 80 # MinSpareThreads 3 # MaxSpareThreads 6 # ThreadsPerChild 0 # MaxRequestsPerChild 200 #</IfModule> Include /etc/apache2/mods-enabled/*.load Include /etc/apache2/mods-enabled/*.conf # PHPIniDir /etc/php5/apache2 AddHandler cgi-script .cgi .pl DefaultLanguage fr AddDefaultCharset UTF-8 DocumentRoot /srv/http/default/ #Sécurisation de php pour tous les vhosts/autres qui n'en ont pas de configuré php_admin_value open_basedir /srv/http/default/ <Directory /> Options Indexes FollowSymLinks AllowOverride All Order allow,deny Allow From All IndexIgnore .ht* IndexIgnore .svn </Directory> AccessFileName .htaccess <FilesMatch "^\.ht"> Order allow,deny Deny From All Satisfy All </FilesMatch> <DirectoryMatch "\.svn"> Deny from all </DirectoryMatch> DirectoryIndex index.html index.htm index.php ErrorLog /var/log/apache2/error.log LogFormat "[%{%a %b %d %T %G}t] [access] %h %v %H %l %u \"%r\" %>s %b bytes = %D ms (%T s)" common CustomLog /var/log/apache2/access.log common TypesConfig /etc/mime.types DefaultType text/plain ################################################################# # Index # ################################################################# IndexOptions FancyIndexing VersionSort <Directory "/usr/share/apache2/icons"> Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all </Directory> <Location /server-status> SetHandler server-status Order Deny,Allow Deny from all Allow from 127.0.0.1 Allow from ::1 Allow from 213.186.47.110 Allow from 2001:41d0:1:d6e::110 </Location> ExtendedStatus On ############################# # VHOSTS # ############################# Include vhosts/srv.domain.tld.conf.default Include vhosts/domain.tld.conf.default Include vhosts/*.conf
Explication sur les options utilisés dans le fichier de configuration
ServerRoot
défini le dossier principal de apache2. C'est dans ce répertoire que les configurations de apache2 sont stockés.User
etgroup
définissent l'utilisateur et le groupe sous lequel apache2 doit être lancé. Ces deux éléments (www-data dans les deux cas) ont normalement été créé automatiquement par aptitude.PidFile
défini l'endroit où le fichier pid de apache2 doit être stocké.Listen
défini les différentes ips et ports sur lesquels apache2 écoute.NameVirtualHost
défini les ips et les ports qui pourront être utilisés par la suite en tant que virtualhost (pour les domaines virtuels).ServerAdmin
défini le nom de la personne (en général une adresse email) que le serveur proposera de contacter en cas de problème lors de l'affichage d'une page ou d'un bug de configuration interne.ServerName
défini le nom du serveur.HostnameLookups
défini s'il faut résoudre l'ip des clients se connectant au serveur dans le but de loguer leur hostname dans les fichiers de logs. Il est préférable de désactiver cette option car apache2 ne servira pas la requête tant que la résolution n'aura pas eu lieu.ServerTokens
défini comment apache2 doit s'identifier auprès des clients.ServerTokens Prod
: Le serveur renvoi : Server: ApacheServerTokens Major
: Le serveur renvoi : Server: Apache/2ServerTokens Minor
: Le serveur renvoie : Server: Apache/2.2ServerTokens Min
: Le serveur renvoi : Server: Apache/2.2.41ServerTokens OS
: Le serveur renvoie : Server: Apache/2.2.41 (Unix)ServerTokens Full
(valeur par défaut) : Le serveur renvoi : Server: Apache/2.2.41 (Unix) PHP/4.2.2 MyMod/1.2
KeepAlive
défini si apache2 doit autoriser les connexions tcp persistantes (plusieurs requêtes http pourront être envoyées lors de la même connexion tcp).KeepAliveTimeout
défini le nombre de secondes que doit attendre apache2 avant de fermer une connexion tcp.MaxKeepAliveRequests
défini le nombre de requêtes maximum que apache2 servira lors de la même connexion tcp. Il est recommandé de laisser cette valeur relativement élevée.ErrorLog
défini le fichier où les logs d'erreur de apache seront stockés.LogFormat
permet de formater les logs customs du serveur. La documentation officielle de apache détaille le formatage possible. La syntaxe estLogFormat Format Type
CustomLog
permet de spécifier un fichier de log pour chaque type de log custom.AddDefaultCharset
permet de spécifier le charset par défaut à utiliser.AddHandler cgi-script
permet de préciser que les fichiers .cgi et .pl sont des scripts cgi.DocumentRoot
défini le répertoire où sont stockés les pages webs par défaut du serveur.DirectoryIndex
défini les fichiers qui seront considérés comme des pages d'index.TypesConfig
défini le fichier spécifiant la correspondance entre les extensions et les types de fichiers.DefaultType
défini le type par défaut d'un fichier si son extension n'est pas spécifié parTypesConfig
AccessFileName
défini le nom du fichier de configuration distribué (un tel fichier sera lu par apache dans tous dossiers auquel apache a accès)
La directive Directory
permet d'appliquer des directives qui ne s'appliqueront que pour un dossier donné (et tout ses sous dossiers et fichiers). Dans l'exemple suivant, on applique des règles pour l'ensemble du système de fichier (/) :
<Directory /> Options Indexes FollowSymLinks AllowOverride All Order allow,deny Allow From All IndexIgnore .ht* </Directory>
IndexIgnore
spécifie qu'il ne faut pas lister les fichiers débutants par .ht
. Ces fichiers sont généralement des fichiers de configurations locaux aux sites webs.
Les lignes suivantes permettent de charger automatiquement tous les modules que vous avez activé pour apache au moyen de la commande a2enmod
:
Include /etc/apache2/mods-enabled/*.load Include /etc/apache2/mods-enabled/*.conf
La directive FilesMatch "patern"
permet de spécifier des directives s'appliquant à tout fichier correspondant à l'expression rationnelle spécifiée.
Les options suivantes s'appliquant aux fichiers de sécurités et de configuration locaux des sites :
<FilesMatch "^\.ht"> Order allow,deny Deny From All Satisfy All </FilesMatch>
Les directives suivantes activent le module status de apache2 qui permet de suivre la consommation et les performances du serveur apache2 :
<Location /server-status> SetHandler server-status Order Deny,Allow Deny from all Allow from 127.0.0.1 Allow from ::1 Allow from 213.186.47.110 Allow from 2001:41d0:1:d6e::110 </Location> ExtendedStatus On
Et enfin, la ligne suivante permet de loader tous les fichiers .conf situés dans /etc/apache2/vhosts/
. C'est dans ce dossier qu'on stockera les vhosts des sites.
Include vhosts/*.conf
Mise en place d'un site
Ajoutez la ligne suivante avant la directive Include vhosts/*.conf
dans le fichier /etc/apache2/apache2.conf
. Il est nécessaire de la placer avant afin d'avoir une sorte de "catch all" récupérant toutes les requêtes ne correspondant à aucune vhost.
Include vhosts/srv.domain.tld.conf.default
Créez le fichier /etc/apache2/vhosts/srv.domain.tld.conf.default
et ajoutez y les lignes suivantes :
<VirtualHost 213.186.47.110:80> ServerName srv.domain.tld Include sites/srv.domain.tld.conf </VirtualHost> <VirtualHost [2001:41d0:1:d6e::110]:80> ServerName srv.domain.tld Include sites/srv.domain.tld.conf </VirtualHost>
Étant donné que nous n'avons pas précisé le port à la directive servername
du fichier /etc/apache/apache2.conf
, il est nécessaire de préciser le port pour chaque déclaration virtualhost
.
La configuration de cette vhost est défini pour être dans /etc/apache2/sites/srv.domain.tld.conf
. Créez ce fichier et ajoutez-y les lignes suivantes :
DocumentRoot /srv/http/default/
Les requêtes pour cette vhost correspondront donc aux pages webs situés dans /srv/http/default/
. Bien sur, ce dossier doit exister et être accessible par apache2. Si ce n'est pas le cas :
mkdir -p /srv/http/default chown root:www-data /srv/http/default
Pour valider les modifications il faut reloader apache2:
/etc/init.d/apache2 reload
Mise en place d'un site sécurisé en ssl
Attention, cette rubrique n'est pas à jour le module ssl de Apache supporte désormais SNI (http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI) ce qui permet d'utiliser plusieurs certificats ssl sur une seule et même ip.
Il faudra dans ce cas préciser le certificat ssl à utiliser dans chaque vhost où ssl est activé. Le premier certificat ssl chargé sera utilisé en tant que fallback si le client ne supporte pas SNI.
Nous allons maintenant mettre en place les deux sites sécurisés en ssl : www.domain.tld
et webmail.domain.tld
.
Étant donné qu'on ne dispose que d'une seule adresse ipv4 on ne va pouvoir utiliser qu'un seul certificat ssl. C'est une limitation obligatoire du protocole https car la connexion sécurisée est établie avant l'envoi du header spécifiant quel site apache2 doit afficher (et donc quel certificat ssl utiliser).
Il est cependant possible de sécuriser plusieurs sites différents avec le même certificat ssl en utilisant la directive subjectAltName
lors de la génération du certificat. Cela règlera les problèmes d'alertes sur tous les navigateur conforme à la RFC 2818 ("HTTP Over TLS").
A titre d'information il est possible de contourner ce problème avec le module gnutls : http://www.gcu.info/2399/2007/09/03/george-met-ssl-a-gnou/ http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/
Génération du certificat ssl
Nous allons supposer que vous avez créé votre propre autorité de certification. Vous pouvez suivre mon howto sur openssl si vous ne disposez pas d'autorité de certification.
Éditez votre fichier /etc/ssl/openssl.cnf
et ajoutez les lignes suivantes :
[APACHE] nsComment = "SRV Apache Server" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always issuerAltName = issuer:copy subjectAltName = DNS:www.domain.tld, DNS:webmail.domain.tld basicConstraints = critical,CA:FALSE keyUsage = critical,digitalSignature, nonRepudiation, keyEncipherment nsCertType = server extendedKeyUsage = serverAuth
Nous allons maintenant générer les clés publics et privés de notre certificat. Si vous connaissez un peu openssl vous devez savoir qu'il est possible de verrouiller les clés avec une passphrase. Apache2 supporte ce mécanisme mais cela empêchera apache2 de se lancer tout seul lors d'un redémarrage. A vous de choisir entre sécurité et disponibilité. Pour générer votre certificat ssl chiffré avec une passphrase puis le signer par votre autorité :
cd /etc/ssl/core_ca openssl req -config /etc/ssl/openssl.cnf -newkey rsa:2048 -keyout www.domain.tld.key -out www.domain.tld.req openssl ca -config /etc/ssl/openssl.cnf -name core_ca -extensions APACHE -in www.domain.tld.req -out www.domain.tld.pem chmod -R 600 /etc/ssl/core_ca/
Si vous ne souhaitez pas chiffrer le certificat avec une passphrase ajoutez l'argument -nodes
à la première ligne.
Répondez aux différentes questions posées par openssl. La plupart sont assez triviales. Attention toutefois : Common Name
doit être l'adresse principale de votre site (www.domain.tld
dans mon cas).
Il est préférable de déplacer le certificat dans le dossier root de apache2:
mkdir /etc/apache2/ssl/ mv www.domain.tld.* /etc/apache2/ssl/ chown -R root:root /etc/apache2/ssl/ chmod -R 600 /etc/apache2/ssl/
Enfin, nous allons créer un fichier contenant la chaine de certification (de préférence en partant de la CA la plus proche de certificat serveur en remontant vers la root) :
cat /etc/ssl/core_ca/core_ca.pem /etc/ssl/root_ca/root_ca.pem > /etc/apache2/ssl/ca_chain.pem
Apache enverra ce fichier aux clients souhaitant se connecter en https. Ainsi, même si le navigateur du client n'a que le certificat root_ca.pem dans sa liste de confiance, le certificat établit pour apache sera validé car le client recevra tous les certificats de la chaine (root_ca.pem > core_ca.pem > www.domain.tld.pem) : le client sera certain que la chaine est complètement valide.
Mise en place des sites
Activez le module ssl de apache2:
a2enmod ssl
Ajoutez la ligne suivante dans /etc/apache2/apache2.conf
après
Include vhosts/srv.domain.tld.conf.default
mais avant Include vhosts/*.conf
:
Include vhosts/domain.tld.conf.default
Cette ligne doit a tout prix être placé à cet endroit. C'est la vhost ssl par défaut dans laquelle on charge le certificat ssl. Si elle est placée après le Include
chargeant les autres vhosts, si l'une de ces vhosts est configuré en ssl, apache2 ne démarrera pas.
Créez le fichier /etc/apache2/vhosts/domain.tld.conf.default
et ajoutez y ceci :
#Certificat SSL
#SSLCACertificateFile
SSLCertificateChainFile /etc/apache2/ssl/ca_chain.pem
SSLCertificateFile /etc/apache2/ssl/www.domain.tld.pem
SSLCertificateKeyFile "/etc/apache2/ssl/www.domain.tld.key"
<VirtualHost 213.186.47.110:80>
ServerName www.domain.tld
ServerAlias domain.tld
Include sites/domain.tld.conf
</VirtualHost>
<VirtualHost [2001:41d0:1:d6e::110]:80>
ServerName www.domain.tld
ServerAlias domain.tld
Include sites/domain.tld.conf
</VirtualHost>
<VirtualHost 213.186.47.110:443>
SSLEngine on
SSLProtocol All -SSLv2 -SSLv3
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"
ServerName www.domain.tld
ServerAlias domain.tld
Include sites/domain.tld.conf
</VirtualHost>
<VirtualHost [2001:41d0:1:d6e::110]:443>
SSLEngine on
SSLProtocol All -SSLv2 -SSLv3
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"
ServerName www.domain.tld
ServerAlias domain.tld
Include sites/domain.tld.conf
</VirtualHost>
Notez que les directives SSLCertificate*
ne sont situés en dehors des bloques VirtualHost
du port 443 uniquement parce que nous allons utiliser le même certificat pour plusieurs sites sur la même ip.
Si vous disposez de plusieurs adresses IPs, vous devrez indiquer le certificat ssl correspondant dans chaque bloque VirtualHost
correspondant (donc deux fois pour chaque site si vous utilisez IPv4 et IPv6).
La directive ServerAlias
défini domain.tld comme un alias pour www.domain.tld
Créez ensuite /etc/apache2/sites/domain.tld.conf
et ajoutez y les lignes suivantes:
DocumentRoot /srv/http/domain.tld/domain.tld/
ServerAdmin admin@domain.tld
Bien sur il faut que /srv/http/domain.tld/domain.tld/
existe et soit accessible par apache2:
mkdir -p /srv/http/domain.tld/domain.tld/
chown -R root:www-data /srv/http/domain.tld/
Pour que l'ajout soit pris en compte il faut reloader apache2:
/etc/init.d/apache2 reload
Si vous avez chiffré votre clé avec une passphrase il est important de modifier votre script logrotate car par défaut, il lance un restart de apache qui ne pourra pas se relancer tout seul du fait de la passphrase. Éditez le fichier /etc/logrotate.d/apache2
et modifiez la ligne /etc/init.d/apache restart
en /etc/init.d/apache reload
Pour le site webmail.domain.tld
créez le fichier /etc/apache2/vhosts/webmail.domain.tld.conf
et ajoutez y les lignes suivantes :
<VirtualHost 213.186.47.110:443>
SSLEngine on
SSLProtocol All -SSLv2 -SSLv3
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"
ServerName webmail.domain.tld
Include sites/webmail.domain.tld.conf
</VirtualHost>
<VirtualHost 213.186.47.110:80>
ServerName webmail.domain.tld
Include sites/webmail.domain.tld.conf
</VirtualHost>
<VirtualHost [2001:41d0:1:d6e::110]:80>
ServerName webmail.domain.tld
Include sites/webmail.domain.tld.conf
</VirtualHost>
<VirtualHost [2001:41d0:1:d6e::110]:443>
SSLEngine on
SSLProtocol All -SSLv2 -SSLv3
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"
ServerName webmail.domain.tld
Include sites/webmail.domain.tld.conf
</VirtualHost>
Créez ensuite le fichier /etc/apache2/sites/webmail.domain.tld.conf
et ajoutez y les lignes suivantes :
DocumentRoot /srv/http/domain.tld/webmail.domain.tld/
ServerAdmin admin@domain.tld
Comme précédemment, /srv/http/domain.tld/webmail.domain.tld/
doit exister et être accessible par apache2.
Installer le module php
Installez juste le paquet libapache2-mod-php5 avec aptitude :
aptitude install libapache2-mod-php5
a2enmod php5
Sécuriser php
C'est probablement ce dont rêve un administrateur linux chaque nuit. Un vilain petit pirate insomniaque découvre une faille dans un script php d'un des sites hébergé sur le serveur. Grâce à cette faille, le pirate pourrait avoir accès à tous les fichiers auxquels apache a accès.
Heureusement, plusieurs méthodes permettent de parquer php dans un dossier précis et l'empêcher d'accéder aux fichiers des autres sites :
- SUPHP
- SUEXEC
- Open_basedir
Open_basedir
Cette méthode est la plus simple et la plus rapide à mettre en place.
La méthode Open_basedir fonctionne par rapport aux dossiers, et non pas par rapport aux utilisateurs comme le font SuPHP ou SuExec.
L'idée est très simple : si quelqu'un tente d'ouvrir un fichier, php vérifie si ce fichier se situe dans la zone autorisée. Si ce n'est pas le cas, l'ouverture est refusée.
Il suffit d'ajouter la ligne suivante dans les fichiers de configuration des vhosts (situés dans /etc/apache2/sites/ si vous avez suivis ce howto) :
php_admin_value open_basedir PATH1:PATH2
Comme vous le voyez, on peut spécifier plusieurs chemins pour les zones autorisées en les séparant par des "deux points" (:).
Il faut entrer des chemins absolus et toujours terminer les chemins par le / final, sinon apache va interpréter le chemin comme étant path*. Par exemple /srv/http/pof correspondra a /srv/http/pof, mais aussi à /srv/http/pofpof alors que /srv/http/pof/ ne correspondra que au dossier /srv/http/pof/
Généralement, entrer le DocumentRoot
comme path est largement suffisant. Voici l'exemple pour la vhost www.domain.tld (/etc/apache2/sites/domain.tld.conf:
php_admin_value open_basedir /srv/http/domain.tld/domain.tld/
Et voila, maintenant, lorsque notre méchant pirate viendra s'attaquer à notre petit script php bugué, il ne pourra qu'accéder aux fichiers du vhost correspondant. Les autres sites hébergés sur d'autres vhosts resteront en sécurité.
Afin de prévenir un oubli d'ajout de la directive php_admin_value open_basedir
sur une vhost il est bon de spécifier un open_basedir par défaut dans le fichier /etc/apache2/apache2.conf
:
php_admin_value open_basedir /srv/http/default/
Toutes les vhosts ne disposant pas leur propre directive php_admin_value open_basedir
seront donc parquées dans /srv/http/default/
Si vous utilisez le mod-userdir
il peut être intéressant d'ajouter la directive php_admin_value open_basedir
dans la configuration du module. Voici la mienne :
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root
<Directory /home/*/public_html>
php_admin_value open_basedir ./
AllowOverride FileInfo AuthConfig Limit Indexes
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
</IfModule>
Pour plus d'information : http://wiki.apache.org/httpd/SecuringPHP
SuExec
aptitude install apache2-suexec
a2enmod suexec
/etc/init.d/apache2 restart
<VirtualHost *:80>
DocumentRoot /home/user/www
ServerName domain.tld
SuExecUserGroup user group
Les scripts a executer devront être dans /var/www (sinon utilisez apache2-suexec-custom)
SuPHP
SuPHP est un module apache permettant d'exécuter les scripts php avec les permissions de leur propriétaire.
Nous allons voir comment coupler le mod_php5
traditionnel de apache2 avec SuPHP
. En fait, SuPHP sera utilisé pour les comptes utilisateurs (dans /home) tandis que mod_php5 sera utilisé pour les sites n'étant pas rattachés à un utilisateur (dans /srv/http/)
Commencez par installer suphp :
aptitude install libapache2-mod-suphp suphp-common
Comme vous pouvez le voir, php5-cgi sera automatiquement installé. Activez SuPHP :
a2enmod suphp
Le fichier de configuration SuPHP de apache 2 est /etc/apache2/mods-enabled/suphp.conf
.
Le fichier de configuration de SuPHP est /etc/suphp/suphp.conf
. Dans ce dernier fichier, adaptez la ligne docroot=
afin qu'elle pointe sur le répertoire contenant le DocumentRoot
de toutes les vhosts qui utiliseront SuPHP. Depuis debian squeeze, il est possible de spécifier un docroot correspondant au home respectif de chaque utilisateurs :
docroot=${HOME}/
Notez que depuis debian squeeze, il est possible d'indiquer plusieurs docroot en les séparant par deux-points (:).
Vous pouvez aussi y modifier l'umask (cela défini avec quels permissions les fichiers seront créés) en 0027.
Modifiez le fichier /etc/apache2/mods-enabled/php5.conf
comme suit afin de n'activer le module php que dans /srv/http/
:
<IfModule mod_php5.c>
#Désactivé car casse la compatibilité avec suphp (petit bug de debian ;))
# <FilesMatch "\.ph(p3?|tml)$">
# SetHandler application/x-httpd-php
# </FilesMatch>
# <FilesMatch "\.phps$">
# SetHandler application/x-httpd-php-source
# </FilesMatch>
#Fix 1 pour réactiver php, mais ne fonctionne plus pour phpsysinfo
# AddType application/x-httpd-php .php .phtml .php3
# AddType application/x-httpd-php-source .phps
php_flag engine off
#fix fonctionnant avec phpsysinfo
<Directory /usr/share>
<FilesMatch "\.ph(p3?|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch "\.phps$">
SetHandler application/x-httpd-php-source
</FilesMatch>
</Directory>
<Directory /srv/http>
php_flag engine on
</Directory>
</IfModule>
mod_php5
étant prioritaire sur suPHP
ces quelques lignes permettent de désactiver mod_php5
partout sauf dans /srv/http/.
Dans la même idée, vous pouvez limiter SuPHP à /home en modifiant /etc/apache2/mods-enabled/suphp.conf
comme suit :
<IfModule mod_suphp.c>
AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-php
<Directory /home>
suPHP_Engine on
</Directory>
# By default, disable suPHP for debian packaged web applications as files
# are owned by root and cannot be executed by suPHP because of min_uid.
<Directory /usr/share>
suPHP_Engine off
</Directory>
#suPHP_ConfigPath /home/*/php.ini
</IfModule>
Si vous utilisez des utilitaires d'administration web comme PhpMyAdmin
n'oubliez pas d'activer mod_php5
dans le répertoire correspondant. Par exemple, pour PhpMyAdmin
, il faudra ajouter les lignes suivantes au fichier /etc/apache2/mods-enabled/php5.conf
:
<Directory /usr/share/phpmyadmin>
php_flag engine on
</Directory>
SuPHP ne permet pas l'utilisation de php_admin_value
et il est donc impossible de définir open_basedir de cette manière pour les vhosts de /home. Pourtant, il peut-être pratique de limiter les fichiers accessibles en php (même si théoriquement, le principe de suPHP est largement suffisant).
Pour contourner ce problème, il faut définir un fichier de configuration php propre pour chaque vhost utilisant SuPHP. Il suffit d'ajouter dans le fichier de configuration de la vhost la directive suPHP_ConfigPath
suivie du répertoire dans lequel le fichier php.ini
personnalisé est présent.
Par exemple, si le fichier de configuration de la vhost blah.domain.tld
ayant comme documentroot /home/blah/www/
est /home/blah/php.ini
il faut ajouter la directive suPHP_ConfigPath /home/blah
(sans le / final !) dans le fichier de configuration de la vhost.
Ce php.ini personnalisé peut être une copie conforme de /etc/php5/cgi/php.ini
mais dans lequel vous pouvez définir open_basedir = /home/blah/www/
par exemple. Si vous ne voulez pas que les utilisateurs puissent modifier leurs directives php, placez le fichier php.ini personnalisé dans un dossier auquel ils n'ont pas accès (n'oubliez pas que l'utilisateur www-data doit toujours pouvoir lire ce fichier).
Vous pouvez aussi spécifier un open_basedir par défaut dans le fichier /etc/php5/cgi/php.ini
qui sera appliqué pour toutes les vhosts n'ayant pas de php.ini personnalisé.
Si vous voulez vérifier que tout fonctionne bien, créez une vhost ayant son documentroot quelque part dans /srv/http/ et une autre ayant son documentroot quelque part dans /home/, puis appelez la directive phpinfo()
avec un fichier .php dans ce genre :
<?php
phpinfo();
?>
Notez que si vous utilisez mod_userdir
il sera impossible d'exécuter les scripts php à l'aide de suphp à cause de la directive check_vhost_docroot=true
de SuPHP. Vous pouvez ajouter la directive suPHP_Engine off
dans le fichier de configuration de mod_userdir
:
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root
<Directory /home/*/public_html>
php_admin_value open_basedir ./
suPHP_Engine off
AllowOverride FileInfo AuthConfig Limit Indexes
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
</IfModule>
Si vous avez vraiment besoin de php avec mod_userdir, il faudra soit y activer le module php5, soit le module suphp en désactivant la vérification du docroot de suphp.
N'oubliez pas de relancer apache2 après tout cela :
/etc/init.d/apache2 restart
suhosin
Depuis debian wheezy, les fonctionnalités de suhosin ont été mergées directement dans le coeur de php, le packet n'est par conséquent plus disponible.
Sous debian squeeze, les modules php de apache (que ce soit mod_php5 ou mod_suphp) sont fournis par défaut avec le module de sécurité suhosin activé. Dans la majorité des cas, vous ne devriez pas en ressentir la présence. Si vous remarquez cependant des comportements anormaux (variable php perdus, ...), jetez un œil au fichier /etc/php5/conf.d/suhosin.ini
qui contient la configuration par défaut de suhosin. Vous y trouverez peut-être votre bonheur.
Dans le cadre de l'utilisation de suphp et si vous devez modifier des variables de suhosin, je vous recommande vivement de ne pas les modifier directement dans /etc/php5/conf.d/suhosin.ini
, mais de copier les directives qui vous intéressent dans le fichier de configuration php personnalisé de la vhost qui pose problème.
Lancer les virtualhost selon un uid spécifique
Attention cette méthode n'est pas compatible avec suphp ! Il vous faudrautiliser le module php5 classique.
aptitude install apache2-mpm-itk
Puis dans chaque virtualhost :
AssignUserId user group
Dans le cas présent, vous n'aurez plus besoin d'ajouter les utilisateurs au groupe www-data
Il n'est cependant pas possible de définir un fichier de configuration php par vhost (y compris avec phpinidir). Vous devrez donc passer par php_admin_value.
Contrôle d'accès via .htaccess, .htpasswd et .htgroup
Authentification Basic
C'est le monde d'authentification le plus fréquemment utilisé. Dans ce mode, le login et le mot-de-passe transitent en clair sur le réseau.
Nous allons voir comment sécuriser le dossier /srv/http/admin.domain.tld/
qui correspond à la vhost http://admin.domain.tld/
.
L'outil htpasswd
permet de créer le fichier contenant les mot-de-passes.
Nous allons commencer par créer le fichier avec un utilisateur par défaut nommé pfoo :
$ htpasswd -cs /srv/http/admin.domain.tld/.htpasswd pfoo
Adding password for pfoo
New password:
Re-type new password:
Une fois le fichier créé, vous pouvez ajouter des utilisateurs ou modifier des utilisateurs existant avec la même commande mais sans l'option -c :
$ htpasswd -s /srv/http/admin.domain.tld/.htpasswd plop
Adding user plop
New password:
Re-type new password:
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
Il faut ensuite créer le fichier /srv/http/admin.domain.tld/.htaccess
.
- Pour que tous les utilisateurs valides (qui sont présent dans le
.htpasswd
) aient accès au dossier :
AuthUserFile /srv/http/admin.domain.tld/.htpasswd
AuthGroupFile /dev/null
AuthName "Accès Restreint"
AuthType Basic
require valid-user
- Accès pour l'utilisateur pfoo uniquement :
AuthUserFile /srv/http/admin.domain.tld/.htpasswd
AuthGroupFile /dev/null
AuthName "Accès Restreint"
AuthType Basic
require user pfoo
- Accès au groupe admin et uniquement pour les GET et POST :
AuthUserFile /srv/http/admin.domain.tld/.htpasswd
AuthGroupFile /srv/http/admin.domain.tld/.htgroup
AuthName "Accès Restreint"
AuthType Basic
<Limit GET POST>
require group admin
</Limit>
Authentification sécurisée (Digest)
Lors d'une authentification classique, les données circulent en clair.
Pour palier à ce problème de sécurité il existe l'authentification digest. Ce type d'authentification utilise l'algorithme de hash md5 ce qui rend impossible de remonter aux informations de départ (à savoir, le login et le mot-de-passe). Afin d'éviter qu'un pirate puisse réutiliser le login/password hashé, un "nonce" est transmit par le serveur puis ajouté par le client au hashé lors de la réponse ce qui rend ainsi le hashé unique.
Pour utiliser cette fonction, les modules auth_digest
et authn_file
de apache doivent être activés :
a2enmod authn_file auth_digest
L'outil htdigest
permet de créer un fichier .htpasswd
utilisant cette méthode d'authentification.
Pour créer un tel fichier :
htdigest -c /srv/http/admin.domain.tld/.htpasswd realm username
Comme avant, si le fichier existe déjà, supprimez l'argument -c
En ce qui concerne le fichier .htaccess
:
AuthType Digest
AuthName realm
AuthDigestDomain /
AuthDigestProvider file
AuthUserFile /srv/http/admin.domain.tld/.htpasswd
AuthGroupFile /srv/http/admin.domain.tld/.htgroup
Require valid-user
Comme vous pouvez le voir, AuthName
doit correspondre au realm
fourni avec htdigest
.
Monitorer apache avec apachetop
apachetop
permet d'analyser facilement les requêtes servies par votre serveur apache en analysant les fichiers de log.
aptitude install apachetop
Par défaut, apachetop
utilise les données de /var/log/apache/access.log
. Vous pouvez spécifier un autre fichier de log avec l'option -f
.