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

Aller à la navigation Aller à la recherche

Installation et configuration d'un serveur http apache 2.2 (voir la source)

Version du 15 mars 2016 à 02:06

20 579 octets ajoutés ,  15 mars 2016
→‎Génération du certificat ssl
 
(67 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
Ce howto a été écrit au départ pour debian etch puis a été adapté pour debian lenny. Il reste cependant valable la plupart du temps pour ces deux versions de debian.
[[Category:serveur]]
[[Category:debian]]
[[Category:wheezy]]
[[Category:toupdate]]


Ce howto va vous montrer comment mettre en place un serveur web apache2 gérant les domaines virtuels et l'ipv6 sous debian lenny.
'''<span style="color: red;">Tuto plus vraiment à jour</span>'''
Nous allons mettre en place trois sites : <code>core.csnu.org</code>, <code>www.csnu.org</code> et <code>webmail.csnu.org</code>.
<code>core.csnu.org</code> sera le site par défaut sur lequel tombera toute personne effectuant une requête http ne désignant aucun autre domaine virtuel.
<code>www.csnu.org</code> et <code>webmail.csnu.org</code> sont ce qu'on peut appeler des domaines virtuels : ils sont sur la même ip que <code>core.csnu.org</code> mais servent des domaines différents. Ces deux domaines disposeront d'un chiffrement ssl/tls actif.


Au niveau dns, <code>core.csnu.org</code> est le domaine identifiant la machine. Il possède l'adresse ipv4 <code>213.186.47.110</code> et l'adresse ipv6 <code>2001:41d0:1:d6e::127</code>.
[[Installation_de_configuration_du_serveur_web_Apache_2.4_sous_Debian_Jessie|Nouveau wiki à jour (mais incomplet pour le moment)]]
<code>www.csnu.org</code> et <code>webmail.csnu.org</code> sont des alias pour <code>core.csnu.org</code>.
 
 
 
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 : <code>srv.domain.tld</code>, <code>www.domain.tld</code> et <code>webmail.domain.tld</code>.
<code>srv.domain.tld</code> sera le site par défaut sur lequel tombera toute personne effectuant une requête http ne désignant aucun autre domaine virtuel.
<code>www.domain.tld</code> et <code>webmail.domain.tld</code> sont ce qu'on peut appeler des domaines virtuels : ils sont sur la même ip que <code>srv.domain.tld</code> mais servent des domaines différents. Ces deux domaines disposeront d'un chiffrement ssl/tls actif.
 
Au niveau dns, <code>srv.domain.tld</code> est le domaine identifiant la machine. Il possède l'adresse ipv4 <code>213.186.47.110</code> et l'adresse ipv6 <code>2001:41d0:1:d6e::110</code>.
<code>www.domain.tld</code> et <code>webmail.domain.tld</code> sont des alias pour <code>srv.domain.tld</code>.


Les changements de permissions effectués dans ce howto supposent que vous êtes en <code>umask 0027</code>
Les changements de permissions effectués dans ce howto supposent que vous êtes en <code>umask 0027</code>
Ligne 13 : Ligne 22 :
=Champs dns=
=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 (<code>/srv/http/csnu.org.host</code> dans mon cas) et ajoutez ou modifiez les lignes suivantes :
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 (<code>/srv/http/domain.tld.host</code> dans mon cas) et ajoutez ou modifiez les lignes suivantes :
<pre>
<pre>
csnu.org.      IN      A      213.186.47.110
domain.tld.      IN      A      213.186.47.110
csnu.org.      IN      AAAA    2001:41d0:1:d6e::110
domain.tld.      IN      AAAA    2001:41d0:1:d6e::110
core.csnu.org.  IN      A      213.186.47.110
srv.domain.tld.  IN      A      213.186.47.110
core.csnu.org.  IN      AAAA    2001:41d0:1:d6e::110
srv.domain.tld.  IN      AAAA    2001:41d0:1:d6e::110
www            IN      CNAME  core.csnu.org.
www            IN      CNAME  srv.domain.tld.
webmail IN CNAME core.csnu.org.
webmail IN CNAME srv.domain.tld
</pre>
</pre>


Ligne 53 : Ligne 62 :
Listen 213.186.47.110:443
Listen 213.186.47.110:443
Listen 127.0.0.1:80
Listen 127.0.0.1:80
Listen ::1:80
Listen [::1]:80
Listen 2001:41d0:1:d6e::110:80
Listen [2001:41d0:1:d6e::110]:80
Listen 2001:41d0:1:d6e::110:443
Listen [2001:41d0:1:d6e::110]:443


User www-data
User www-data
Ligne 61 : Ligne 70 :
PidFile /var/run/apache2.pid
PidFile /var/run/apache2.pid


ServerAdmin root@csnu.org
ServerAdmin root@domain.tld
ServerName www.csnu.org:80
ServerName www.domain.tld


HostnameLookups Off
HostnameLookups Off
Ligne 70 : Ligne 79 :
NameVirtualHost 213.186.47.110:80
NameVirtualHost 213.186.47.110:80
NameVirtualHost 213.186.47.110:443
NameVirtualHost 213.186.47.110:443
NameVirtualHost 2001:41d0:1:d6e::110:80
NameVirtualHost [2001:41d0:1:d6e::110]:80
NameVirtualHost 2001:41d0:1:d6e::110:443
NameVirtualHost [2001:41d0:1:d6e::110]:443


#NameVirtualHost 127.0.0.1:80
#NameVirtualHost 127.0.0.1:80
Ligne 166 : Ligne 175 :
  #############################
  #############################


Include vhosts/core.csnu.org.conf.default
Include vhosts/srv.domain.tld.conf.default
Include vhosts/csnu.org.conf.default
Include vhosts/domain.tld.conf.default
Include vhosts/*.conf
Include vhosts/*.conf
</nowiki></pre>
</nowiki></pre>
Ligne 238 : Ligne 247 :
  Allow from 127.0.0.1
  Allow from 127.0.0.1
  Allow from ::1
  Allow from ::1
  Allow from 91.121.60.127
  Allow from 213.186.47.110
Allow from 2001:41d0:1:d6e::110
</Location>
</Location>
ExtendedStatus On
ExtendedStatus On
Ligne 251 : Ligne 261 :


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.
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>Include vhosts/core.csnu.org.conf.default</pre>
<pre>Include vhosts/srv.domain.tld.conf.default</pre>


Créez le fichier <code>/etc/apache2/vhosts/core.csnu.org.conf.default</code> et ajoutez y les lignes suivantes :
Créez le fichier <code>/etc/apache2/vhosts/srv.domain.tld.conf.default</code> et ajoutez y les lignes suivantes :
<pre><nowiki>
<pre><nowiki>
<VirtualHost 91.121.60.127>
<VirtualHost 213.186.47.110:80>
         ServerName core.csnu.org
         ServerName srv.domain.tld
         Include sites/core.csnu.org.conf
         Include sites/srv.domain.tld.conf
</VirtualHost>
</VirtualHost>
<VirtualHost [2001:41d0:1:d6e::127]>
<VirtualHost [2001:41d0:1:d6e::110]:80>
         ServerName core.csnu.org
         ServerName srv.domain.tld
         Include sites/core.csnu.org.conf
         Include sites/srv.domain.tld.conf
</VirtualHost>
</VirtualHost>
</nowiki></pre>
</nowiki></pre>


La configuration de cette vhost est défini pour être dans <code>/etc/apache2/sites/core.csnu.org.conf</code>. Créez ce fichier et ajoutez-y les lignes suivantes :
É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>.
 
La configuration de cette vhost est défini pour être dans <code>/etc/apache2/sites/srv.domain.tld.conf</code>. Créez ce fichier et ajoutez-y les lignes suivantes :
<pre>DocumentRoot /srv/http/default/</pre>
<pre>DocumentRoot /srv/http/default/</pre>


Ligne 281 : Ligne 293 :
=Mise en place d'un site sécurisé en ssl=
=Mise en place d'un site sécurisé en ssl=


Nous allons maintenant mettre en place les deux sites sécurisés en ssl : <code>www.csnu.org</code> et <code>webmail.csnu.org</code>.
----
----
 
'''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 : <code>www.domain.tld</code> et <code>webmail.domain.tld</code>.
É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).
É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").
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").
Ligne 292 : Ligne 315 :
<pre>
<pre>
[APACHE]
[APACHE]
nsComment                      = "CORE Apache Server"
nsComment                      = "SRV Apache Server"
subjectKeyIdentifier            = hash
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                  = issuer:copy
issuerAltName                  = issuer:copy
subjectAltName                  = DNS:www.csnu.org, DNS:webmail.csnu.org
subjectAltName                  = DNS:www.domain.tld, DNS:webmail.domain.tld
basicConstraints                = critical,CA:FALSE
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation, keyEncipherment
keyUsage                        = critical,digitalSignature, nonRepudiation, keyEncipherment
nsCertType                      = server
nsCertType                      = server
extendedKeyUsage                = serverAuth
extendedKeyUsage                = serverAuth
Ligne 307 : Ligne 330 :
<pre>
<pre>
cd /etc/ssl/core_ca
cd /etc/ssl/core_ca
openssl req -config /etc/ssl/openssl.cnf -newkey rsa:2048 -keyout www.csnu.org.key -out www.csnu.org.req
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.csnu.org.req -out www.csnu.org.pem
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/
chmod -R 600 /etc/ssl/core_ca/
</pre>
</pre>


Si vous ne souhaitez pas chiffrer le certificat avec une passphrase ajoutez l'argument <code>-nodes</code> à la première ligne.
Si vous ne souhaitez pas chiffrer le certificat avec une passphrase ajoutez l'argument <code>-nodes</code> à la première ligne.
Répondez aux différentes questions posées par openssl. La plupart sont assez triviales. Attention toutefois : <code>Common Name</code> doit être l'adresse principale de votre site (<code>www.csnu.org</code> dans mon cas).
Répondez aux différentes questions posées par openssl. La plupart sont assez triviales. Attention toutefois : <code>Common Name</code> doit être l'adresse principale de votre site (<code>www.domain.tld</code> dans mon cas).


Il est préférable de déplacer le certificat dans le dossier root de apache2:
Il est préférable de déplacer le certificat dans le dossier root de apache2:
<pre>
<pre>
mkdir /etc/apache2/ssl/
mkdir /etc/apache2/ssl/
mv www.csnu.org.* /etc/apache2/ssl/
mv www.domain.tld.* /etc/apache2/ssl/
chown -R root:root /etc/apache2/ssl/
chown -R root:root /etc/apache2/ssl/
chmod -R 600 /etc/apache2/ssl/
chmod -R 600 /etc/apache2/ssl/
</pre>
</pre>


Enfin, nous allons créer un fichier contenant la chaine de certification :
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) :
<pre>
<pre>
cat /etc/ssl/root_ca/root_ca.pem > /etc/apache2/ssl/ca_chain.pem
cat /etc/ssl/core_ca/core_ca.pem /etc/ssl/root_ca/root_ca.pem > /etc/apache2/ssl/ca_chain.pem
cat /etc/ssl/core_ca/core_ca.pem >> /etc/apache2/ssl/ca_chain.pem
</pre>
</pre>


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.csnu.org.pem) : le client sera certain que la chaine est complètement valide.
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==
==Mise en place des sites==
Ligne 336 : Ligne 358 :
<pre>a2enmod ssl</pre>
<pre>a2enmod ssl</pre>


Ajoutez la ligne suivante dans <code>/etc/apache2/apache2.conf<code> après <code>Include vhosts/core.csnu.org.conf.default</code> mais avant <code>Include vhosts/*.conf</code> :
Ajoutez la ligne suivante dans <code>/etc/apache2/apache2.conf<code> après <code>Include vhosts/srv.domain.tld.conf.default</code> mais avant <code>Include vhosts/*.conf</code> :
<pre>Include vhosts/csnu.org.conf.default</pre>
<pre>Include vhosts/domain.tld.conf.default</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.
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.


Créez le fichier <code>/etc/apache2/vhosts/csnu.org.conf.default</code> et ajoutez y ceci :
Créez le fichier <code>/etc/apache2/vhosts/domain.tld.conf.default</code> et ajoutez y ceci :
<pre><nowiki>
<pre><nowiki>
#Certificat SSL
#Certificat SSL
#SSLCACertificateFile
#SSLCACertificateFile
SSLCertificateChainFile /etc/apache2/ssl/ca_chain.pem
SSLCertificateChainFile /etc/apache2/ssl/ca_chain.pem
SSLCertificateFile /etc/apache2/ssl/www.csnu.org.pem
SSLCertificateFile /etc/apache2/ssl/www.domain.tld.pem
SSLCertificateKeyFile "/etc/apache2/ssl/www.csnu.org.key"
SSLCertificateKeyFile "/etc/apache2/ssl/www.domain.tld.key"


<VirtualHost 91.121.60.127:80>
<VirtualHost 213.186.47.110:80>
         ServerName www.csnu.org
         ServerName www.domain.tld
         ServerAlias csnu.org
         ServerAlias domain.tld
         Include sites/csnu.org.conf
         Include sites/domain.tld.conf
</VirtualHost>
</VirtualHost>


<VirtualHost [2001:41d0:1:d6e::127]:80>
<VirtualHost [2001:41d0:1:d6e::110]:80>
         ServerName www.csnu.org
         ServerName www.domain.tld
         ServerAlias csnu.org
         ServerAlias domain.tld
         Include sites/csnu.org.conf
         Include sites/domain.tld.conf
</VirtualHost>
</VirtualHost>


<VirtualHost 91.121.60.127:443>
<VirtualHost 213.186.47.110:443>
         SSLEngine on
         SSLEngine on
         SSLProtocol All
         SSLProtocol All -SSLv2 -SSLv3
         SSLCipherSuite MEDIUM:HIGH
         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.csnu.org
         ServerName www.domain.tld
         ServerAlias csnu.org
         ServerAlias domain.tld
         Include sites/csnu.org.conf
         Include sites/domain.tld.conf
</VirtualHost>
</VirtualHost>


<VirtualHost [2001:41d0:1:d6e::127]:443>
<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>
</nowiki></pre>
 
Notez que les directives <code>SSLCertificate*</code> ne sont situés en dehors des bloques <code>VirtualHost</code> 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 <code>VirtualHost</code> correspondant (donc deux fois pour chaque site si vous utilisez IPv4 et IPv6).
 
La directive <code>ServerAlias</code> défini domain.tld comme un alias pour <code>www.domain.tld</code>
Créez ensuite <code>/etc/apache2/sites/domain.tld.conf</code> et ajoutez y les lignes suivantes:
<pre>
DocumentRoot /srv/http/domain.tld/domain.tld/
ServerAdmin admin@domain.tld
</pre>
 
Bien sur il faut que <code>/srv/http/domain.tld/domain.tld/</code> existe et soit accessible par apache2:
<pre>
mkdir -p /srv/http/domain.tld/domain.tld/
chown -R root:www-data /srv/http/domain.tld/
</pre>
Pour que l'ajout soit pris en compte il faut reloader apache2:
<pre>
/etc/init.d/apache2 reload
</pre>
 
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>
 
Pour le site <code>webmail.domain.tld</code> créez le fichier <code>/etc/apache2/vhosts/webmail.domain.tld.conf</code> et ajoutez y les lignes suivantes :
<pre><nowiki>
<VirtualHost 213.186.47.110:443>
         SSLEngine on
         SSLEngine on
         SSLProtocol All
         SSLProtocol All -SSLv2 -SSLv3
         SSLCipherSuite MEDIUM:HIGH
         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.csnu.org
         ServerName webmail.domain.tld
        ServerAlias csnu.org
         Include sites/webmail.domain.tld.conf
         Include sites/csnu.org.conf
</VirtualHost>
</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>
</nowiki></pre>
Créez ensuite le fichier <code>/etc/apache2/sites/webmail.domain.tld.conf</code> et ajoutez y les lignes suivantes :
<pre>
DocumentRoot /srv/http/domain.tld/webmail.domain.tld/
ServerAdmin admin@domain.tld
</pre>
Comme précédemment, <code>/srv/http/domain.tld/webmail.domain.tld/</code> doit exister et être accessible par apache2.
=Installer le module php=
Installez juste le paquet libapache2-mod-php5 avec aptitude :
<pre>
aptitude install libapache2-mod-php5
a2enmod php5
</pre>
==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) :
<pre>php_admin_value open_basedir PATH1:PATH2</pre>
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 <code>DocumentRoot</code> comme path est largement suffisant. Voici l'exemple pour la vhost www.domain.tld (/etc/apache2/sites/domain.tld.conf:
<pre>php_admin_value open_basedir /srv/http/domain.tld/domain.tld/</pre>
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 <code>php_admin_value open_basedir</code> sur une vhost il est bon de spécifier un open_basedir par défaut dans le fichier <code>/etc/apache2/apache2.conf</code> :
<pre>php_admin_value open_basedir /srv/http/default/</pre>
Toutes les vhosts ne disposant pas leur propre directive <code>php_admin_value open_basedir</code> seront donc parquées dans <code>/srv/http/default/</code>
Si vous utilisez le <code>mod-userdir</code> il peut être intéressant d'ajouter la directive <code>php_admin_value open_basedir</code> dans la configuration du module. Voici la mienne :
<pre><nowiki>
<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>
</nowiki></pre>
Pour plus d'information : http://wiki.apache.org/httpd/SecuringPHP
===SuExec===
<pre>
aptitude install apache2-suexec
a2enmod suexec
/etc/init.d/apache2 restart
</pre>
<pre>
<VirtualHost *:80>
DocumentRoot /home/user/www
ServerName domain.tld
SuExecUserGroup user group
</pre>
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 <code>mod_php5</code> traditionnel de apache2 avec <code>SuPHP</code>. 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 :
<pre>aptitude install libapache2-mod-suphp suphp-common</pre>
Comme vous pouvez le voir, php5-cgi sera automatiquement installé. Activez SuPHP :
<pre>a2enmod suphp</pre>
Le fichier de configuration SuPHP de apache 2 est <code>/etc/apache2/mods-enabled/suphp.conf</code>. <br />
Le fichier de configuration de SuPHP est <code>/etc/suphp/suphp.conf</code>. Dans ce dernier fichier, adaptez la ligne <code>docroot=</code> afin qu'elle pointe sur le répertoire contenant le <code>DocumentRoot</code> 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 :
<pre>
docroot=${HOME}/
</pre>
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 <code>/etc/apache2/mods-enabled/php5.conf</code> comme suit afin de n'activer le module php que dans <code>/srv/http/</code> :
<pre><nowiki>
<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>
</nowiki></pre>
<code>mod_php5</code> étant prioritaire sur <code>suPHP</code> ces quelques lignes permettent de désactiver <code>mod_php5</code> partout sauf dans /srv/http/.
Dans la même idée, vous pouvez limiter SuPHP à /home en modifiant <code>/etc/apache2/mods-enabled/suphp.conf</code> comme suit :
<pre><nowiki>
<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>
</nowiki></pre>
Si vous utilisez des utilitaires d'administration web comme <code>PhpMyAdmin</code> n'oubliez pas d'activer <code>mod_php5</code> dans le répertoire correspondant. Par exemple, pour <code>PhpMyAdmin</code>, il faudra ajouter les lignes suivantes au fichier <code>/etc/apache2/mods-enabled/php5.conf</code> :
<pre>
<Directory /usr/share/phpmyadmin>
  php_flag engine on
</Directory>
</pre>
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.
Par exemple, si le fichier de configuration de la vhost <code>blah.domain.tld</code> ayant comme <code>documentroot /home/blah/www/</code> est <code>/home/blah/php.ini</code> il faut ajouter la directive <code>suPHP_ConfigPath /home/blah</code> (sans le / final !) dans le fichier de configuration de la vhost.
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).
Vous pouvez aussi spécifier un open_basedir par défaut dans le fichier <code>/etc/php5/cgi/php.ini</code> 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 <code>phpinfo()</code> avec un fichier .php dans ce genre :
<pre><nowiki>
<?php
    phpinfo();
?>
</nowiki></pre>
</nowiki></pre>
Notez que si vous utilisez <code>mod_userdir</code> il sera impossible d'exécuter les scripts php à l'aide de suphp à cause de la directive <code>check_vhost_docroot=true</code> de SuPHP. Vous pouvez ajouter la directive <code>suPHP_Engine off</code> dans le fichier de configuration de <code>mod_userdir</code> :
<pre>
<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>
</pre>
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 :
<pre>/etc/init.d/apache2 restart</pre>
==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é [http://www.hardened-php.net/suhosin/ 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 <code>/etc/php5/conf.d/suhosin.ini</code> 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 <code>/etc/php5/conf.d/suhosin.ini</code>, 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.
<pre>aptitude install apache2-mpm-itk</pre>
Puis dans chaque virtualhost :
<pre>AssignUserId user group</pre>
Dans le cas présent, vous n'aurez plus besoin d'ajouter les utilisateurs au groupe <code>www-data</code>
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 <code>/srv/http/admin.domain.tld/</code> qui correspond à la vhost <code>http://admin.domain.tld/</code>.
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>
$ htpasswd -cs /srv/http/admin.domain.tld/.htpasswd pfoo
Adding password for pfoo
New password:
Re-type new password:
</pre>
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>
$ htpasswd -s /srv/http/admin.domain.tld/.htpasswd plop
Adding user plop
New password:
Re-type new password:
</pre>
Le fichier <code>.htgroup</code> permet de rassembler plusieurs utilisateurs dans un même groupe. Il suffit de créer un fichier (<code>.htgroup</code>) texte contenant par exemple (pour créer un groupe admin et un groupe user) :
<pre>
admin: pfoo plop
user: blah
</pre>
Il faut ensuite créer le fichier <code>/srv/http/admin.domain.tld/.htaccess</code>.
* Pour que tous les utilisateurs valides (qui sont présent dans le <code>.htpasswd</code>) aient accès au dossier :
<pre><nowiki>
AuthUserFile /srv/http/admin.domain.tld/.htpasswd
AuthGroupFile /dev/null
AuthName "Accès Restreint"
AuthType Basic
require valid-user
</nowiki></pre>
* Accès pour l'utilisateur pfoo uniquement :
<pre><nowiki>
AuthUserFile /srv/http/admin.domain.tld/.htpasswd
AuthGroupFile /dev/null
AuthName "Accès Restreint"
AuthType Basic
require user pfoo
</nowiki></pre>
* Accès au groupe admin et uniquement pour les GET et POST :
<pre><nowiki>
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>
</nowiki></pre>
==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 <code>auth_digest</code> et <code>authn_file</code> de apache doivent être activés :
<pre>a2enmod authn_file auth_digest</pre>
L'outil <code>htdigest</code> permet de créer un fichier <code>.htpasswd</code> utilisant cette méthode d'authentification.
Pour créer un tel fichier :
<pre>htdigest -c /srv/http/admin.domain.tld/.htpasswd realm username</pre>
Comme avant, si le fichier existe déjà, supprimez l'argument -c
En ce qui concerne le fichier <code>.htaccess</code> :
<pre>
AuthType Digest
AuthName realm
AuthDigestDomain /
AuthDigestProvider file
AuthUserFile /srv/http/admin.domain.tld/.htpasswd
AuthGroupFile /srv/http/admin.domain.tld/.htgroup
Require valid-user
</pre>
Comme vous pouvez le voir, <code>AuthName</code> doit correspondre au <code>realm</code> fourni avec <code>htdigest</code>.
=Monitorer apache avec apachetop=
<code>apachetop</code> permet d'analyser facilement les requêtes servies par votre serveur apache en analysant les fichiers de log.
<pre>aptitude install apachetop</pre>
Par défaut, <code>apachetop</code> utilise les données de <code>/var/log/apache/access.log</code>. Vous pouvez spécifier un autre fichier de log avec l'option <code>-f</code>.
Pfoo
Bureaucrates, Administrateurs
4 231

modifications

Récupérée de « https://wiki.unscdf.org/index.php?title=Spécial:MobileDiff/69...2172 »

Menu de navigation