Sécuriser Apache le minimum à savoir


-  Sécurisation par défaut
Pour sécurisé apache, un bon moyen consiste à définir une politique sécuritaire stricte par défaut. Pour cela il faut modifier de la manière suivante :

Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all Order deny,allow Deny from all

-  ServerTokens
Syntaxe : ServerTokens Minimal|ProductOnly|OS|Full
Défaut : ServerTokens Full
Positionner : ProductOnly

Cette directive contrôle si le champ Server de l’en-tête de réponse qui est renvoyé aux clients inclut une description du type de système de du serveur ainsi que des informations sur les modules compilés. Cette directive s’applique à la globalité du serveur et ne paut pas être activé ou désactivé sur la base d’hôtes virtuels.

ServerTokens Prod[uctOnly]
Le serveur renvoie par exemple : Server : Apache
ServerTokens Min[imal]
Le serveur renvoie par exemple : Server : Apache/1.3.0
ServerTokens OS
Le serveur renvoie par exemple : Server : Apache/1.3.0 (Unix)
ServerTokens Full (ou non spécifié)
Le serveur renvoie par exemple : Server : Apache/1.3.0 (Unix) PHP/3.0 MyMod/1.2

-  ServerSignature
Syntaxe : ServerSignature On|Off|EMail
Défaut : ServerSignature Off
Positionner : Off

La directive ServerSignature permet la configuration d’une ligne de bas de page pour les documents générés par le serveur (messages d’erreur, liste des répertoire ftp, affichage de mod_info, ...) L’utilité de l’emploi d’une telle ligne apparaît dans la cas d’enchaînement de proxy, où l’utilisateuir so uvent n’a aucune possibilité de déterminer quel élément de la chaîne de proxies a produit un message d’erreur.

-  ErrorDocument
Syntaxe : ErrorDocument code d’erreur document

Dans la mesure où l’on veut sécuriser le serveur web, il faut que celui-ci soit le moins bavard possible. Il est donc préconisé d’utiliser un texte simple ou une page HTML si vous vouler que cela soit plus estétique.

Dans l’éventualité d’un problème ou d’une erreur, Apache peut exécuter l’une des quatre actions suivantes :

  1. sortie d’un message d’erreur simple standard
  2. sortie d’un message personnalisé
  3. redirection vers une URL locale pour traiter le problème (ou l’erreur)
  4. redirection vers une URL externe pour traiter le problème (ou l’erreur)

La première option est celle par défaut, les options 2 à 4 seront obtenues en utilisant la directive ErrorDocument, suivi du code HTTP d’erreur et du message textuel d’erreur, ou une URL.

Messages dans ce contexte, commence par un guillemet simple ("), qui ne fait pas partie du message lui-même. Apache ajoutera souvent des informations complémentaires explicitant le problème (ou l’erreur).

L’URL peut débuter par un slash (/) pour des URL locales, ou être complètement qualifiées. Exemples :

ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today

Notez que lorsque vous spécifiez un ErrorDocument qui pointe vers une URL externe (c’est -à-dire toute adresse commençant par quelque chose du style "http:") Apache émettra une requête de redirection au client pour lui indiquer où trouver le document. Ceci peut perturber les robots et d’autres clients qui essaient de déterminer si une URL est valide en testant le code retour de la requête. De plus, si vous utilisez l’écriture ErrorDocument 401 le client ne saura pas qu’il doit demander un mot de passe puisqu’il ne recevra pas le code retour 401. Par conséquent, il est impératif d’utiliser une URL locale pour une directive "ErrorDocument 401". Ceci est induit par la nature des schémas d’authentification de base d’HTTP.

Copyright 2000-2009 BUCHARD@comwebmaster le 15.08.2002