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 :
- sortie d’un message d’erreur simple standard
- sortie d’un message personnalisé
- redirection vers une URL locale pour traiter le problème (ou l’erreur)
- 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. |