Problèmes DNS avec Apache

Langues Disponibles: en | + es | + fr | + ja | + ko | + tr

+ +

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

Un exemple simple
Déni de Service
L'Adresse du "serveur principal"
Comment éviter ces problèmes
Appendice: Perspectives futures

Un exemple simple

+ + +

+ <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> +

Déni de Service

+ + +

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'Adresse du "serveur principal"

+ + +

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.

Comment éviter ces problèmes

+ + +

+ spécifier les adresses IP dans les + VirtualHost +
+ spécifier les adresses IP au moyen de + Listen +
+ s'assurer que tous les serveurs virtuels spécifient explicitement + leur ServerName +
créer un serveur virtuel <VirtualHost _default_:*> + qui ne sert aucune page

Appendice: Perspectives futures

+ + +

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