wiki:GnuLinuxAdminApache

Ce chapitre fait partie du cours d'aministration de GNU/Linux.

Debian GNU/Linux - Configuration d'Apache (+PHP)

Note: consultez également la Cf. configuration d'Apache dans Debian.

1. Virtual hosting

En général, une seule instance d'Apache sur un serveur va pouvoir répondre pour différents "sites webs" ou "domaines". La plupart des distributions sont livrées avec une configuration utilisant par défaut ce qu'on appelle le virtual hosting. La méthode de loin la plus utilisée est appelée le name-based virtual hosting, que l'on active avec cette directive:

NameVirtualHost *

Par la suite, nous allons distinguer si nos directives sont spécifiques à un virtual host (cad. si elles sont imbriquées dans des balises <VirtualHost>) ou globales. Cette information est appelée le contexte et doit être prise soigneusement en considération dans la documentation des directives Apache (2.0).

Une fois ce modèle activé, nous allons pouvoir déclarer chacun de nos "sites webs" à héberger à l'aide de ces 4 lignes (strictement nécessaires):

<VirtualHost *>
    ServerName www.mycompany.com
    DocumentRoot /var/www/mycompany.com
</VirtualHost>

La directive ServerName spécifie le nom de domaine pour lequelle ce virtual host va répondre. Ainsi seules les requêtes HTTP dont l'adresse commence par http://www.mycompany.com/... seront prises en compte par cette configuration.

La directive DocumentRoot indique où se trouve les documents servis par Apache, plus exactement la racine du site tel que vu par les utilisateurs. Le fichier /var/www/mycompany.com/bonjour.html sera donc disponible à l'adresse http://www.mycompany.com/bonjour.html.

site.com et www.site.com

La plupart des navigateurs vont essayer les orthographes "site.com" et "www.site.com" lorsque vous tapez une adresse, mais certains échouent, ou d'autres plus stupides rajoutent systématiquement le préfixe "www.". Afin que votre site soit universellement accessible, pensez à définir des entrées A et/ou CNAME pour chacun de ces noms qualifiés. Par exemple, ici zerodeux.net est un CNAME vers www.zerodeux.net:

# host zerodeux.net
zerodeux.net is an alias for www.zerodeux.net.
www.zerodeux.net has address 213.186.37.123

Au niveau d'Apache évitez la facilité qui consiste à faire correspondre les deux noms au même virtual host, cad:

<VirtualHost *>
    ServerName www.mycompany.com
    ServerAlias mycompany.com
    ...
</VirtualHost>

Ceci pose souvent problème, car les utilisateurs accèderont à votre site via deux domaines distincts, et de nombreuses applications webs vont mal gérer ce cas. En particulier, les cookies sont la plupart du temps attachés à un domaine précis et non pas l'ensemble des sous-domaines du site: ceci créée un effet de "sessions fantômes" lorsque l'utilisateur se connecte alternativement avec un nom de domaine ou l'autre.

Une bonne solution au problème consiste à déclarer un virtual host minimaliste pour ramener l'utilisateur sur le nom de domaine voulu:

<VirtualHost *>
    ServerName mycompany.com
    RedirectMatch (.*) http://www.mycompany.com$1
</VirtualHost>

Site par défaut

Parfois il est difficile de prévoir toutes les façons d'atteindre un serveur web. Par exemple on peut le contacter avec son adresse IP avec une adresse de la forme http://213.251.170.172/. Apache considère alors que le premier virtual host défini est celui par défaut: toutes les requêtes ne satisfaisant pas un ServerName ou ServerAlias connu seront considérées comme concernant ce site par défaut.

2. Les logs

Il est important de maintenir des logs d'accès, pratique d'avoir des logs d'erreur, et en général de les grouper par virtual host. Ceci simplifie les recherches et le traitement par lot (par exemple le calcul des statistiques). Utilisez de manière générale le format de log combined de Apache, il fournit beaucoup d'informations exploitables par les outils de statistiques. Evaluez d'autres formats si vous n'arrivez plus à traiter le volume de logs générés. Exemple:

