Mettre en place un serveur web (apache2)

Transcription

Introduction
Apache2 est un logiciel qui permet de mettre à disposition sur le réseau un site web (pages
html, php). Plus précisément apache2 est un serveur http. Les utilisateurs utilisent quant à eux
un client http pour afficher à l'écran ce site, comme par exemple firefox, chrome, Microsoft
Internet Explorer etc...
Selon les fonctionnalités qu'apache2 doit supporter, on installe un certain nombre de modules
supplémentaires (support du langage php, du perl, du python, de l'ASP.net etc...). Il ne faut pas
confondre la notion de module au sens Linux (qui servent à supporter par exemple du matériel)
et de module au sens apache (qui sert à apporter de nouvelles fonctionnalités au serveur
apache).
Le fonctionnement d'apache repose sur un moteur, le MPM (multi processing module). De nos
jours, il existe principalement deux moteurs :
Le MPM prefork : c'est l'ancien moteur. Il est mono threadé donc plus lent. On l'utilise
encore car certains modules (dont le module PHP) le requièrent.
Le MPM worker : c'est celui que vous devriez utiliser autant que possible car il supporte
le multi threading et sera donc plus rapide.
Mistra Formation - 19 rue Béranger 75003 Paris - Métro République - 01 82 52 25 25 - [email protected]
Lorsqu'on installe sur une machine Linux un serveur apache, un serveur de base de données
MySQL et PHP, on parle d'architecture LAMP (Linux, Apache, MySQL, PHP).
Pour aborder ce tutoriel, il est recommandé de lire au préalable les articles sur nano et lire les
rappels sur les adresses IP.
Installation d'apache
Étape 1 : installer les paquets apache
Comme la plupart des logiciels sous linux, apache2, les MPM et les modules sont disponibles
sous forme de paquets.
Nous allons partir du principe dans cette étape que l'on utilise une distribution Debian ou basée
sur Debian (Ubuntu...). Dans ce cas, les noms des paquets apache sont normalisés comme suit
:
apache2 : le paquet qui installe apache2,
apache2-mpm-... : un MPM pour apache2,
libapache2-mod-... : un module apache2.
Le gestionnaire de paquets s'assurera notamment que seul l'un des deux MPM est installé (et
donc utilisé). Par le jeu des dépendances il installera le MPM worker. Si un paquet
(typiquement libapache2-mod-php5 qui installe le support du PHP5) exige le MPM worker, alors
le gestionnaire de paquet supprimera le MPM worker pour installer à la place le MPM prefork.
Installons à présent quelques paquets (dans une console root ou par le biais de la commande
sudo).
aptitude update
aptitude safe-upgrade
aptitude install apache2
Étape 2 : démarrer ou stopper le serveur apache
Comme la plupart des serveurs réseaux (ssh, mysql, ftp...), apache2 s'instancie par le biais d'un
script shell (appelé service) rangé dans /etc/init.d. Ces scripts prennent en paramètre une
chaîne de caractère dont :
start : démarre le service (s'il était stoppé),
stop : stoppe le service (s'il était démarré),
restart : redémarre le service (ou le démarre s'il était éteint), mais avec rupture de
service (les sessions ouvertes par les clients sont coupées),
reload : redémarre le service dans la mesure du possible sans rupture de service
Ce script shell instancie un démon, c'est-à-dire une tâche qui tourne en arrière plan et qui n'est
pas rattachée à une session en mode texte ou en mode graphique. Sous Linux, les démons
sont des tâches qui apparaissent dans la table des processus et ont généralement un nom qui
finit par un "d" (sshd, proftpd, mysqld etc...). Pour plus de détails à ce sujet, vous pouvez
consulter le tutoriel sur les processus.
On peut instancier le service explicitement :
/etc/init.d/apache2 stop
/etc/init.d/apache2 start
/etc/init.d/apache2 restart
Sur les distributions récentes, on passera de préférence par la commande service (il suffit de
substituer "/etc/init.d" par "service ") :
service apache2 stop
service apache2 start
service apache2 restart
Gardez à l'esprit que relancer (restart) un serveur apache engendre une interruption de
service. Ici il s'agit d'une mise en place de serveur, donc a priori personne n'est sensé
consulter le site pendant cette phase de maintenance. Mais pour un serveur en production,
dans la mesure du possible, il est préférable de faire un rechargement (reload) :
service apache2 reload
Facultatif : notez qu'on peut surveiller à tout instant l'activité du serveur apache grâce à la
commande apachetop, qu'il faudra au préalable installer. Pour l'installer, on taperait sous
debian :
aptitude update
aptitude safe-upgrade
aptitude install apachetop
apachetop
Étape 3 : premiers tests
On sait à présent lancer, stopper ou redémarrer apache2 proprement. La configuration par
défaut d'apache2 le fait écouter sur le port 80. On peut vérifier que le serveur écoute bien sur ce
port grâce à la commande netstat :
netstat -ntlp | grep ":80 "
Exemple : si apache2 est démarré, la commande netstat (tapée sur la machine qui héberge le
serveur apache) devrait écrire quelque chose du genre :
(mando@silk) (~) $ netstat -ntlp | grep ":80 "
(Tous les processus ne peuvent être identifiés, les infos sur les processus
non possédés ne seront pas affichées, vous devez être root pour les voir toutes.)
tcp6
0
0 :::80
:::*
LISTEN
-
Ici, apache2 écoute sur n'importe quelle interface réseau (devant le :::: ne figure pas l'adresse
IP d'une interface réseau) et sur le port 80. Le port sur lequel écoute apache peut être
personnalisé, nous verrons comment ultérieurement.
Remarques :
Au niveau du navigateur, le port peut généralement être sous-entendu. Celui-ci retrouve
le port auquel se connecter grâce au préfixe passé au début de l'adresse (par exemple
http://, https:// ou ftp://). Sous Linux, on retrouve l'association entre les différents
protocole dans le fichier /etc/services. Ainsi http, https et ftp sont respectivement
associés par défaut aux port 80, 443 et 21.
Si le port utilisé par le serveur n'est pas le port par défaut, il faut l'indiquer au navigateur.
Par exemple, si le serveur s'appelle localhost et écoute sur le port 8888 en http, alors
l'adresse à taper devient http://localhost:8888 au lieu de http://localhost.
Étape 4 : configurer apache
Principes de base
La plupart des logiciels sous Linux examinent leurs fichiers de configuration au démarrage.
Apache n'échappe pas à la règle : dès que l'on modifiera les fichiers de configuration
d'apache2, il faudra forcer apache à les relire :
soit en redémarrant apache (avec la commande "service apache2 restart", voir étape 2),
soit en rechargeant sa configuration ("service apache2 reload").
Tout point de configuration global au système (c'est-à-dire qui n'est pas spécifique à un
utilisateur) est stocké dans /etc. Plus précisément, la configuration d'apache2 est rassemblée
dans /etc/apache2 :
/etc/apache2/apache2.conf : le "remplaçant" de httpd.conf, lu au démarrage d'apache. Il
n'est jamais sensé être modifié (voir httpd.conf). Il inclue notamment les fichiers de
configuration mentionnés ci-dessous.
/etc/apache2/ports.conf : indique le(s) port(s) sur lequel(s) écoute apache2 (80 pour
http, 443 pour https),
/etc/apache2/httpd.conf : fichier généralement vide. Il essentiellement là pour des
raisons historiques et sert de nos jours pour injecter de la configuration personnalisés.
...
Dans le cas général
Sous Debian et les distributions qui en dérivent, la configuration associée au(x) site(s) et aux
modules apaches est modulaire. Dans le cas général on pourrait tout mettre dans
/etc/apache2/httpd.conf ou /etc/apache2/apache2.conf. Toutefois une telle configuration serait
peu pratique ; le fichier serait très long et l'activation ou la désactivation d'un site ou d'un
module consisterait à commenter ou décommenter la bonne section de fichier et pourrait
engendrer un certain nombre d'erreurs humaines.
C'est la raison pour laquelle Fedora suggère de reproduire une décomposition voisine de celle
proposée par Debian en mettant en place une série de fichiers dans un répertoire dédié,
/etc/apache2/conf.d. Pour plus de détails, on pourra consulter ce lien :
http://doc.fedora-fr.org/wiki/Installation_et_configuration_d%27Apache#Configuration_d.27Apac
he
Sous Debian et les distributions qui en dérivent
Voyons à présent les quatre sous-répertoires de /etc/apache2.
/etc/apache2/mods-available/
On y trouve les modules apache2 installés, mais pas forcément utilisés par apache2. On trouve
pour chaque module un couple de fichier (.load et .conf) qui explicitent comment apache2 doit
charger le module en question. Ce répertoire est alimenté en installant les paquets
"libapache2-mod-..." .
Exemple : si on installe libapache2-mod-php5, un fichier "php5.load" et "php5.conf" devrait
apparaître dans ce répertoire.
/etc/apache2/mods-enabled/
Ce répertoire contient un ensemble de liens symboliques qui pointent vers les fichiers ".conf" et
".load" des modules qu'apache2 doit charger à son démarrage. Concrètement, il suffit donc de
créer les bons liens symboliques pour indiquer à apache2 quels modules charger, et supprimer
les liens symboliques des modules qu'on ne souhaite pas charger. On pourrait pour ce faire
utiliser les commandes "ln" ou "rm", mais on utilisera de préférence les commandes :
a2enmod : (apache2 enable module) : active un module apache2,
a2dismod : (apache2 disable module) : désactive un module apache2.
Nous verrons un peu plus loin leur utilisation.
/etc/apache2/sites-available/
Ce répertoire contient des fichiers qui indiquent chaque site hébergé par apache2. En
particulier, l'arborescence fournit par le serveur apache peut provenir de différents endroits. Par
exemple, lorsqu'on installe apache2, le site "default" est configuré de sorte à mettre à
disposition tout ce qui est dans /var/www.
/etc/apache2/sites-enabled/
Sur le même principe que /etc/apache/mod-enabled, ce répertoire contient des liens
symboliques qui pointent vers des fichiers de /etc/apache2/sites-available. Encore une fois, on
pourrait utiliser les commandes "ln" et "rm" pour gérer ces liens, mais on utilisera plutôt les
commandes :
a2ensite : (apache2 enable site) : active un site,
a2dissite : (apache2 disable site) : désactive un site.
Résumé
Une partie de la configuration apache2 découle des liens symbolique créés dans mods-enabled
et site-enabled. Ils pointent respectivement vers des fichiers de mods-available et
sites-available.
Remarque : on retrouve ce mécanisme pour d'autres serveurs (par exemple munin) ou dans la
chaîne de lancement de Linux (voir /etc/rc0.d à /etc/rc6.d qui pointent sur les services stockés
dans /etc/init.d et qui décrivent les services à lancer ou stopper en fonction du runlevel avec
lequel on a démarré Linux).
Pour le moment nous n'allons pas toucher à la configuration fourni par apache2. Conformément
au contenu de /etc/apache2/sites-available/default, on retrouve que les pages mises à
dispositions doivent êtres stockées dans /var/www.
Étape 5 : écrire une page de test
À ce stade, le serveur apache se contente d'envoyer du texte brut au navigateur. Ainsi seuls les
sections de code écrites dans un langage compris par le navigateur (côté client) fonctionneront.
Ceci concerne en particulier le code HTML, CSS, javascript, mais pas PHP.
Par défaut, apache2 dispose d'un site activé comme en témoigne le lien symbolique
/etc/apache2/sites-enabled/000-default. Celui-ci pointe sur /etc/apache2/sites-available/default.
ls -l /etc/apache2/sites-enabled/000-default
Ce fichier consiste à mettre disposition l'arborescence /var/www, comme l'indique la ligne
DocumentRoot renvoyée par la commande suivante :
cat /etc/apache2/sites-available/default
C'est donc dans cette arborescence que l'on doit placer les pages mises à disposition par le
site. Si l'on regarde les droits associés à ce répertoire, seul root peut écrire dans ce répertoire.
A priori un fichier existe déjà (/var/www/index.html). On va le corriger ou le créer s'il n'existe pas
en lançant nano en root.
nano /var/www/index.html
Avec nano on écrit un peu de code html :
<html>
<body>
<h1> Test !</h1>
Et voici des caractères accentués !
</body>
</html>
Testons à présent la page dans un navigateur (par exemple chromium-browser, firefox
(iceweasel), konqueror, evolution...) . Si le navigateur et le serveur apache sont sur la même
machine il suffit de taper dans la barre d'adresse du navigateur, au choix :
http://127.0.0.1/index.html
http://localhost/index.html
Si le navigateur est sur une autre machine que le serveur, il faut saisir le hostname ou l'adresse
IP du serveur à la place de 127.0.0.1 ou de localhost.
Remarques :
L'alias "localhost" est résolu grâce au fichier /etc/hosts.
Si l'on passe au navigateur un nom de page qui n'existe pas, celui-ci affiche une erreur
404. Dans ce cas-là, celle-ci sera retranscrite par défaut dans /var/log/apache2/error.log
(ceci peut être personnalisé dans la configuration spécifique à un site, par exemple
/etc/apache2/sites-available/default).
Si on écrit juste http://localhost ou http://127.0.0.1, le serveur apache2 va chercher si le
fichier index.php existe. Si c'est le cas il va le transmettre au navigateur. Sinon il va
chercher le fichier index.html et le transmettre.
N'oubliez pas de préciser le port si votre serveur apache2 écoute sur un port autre que
le port par défaut (80 pour http et 443 pour https). Par exemple, s'il écoute sur le port
8888 en http, saisissez l'adresse http://127.0.0.1:8888
Si la page s'affiche correctement en local (depuis la machine qui héberge le serveur
apache2) mais pas depuis une autre machine, c'est probablement un pare-feu ou un
proxy situé le long du chemin séparant les deux machine (aller ou retour) qui bloque la
transmission.
Étape 6 : caractères accentués et problèmes d'encodage
Aperçu de plusieurs solutions
Il peut arriver que les caractères accentués s'affichent mal. Dans ce cas, l'encodage est mis en
cause. Si le fichier est écrit dans un certain encodage mais que le navigateur s'attend à en
recevoir un autre, les caractères accentués apparaissent mal. Dans ce cas, plusieurs solutions
sont possibles.
Changer l'encodage au niveau du navigateur (dans firefox/iceweasel : affichage,
encodage des caractères). C'est la plus mauvaise solution car cela force le visiteur à
régler son navigateur spécialement pour le site. De plus ce réglage sera perdu à la
prochaine consultation.
Préciser l'encodage dans l'en-tête du fichier html. Ce n'est pas toujours très pratique
dans la mesure où cela peut nécessiter de corriger de nombreux fichiers html. Par
exemple si le fichier est écrit en UTF8 on peut ajouter au début du fichier <meta
http-equiv="Content-Type" content="text/html; charset=UTF-8"/>.
Le développeur se discipline à utiliser des séquences comme é pour le
caractère 'é' etc...
Forcer l'encodage au niveau du serveur apache. Dans ce cas, le code html n'a pas
besoin d'être modifié. Il suffit que tous les fichiers utilisent le même encodage (par
exemple utf8). C'est la solution que nous allons présenter.
Forcer l'encodage au niveau d'apache2
Cette solution présente plusieurs avantages.
Si l'on force l'encodage utilisé par le système, les pages crées sur cette machine seront
écrites dans cet encodage. Il est dès lors inutile de le préciser au travers d'une balise
meta.
Les fichiers créés sur cette machine seront écrits l'encodage utilisé par défaut sur la
machine. Il sera inutile de le préciser dans ce cas également.
Il est recommandé de lire au préalable l'article sur les locales.
On commence par corriger le fichier /etc/apache2/conf.d/charset. En root :
nano /etc/apache2/conf.d/charset
On corrige ce fichier de sorte à avoir (en décommentant la ligne "AddDefaultCharset UTF-8") :
# Read the documentation before enabling AddDefaultCharset.
# In general, it is only a good idea if you know that all your files
# have this encoding. It will override any encoding given in the files
# in meta http-equiv or xml encoding tags.
AddDefaultCharset UTF-8
On va également corriger le fichier /etc/apache2/envvars en root :
nano /etc/apache2/envvars
Encore une fois, cela consiste simplement à décommenter la ligne ". /etc/default/locale" :
# envvars - default environment variables for apache2ctl
# this won't be correct after changing uid
unset HOME
# for supporting multiple apache2 instances
if [ "$" != "$" ] ; then
SUFFIX="-$"
else
SUFFIX=
fi
# Since there is no sane way to get the parsed apache2 config in scripts, some
# settings are defined via environment variables and then used in apache2ctl,
# /etc/init.d/apache2, /etc/logrotate.d/apache2, etc.
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data
export APACHE_PID_FILE=/var/run/apache2$SUFFIX.pid
export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
# Only /var/log/apache2 is handled by /etc/logrotate.d/apache2.
export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
## The locale used by some modules like mod_dav
export LANG=C
## Uncomment the following line to use the system default locale instead:
. /etc/default/locale
export LANG
## The command to get the status for 'apache2ctl status'.
## Some packages providing 'www-browser' need '--dump' instead of '-dump'.
#export APACHE_LYNX='www-browser -dump'
Comme à chaque fois que l'on modifie ses fichiers de configuration, il faut relancer apache2
pour que les modifications soient prises en compte :
Il ne reste plus qu'à rafraîchir la page au niveau du navigateur pour que tout s'affiche
correctement.
Remarque : si les caractères accentués s'affichent toujours mal, essayez de vider le cache de
votre navigateur. Par exemple, si vous utilisez firefox (iceweasel), cliquez sur "Outils >
Supprimer l'historique récent".
Étape 7 : les droits
Droits UNIX/POSIX
Pour qu'un site soit sécurisé, il faut notamment attribuer aux fichiers mis à disposition des droits
aussi restreints que possible.
A priori le fichier /var/www/index.html, au même titre que n'importe quelle page web accessible
depuis un navigateur web, devrait avoir les droits suivants :
(mando@silk) (~) $ ls -l /var/www/
total 4
-rw-r----- 1 root www-data 142 3 déc. 17:03 index.html
Comme mentionné dans le fichier /etc/apache2/envvars, un client aura au niveau du système
linux les droits de l'utilisateur www-data et du groupe www-data.
Pour des raisons évidentes de sécurité, il faut que ce groupe ait des droits aussi restreints que
possible tout en autorisant l'accès au fichier auxquels un client web peut avoir légitimement
accès :
L'utilisateur propriétaire ne doit pas être www-data. On utilise les droits suivants :
droits en lecture (r) écriture (w) sur les fichiers réguliers,
droits en lecture (r) écriture (w) exécution (x) sur les répertoires.
Le groupe propriétaire doit être www-data :
les droits en lecture (r) sur les fichiers réguliers et répertoires auxquels il est
sensé pouvoir accéder,
aucun droit pour le reste.
Les autres utilisateurs ne sont pas sensés avoir de droits sur ces fichiers.
Remarques :
Afin qu'un client ne puisse par modifier ces droits, on attribue les fichiers de /var/www au
groupe www-data et non à l'utilisateur www-data. C'est la raison pour laquelle les
fichiers présents dans /var/www appartiennent en général à l'utilisateur root.
Il est important que le groupe www-data ait les droits en lecture sur les fichiers que les
internautes doivent pouvoir consulter, sans quoi ils verront s'afficher une page d'erreur
403 (permission denied). Dans ce cas, l'erreur d'accès sera répercutée par défaut dans
/var/log/apache2/error.log (ceci peut être personnalisé dans la configuration spécifique à
un site, par exemple /etc/apache2/sites-available/default).
Il ne faut pas donner de droits en lecture à www-data sur des fichiers sensibles ou des
droits en lecture exécution sur des répertoires sensibles. Typiquement, un utilisateur
n'est pas sensé pouvoir accéder aux fichiers htaccess, htpasswd et htgroup si vous en
utilisez !
Les droits associés à un fichier (répertoire ou non) peuvent être corrigés grâce aux
commandes chgrp et chmod. Notez que les commandes chown et chgrp requièrent des
droits root.
Exemple :
chown root:www-data /var/www/index.html
chmod 640 /var/www/index.html
Il ne reste plus qu'à vérifier que la page s'affiche toujours correctement.
Droits ACL
Si plusieurs personnes sont susceptibles de développer le site, il peut être intéressant d'utiliser
des droits ACL via les commandes getfacl et setfacl. Rappelons que les droits ACL sont
symbolisés par un "+" à droite des droits habituels.
Droits SELinux
On peut durcir ou relâcher la politique d'accès aux fichiers partagés par apache grâce aux
commandes chcon et restorecon fournies par SELinux (Security Enhanced Linux). SELinux
permet par exemple de n'autoriser l'accès à ce fichier que pendant l'exécution d'apache2. Si
une erreur d'accès liée à SELinux survient, celle-ci sera retranscrite dans /var/log/messages.
Étape 8 : corriger l'erreur " Could not reliably determine the
server's fully qualified domain name, using 127.0.1.1 for
ServerName"
Il suffit de rajouter mettre dans le fichier /etc/apache2/httpd.conf :
ServerName localhost
Sécurisation
Introduction
Cette section n'est pas exhaustive mais référence quelques précautions à prendre.
Limiter les droits : il est primordial d'attribuer des droits aussi restreints que possible sur
les fichiers mis à disposition sur une machine. Cet aspect a déjà été abordé dans ce
tutoriel.
Diffuser un minimum d'informations sensibles : un pirate informatique utilise souvent des
exploits qui consistent souvent à tirer parti d'une faille de sécurité dans l'implémentation
d'un logiciel. Souvent ces bugs sont corrigés dans les mises à jours qui suivent et sont
donc spécifique à une version de ce logiciel. C'est pourquoi il est souhaitable de
masquer autant que possible ce genre d'informations lorsque le serveur est accessible
sur Internet. Apache2 propose au niveau de ses fichiers de configuration ce genre de
personnalisations.
Limiter la portée des fichiers auxquel peut accéder un client : un internaute ne devrait
jamais être en mesure de sortir de l'arborescence associé au site (/var/www dans notre
exemple). Si par exemple, il est en mesure d'accéder en dehors de cette arborescence,
il est susceptible d'accéder à des fichiers sensibles comme /etc/passwd et avoir une
idée des logins à attaquer.
Limiter les accès réseaux : On peut également restreindre les machines autorisées à
accéder à apache2, soit directement dans la configuration du serveur apache, soit à
l'aide d'un pare-feu (voire des deux). On pourra utiliser par exemple des outils comme
ufw ou iptables.
Chiffrer les communications grâce à SSL : on pourra se référer à ce tutoriel.
Effectuer un audit de sécurité. En complément, on pourra utiliser des outils comme
nikto, wapiti, w3af...
Diffuser un minimum d'informations sensibles
On corrige le fichier /etc/apache2/conf.d/security de sorte à avoir :
#
# Disable access to the entire file system except for the directories that
# are explicitly allowed later.
#
# This currently breaks the configurations that come with some web application
# Debian packages.
#
#<Directory />
# AllowOverride None
# Order Deny,Allow
# Deny from all
#</Directory>
# Changing the following options will not really affect the security of the
# server, but might make attacks slightly more difficult in some cases.
#
# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of: Full | OS | Minimal | Minor | Major | Prod
# where Full conveys the most information, and Prod the least.
#
#ServerTokens Minimal
#ServerTokens OS
#ServerTokens Full
ServerTokens Prod
#
# Optionally add a line containing the server version and virtual host
# name to server-generated pages (internal error documents, FTP directory
# listings, mod_status and mod_info output etc., but not CGI generated
# documents or custom error documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
# Set to one of: On | Off | EMail
#
ServerSignature Off
#ServerSignature On
#
# Allow TRACE method
#
# Set to "extended" to also reflect the request body (only for testing and
# diagnostic purposes).
#
# Set to one of: On | Off | extended
#
TraceEnable Off
#TraceEnable On
Puis on redémarre apache2 :
Limiter la portée des fichiers auxquel peut accéder un client
Pour chaque site, apache2 parcourt un certain nombre de règles évaluées séquentiellement.
Chaque règle a une portée (indiquant à quelle arborescence elle s'applique). Certaines
relâchent des possibilités, d'autres les contraignent.
1. La première règle évaluée par apache2 devrait consister à limiter l'accès à toute
l'arborescence du système Linux (/).
2. Ensuite, on relâche un minimum de possibilités en fonction des besoins du site.
On peut définir cette première règle directement dans /etc/apache2/conf.d/security en
décommentant la section suivante et en relançant apache :
#<Directory />
# AllowOverride None
# Order Deny,Allow
# Deny from all
#</Directory>
Cependant, comme mentionné dans ce fichier, décommenter cette section peut provoquer un
dysfonctionnement de certaines applications fournies par les paquets Debian. C'est la raison
pour laquelle on va plutôt définir chacune de ces règles en intervenant dans la configuration
spécifique à chaque site (par exemple /etc/apache2/sites-available/default). Afin de garder ce
fichier en exemple, il est temps de créer notre propre fichier :
nano /etc/apache2/sites-available/mon_site
Dedans on met par exemple ceci :
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www
<Directory />
# Accès autorisé si l'IP du client est autorisée (Allow)
# ET pas rejetée (Deny)
Order Deny,Allow
# On limite l'accès à tout le monde
Deny from all
# On n'active aucune option.
Options None
AllowOverride None
</Directory>
<Directory /var/www/>
AllowOverride None
# Accès autorisé si l'IP du client est autorisée (Allow)
# OU pas rejetée (Deny)
Order Allow,Deny
Allow from all
# Désactiver l'option permettant le parcours d'un répertoire
Options -Indexes
# Désactiver l'option permettant apache de suivre des liens
# symboliques (qui pourrait permettre de quitter /var/www)
Options -FollowSymLinks
# Désactiver l'option permettant apache de faire des inclusions
# côté serveur
Options -Includes
# Désactiver l'option permettant à apache l'utilisation de
# scripts CGI (si on n'utilise pas de script CGI !)
Options -ExecCGI
Options MultiViews
</Directory>
# Empêcher le téléchargement des fichiers dont le nom commence
# par ".ht" (.htaccess ...)
AccessFileName .httpdoverride
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
ErrorLog $/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog $/access.log combined
</VirtualHost>
Notez que ce fichier permet de personnaliser :
la position de l'arborescence mise à disposition sur le site,
l'email du webmestre,
le fichier de log dans lequel écrire les erreurs spécifiques à ce site.
Il ne reste plus qu'à désactiver le site "default" au profit du site "mon_site" et relancer apache2.
En root :
a2dissite default
a2ensite mon_site
Restreindre les IP des clients autorisés à se connecter au site
Ceci se règle encore une fois dans le fichier relatif à la configuration du site. Si ce site n'est
sensé être accessible que par la machine sur laquelle le serveur est déployé ou juste par les
machines faisant partie de son réseau locale, une règle devrait le stipuler. De la même manière
on peut blacklister une IP.
nano /etc/apache2/sites-available/mon_site
Il suffit ensuite de corriger cette section de configuration :
<VirtualHost *:80>
...
<Directory /var/www/>
...
Order Allow,Deny
Allow from all
...
</Directory>
</VirtualHost>
Rendre le site uniquement accessible depuis la machine faisant office de serveur apache :
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
Rendre le site visible des machines ayant une IP en 192.168.1.* :
Order Deny,Allow
Deny from all
Allow from 192.168.1.0/24
Blacklister l'IP 11.22.33.44 :
Order Allow,Deny
Allow from all
Deny from 11.22.33.44
Comme d'habitude, pensez à relancer le site une fois ces modifications apportées :
Pour aller plus loin
Vous devriez consulter ce lien pour découvrir quelques attaques classiques et ainsi vous en
prémunir :
http://www.haypocalc.com/wiki/Injection_de_code
Certaines failles sont liées à l'administration du serveur en lui-même, et d'autres sont liées au
code écrit par le développeur web.
Installation d'un module apache2 : illustration avec PHP5
Principe
La démarche reste exactement la même quelque soit le module à installer.
1. installation du module
2. activation du module
3. relancer apache2.
Au niveau des commandes, nous allons illustrer chacune de ces étapes par celle que l'on
taperait sur un système Debian ou dérivé de Debian, respectivement :
1. aptitude install libapache2-mod-....,
2. a2enmod le_nom_du_module
3. service apache2 restart
Pour retrouver les noms de modules disponibles dans le gestionnaire de paquets, il est
recommandé d'avoir installé l'autocomplétion bash. On peut également utiliser la commande
apt-cache pour les distributions basées sur Debian.
Exemple :
apt-cache search libapache2-mod | grep libapache2-mod
Nous allons maintenant détailler ces différentes étapes au travers d'un exemple : PHP5. Nous
en profiterons pour aborder quelques spécificités liées à PHP5.
Étape 1 : installer le paquet PHP5
Comme d'habitude on passe par le gestionnaire de paquets. Sous Debian on tapera en root la
commande :
aptitude install libapache2-mod-php5
Ce paquet casse le MPM worker et engendre l'installation du MPM prefork. Rappelons que le
MPM prefork est moins performant que le MPM worker. Une fois l'installation effectuée on peut
vérifier que php5 est apparu dans /etc/apache2/mod-available. Par contre dans
/etc/apache2/mod-enabled, les liens symboliques qui activent ce module n'est pas forcément
présent :
ls -l /etc/apache2/mods-available/php5*
ls -l /etc/apache2/mods-enabled/php5*
Étape 2 : activer le module
En root, on utilise la commande a2enmod qui crée le couple de lien symbolique php5.conf et
php.load dans /etc/mods-enabled et qui pointent vers les fichiers correspondants dans
/etc/mods-available. On aurait pu créer ces liens avec la commande "ln -s ....".
a2enmod php5
Étape 3 : relancer apache2
En tant que fichiers de configuration, il faut garder à l'esprit que corriger ces liens symboliques
sont vus comme des fichiers de configuration. Ainsi ils ne sont pris en compte qu'au lancement
d'apache2, et il faut donc le relancer. En root :
Étape 4 : tester le module
Créer la page de test
Nous allons repartir du fichier index.html que nous avons créé auparavant. En root :
mv /var/www/index.html /var/www/index.php
nano /var/www/index.php
Note : il est important que l'extension soit .php (ou .php5). Sinon apache2 ne cherchera pas à
interpréter le php.
Corrigeons ce fichier de sorte à avoir :
<html>
<body>
<h1> Test !</h1>
<?php
echo "La date du jour est " . date("d/m/Y") . "!\n";
?>
</body>
</html>
Il ne reste plus qu'à tester : http://localhost/index.php
Si la page ne s'affiche pas
Si au lieu de voir la page s'afficher, le navigateur propose de télécharger index.php, il faut
corriger /etc/apache2/httpd.conf en root :
nano /etc/apache2/httpd.conf
On met dedans :
<IfModule mod_mime.c>
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .php5
AddLanguage ca .ca
AddLanguage cs .cz .cs
AddLanguage da .dk
AddLanguage de .de
AddLanguage el .el
AddLanguage en .en
AddLanguage eo .eo
AddLanguage es .es
AddLanguage et .et
AddLanguage fr .fr
AddLanguage he .he
AddLanguage hr .hr
AddLanguage it .it
AddLanguage ja .ja
AddLanguage ko .ko
AddLanguage ltz .ltz
AddLanguage nl .nl
AddLanguage nn .nn
AddLanguage no .no
AddLanguage pl .po
AddLanguage pt .pt
AddLanguage pt-BR .pt-br
AddLanguage ru .ru
AddLanguage sv .sv
AddLanguage zh-CN .zh-cn
AddLanguage zh-TW .zh-tw
</IfModule>
Note : on aurait pu ajouter ceci à la fin de /etc/apache2/apache2.conf.
Comme la configuration a été modifiée, on relance apache2 :
... et on teste à nouveau (avec le bouton rafraîchir par exemple) : http://localhost/index.php
Étape 5 : optimisation du serveur apache2
Introduction
Si l'on utilise du PHP, il est recommandé d'installer xcache, eaccelerator ou APC (Alternative
PHP cache). Ces outils permettent de compiler au préalable le code PHP et d'augmenter
sensiblement les performances. On peut retrouver un comparatif des performances des
différents accélérateur PHP ici.
Nous allons parler ici de xcache qui est disponible sous forme d'un paquet debian, simple à
mettre en place et très performant. Selon le benchmark évoqué ci-dessus, ses performances
sont meilleures que celle proposées par APC et comparable à celle de eaccelerator qui n'est
pas disponible sous forme de paquet debian.
xcache
Installation
On installe le paquet xcache :
aptitude install php5-xcache
Configuration
Pour profiter au maximum xcache, on va avoir besoin de récupérer le nombre de
microprocesseurs disponibles sur la machine :
grep -c processor /proc/cpuinfo
On corrige ensuite la configuration de xcache :
nano /etc/php5/apache2/conf.d/xcache.ini
On peut notamment :
corriger la valeur la valeur xcache.count (nombre de microprocesseurs + 1), comme
suggéré ici,
augmenter la taille du cache xcache.size,
et régler de nombreux autres paramètres (voir ici).
Une fois les corrections apportées, on relance apache2 :
Test
Corrigeons le fichier /var/www/index.php de sorte à avoir :
<html>
<body>
<h1> Test !</h1>
<?php
phpinfo();
?>
</body>
</html>
Il ne reste plus qu'à rafraîchir la page dans le navigateur. Si xcache est actif, alors "xcache.ini"
devrait apparaître dans le tableau d'information fourni par apache2.
Activer les messages d'erreur PHP
Sur un serveur servant de plateforme de développement, il est pratique d'afficher les erreurs
PHP afin de détecter les erreurs de syntaxe etc... Pour ce faire, il faut corriger la configuration
du module PHP. En root :
nano /etc/apache2/mods-available/php5.conf
Dans ce fichier, on ajoute la ligne "php_value display_errors on" :
<IfModule mod_php5.c>
php_value display_errors on
<FilesMatch "\.ph(p3?|tml)$">
SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch "\.phps$">
SetHandler application/x-httpd-php-source
</FilesMatch>
# To re-enable php in user directories comment the following lines
# (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
# prevents .htaccess files from disabling it.
<IfModule mod_userdir.c>
<Directory /home/*/public_html>
php_admin_value engine Off
</Directory>
</IfModule>
</IfModule>
Enfin, on n'oublie pas de relancer le serveur apache pour que cette modification des fichiers de
configuration soit prise en compte :
Installer MySQL
Ici nous allons nous en tenir à une installation "basique" de MySQL (pas de réplication et pas de
proxy MySQL). L'installation de base est suffisante si la base n'est pas très importante.
Sous Debian , il suffit d'installer les paquets suivants :
aptitude install mysql-server php5-mysql
Pour aller plus loin
Pour aller plus loin dans la configuration d'apache, on pourra se référer à ce site :
http://www.system-linux.eu/index.php?category/Apache2
.
Powered by TCPDF (www.tcpdf.org)

Mettre en place un serveur web (apache2)

Transcription

Documents pareils

TUTORIEL : SERVEUR WEB ET VIRTUALHOST

7. Web Server and Browser

TP: Sécurisation d`un serveur WEB

Tutoriel Apache

TP 02: Installation et configuration de serveur web apache

Demander un CIF

(Coagul - Installation

A6 - Apache

Ecran d`accueil du CD d`installation Debian

Installer un domaine (sur Debian - Etch)