Serveur Apache HTTP Version 2.0
Serveur Apache HTTP Version 2.0
L'ensemble de cette page pourrait se r�sumer � la phrase : ne jamais configurer Apache de telle sorte qu'il s'appuie sur des r�solutions DNS pour parcourir ses fichiers de configuration. Une telle configuration risque d'engendrer des probl�mes de fiabilit� (le serveur peut ne pas d�marrer), des attaques de type d�ni et de vol de service (comme par exemple des utilisateurs volant les hits d'autres utilisateurs).
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Pour qu'Apache fonctionne correctement, il a absolument besoin
de deux informations pour chacun de ses serveurs virtuels :
ServerName ainsi qu'au moins une
adresse IP � laquelle le serveur s'attachera pour r�pondre.
L'exemple ci-dessus ne pr�cise pas l'adresse IP, si bien qu'Apache doit
utiliser le DNS pour trouver l'adresse de www.abc.dom.
Si, pour une raison ou une autre, le DNS ne fonctionne pas au moment
o� Apache lit ses fichiers de configuration, le serveur virtuel
ne sera pas configur�. Il sera incapable de r�pondre
aux requ�tes. Jusqu'� la version 1.2, Apache refusait m�me de
d�marrer dans ce cas de figure.
Prenons le cas o� l'adresse de www.abc.dom est 10.0.0.1
et consid�rons cet extrait de configuration :
<VirtualHost 10.0.0.1>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Cette fois, Apache a besoin d'utiliser la r�solution DNS
invers�e pour d�terminer le nom ServerName de ce
serveur virtuel. Si cette r�solution n'aboutit pas, le serveur
virtuel sera partiellement mis hors service (jusqu'� la version
1.2, Apache refusait m�me de d�marrer dans ce cas de figure). Si
le serveur virtuel est un serveur bas� sur un nom (name-based),
il sera totalement hors service, mais s'il s'agit d'un serveur
par IP (IP-based), il fonctionnera correctement. Cependant, dans
le cas o� Apache doit g�n�rer une adresse compl�te URL en
s'appuyant sur le nom du serveur, il �chouera � fournir une
adresse valide.
Voici un extrait de configuration qui r�sout ces deux probl�mes :
<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Il existe (au moins) deux probl�mes possibles de d�ni de service.
Les versions d'Apache ant�rieures � 1.2 ne d�marreront pas si
l'une des deux requ�tes DNS cit�es ci-dessus n'aboutissent pas pour
un de vos serveurs virtuels. Dans certains cas, les entr�es DNS
sont hors de contr�le de l'administrateur Web ; par exemple si
abc.dom appartient � un de vos clients qui a la
ma�trise de son propre DNS, celui-ci peut emp�cher votre serveur
Web (avant la version 1.2) de d�marrer, simplement en effa�ant
l'enregistrement www.abc.dom du DNS.
L'autre probl�me possible est bien plus pernicieux. Dans la configuration suivante :
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
<VirtualHost www.def.dom>
ServerAdmin webguy@def.dom
DocumentRoot /www/def
</VirtualHost>
Supposons que www.abc.dom ait l'adresse 10.0.0.1,
et que www.def.dom ait l'adresse 10.0.0.2. Supposons
�galement que def.com ait la main sur son DNS.
Cette configuration peut permettre � def.dom de
d�tourner vers son serveur tout le trafic destin� �
abc.dom. Pour ce faire, il doit simplement
positionner le champ DNS de www.def.dom sur 10.0.0.1,
et rien ne peut l'emp�cher de faire, puisqu'il a la main sur
son DNS.
Les requ�tes � destination de 10.0.0.1 (incluant celles dont
l'URL contient http://www.abc.com/tout_et_n_importe_quoi)
seront envoy�es au serveur virtuel de def.dom. Une
bonne compr�hension des m�canismes internes d'Apache concernant
la gestion des serveur virtuels est requise.
Ce document explique ce
fonctionnement.
L'impl�mentation du support des serveur virtuels par nom depuis Apache 1.1 suppose
qu'Apache connaisse la ou les adresse(s) IP sur lesquelles le serveur
�coute. Pour d�terminer cette adresse, Apache utilise soit la
directive globale ServerName
(si elle est pr�sente), soit un appel � la fonction C
gethostname (cet appel renvoie le m�me r�sultat
que la commande "hostname" entr�e sur une ligne de commande).
Une r�solution DNS est alors effectu�e sur l'adresse obtenue.
Pour l'instant, il n'existe aucun moyen de contourner cette
requ�te DNS.
Pour se pr�munir du cas o� cette r�solution DNS �chouerait �
cause de la d�faillance du serveur DNS, le nom d'h�te peut �tre
ajout� dans /etc/hosts (il y est probablement d�j�).
Assurez vous que votre machine est configur�e pour lire ce fichier
/etc/hosts en cas de d�faillance du serveur DNS.
Pour cela, selon votre syst�me d'exploitation, il vous faudra configurer
/etc/resolv.conf ou /etc/nsswitch.conf.
Au cas o� votre serveur n'a pas besoin de r�aliser des requ�tes
DNS pour d'autres raisons que de d�marrer Apache, il est possible
que vous puissiez vous en sortir en positionnant la variable
d'environnement HOSTRESORDER sur "local". Ceci d�pend
cependant de votre syst�me d'exploitation et des librairies de
r�solution DNS que vous utilisez. Ceci affecte �galement le
comportement des scripts CGIs, � moins que vous n'utilisiez
mod_env pour contr�ler leur environnement. La
meilleure solution est de consulter les pages "man" ou les FAQs
sp�cifiques � votre syst�me d'exploitation.
VirtualHost
Listen
ServerName
<VirtualHost _default_:*>
qui ne sert aucune pageLes probl�mes li�s au DNS sont tr�s ind�sirables. � partir d'Apache 1.2, nous avons travaill� � ce qu'Apache d�marre m�me dans le cas o� les requ�tes DNS �chouent, mais ce n'est pas forc�ment la meilleure des solutions. En tous cas, obliger l'administrateur � sp�cifier explicitement des adresses IP est �galement tr�s ind�sirable sur le r�seau Internet tel qu'il existe actuellement, o� le nombre d'adresses IP commence � manquer.
Une r�ponse possible au probl�me de vol de trafic d�crit ci-avant pourrait �tre de r�aliser une r�solution inverse DNS sur l'adresse IP renvoy�e par la premi�re requ�te, et de comparer les deux noms obtenus -- lorsqu'ils sont diff�rents, le serveur virtuel serait d�sactiv�. Ceci suppose que la configuration pour la r�solution inverse DNS soit faite correctement (c'est une chose � laquelle les administrateurs DNS commencent � s'habituer, en raison de l'utilisation de plus en plus r�pandue des requ�tes DNS "double-reverse" par les serveurs FTP et les filtrages "TCP wrappers").
Dans tous les cas de figures, il ne semble pas possible de d�marrer de fa�on fiable un serveur virtuel quand la requ�te DNS a �chou�, � moins de recourir � l'utilisation d'adresses IP fixes. Des solutions partielles, telles que d�sactiver des portions de la configuration selon les t�ches attribu�es au serveur Web, risquent d'�tre pires que ne pas d�marrer du tout.
Au fur et � mesure que HTTP/1.1 se r�pand, et que les navigateurs
et les serveurs mandataires envoient l'en-t�te Host,
il devient possible d'�viter compl�tement l'utilisation de serveurs
virtuels par IP. Dans ce cas, les serveurs Web n'ont plus aucun
besoin de r�aliser des requ�tes DNS lors de leur d�marrage. Au 1er
mars 1997, ces fonctionnalit�s ne sont pas suffisamment d�ploy�es pour
que des serveurs Web sensibles les mettent en oeuvre (NdT : cette
remarque est aujourd'hui compl�tement d�pass�e, HTTP/1.1 est
d�sormais support� par l'immense majorit� des navigateurs et
des serveurs mandataires).