1 <?xml version="1.0" encoding="ISO-8859-1"?>
2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head><!--
4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
5 This file is generated from xml source: DO NOT EDIT
6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
8 <title>Conseils sur la sécurité - Serveur Apache HTTP</title>
9 <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
10 <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
11 <link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="../style/css/prettify.css" />
12 <script src="../style/scripts/prettify.js" type="text/javascript">
15 <link href="../images/favicon.ico" rel="shortcut icon" /></head>
16 <body id="manual-page"><div id="page-header">
17 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
18 <p class="apache">Serveur Apache HTTP Version 2.5</p>
19 <img alt="" src="../images/feather.gif" /></div>
20 <div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
22 <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.5</a> > <a href="./">Documentations diverses</a></div><div id="page-content"><div id="preamble"><h1>Conseils sur la sécurité</h1>
24 <p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English"> en </a> |
25 <a href="../fr/misc/security_tips.html" title="Français"> fr </a> |
26 <a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
27 <a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
30 <p>Ce document propose quelques conseils et astuces concernant les
31 problèmes de sécurité liés
32 à l'installation d'un serveur web. Certaines suggestions seront à caractère
33 général, tandis que d'autres seront spécifiques à Apache.</p>
35 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#uptodate">Maintenez votre serveur à jour</a></li>
36 <li><img alt="" src="../images/down.gif" /> <a href="#dos">Attaques de type "Déni de service"
37 (Denial of Service - DoS)</a></li>
38 <li><img alt="" src="../images/down.gif" /> <a href="#serverroot">Permissions sur les répertoires de la racine du serveur</a></li>
39 <li><img alt="" src="../images/down.gif" /> <a href="#ssi">Inclusions côté serveur</a></li>
40 <li><img alt="" src="../images/down.gif" /> <a href="#cgi">Les CGI en général</a></li>
41 <li><img alt="" src="../images/down.gif" /> <a href="#nsaliasedcgi">CGI sans alias de script</a></li>
42 <li><img alt="" src="../images/down.gif" /> <a href="#saliasedcgi">CGI avec alias de script</a></li>
43 <li><img alt="" src="../images/down.gif" /> <a href="#dynamic">Autres sources de contenu dynamique</a></li>
44 <li><img alt="" src="../images/down.gif" /> <a href="#systemsettings">Protection de la configuration du système</a></li>
45 <li><img alt="" src="../images/down.gif" /> <a href="#protectserverfiles">Protection par défaut des fichiers du serveur</a></li>
46 <li><img alt="" src="../images/down.gif" /> <a href="#watchyourlogs">Surveillez vos journaux</a></li>
47 <li><img alt="" src="../images/down.gif" /> <a href="#merging">Fusion des sections de configuration</a></li>
48 </ul><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
49 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
51 <h2><a name="uptodate" id="uptodate">Maintenez votre serveur à jour</a></h2>
53 <p>Le serveur HTTP Apache a une bonne réputation en matière de sécurité
54 et possède une communauté de développeurs très sensibilisés aux problèmes
55 de sécurité. Mais il est inévitable de trouver certains problèmes
56 -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour
57 cette raison qu'il est crucial de se tenir informé des mises à jour. Si
58 vous avez obtenu votre version du serveur HTTP directement depuis Apache,
59 nous vous conseillons grandement de vous abonner à la <a href="http://httpd.apache.org/lists.html#http-announce">Liste de diffusion
60 des annonces du serveur HTTP</a> qui vous informera de
61 la parution des nouvelles versions et des mises à jour de sécurité. La
62 plupart des distributeurs tiers d'Apache fournissent des services
65 <p>Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le
66 code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes
67 proviennent plutôt de code ajouté, de scripts CGI, ou du système
68 d'exploitation sous-jacent. Vous devez donc vous tenir informé des
69 problèmes et mises à jour concernant tous les logiciels présents sur
72 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
74 <h2><a name="dos" id="dos">Attaques de type "Déni de service"
75 (Denial of Service - DoS)</a></h2>
79 <p>Tous les services réseau peuvent faire l'objet d'attaques de type
80 "Déni de service" qui tentent de les empêcher de répondre aux clients en
81 saturant leurs ressources. Il est impossible de se prémunir totalement
82 contre ce type d'attaques, mais vous pouvez accomplir certaines actions
83 afin de minimiser les problèmes qu'elles créent.</p>
85 <p>Souvent, l'outil anti-DoS le plus efficace sera constitué par le
86 pare-feu ou certaines configurations du système d'exploitation. Par
87 exemple, la plupart des pare-feu peuvent être configurés de façon à
88 limiter le nombre de connexions simultanées depuis une adresse IP ou un
89 réseau, ce qui permet de prévenir toute une gamme d'attaques simples.
90 Bien sûr, ceci n'est d'aucun secours contre les attaques de type
91 "Déni de service" distribuées (DDoS).</p>
93 <p>Certains réglages de la configuration d'Apache peuvent aussi
94 minimiser les problèmes :</p>
97 <li>La directive <code class="directive"><a href="../mod/mod_reqtimeout.html#requestreadtimeout">RequestReadTimeout</a></code> permet de
98 limiter le temps que met le client pour envoyer sa requête.</li>
100 <li>La valeur de la directive
101 <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code> doit être diminuée sur les
102 sites sujets aux attaques DoS. Une valeur de quelques secondes devrait
103 convenir. Cependant, comme <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code>
104 est actuellement concerné par de nombreuses opérations différentes, lui
105 attribuer une valeur trop faible peut provoquer des problèmes avec les
106 scripts CGI qui présentent un long temps de réponse.</li>
108 <li>La valeur de la directive
109 <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> doit aussi être
110 diminuée sur les sites sujets aux attaques DoS. Certains sites
111 désactivent même complètement le "maintien en vie" (keepalives)
112 à l'aide de la directive
113 <code class="directive"><a href="../mod/core.html#keepalive">KeepAlive</a></code>, ce qui bien sûr
114 présente des inconvénients en matière de performances.</li>
116 <li>Les valeurs des différentes directives fournies par d'autres modules
117 et en rapport avec des délais doivent aussi être vérifiées.</li>
120 <code class="directive"><a href="../mod/core.html#limitrequestbody">LimitRequestBody</a></code>,
121 <code class="directive"><a href="../mod/core.html#limitrequestfields">LimitRequestFields</a></code>,
122 <code class="directive"><a href="../mod/core.html#limitrequestfieldsize">LimitRequestFieldSize</a></code>,
123 <code class="directive"><a href="../mod/core.html#limitrequestline">LimitRequestLine</a></code>, et
124 <code class="directive"><a href="../mod/core.html#limitxmlrequestbody">LimitXMLRequestBody</a></code> doivent être
125 configurées avec prudence afin de limiter la consommation de ressources
126 induite par les demandes des clients.
129 <li>Sur les systèmes d'exploitation qui le supportent, assurez-vous que
130 la directive <code class="directive"><a href="../mod/core.html#acceptfilter">AcceptFilter</a></code> est
131 activée afin de déléguer une partie du traitement des requêtes au
132 système d'exploitation. Elle est activée par défaut dans le démon httpd
133 d'Apache, mais peut nécessiter une reconfiguration de votre noyau.</li>
135 <li>Optimisez la directive <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> de façon à définir le nombre
136 maximum de connexions simultanées au dessus duquel les ressources
137 s'épuisent. Voir aussi la <a href="perf-tuning.html">documentation sur l'optimisation des
138 performances</a>.</li>
140 <li>L'utilisation d'un <a href="../mpm.html">module mpm</a> threadé
141 vous permet de traiter d'avantage de connexions simultanées, ce qui
142 minimise l'effet des attaques DoS. Dans le futur, le module mpm
143 <code class="module"><a href="../mod/event.html">event</a></code> utilisera un traitement asynchrone afin de ne pas
144 dédier un thread à chaque connexion. De par la
145 nature de la bibliothèque OpenSSL, le module mpm <code class="module"><a href="../mod/event.html">event</a></code> est actuellement incompatible
146 avec le module <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> ainsi que d'autres filtres
147 en entrée. Dans ces cas, son comportement se ramène à celui
148 du module mpm <code class="module"><a href="../mod/worker.html">worker</a></code>.</li>
150 <li>Il existe de nombreux modules tiers disponibles à <a href="http://modules.apache.org/">http://modules.apache.org/</a> qui
151 peuvent retreindre les comportements de certains clients et ainsi
152 minimiser les problèmes de DoS.</li>
156 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
157 <div class="section">
158 <h2><a name="serverroot" id="serverroot">Permissions sur les répertoires de la racine du serveur</a></h2>
162 <p>Typiquement, Apache est démarré par l'utilisateur root, puis il devient
163 la propriété de l'utilisateur défini par la directive <code class="directive"><a href="../mod/mod_unixd.html#user">User</a></code> afin de répondre aux demandes. Comme
164 pour toutes les commandes exécutées par root, vous devez vous assurer
165 qu'elle n'est pas modifiable par les utilisateurs autres que root. Les
166 fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne
167 doivent être modifiables que par root. Par exemple, si vous avez choisi de
168 placer la racine du serveur dans <code>/usr/local/apache</code>, il est conseillé de
169 créer le répertoire en tant que root, avec des commandes du style :</p>
171 <div class="example"><p><code>
172 mkdir /usr/local/apache <br />
173 cd /usr/local/apache <br />
174 mkdir bin conf logs <br />
175 chown 0 . bin conf logs <br />
176 chgrp 0 . bin conf logs <br />
177 chmod 755 . bin conf logs
180 <p>Nous supposerons que <code>/</code>, <code>/usr</code> et
181 <code>/usr/local</code> ne sont modifiables que par
182 root. Quand vous installez l'exécutable <code class="program"><a href="../programs/httpd.html">httpd</a></code>, vous
183 devez vous assurer qu'il possède des protections similaires :</p>
185 <div class="example"><p><code>
186 cp httpd /usr/local/apache/bin <br />
187 chown 0 /usr/local/apache/bin/httpd <br />
188 chgrp 0 /usr/local/apache/bin/httpd <br />
189 chmod 511 /usr/local/apache/bin/httpd
192 <p>Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres
193 utilisateurs -- car root ne crée ni exécute aucun fichier dans ce
196 <p>Si vous permettez à des utilisateurs non root de modifier des fichiers
197 que root écrit ou exécute, vous exposez votre système à une compromission
198 de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire
199 <code class="program"><a href="../programs/httpd.html">httpd</a></code> de façon à ce que la prochaine fois que vous le
200 redémarrerez, il exécutera un code arbitraire. Si le répertoire des
201 journaux a les droits en écriture (pour un utilisateur non root), quelqu'un
202 pourrait remplacer un fichier journal par un lien symbolique vers un autre
203 fichier système, et root pourrait alors écraser ce fichier avec des données
204 arbitraires. Si les fichiers journaux eux-mêmes ont des droits en
205 écriture (pour un utilisateur non root), quelqu'un pourrait
206 modifier les journaux eux-mêmes avec des données fausses.</p>
208 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
209 <div class="section">
210 <h2><a name="ssi" id="ssi">Inclusions côté serveur</a></h2>
214 <p>Les inclusions côté serveur (Server Side Includes - SSI) exposent
215 l'administrateur du serveur à de nombreux risques potentiels en matière de
218 <p>Le premier risque est l'augmentation de la charge du serveur. Tous les
219 fichiers où SSI est activé doivent être analysés par Apache, qu'ils
220 contiennent des directives SSI ou non. L'augmentation de la charge induite
221 est minime, mais peut devenir significative dans le contexte d'un
224 <p>Les fichiers SSI présentent les mêmes risques que les scripts CGI en
225 général. Les fichiers où SSI est activé peuvent exécuter tout script CGI
226 ou autre programme à l'aide de la commande <code>"exec cmd"</code> avec les permissions
227 des utilisateur et groupe sous lesquels Apache s'exécute, comme défini
228 dans <code>httpd.conf</code>.</p>
230 <p>Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout
231 en tirant parti des bénéfices qu'ils apportent.</p>
233 <p>Pour limiter les dommages qu'un fichier SSI agressif pourrait causer,
234 l'administrateur du serveur peut activer<a href="../suexec.html">suexec</a>
235 comme décrit dans la section <a href="#cgi">Les CGI en général</a>.</p>
237 <p>L'activation des SSI pour des fichiers possédant des extensions
238 <code>.html</code> ou
239 <code>.htm</code> peut s'avérer dangereux. Ceci est particulièrement vrai dans un
240 environnement de serveur partagé ou étant le siège d'un traffic élevé. Les
241 fichiers où SSI est activé doivent posséder une extension spécifique, telle
242 que la conventionnelle <code>.shtml</code>. Ceci permet de limiter la charge du serveur
243 à un niveau minimum et de simplifier la gestion des risques.</p>
245 <p>Une autre solution consiste à interdire l'exécution de scripts et
246 programmes à partir de pages SSI. Pour ce faire, remplacez
247 <code>Includes</code> par <code>IncludesNOEXEC</code> dans la directive
248 <code class="directive"><a href="../mod/core.html#options">Options</a></code>. Notez que les utilisateurs
249 pourront encore utiliser <code><--#include virtual="..." --></code> pour exécuter
250 des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
252 <code class="directive"><a href="../mod/mod_alias.html#scriptalias">ScriptAlias</a></code>.</p>
254 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
255 <div class="section">
256 <h2><a name="cgi" id="cgi">Les CGI en général</a></h2>
260 <p>Tout d'abord, vous devez toujours garder à l'esprit que vous devez
261 faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à
262 vos compétences pour déceler les trous de sécurité potentiels dans les
263 CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent
264 essentiellement exécuter des commandes arbitraires sur votre système avec
265 les droits de l'utilisateur du serveur web, et peuvent par conséquent être
266 extrèmement dangereux s'ils ne sont pas vérifiés avec soin.</p>
268 <p>Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent
269 donc entrer en conflit (accidentellement ou délibérément) avec d'autres
270 scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc
271 un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez
272 utiliser le programme <a href="../suexec.html">suEXEC</a> pour faire en
273 sorte que les scripts s'exécutent sous des utilisateurs différents. Ce
274 programme est inclus dans la distribution d'Apache depuis la version 1.2
275 et est appelé à partir de certaines portions de code du serveur Apache. Une
276 autre méthode plus connue est l'utilisation de
277 <a href="http://cgiwrap.sourceforge.net/">CGIWrap</a>.</p>
279 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
280 <div class="section">
281 <h2><a name="nsaliasedcgi" id="nsaliasedcgi">CGI sans alias de script</a></h2>
285 <p>Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI
286 depuis n'importe quel répertoire que dans l'éventualité où :</p>
289 <li>Vous faites confiance à vos utilisateurs pour ne pas écrire de
290 scripts qui vont délibérément ou accidentellement exposer votre
291 système à une attaque.</li>
292 <li>Vous estimez que le niveau de sécurité dans les autres parties de
293 votre site est si faible qu'un trou de sécurité de plus ou de moins
294 n'est pas très important.</li>
295 <li>Votre système ne comporte aucun utilisateur, et personne ne visite
296 jamais votre site.</li>
299 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
300 <div class="section">
301 <h2><a name="saliasedcgi" id="saliasedcgi">CGI avec alias de script</a></h2>
305 <p>Le confinement des CGI dans des répertoires spécifiques permet à
306 l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci
307 est bien entendu mieux sécurisé que les CGI sans alias de script, mais
308 seulement à condition que les utilisateurs avec les droits en écriture sur
309 les répertoires soient dignes de confiance, et que l'administrateur ait la
310 volonté de tester chaque programme ou script CGI à la recherche d'éventuels
311 trous de sécurité.</p>
313 <p>La plupart des sites choisissent cette approche au détriment des CGI
314 sans alias de script.</p>
316 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
317 <div class="section">
318 <h2><a name="dynamic" id="dynamic">Autres sources de contenu dynamique</a></h2>
323 Les options de scripting intégrées qui s'exécutent en tant que partie du
324 serveur lui-même, comme <code>mod_php</code>, <code>mod_perl</code>,
325 <code>mod_tcl</code>, et <code>mod_python</code>,
326 s'exécutent sous le même utilisateur que le serveur (voir la directive
327 <code class="directive"><a href="../mod/mod_unixd.html#user">User</a></code>), et par conséquent,
328 les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources
329 que le serveur. Certains moteurs de scripting peuvent proposer des
330 restrictions, mais pour plus de sûreté, il vaut mieux partir du principe
331 que ce n'est pas le cas.</p>
333 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
334 <div class="section">
335 <h2><a name="systemsettings" id="systemsettings">Protection de la configuration du système</a></h2>
339 <p>Pour contrôler étroitement votre serveur, vous pouvez interdire
340 l'utilisation des fichiers <code>.htaccess</code> qui permettent de
341 passer outre les fonctionnalités de sécurité que vous avez configurées.
342 Voici un moyen pour y parvenir :</p>
344 <p>Ajoutez dans le fichier de configuration du serveur</p>
346 <pre class="prettyprint lang-config">
353 <p>Ceci interdit l'utilisation des fichiers <code>.htaccess</code> dans
354 tous les répertoires, sauf ceux pour lesquels c'est explicitement
357 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
358 <div class="section">
359 <h2><a name="protectserverfiles" id="protectserverfiles">Protection par défaut des fichiers du serveur</a></h2>
363 <p>Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal
364 compris. C'est à dire que, à moins que vous ne changiez explicitement ce
365 comportement, si le serveur trouve son chemin vers un fichier en suivant
366 les règles normales de correspondance URL - fichier, il peut le retourner
369 <p>Considérons l'exemple suivant :</p>
371 <div class="example"><p><code>
372 # cd /; ln -s / public_html <br />
373 puis accès à <code>http://localhost/~root/</code>
376 <p>Ceci permettrait aux clients de parcourir l'ensemble du système de
377 fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration
378 de votre serveur :</p>
380 <pre class="prettyprint lang-config">
388 <p>ceci va interdire l'accès par défaut à tous les fichiers du système de
389 fichiers. Vous devrez ensuite ajouter les blocs
390 <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> appropriés correspondant
391 aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,</p>
393 <pre class="prettyprint lang-config">
394 <Directory /usr/users/*/public_html>
398 <Directory /usr/local/httpd>
405 <p>Portez une attention particulière aux interactions entre les directives
406 <code class="directive"><a href="../mod/core.html#location">Location</a></code> et
407 <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> ; par exemple, si une
408 directive <code><Directory /></code> interdit un accès, une
409 directive <code><Location /></code> pourra passer outre.</p>
411 <p>De même, soyez méfiant en jouant avec la directive
412 <code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code> ; la positionner à
413 <code>"./"</code> aurait le même effet, pour root, que le premier exemple plus haut.
414 Nous vous conseillons
415 fortement d'inclure la ligne suivante dans le fichier de configuration de
418 <pre class="prettyprint lang-config">UserDir disabled root</pre>
421 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
422 <div class="section">
423 <h2><a name="watchyourlogs" id="watchyourlogs">Surveillez vos journaux</a></h2>
427 <p>Pour vous tenir informé de ce qui se passe réellement dans votre
428 serveur, vous devez consulter vos
429 <a href="../logs.html">fichiers journaux</a>. Même si les fichiers journaux
430 ne consignent que des évènements qui se sont déjà produits, ils vous
431 informeront sur la nature des attaques qui sont lancées contre le serveur
432 et vous permettront de vérifier si le niveau de sécurité nécessaire est
435 <p>Quelques exemples :</p>
437 <div class="example"><p><code>
438 grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br />
439 grep "client denied" error_log | tail -n 10
442 <p>Le premier exemple listera les attaques essayant d'exploiter la
443 <a href="http://online.securityfocus.com/bid/4876/info/">vulnérabilité
444 d'Apache Tomcat pouvant provoquer la divulgation d'informations par des
445 requêtes Source.JSP mal formées</a>, le second donnera la liste des dix
446 dernières interdictions client ; par exemple :</p>
448 <div class="example"><p><code>
449 [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
450 by server configuration: /usr/local/apache/htdocs/.htpasswd
453 <p>Comme vous le voyez, les fichiers journaux ne consignent que ce qui
454 s'est déjà produit ; ainsi, si le client a pu accéder au fichier
455 <code>.htpasswd</code>, vous devriez avoir quelque chose du style :</p>
457 <div class="example"><p><code>
458 foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
461 <p>dans votre <a href="../logs.html#accesslog">journal des accès</a> ; ce
462 qui signifie que vous avez probablement mis en commentaire ce qui suit dans
463 le fichier de configuration de votre serveur :</p>
465 <pre class="prettyprint lang-config">
473 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
474 <div class="section">
475 <h2><a name="merging" id="merging">Fusion des sections de configuration</a></h2>
479 <p>La fusion des sections de configuration est complexe et dépend
480 souvent des directives utilisées. Vous devez systématiquement tester
481 vos modifications pour vérifier la manière dont les directives sont
484 <p>Concernant les modules qui n'implémentent aucune logique de
485 fusion, comme <code class="directive">mod_access_compat</code>, le
486 comportement des sections suivantes est tributaire de la présence
487 dans ces dernières de directives appartenant à ces modules. La
488 configuration est héritée jusqu'à ce qu'une modification soit
489 effectuée ; à ce moment, la configuration est <em>remplacée</em> et
492 <div class="bottomlang">
493 <p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English"> en </a> |
494 <a href="../fr/misc/security_tips.html" title="Français"> fr </a> |
495 <a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
496 <a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
497 </div><div class="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Commentaires</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
498 <script type="text/javascript"><!--//--><![CDATA[//><!--
499 var comments_shortname = 'httpd';
500 var comments_identifier = 'http://httpd.apache.org/docs/trunk/misc/security_tips.html';
502 if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
503 d.write('<div id="comments_thread"><\/div>');
504 var s = d.createElement('script');
505 s.type = 'text/javascript';
507 s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
508 (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
511 d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
513 })(window, document);
514 //--><!]]></script></div><div id="footer">
515 <p class="apache">Copyright 2012 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
516 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!--
517 if (typeof(prettyPrint) !== 'undefined') {