Installation et configuration d'un serveur http apache 2.2

De Linux Server Wiki
Aller à la navigation Aller à la recherche


Tutos plus vraiment à jour

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 et group 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: Apache
    • ServerTokens Major : Le serveur renvoi : Server: Apache/2
    • ServerTokens Minor : Le serveur renvoie : Server: Apache/2.2
    • ServerTokens Min : Le serveur renvoi : Server: Apache/2.2.41
    • ServerTokens 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 est LogFormat 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é par TypesConfig
  • 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                        = 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.

Récupérée de « https://wiki.unscdf.org/index.php?title=Installation_et_configuration_d%27un_serveur_http_apache_2.2&oldid=1882 »