« Installation et configuration d'un serveur http apache 2.2 » : différence entre les versions

[[Category:debian]]

Ce howto va vous montrer comment mettre en place un serveur web apache2 gérant les domaines virtuels et l'ipv6 sous debian squeeze.

Les changements de permissions effectués dans ce howto supposent que vous êtes en <code>umask 0027</code>

=Champs dns=

<pre>

</pre>

PidFile /var/run/apache2.pid

HostnameLookups Off

  #############################

Include vhosts/*.conf

</nowiki></pre>

Ajoutez la ligne suivante avant la directive <code>Include vhosts/*.conf</code> dans le fichier <code>/etc/apache2/apache2.conf</code>. 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.

<pre><nowiki>

<VirtualHost 213.186.47.110:80>

</VirtualHost>

<VirtualHost [2001:41d0:1:d6e::110]:80>

</VirtualHost>

</nowiki></pre>

Étant donné que nous n'avons pas précisé le port à la directive <code>servername</code> du fichier <code>/etc/apache/apache2.conf</code>, il est nécessaire de préciser le port pour chaque déclaration <code>virtualhost</code>.

<pre>DocumentRoot /srv/http/default/</pre>

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.

É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 <code>subjectAltName</code> 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").

<pre>

[APACHE]

subjectKeyIdentifier            = hash

authorityKeyIdentifier          = keyid,issuer:always

<pre>

cd /etc/ssl/core_ca

chmod -R 600 /etc/ssl/core_ca/

</pre>

Si vous ne souhaitez pas chiffrer le certificat avec une passphrase ajoutez l'argument <code>-nodes</code> à la première ligne.

Il est préférable de déplacer le certificat dans le dossier root de apache2:

<pre>

mkdir /etc/apache2/ssl/

chown -R root:root /etc/apache2/ssl/

chmod -R 600 /etc/apache2/ssl/

</pre>

==Mise en place des sites==

<pre>a2enmod ssl</pre>

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 <code>Include</code> chargeant les autres vhosts, si l'une de ces vhosts est configuré en ssl, apache2 ne démarrera pas.

<pre><nowiki>

#Certificat SSL

#SSLCACertificateFile

SSLCertificateChainFile /etc/apache2/ssl/ca_chain.pem

<VirtualHost 213.186.47.110:80>

</VirtualHost>

<VirtualHost [2001:41d0:1:d6e::110]:80>

</VirtualHost>

         SSLProtocol All

         SSLCipherSuite MEDIUM:HIGH

</VirtualHost>

         SSLProtocol All

         SSLCipherSuite MEDIUM:HIGH

</VirtualHost>

</nowiki></pre>

Si vous disposez de plusieurs adresses IPs, vous devrez indiquer le certificat ssl correspondant dans chaque bloque <code>VirtualHost</code> correspondant (donc deux fois pour chaque site si vous utilisez IPv4 et IPv6).

<pre>

</pre>

<pre>

</pre>

Pour que l'ajout soit pris en compte il faut reloader apache2:

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 <code>/etc/logrotate.d/apache2</code> et modifiez la ligne <code>/etc/init.d/apache restart</code> en <code>/etc/init.d/apache reload</code>

<pre><nowiki>

<VirtualHost 213.186.47.110:443>

         SSLProtocol All

         SSLCipherSuite MEDIUM:HIGH

</VirtualHost>

<VirtualHost 213.186.47.110:80>

</VirtualHost>

<VirtualHost [2001:41d0:1:d6e::110]:80>

</VirtualHost>

<VirtualHost [2001:41d0:1:d6e::110]:443>

         SSLProtocol All

         SSLCipherSuite MEDIUM:HIGH

</VirtualHost>

</nowiki></pre>

<pre>

</pre>

=Installer le module php=

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/

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é.

SuPHP ne permet pas l'utilisation de <code>php_admin_value</code> 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 <code>suPHP_ConfigPath</code> suivie du répertoire dans lequel le fichier <code>php.ini</code> personnalisé est présent.

Ce php.ini personnalisé peut être une copie conforme de <code>/etc/php5/cgi/php.ini</code> mais dans lequel vous pouvez définir <code>open_basedir = /home/blah/www/</code> 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).

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.

L'outil <code>htpasswd</code> 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 :

<pre>

Adding password for pfoo

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 :

<pre>

Adding user plop

New password:

</pre>

* Pour que tous les utilisateurs valides (qui sont présent dans le <code>.htpasswd</code>) aient accès au dossier :

<pre><nowiki>

AuthGroupFile /dev/null

AuthName "Accès Restreint"

* Accès pour l'utilisateur pfoo uniquement :

<pre><nowiki>

AuthGroupFile /dev/null

AuthName "Accès Restreint"

* Accès au groupe admin et uniquement pour les GET et POST :

<pre><nowiki>

AuthName "Accès Restreint"

AuthType Basic

Pour créer un tel fichier :

Comme avant, si le fichier existe déjà, supprimez l'argument -c

AuthDigestDomain /

AuthDigestProvider file

Require valid-user

</pre>