granicus.if.org Git - apache/blob - docs/manual/misc/security_tips.html.fr

   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
   7       -->
   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">
  13 </script>
  14
  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="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div>
  21 <div id="path">
  22 <a href="http://www.apache.org/">Apache</a> &gt; <a href="http://httpd.apache.org/">Serveur HTTP</a> &gt; <a href="http://httpd.apache.org/docs/">Documentation</a> &gt; <a href="../">Version 2.5</a> &gt; <a href="./">Documentations diverses</a></div><div id="page-content"><div id="preamble"><h1>Conseils sur la sécurité</h1>
  23 <div class="toplang">
  24 <p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
  25 <a href="../fr/misc/security_tips.html" title="Français">&nbsp;fr&nbsp;</a> |
  26 <a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
  27 <a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="Türkçe">&nbsp;tr&nbsp;</a></p>
  28 </div>
  29
  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>
  34   </div>
  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>
  50 <div class="section">
  51 <h2><a name="uptodate" id="uptodate">Maintenez votre serveur à jour</a></h2>
  52
  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
  63     similaires.</p>
  64
  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
  70     votre système.</p>
  71
  72   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
  73 <div class="section">
  74 <h2><a name="dos" id="dos">Attaques de type "Déni de service"
  75     (Denial of Service - DoS)</a></h2>
  76
  77
  78
  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>
  84
  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>
  92
  93     <p>Certains réglages de la configuration d'Apache peuvent aussi
  94     minimiser les problèmes :</p>
  95
  96     <ul>
  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>
  99
 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>
 107
 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>
 115
 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>
 118
 119       <li>Les directives
 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.
 127       </li>
 128
 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>
 134
 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>
 139
 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>
 149
 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>
 153
 154     </ul>
 155
 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>
 159
 160
 161
 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>
 170
 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
 178     </code></p></div>
 179
 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>
 184
 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
 190     </code></p></div>
 191
 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
 194     sous-répertoire.</p>
 195
 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>
 207
 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>
 211
 212
 213
 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
 216     sécurité.</p>
 217
 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
 222     serveur partagé.</p>
 223
 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>
 229
 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>
 232
 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>
 236
 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>
 244
 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>&lt;--#include virtual="..." --&gt;</code> pour exécuter
 250     des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
 251     par une directive
 252     <code class="directive"><a href="../mod/mod_alias.html#scriptalias">ScriptAlias</a></code>.</p>
 253
 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>
 257
 258
 259
 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>
 267
 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>
 278
 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>
 282
 283
 284
 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>
 287
 288     <ul>
 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>
 297     </ul>
 298
 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>
 302
 303
 304
 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>
 312
 313     <p>La plupart des sites choisissent cette approche au détriment des CGI
 314     sans alias de script.</p>
 315
 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>
 319
 320
 321
 322   <p>
 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>
 332
 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>
 336
 337
 338
 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>
 343
 344     <p>Ajoutez dans le fichier de configuration du serveur</p>
 345
 346     <pre class="prettyprint lang-config">
 347 &lt;Directory /&gt;
 348     AllowOverride None
 349 &lt;/Directory&gt;
 350     </pre>
 351
 352
 353     <p>Ceci interdit l'utilisation des fichiers <code>.htaccess</code> dans
 354     tous les répertoires, sauf ceux pour lesquels c'est explicitement
 355     autorisé.</p>
 356
 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>
 360
 361
 362
 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
 367     aux clients.</p>
 368
 369     <p>Considérons l'exemple suivant :</p>
 370
 371     <div class="example"><p><code>
 372       # cd /; ln -s / public_html <br />
 373       puis accès à <code>http://localhost/~root/</code>
 374     </code></p></div>
 375
 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>
 379
 380     <pre class="prettyprint lang-config">
 381 &lt;Directory /&gt;
 382     Order Deny,Allow
 383     Deny from all
 384 &lt;/Directory&gt;
 385     </pre>
 386
 387
 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>
 392
 393     <pre class="prettyprint lang-config">
 394 &lt;Directory /usr/users/*/public_html&gt;
 395     Order Deny,Allow
 396     Allow from all
 397 &lt;/Directory&gt;
 398 &lt;Directory /usr/local/httpd&gt;
 399     Order Deny,Allow
 400     Allow from all
 401 &lt;/Directory&gt;
 402     </pre>
 403
 404
 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>&lt;Directory /&gt;</code> interdit un accès, une
 409     directive <code>&lt;Location /&gt;</code> pourra passer outre.</p>
 410
 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
 416     votre serveur :</p>
 417
 418     <pre class="prettyprint lang-config">UserDir disabled root</pre>
 419
 420
 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>
 424
 425
 426
 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
 433     atteint.</p>
 434
 435     <p>Quelques exemples :</p>
 436
 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
 440     </code></p></div>
 441
 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>
 447
 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
 451     </code></p></div>
 452
 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>
 456
 457     <div class="example"><p><code>
 458       foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
 459     </code></p></div>
 460
 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>
 464
 465     <pre class="prettyprint lang-config">
 466 &lt;Files ".ht*"&gt;
 467     Order allow,deny
 468     Deny from all
 469 &lt;/Files&gt;
 470     </pre>
 471
 472
 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>
 476
 477
 478
 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
 482     fusionnées.</p>
 483
 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
 490     non fusionnée.</p>
 491   </div></div>
 492 <div class="bottomlang">
 493 <p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
 494 <a href="../fr/misc/security_tips.html" title="Français">&nbsp;fr&nbsp;</a> |
 495 <a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
 496 <a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="Türkçe">&nbsp;tr&nbsp;</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&amp;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';
 501 (function(w, d) {
 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';
 506         s.async = true;
 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);
 509     }
 510     else {
 511         d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
 512     }
 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') {
 518     prettyPrint();
 519 }
 520 //--><!]]></script>
 521 </body></html>