<VirtualHost *>
    ServerName www.mycompany.com
    ...
    ErrorLog /var/log/apache2/www.mycompany.com/error.log
    customLog /var/log/apache2/www.mycompany.com/access.log combined
</VirtualHost>

Attention: vous devez alors impérativement adapter la rotation des logs en conséquence, sous peine de voir ces logs grossir indéfiniment ! En général, cette configuration de logrotate fait l'affaire:

/var/log/apache2/*/*.log {
        weekly
        missingok
        rotate 52
        compress
}

Notez que dans cet exemple, nous effectuons une rotation par semaine (pour un site à traffic modeste, quelques milliers de visites par jour environ), et nous gardons 52 rotations - donc 1 an d'historique. Les logs Apache se compressent très bien (un facteur 10 n'est pas rare).

3. Contrôle d'accès

Accès Apache

Avant même de contrôler l'utilisateur, nous devons contrôler Apache. Une bonne configuration par défaut comprend en général ces directives globales:

<Directory />
        Options None
        AllowOverride None
        Order allow,deny
        Deny from all
</Directory>

<Directory /var/www/>
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        Allow from all
</Directory>

Dans cet exemple, la politique d'accès par défaut considère à empêcher l'accès à l'ensemble du système de fichier, ainsi que toute modification locales à l'aide de fichiers .htaccess. Il faut alors autoriser au cas par cas les répertoires qui nous intéressent, ce qui est par exemple fait pour /var/www. Notez qu'en général l'option Indexes est désactivée en production, celle-ci autorise sinon le listing du contenu des répertoires qui n'ont pas de fichier d'index.

Si vous avez besoin que votre site ou votre application web puisse contrôler certaines directives d'Apache localement, à partir de fichiers de type .htaccess, il vous faudra modifier la valeur de AllowOverride (consulter sa documentation). Ceci peut avoir un léger impact sur les performances si Apache effectue le principal de son travail en servant des fichiers, car dans ce cas il doit chercher à chaque requête la présence d'un fichier .htaccess récursivement.

Accès utilisateur

Il est courant de vouloir restreindre l'accès d'un site ou d'une partie d'un site à certains utilisateurs. Voici un exemple courant:

<Directory /var/www/mycompany.com>
    AuthType Basic
    AuthName "Site réservé au personnel de MyCompany"
    AuthUserFile /var/lib/auth/mycompany.htpasswd
    Require valid-user
</Directory>

Nous protégeons ici l'accès à des fichiers en désignant un répertoire (et implicitement tous ses sous-répertoires) dans le système de fichiers. Nous pourrions également appliquer cette restriction plutôt par URL:

<Location /private>
    AuthType Basic
    AuthName "Site réservé au personnel de MyCompany"
    ...
</Location>

Ces deux façons de faire sont sensibles au contexte. Si elles sont globales, elles sont appliquées pour tous les sites. Sinon il faut les spécifier dans la définition d'un virtual host.

Il est vivement conseillé de stocker le fichier de mot de passe dans un chemin non accessible via Apache. Il arrive souvent que celui-ci soit stocké dans la zone protégée: dans ce cas, seuls les personnes autorisées auront accès à ce fichier, mais cela veut dire qu'une seule personne peut obtenir des infos sur l'ensemble des personnes autorisées. Précisons également le fait que le chiffrage des mots de passe est faible (man crypt) et peut être souvent "cracké" via une attaque par dictionnaire.

Note technique: avec cette méthode d'authentification, l'identifiant et le mot de passe de l'utilisateur passent en clair à chaque requête. Il existe des modes d'authentification plus sophistiqués mais plus rarement disponibles (ex: DIGEST). En général, on combine l'utilisation de l'authentification "basique" avec HTTPS.

4. SSL / HTTPS

Note: cette partie est applicable à Apache 2.0 et mod_ssl. Il faut effectuer certains ajustements pour le cas d'Apache-ssl, mais les similarités sont grandes.

Module SSL

Assurez-vous tout d'abord que le module SSL est bien chargé. Ceci est en général annoncé dans la signature du serveur par la bannière "mod_ssl/version":

# telnet localhost 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Apache/2.0.54 mod_ssl/2.0.54 OpenSSL/0.9.7e

Création d'un certificat auto-signé

Un certificat SSL en bonne et due forme est en général issu de et signée par un organisme de certification (Verisign, Thawte, etc). Vous trouverez facilement des certificats à acquérir en ligne, et ceux-ci sont fournis en général avec une documentation exhaustive pour leur installation sur votre plateforme.

Mais pour les tests, ou pour des besoins internes, un certificat que nous allons générer et signer nous-même suffira. Cela veut dire que les navigateurs estimeront que votre certificat n'est pas "digne de confiance" (en d'autres termes, vous n'êtes pas dans leur liste pré-installée de fournisseur de certificats), mais que hormis cet avertissement, vous allez pouvoir profiter des mécanismes d'authentification (vérification de l'identité du serveur) et de chiffrage de SSL.

Votre distribution fournit en général un script pour créer un tel certificat rapidement. La séquence complète est la suivante:

# cd /etc/apache2/ssl
# openssl req -new -x509 -nodes -out mycompany.pem -keyout mycompany.pem
# chmod 600 mycompany.pem

Le champ le plus important à saisir est le Common Name, il doit correspondre exactement au nom du serveur (ServerName?) concerné. Vous ne pouvez pas (du moins de manière simple et fiable) générer des certificats multi-site. Tout au plus vous pouvez saisir un Common Name comme *.mycompany.com avec des résultats variables suivant les navigateurs.

Le fichier généré contient la clé du serveur et le certificat pour votre site, il doit donc être protégé (il est lu par Apache en root avant que ce dernier n'abandonne ses privilèges pour servir les fichiers). Le certificat n'est pas protégé par un mot de passe (comme c'est souvent le cas en production), tout administrateur peut donc arrêter ou lancer le site SSL sans se voir demander la "passphrase".

Configuration mod_ssl

Dans le contexte du virtual host qui vous intéresse, ils vous suffit alors d'activer le support SSL et de le configurer:

NameVirtualHost *:443
<VirtualHost *:443>
    ...
    SSLEngine On
    SSLCertificateFile /etc/apache2/ssl/mycompany.pem
    SSLSessionCache         dbm:/var/run/apache2/ssl_scache
    SSLSessionCacheTimeout  300
    SSLMutex  file:/var/run/apache2/ssl_mutex
    SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
</VirtualHost>

Les deux premières lignes sont essentielles. A partir de ce moment, votre virtual host n'est disponible que via le protocole HTTPS.

Les deux ligne suivantes sont vivement recommandées, cacher les sessions permet des augmentations de performances simples et quasiment gratuites.

Enfin, les deux dernières lignes sont pratiquement standard, elles sont à régler suivant votre environnement, vos besoins, etc.

Le port 443

Si vous essayez la configuration ci-dessus, vous constaterez d'une part que votre navigateur vous renvoie une erreur étrange en consultant http://mycompany.com/ et d'autre part que https://mycompany.com/ ne répond pas. C'est que vous avez défini un virtual host qui utilise le protocole SSL sur le port 80 au lieu du 443 attendu. Il vous manque cette directive (globale):

Listen 443

... et le fait que votre 'virtual host répond pour un nom de domaine et un port donné, ce qui s'écrit:

<VirtualHost *:443>
    ...
</VirtualHost>

SSL et VirtualHostName?

(TODO: 1 seul certificat pour tous les vhosts, limitation du protocole HTTPS)

5. CGI, PHP, mod_perl

  • CGI classique
  • PHP et Perl en module vs. CLI
  • php.ini, php_flag/php_value/php_admin_flag

6. Statistiques

  • Webalizer
Last modified 14 years ago Last modified on Sep 4, 2006, 4:24:21 PM