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).