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