Serveur Apache HTTP Version 2.3
Serveur Apache HTTP Version 2.3
Cette page pourrait se résumer ainsi : configurez le serveur HTTP Apache de façon à ce qu'il n'ait pas besoin de résolution DNS pour interpréter les fichiers de configuration. Si httpd doit effectuer des résolutions DNS pour interpréter les fichiers de configuration, votre serveur pourra présenter des problèmes de fiabilité (en d'autres termes, il est possible qu'il refuse de démarrer), ou d'attaques par déni ou usurpation de service (y compris le détournement d'informations utilisateurs).
# Cet exemple de configuration est invalide, ne l'utilisez pas comme base
# de configuration
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Pour fonctionner correctement, le serveur a absolument besoin de deux
informations à propos de chaque serveur virtuel : le nom du serveur
défini par la directive ServerName, et au moins une adresse IP à
laquelle le serveur va se rattacher et répondre. L'exemple ci-dessus
ne comporte pas d'adresse IP, si bien que httpd devra utiliser le
DNS pour trouver l'adresse IP de www.abc.dom. Si pour
une raison quelconque, le DNS n'est pas disponible au moment où
votre serveur interprète son fichier de configuration, ce serveur
virtuel ne sera pas pris en compte dans la
configuration. Il sera incapable de
répondre à toute requête pour ce serveur virtuel (avec les versions
de httpd antérieures à 1.2, le serveur ne démarrera tout simplement
pas).
Supposons que l'adresse de www.abc.dom soit
192.0.2.1, et examinons cet extrait de configuration :
# Cet exemple de configuration est invalide, ne l'utilisez pas comme base
# de configuration
<VirtualHost 192.0.2.1>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Cette fois, httpd doit effectuer une recherche DNS inverse pour
trouver le nom ServerName de ce serveur virtuel. Si
cette recherche inverse échoue, le serveur virtuel sera
partiellement désactivé. Si le serveur
virtuel est à base de nom, il sera en fait totalement désactivé,
mais s'il est à base d'adresse IP, il fonctionnera probablement.
Cependant, httpd échouera s'il doit générer une URL complète pour
le serveur qui inclut ce nom de serveur.
Voici un extrait de configuration qui permet d'éviter ces deux types de problèmes :
<VirtualHost 192.0.2.1>
ServerName www.abc.dom
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
Il existe (au moins) deux formes possibles de déni de service. Si
vous utilisez une version de httpd antérieure à 1.2, votre serveur
ne démarrera pas si une des deux recherches DNS mentionnées
ci-dessus échoue pour au moins un de vos serveurs virtuels. Dans
certains cas, cette recherche DNS ne sera même pas sous votre
contrôle ; par exemple, si abc.dom est un de vos
clients et s'il gère son propre DNS, il peut empêcher votre
serveur (pre-1.2) de démarrer, simplement en supprimant
l'enregistrement www.abc.dom.
La deuxième forme de déni de service est beaucoup plus subtile. Examinons cet extrait de configuration :
<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 vous avez assigné 192.0.2.1 à
www.abc.dom et 192.0.2.2 à www.def.dom. En
outre, supposons que def.dom gère son propre DNS. Avec
cette configuration, def.dom sera en mesure de
détourner tout trafic destiné à abc.dom. Pour y
parvenir, tout ce qu'ils ont à faire consiste à assigner 192.0.2.1 à
www.def.dom. Comme ils gèrent leur propre DNS, vous ne
pouvez pas les empêcher de faire pointer l'enregistrement
www.def.dom vers l'adresse qu'ils veulent.
Les requêtes à destination de 192.0.2.1 (y compris toutes celles
où l'utilisateur à tapé une URL de la forme
http://www.abc.dom/quelquepart), seront toutes servies
par le serveur virtuel def.dom. Une meilleur
compréhension de la raison pour laquelle ceci peut se produire
nécessite une discussion plus approfondie à propos de la manière
dont httpd associe les requêtes entrantes aux différents serveurs
virtuels qui vont les servir. Un document de base décrivant ceci est disponible.
Le support des
serveurs virtuels à base de nom oblige httpd à
connaître la/les adresse(s) IP de l'hôte sur
lequel httpd s'exécute. Pour obtenir cette
adresse, soit il utilise la directive ServerName globale (si elle est présente),
soit il fait appel à la fonction C gethostname (qui
doit renvoyer le même nom que la commande shell "hostname"). Il
effectue ensuite une recherche DNS sur cette adresse. Pour le
moment, il n'existe aucun moyen d'éviter cette recherche DNS.
Si vous craignez que cette recherche DNS échoue parce que votre
serveur DNS est arrêté, vous pouvez insérer le nom d'hôte dans le
fichier /etc/hosts (où il est probablement déjà
enregistré afin que la machine démarre correctement). Assurez-vous
ensuite que la machine est configurée pour utiliser
/etc/hosts dans le cas où la recherche DNS échoue.
Suivant le système d'exploitation que vous utilisez, vous y
parviendrez en éditant /etc/resolv.conf, ou
/etc/nsswitch.conf.
Si votre serveur n'a aucune autre raison d'effectuer des
recherches DNS, vous pouvez définir la variable d'environnement
HOSTRESORDER à "local", et vous serez alors en mesure
d'exécuter httpd. Tout dépend du système d'exploitation et des
bibliothèques de résolution de noms que vous utilisez. Elle affecte
aussi les programmes CGI, à moins que vous n'utilisiez
mod_env pour contrôler l'environnement. Il est
conseillé de consulter les pages de manuel ou les FAQs de votre
système d'exploitation.
VirtualHost
Listen
ServerName explicite
<VirtualHost
_default_:*> qui n'a aucune page à servirLa situation concernant le DNS apparaît clairement comme non souhaitable. Bien que nous ayons fait en sorte que le serveur puisse au moins démarrer en cas d'échec de recherche DNS, ce n'est pas ce que nous pouvons faire de mieux. En tout état de cause, le fait de devoir spécifier des adresses IP explicites dans les fichiers de configuration est fortement non souhaitable avec l'Internet d'aujourd'hui où les changements de numérotation sont une nécessité.
Il est possible d'éviter les attaques par usurpation de service décrites ci-dessus en effectuant une recherche DNS inverse sur l'adresse IP renvoyée par la recherche DNS directe et en comparant les deux noms -- en cas de non correspondance, le serveur virtuel serait désactivé. Ceci nécessite cependant une configuration correcte du DNS inverse (ce avec quoi les administrateurs sont familiers à cause de l'utilisation courante des doubles recherches DNS inverses par les serveurs FTP et les TCP wrappers).
En tout état de cause, il ne semble pas envisageable de démarrer de manière fiable un serveur web avec serveurs virtuels losqu'une recherche DNS a échoué, sauf si l'on utilise des adresses IP. Les solutions partielles consistant à désactiver des portions de configuration pourraient s'avérer pires que ne pas démarrer du tout ; tout dépend de ce que le serveur est supposé faire.
Au fur et à mesure du déploiement de HTTP/1.1, et comme les
navigateurs et les mandataires commencent à générer l'en-tête
Host, il devient possible d'envisager de se passer
complètement des serveurs virtuels à base d'adresses IP. Dans ce
cas, un serveur web n'a besoin d'aucune recherche DNS pendant
l'interprétation de ses fichiers de configuration. Cependant, au
mois de mars 1997, ces fonctionnalités n'ont pas été assez largement
déployées pour être utilisées sur des serveurs web critiques.