<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
-<!-- English Revision : 924467 -->
+<!-- English Revision : 1332626 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
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).</p>
+ usurpation de service (y compris l'attribution de requêtes à un
+ serveur virtuel autre que le serveur virtuel voulu).</p>
</summary>
<section id="example">
<title>Un exemple simple</title>
- <example>
- # Cet exemple de configuration est invalide, ne l'utilisez pas comme base
- # de configuration
- <VirtualHost www.abc.dom> <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
- </VirtualHost>
- </example>
+ <highlight language="config">
+# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
+# de configuration
+<VirtualHost www.example.dom>
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
+</VirtualHost>
+ </highlight>
<p>Pour fonctionner correctement, le serveur a absolument besoin de deux
informations à propos de chaque serveur virtuel : le nom du serveur
module="core">ServerName</directive>, 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 <code>www.abc.dom</code>. Si pour
+ DNS pour trouver l'adresse IP de <code>www.example.dom</code>. 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 <strong>ne sera pas pris en compte dans la
configuration</strong>. 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).</p>
+ répondre à toute requête pour ce serveur virtuel.</p>
- <p>Supposons que l'adresse de <code>www.abc.dom</code> soit
+ <p>Supposons que l'adresse de <code>www.example.dom</code> soit
192.0.2.1, et examinons cet extrait de configuration :</p>
- <example>
- # Cet exemple de configuration est invalide, ne l'utilisez pas comme base
- # de configuration
- <VirtualHost 192.0.2.1> <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
- </VirtualHost>
- </example>
+ <highlight language="config">
+# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
+# de configuration
+<VirtualHost 192.0.2.1>
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
+</VirtualHost>
+ </highlight>
<p>Cette fois, httpd doit effectuer une recherche DNS inverse pour
trouver le nom <code>ServerName</code> de ce serveur virtuel. Si
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.</p>
+ le serveur qui inclut ce nom de serveur (comme dans le cas d'une
+ redirection).</p>
<p>Voici un extrait de configuration qui permet d'éviter ces deux
types de problèmes :</p>
- <example>
- <VirtualHost 192.0.2.1> <br />
- ServerName www.abc.dom <br />
- ServerAdmin webgirl@abc.dom <br />
- DocumentRoot /www/abc <br />
- </VirtualHost>
- </example>
+ <highlight language="config">
+<VirtualHost 192.0.2.1>
+ ServerName www.example.dom
+ ServerAdmin webgirl@example.dom
+ DocumentRoot /www/example
+</VirtualHost>
+ </highlight>
</section>
<section id="denial">
<title>Déni de service</title>
- <p>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 <code>abc.dom</code> 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 <code>www.abc.dom</code>.</p>
-
- <p>La deuxième forme de déni de service est beaucoup plus subtile.
- Examinons cet extrait de configuration :</p>
-
- <example>
- <VirtualHost www.abc.dom><br />
- <indent>
- ServerAdmin webgirl@abc.dom<br />
- DocumentRoot /www/abc<br />
- </indent>
- </VirtualHost><br />
- <br />
- <VirtualHost www.def.dom><br />
- <indent>
- ServerAdmin webguy@def.dom<br />
- DocumentRoot /www/def<br />
- </indent>
- </VirtualHost>
- </example>
-
- <p>Supposons que vous avez assigné 192.0.2.1 à
- <code>www.abc.dom</code> et 192.0.2.2 à <code>www.def.dom</code>. En
- outre, supposons que <code>def.dom</code> gère son propre DNS. Avec
- cette configuration, <code>def.dom</code> sera en mesure de
- détourner tout trafic destiné à <code>abc.dom</code>. Pour y
- parvenir, tout ce qu'ils ont à faire consiste à assigner 192.0.2.1 à
- <code>www.def.dom</code>. Comme ils gèrent leur propre DNS, vous ne
+ <p>Considérons cet extrait de configuration :</p>
+
+ <highlight language="config">
+<VirtualHost www.example1.dom>
+ ServerAdmin webgirl@example1.dom
+ DocumentRoot /www/example1
+</VirtualHost>
+<VirtualHost www.example2.dom>
+ ServerAdmin webguy@example2.dom
+ DocumentRoot /www/example2
+</VirtualHost>
+ </highlight>
+
+ <p>Supposons que vous ayez assigné 192.0.2.1 à
+ <code>www.example1.dom</code> et 192.0.2.2 à <code>www.example2.dom</code>. En
+ outre, supposons que <code>example1.dom</code> gère son propre DNS. Avec
+ cette configuration, <code>example1.dom</code> sera en mesure de
+ détourner tout trafic destiné à <code>example2.dom</code>. Pour y
+ parvenir, tout ce qu'ils ont à faire consiste à
+ assigner 192.0.2.2 à
+ <code>www.example1.dom</code>. Comme ils gèrent leur propre DNS, vous ne
pouvez pas les empêcher de faire pointer l'enregistrement
- <code>www.def.dom</code> vers l'adresse qu'ils veulent.</p>
+ <code>www.example1.dom</code> vers l'adresse qu'ils veulent.</p>
- <p>Les requêtes à destination de 192.0.2.1 (y compris toutes celles
+ <p>Les requêtes à destination de 192.0.2.2 (y compris toutes celles
où l'utilisateur à tapé une URL de la forme
- <code>http://www.abc.dom/quelquepart</code>), seront toutes servies
- par le serveur virtuel <code>def.dom</code>. Une meilleur
+ <code>http://www.example2.dom/quelquepart</code>), seront toutes servies
+ par le serveur virtuel <code>example1.dom</code>. 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
</ul>
</section>
- <section id="appendix">
- <title>Appendice : orientations pour le futur</title>
-
- <p>La 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é.</p>
-
- <p>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).</p>
-
- <p>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.</p>
-
- <p>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
- <code>Host</code>, 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.</p>
- </section>
</manualpage>
projects / apache / blobdiff