Aller au contenu
Vie du geek le forum entre geek
Phobos

Mettre en place un serveur web (apache2)

Messages recommandés

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.

 

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.27Apache

 

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 :

 

 

1.<html>    
2.<body>    
3.<h1> Test !</h1>
4.Et voici des caractères accentués !
5.</body>    
6.</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 &eacute; 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") :

 

 

1.# Read the documentation before enabling AddDefaultCharset.
2.# In general, it is only a good idea if you know that all your files
3.# have this encoding. It will override any encoding given in the files
4.# in meta http-equiv or xml encoding tags.
5. 
6.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" :

 

 

 

01.# envvars - default environment variables for apache2ctl
02. 
03.# this won't be correct after changing uid
04.unset HOME
05. 
06.# for supporting multiple apache2 instances
07.if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
08.SUFFIX="-${APACHE_CONFDIR##/etc/apache2-}"
09.else
10.SUFFIX=
11.fi
12. 
13.# Since there is no sane way to get the parsed apache2 config in scripts, some
14.# settings are defined via environment variables and then used in apache2ctl,
15.# /etc/init.d/apache2, /etc/logrotate.d/apache2, etc.
16.export APACHE_RUN_USER=www-data
17.export APACHE_RUN_GROUP=www-data
18.export APACHE_PID_FILE=/var/run/apache2$SUFFIX.pid
19.export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
20.export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
21.# Only /var/log/apache2 is handled by /etc/logrotate.d/apache2.
22.export APACHE_LOG_DIR=/var/log/apache2$SUFFIX
23. 
24.## The locale used by some modules like mod_dav
25.export LANG=C
26.## Uncomment the following line to use the system default locale instead:
27.. /etc/default/locale
28. 
29.export LANG
30. 
31.## The command to get the status for 'apache2ctl status'.
32.## Some packages providing 'www-browser' need '--dump' instead of '-dump'.
33.#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 :
 

service apache2 restart


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 ® écriture (w) sur les fichiers réguliers,
    • droits en lecture ® écriture (w) exécution (x) sur les répertoires.
  • Le groupe propriétaire doit être www-data :
    • les droits en lecture ® 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 etsetfacl. 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 :

 

1.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 ouiptables.
  • 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 :

 

 

01.#
02.# Disable access to the entire file system except for the directories that
03.# are explicitly allowed later.
04.#
05.# This currently breaks the configurations that come with some web application
06.# Debian packages.
07.#
08.#<Directory />
09.#    AllowOverride None
10.#    Order Deny,Allow
11.#    Deny from all
12.#</Directory>
13. 
14. 
15.# Changing the following options will not really affect the security of the
16.# server, but might make attacks slightly more difficult in some cases.
17. 
18.#
19.# ServerTokens
20.# This directive configures what you return as the Server HTTP response
21.# Header. The default is 'Full' which sends information about the OS-Type
22.# and compiled in modules.
23.# Set to one of:  Full | OS | Minimal | Minor | Major | Prod
24.# where Full conveys the most information, and Prod the least.
25.#
26.#ServerTokens Minimal
27.#ServerTokens OS
28.#ServerTokens Full
29.ServerTokens Prod
30. 
31.#
32.# Optionally add a line containing the server version and virtual host
33.# name to server-generated pages (internal error documents, FTP directory
34.# listings, mod_status and mod_info output etc., but not CGI generated
35.# documents or custom error documents).
36.# Set to "EMail" to also include a mailto: link to the ServerAdmin.
37.# Set to one of:  On | Off | EMail
38.#
39.ServerSignature Off
40.#ServerSignature On
41. 
42.#
43.# Allow TRACE method
44.#
45.# Set to "extended" to also reflect the request body (only for testing and
46.# diagnostic purposes).
47.#
48.# Set to one of:  On | Off | extended
49.#
50.TraceEnable Off
51.#TraceEnable On

 

 

Puis on redémarre apache2 :

 

service apache2 restart

 

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 :

 

 

1.#<Directory />
2.#    AllowOverride None
3.#    Order Deny,Allow
4.#    Deny from all
5.#</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 :

 

 

01.&lt;VirtualHost *:80&gt;
02.ServerAdmin webmaster@localhost
03. 
04.DocumentRoot /var/www
05.&lt;Directory /&gt;
06.# Accès autorisé si l'IP du client est autorisée (Allow)
07.# ET pas rejetée (Deny)
08.Order Deny,Allow
09. 
10.# On limite l'accès à tout le monde
11.Deny from all
12. 
13.# On n'active aucune option.
14.Options None
15. 
16.AllowOverride None
17.&lt;/Directory&gt;
18.&lt;Directory /var/www/&gt;
19.AllowOverride None
20. 
21.# Accès autorisé si l'IP du client est autorisée (Allow)
22.# OU pas rejetée (Deny)
23.Order Allow,Deny
24.Allow from all
25. 
26.# Désactiver l'option permettant le parcours d'un répertoire
27.Options -Indexes
28. 
29.# Désactiver l'option permettant apache de suivre des liens
30.# symboliques (qui pourrait permettre de quitter /var/www)
31.Options -FollowSymLinks
32. 
33.# Désactiver l'option permettant apache de faire des inclusions
34.# côté serveur
35.Options -Includes
36. 
37.# Désactiver l'option permettant à apache l'utilisation de
38.# scripts CGI (si on n'utilise pas de script CGI !)
39.Options -ExecCGI
40. 
41.Options MultiViews
42.&lt;/Directory&gt;
43. 
44.# Empêcher le téléchargement des fichiers dont le nom commence
45.# par ".ht" (.htaccess ...)
46.AccessFileName .httpdoverride
47.&lt;Files ~ "^.ht"&gt;
48.Order allow,deny
49.Deny from all
50.Satisfy All
51.&lt;/Files&gt;
52. 
53.ErrorLog ${APACHE_LOG_DIR}/error.log
54. 
55.# Possible values include: debug, info, notice, warn, error, crit,
56.# alert, emerg.
57.LogLevel warn
58. 
59.CustomLog ${APACHE_LOG_DIR}/access.log combined
60.&lt;/VirtualHost&gt;

 

 

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

service apache2 reload

 

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 :

 

 

01.&lt;VirtualHost *:80&gt;
02....
03.&lt;Directory /var/www/&gt;
04....
05.Order Allow,Deny
06.Allow from all
07....
08.&lt;/Directory&gt;
09.&lt;/VirtualHost&gt;

 

 

Rendre le site uniquement accessible depuis la machine faisant office de serveur apache :

 

 

1.Order Deny,Allow
2.Deny from all
3.Allow from 127.0.0.1

 

 

Rendre le site visible des machines ayant une IP en 192.168.1.* :

 

 

1.Order Deny,Allow
2.Deny from all
3.Allow from 192.168.1.0/24

 

 

Blacklister l'IP 11.22.33.44 :

 

 

1.Order Allow,Deny
2.Allow from all
3.Deny from 11.22.33.44

 

 

Comme d'habitude, pensez à relancer le site une fois ces modifications apportées :

 

service apache2 reload

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant

×