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" />
  12 <link href="../images/favicon.ico" rel="shortcut icon" /></head>
  13 <body id="manual-page"><div id="page-header">
  14 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
  15 <p class="apache">Serveur Apache HTTP Version 2.3</p>
  16 <img alt="" src="../images/feather.gif" /></div>
  17 <div class="up"><a href="./"><img title="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div>
  18 <div id="path">
  19 <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.3</a> &gt; <a href="./">Documentations diverses</a></div><div id="page-content"><div id="preamble"><h1>Conseils sur la sécurité</h1>
  20 <div class="toplang">
  21 <p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
  22 <a href="../fr/misc/security_tips.html" title="Français">&nbsp;fr&nbsp;</a> |
  23 <a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
  24 <a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="Türkçe">&nbsp;tr&nbsp;</a></p>
  25 </div>
  26
  27     <p>Ce document propose quelques conseils et astuces concernant les
  28     problèmes de sécurité liés
  29     à l'installation d'un serveur web. Certaines suggestions seront à caractère
  30     général, tandis que d'autres seront spécifiques à Apache.</p>
  31   </div>
  32 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#uptodate">Maintenez votre serveur à jour</a></li>
  33 <li><img alt="" src="../images/down.gif" /> <a href="#dos">Attaques de type "Déni de service"
  34     (Denial of Service - DoS)</a></li>
  35 <li><img alt="" src="../images/down.gif" /> <a href="#serverroot">Permissions sur les répertoires de la racine du serveur</a></li>
  36 <li><img alt="" src="../images/down.gif" /> <a href="#ssi">Inclusions côté serveur</a></li>
  37 <li><img alt="" src="../images/down.gif" /> <a href="#cgi">Les CGI en général</a></li>
  38 <li><img alt="" src="../images/down.gif" /> <a href="#nsaliasedcgi">CGI sans alias de script</a></li>
  39 <li><img alt="" src="../images/down.gif" /> <a href="#saliasedcgi">CGI avec alias de script</a></li>
  40 <li><img alt="" src="../images/down.gif" /> <a href="#dynamic">Autres sources de contenu dynamique</a></li>
  41 <li><img alt="" src="../images/down.gif" /> <a href="#systemsettings">Protection de la configuration du système</a></li>
  42 <li><img alt="" src="../images/down.gif" /> <a href="#protectserverfiles">Protection par défaut des fichiers du serveur</a></li>
  43 <li><img alt="" src="../images/down.gif" /> <a href="#watchyourlogs">Surveillez vos journaux</a></li>
  44 </ul></div>
  45 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
  46 <div class="section">
  47 <h2><a name="uptodate" id="uptodate">Maintenez votre serveur à jour</a></h2>
  48
  49     <p>Le serveur HTTP Apache a une bonne réputation en matière de sécurité
  50     et possède une communauté de développeurs très sensibilisés aux problèmes
  51     de sécurité. Mais il est inévitable de trouver certains problèmes
  52     -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour
  53     cette raison qu'il est crucial de se tenir informé des mises à jour. Si
  54     vous avez obtenu votre version du serveur HTTP directement depuis Apache,
  55     nous vous conseillons grandement de vous abonner à la <a href="http://httpd.apache.org/lists.html#http-announce">Liste de diffusion
  56     des annonces du serveur HTTP</a> qui vous informera de
  57     la parution des nouvelles versions et des mises à jour de sécurité. La
  58     plupart des distributeurs tiers d'Apache fournissent des services
  59     similaires.</p>
  60
  61     <p>Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le
  62     code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes
  63     proviennent plutôt de code ajouté, de scripts CGI, ou du système
  64     d'exploitation sous-jacent. Vous devez donc vous tenir informé des
  65     problèmes et mises à jour concernant tous les logiciels présents sur
  66     votre système.</p>
  67
  68   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
  69 <div class="section">
  70 <h2><a name="dos" id="dos">Attaques de type "Déni de service"
  71     (Denial of Service - DoS)</a></h2>
  72
  73
  74
  75     <p>Tous les services réseau peuvent faire l'objet d'attaques de type
  76     "Déni de service" qui tentent de les empêcher de répondre aux clients en
  77     saturant leurs ressources. Il est impossible de se prémunir totalement
  78     contre ce type d'attaques, mais vous pouvez accomplir certaines actions
  79     afin de minimiser les problèmes qu'elles créent.</p>
  80
  81     <p>Souvent, l'outil anti-DoS le plus efficace sera constitué par le
  82     pare-feu ou certaines configurations du système d'exploitation. Par
  83     exemple, la plupart des pare-feu peuvent être configurés de façon à
  84     limiter le nombre de connexions simultanées depuis une adresse IP ou un
  85     réseau, ce qui permet de prévenir toute une gamme d'attaques simples.
  86     Bien sûr, ceci n'est d'aucun secours contre les attaques de type
  87     "Déni de service" distribuées (DDoS).</p>
  88
  89     <p>Certains réglages de la configuration d'Apache peuvent aussi
  90     minimiser les problèmes :</p>
  91
  92     <ul>
  93       <li>La valeur de la directive
  94       <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code> doit être diminuée sur les
  95       sites sujets aux attaques DoS. Une valeur de quelques secondes devrait
  96       convenir. Cependant, comme <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code>
  97       est actuellement concerné par de nombreuses opérations différentes, lui
  98       attribuer une valeur trop faible peut provoquer des problèmes avec les
  99       scripts CGI qui présentent un long temps de réponse.</li>
 100
 101       <li>La valeur de la directive
 102       <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> doit aussi être
 103       diminuée sur les sites sujets aux attaques DoS. Certains sites
 104       désactivent même complètement le "maintien en vie" (keepalives)
 105       à l'aide de la directive
 106       <code class="directive"><a href="../mod/core.html#keepalive">KeepAlive</a></code>, ce qui bien sûr
 107       présente des inconvénients en matière de performances.</li>
 108
 109       <li>Les valeurs des différentes directives fournies par d'autres modules
 110       et en rapport avec des délais doivent aussi être vérifiées.</li>
 111
 112       <li>Les directives
 113       <code class="directive"><a href="../mod/core.html#limitrequestbody">LimitRequestBody</a></code>,
 114       <code class="directive"><a href="../mod/core.html#limitrequestfields">LimitRequestFields</a></code>,
 115       <code class="directive"><a href="../mod/core.html#limitrequestfieldsize">LimitRequestFieldSize</a></code>,
 116       <code class="directive"><a href="../mod/core.html#limitrequestline">LimitRequestLine</a></code>, et
 117       <code class="directive"><a href="../mod/core.html#limitxmlrequestbody">LimitXMLRequestBody</a></code> doivent être
 118       configurées avec prudence afin de limiter la consommation de ressources
 119       induite par les demandes des clients.
 120       </li>
 121
 122       <li>Sur les systèmes d'exploitation qui le supportent, assurez-vous que
 123       la directive <code class="directive"><a href="../mod/core.html#acceptfilter">AcceptFilter</a></code> est
 124       activée afin de déléguer une partie du traitement des requêtes au
 125       système d'exploitation. Elle est activée par défaut dans le démon httpd
 126       d'Apache, mais peut nécessiter une reconfiguration de votre noyau.</li>
 127
 128       <li>Optimisez la directive <code class="directive"><a href="../mod/mpm_common.html#maxclients">MaxClients</a></code> de façon à définir le nombre
 129       maximum de connexions simultanées au dessus duquel les ressources
 130       s'épuisent. Voir aussi la <a href="perf-tuning.html">documentation sur l'optimisation des
 131       performances</a>.</li>
 132
 133       <li>L'utilisation d'un <a href="../mpm.html">module mpm</a> threadé
 134       vous permet de traiter d'avantage de connexions simultanées, ce qui
 135       minimise l'effet des attaques DoS. Dans le futur, le module mpm expérimental
 136       <code class="module"><a href="../mod/event.html">event</a></code> utilisera un traitement asynchrone afin de ne pas
 137       dédier un thread à chaque connexion. Il est en cours d'étude à
 138       l'heure actuelle et n'est pas encore entièrement implémenté. En
 139       particulier, le mpm <code class="module"><a href="../mod/event.html">event</a></code> est actuellement incompatible
 140       avec le module <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> ainsi que d'autres filtres
 141       en entrée.</li>
 142
 143       <li>Il existe de nombreux modules tiers disponibles à <a href="http://modules.apache.org/">http://modules.apache.org/</a> qui
 144       peuvent retreindre les comportements de certains clients et ainsi
 145       minimiser les problèmes de DoS.</li>
 146
 147     </ul>
 148
 149   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 150 <div class="section">
 151 <h2><a name="serverroot" id="serverroot">Permissions sur les répertoires de la racine du serveur</a></h2>
 152
 153
 154
 155     <p>Typiquement, Apache est démarré par l'utilisateur root, puis il devient
 156     la propriété de l'utilisateur défini par la directive <code class="directive"><a href="../mod/mpm_common.html#user">User</a></code> afin de répondre aux demandes. Comme
 157     pour toutes les commandes exécutées par root, vous devez vous assurer
 158     qu'elle n'est pas modifiable par les utilisateurs autres que root. Les
 159     fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne
 160     doivent être modifiables que par root. Par exemple, si vous avez choisi de
 161     placer la racine du serveur dans <code>/usr/local/apache</code>, il est conseillé de
 162     créer le répertoire en tant que root, avec des commandes du style :</p>
 163
 164     <div class="example"><p><code>
 165       mkdir /usr/local/apache <br />
 166       cd /usr/local/apache <br />
 167       mkdir bin conf logs <br />
 168       chown 0 . bin conf logs <br />
 169       chgrp 0 . bin conf logs <br />
 170       chmod 755 . bin conf logs
 171     </code></p></div>
 172
 173     <p>Nous supposerons que <code>/</code>, <code>/usr</code> et
 174     <code>/usr/local</code> ne sont modifiables que par
 175     root. Quand vous installez l'exécutable <code class="program"><a href="../programs/httpd.html">httpd</a></code>, vous
 176     devez vous assurer qu'il possède des protections similaires :</p>
 177
 178     <div class="example"><p><code>
 179       cp httpd /usr/local/apache/bin <br />
 180       chown 0 /usr/local/apache/bin/httpd <br />
 181       chgrp 0 /usr/local/apache/bin/httpd <br />
 182       chmod 511 /usr/local/apache/bin/httpd
 183     </code></p></div>
 184
 185     <p>Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres
 186     utilisateurs -- car root ne crée ni exécute aucun fichier dans ce
 187     sous-répertoire.</p>
 188
 189     <p>Si vous permettez à des utilisateurs non root de modifier des fichiers
 190     que root écrit ou exécute, vous exposez votre système à une compromission
 191     de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire
 192     <code class="program"><a href="../programs/httpd.html">httpd</a></code> de façon à ce que la prochaine fois que vous le
 193     redémarrerez, il exécutera un code arbitraire. Si le répertoire des
 194     journaux a les droits en écriture (pour un utilisateur non root), quelqu'un
 195     pourrait remplacer un fichier journal par un lien symbolique vers un autre
 196     fichier système, et root pourrait alors écraser ce fichier avec des données
 197     arbitraires. Si les fichiers journaux eux-mêmes ont des droits en
 198     écriture (pour un utilisateur non root), quelqu'un pourrait
 199     modifier les journaux eux-mêmes avec des données fausses.</p>
 200
 201   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 202 <div class="section">
 203 <h2><a name="ssi" id="ssi">Inclusions côté serveur</a></h2>
 204
 205
 206
 207     <p>Les inclusions côté serveur (Server Side Includes - SSI) exposent
 208     l'administrateur du serveur à de nombreux risques potentiels en matière de
 209     sécurité.</p>
 210
 211     <p>Le premier risque est l'augmentation de la charge du serveur. Tous les
 212     fichiers où SSI est activé doivent être analysés par Apache, qu'ils
 213     contiennent des directives SSI ou non. L'augmentation de la charge induite
 214     est minime, mais peut devenir significative dans le contexte d'un
 215     serveur partagé.</p>
 216
 217     <p>Les fichiers SSI présentent les mêmes risques que les scripts CGI en
 218     général. Les fichiers où SSI est activé peuvent exécuter tout script CGI
 219     ou autre programme à l'aide de la commande <code>"exec cmd"</code> avec les permissions
 220     des utilisateur et groupe sous lesquels Apache s'exécute, comme défini
 221     dans <code>httpd.conf</code>.</p>
 222
 223     <p>Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout
 224     en tirant parti des bénéfices qu'ils apportent.</p>
 225
 226     <p>Pour limiter les dommages qu'un fichier SSI agressif pourrait causer,
 227     l'administrateur du serveur peut activer<a href="../suexec.html">suexec</a>
 228     comme décrit dans la section <a href="#cgi">Les CGI en général</a>.</p>
 229
 230     <p>L'activation des SSI pour des fichiers possédant des extensions
 231     <code>.html</code> ou
 232     <code>.htm</code> peut s'avérer dangereux. Ceci est particulièrement vrai dans un
 233     environnement de serveur partagé ou étant le siège d'un traffic élevé. Les
 234     fichiers où SSI est activé doivent posséder une extension spécifique, telle
 235     que la conventionnelle <code>.shtml</code>. Ceci permet de limiter la charge du serveur
 236     à un niveau minimum et de simplifier la gestion des risques.</p>
 237
 238     <p>Une autre solution consiste à interdire l'exécution de scripts et
 239     programmes à partir de pages SSI. Pour ce faire, remplacez
 240     <code>Includes</code> par <code>IncludesNOEXEC</code> dans la directive
 241     <code class="directive"><a href="../mod/core.html#options">Options</a></code>. Notez que les utilisateurs
 242     pourront encore utiliser <code>&lt;--#include virtual="..." --&gt;</code> pour exécuter
 243     des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
 244     par une directive
 245     <code class="directive"><a href="../mod/mod_alias.html#scriptalias">ScriptAlias</a></code>.</p>
 246
 247   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 248 <div class="section">
 249 <h2><a name="cgi" id="cgi">Les CGI en général</a></h2>
 250
 251
 252
 253     <p>Tout d'abord, vous devez toujours garder à l'esprit que vous devez
 254     faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à
 255     vos compétences pour déceler les trous de sécurité potentiels dans les
 256     CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent
 257     essentiellement exécuter des commandes arbitraires sur votre système avec
 258     les droits de l'utilisateur du serveur web, et peuvent par conséquent être
 259     extrèmement dangereux s'ils ne sont pas vérifiés avec soin.</p>
 260
 261     <p>Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent
 262     donc entrer en conflit (accidentellement ou délibérément) avec d'autres
 263     scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc
 264     un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez
 265     utiliser le programme <a href="../suexec.html">suEXEC</a> pour faire en
 266     sorte que les scripts s'exécutent sous des utilisateurs différents. Ce
 267     programme est inclus dans la distribution d'Apache depuis la version 1.2
 268     et est appelé à partir de certaines portions de code du serveur Apache. Une
 269     autre méthode plus connue est l'utilisation de
 270     <a href="http://cgiwrap.sourceforge.net/">CGIWrap</a>.</p>
 271
 272   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 273 <div class="section">
 274 <h2><a name="nsaliasedcgi" id="nsaliasedcgi">CGI sans alias de script</a></h2>
 275
 276
 277
 278     <p>Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI
 279     depuis n'importe quel répertoire que dans l'éventualité où :</p>
 280
 281     <ul>
 282       <li>Vous faites confiance à vos utilisateurs pour ne pas écrire de
 283       scripts qui vont délibérément ou accidentellement exposer votre
 284       système à une attaque.</li>
 285       <li>Vous estimez que le niveau de sécurité dans les autres parties de
 286       votre site est si faible qu'un trou de sécurité de plus ou de moins
 287       n'est pas très important.</li>
 288       <li>Votre système ne comporte aucun utilisateur, et personne ne visite
 289       jamais votre site.</li>
 290     </ul>
 291
 292   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 293 <div class="section">
 294 <h2><a name="saliasedcgi" id="saliasedcgi">CGI avec alias de script</a></h2>
 295
 296
 297
 298     <p>Le confinement des CGI dans des répertoires spécifiques permet à
 299     l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci
 300     est bien entendu mieux sécurisé que les CGI sans alias de script, mais
 301     seulement à condition que les utilisateurs avec les droits en écriture sur
 302     les répertoires soient dignes de confiance, et que l'administrateur ait la
 303     volonté de tester chaque programme ou script CGI à la recherche d'éventuels
 304     trous de sécurité.</p>
 305
 306     <p>La plupart des sites choisissent cette approche au détriment des CGI
 307     sans alias de script.</p>
 308
 309   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 310 <div class="section">
 311 <h2><a name="dynamic" id="dynamic">Autres sources de contenu dynamique</a></h2>
 312
 313
 314
 315   <p>
 316   Les options de scripting intégrées qui s'exécutent en tant que partie du
 317   serveur lui-même, comme <code>mod_php</code>, <code>mod_perl</code>,
 318   <code>mod_tcl</code>, et <code>mod_python</code>,
 319   s'exécutent sous le même utilisateur que le serveur (voir la directive
 320   <code class="directive"><a href="../mod/mpm_common.html#user">User</a></code>), et par conséquent,
 321   les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources
 322   que le serveur. Certains moteurs de scripting peuvent proposer des
 323   restrictions, mais pour plus de sûreté, il vaut mieux partir du principe
 324   que ce n'est pas le cas.</p>
 325
 326   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 327 <div class="section">
 328 <h2><a name="systemsettings" id="systemsettings">Protection de la configuration du système</a></h2>
 329
 330
 331
 332     <p>Pour contrôler étroitement votre serveur, vous pouvez interdire
 333     l'utilisation des fichiers <code>.htaccess</code> qui permettent de
 334     passer outre les fonctionnalités de sécurité que vous avez configurées.
 335     Voici un moyen pour y parvenir :</p>
 336
 337     <p>Ajoutez dans le fichier de configuration du serveur</p>
 338
 339     <div class="example"><p><code>
 340       &lt;Directory /&gt; <br />
 341         AllowOverride None <br />
 342       &lt;/Directory&gt;
 343     </code></p></div>
 344
 345     <p>Ceci interdit l'utilisation des fichiers <code>.htaccess</code> dans
 346     tous les répertoires, sauf ceux pour lesquels c'est explicitement
 347     autorisé.</p>
 348
 349   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 350 <div class="section">
 351 <h2><a name="protectserverfiles" id="protectserverfiles">Protection par défaut des fichiers du serveur</a></h2>
 352
 353
 354
 355     <p>Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal
 356     compris. C'est à dire que, à moins que vous ne changiez explicitement ce
 357     comportement, si le serveur trouve son chemin vers un fichier en suivant
 358     les règles normales de correspondance URL - fichier, il peut le retourner
 359     aux clients.</p>
 360
 361     <p>Considérons l'exemple suivant :</p>
 362
 363     <div class="example"><p><code>
 364       # cd /; ln -s / public_html <br />
 365       puis accès à <code>http://localhost/~root/</code>
 366     </code></p></div>
 367
 368     <p>Ceci permettrait aux clients de parcourir l'ensemble du système de
 369     fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration
 370     de votre serveur :</p>
 371
 372     <div class="example"><p><code>
 373       &lt;Directory /&gt; <br />
 374       Order Deny,Allow <br />
 375       Deny from all <br />
 376       &lt;/Directory&gt;
 377     </code></p></div>
 378
 379     <p>ceci va interdire l'accès par défaut à tous les fichiers du système de
 380     fichiers. Vous devrez ensuite ajouter les blocs
 381     <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> appropriés correspondant
 382     aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,</p>
 383
 384     <div class="example"><p><code>
 385       &lt;Directory /usr/users/*/public_html&gt; <br />
 386         Order Deny,Allow <br />
 387         Allow from all <br />
 388       &lt;/Directory&gt; <br />
 389       &lt;Directory /usr/local/httpd&gt; <br />
 390         Order Deny,Allow <br />
 391         Allow from all <br />
 392       &lt;/Directory&gt;
 393     </code></p></div>
 394
 395     <p>Portez une attention particulière aux interactions entre les directives
 396     <code class="directive"><a href="../mod/core.html#location">Location</a></code> et
 397     <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> ; par exemple, si une
 398     directive <code>&lt;Directory /&gt;</code> interdit un accès, une
 399     directive <code>&lt;Location /&gt;</code> pourra passer outre.</p>
 400
 401     <p>De même, soyez méfiant en jouant avec la directive
 402     <code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code> ; la positionner à
 403     <code>"./"</code> aurait le même effet, pour root, que le premier exemple plus haut.
 404     Si vous utilisez Apache version 1.3 ou supérieure, nous vous conseillons
 405     fortement d'inclure la ligne suivante dans le fichier de configuration de
 406     votre serveur :</p>
 407
 408     <div class="example"><p><code>
 409       UserDir disabled root
 410     </code></p></div>
 411
 412   </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 413 <div class="section">
 414 <h2><a name="watchyourlogs" id="watchyourlogs">Surveillez vos journaux</a></h2>
 415
 416
 417
 418     <p>Pour vous tenir informé de ce qui se passe réellement dans votre
 419     serveur, vous devez consulter vos
 420     <a href="../logs.html">fichiers journaux</a>. Même si les fichiers journaux
 421     ne consignent que des évènements qui se sont déjà produits, ils vous
 422     informeront sur la nature des attaques qui sont lancées contre le serveur
 423     et vous permettront de vérifier si le niveau de sécurité nécessaire est
 424     atteint.</p>
 425
 426     <p>Quelques exemples :</p>
 427
 428     <div class="example"><p><code>
 429       grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br />
 430       grep "client denied" error_log | tail -n 10
 431     </code></p></div>
 432
 433     <p>Le premier exemple listera les attaques essayant d'exploiter la
 434     <a href="http://online.securityfocus.com/bid/4876/info/">vulnérabilité
 435     d'Apache Tomcat pouvant provoquer la divulgation d'informations par des
 436     requêtes Source.JSP mal formées</a>, le second donnera la liste des dix
 437     dernières interdictions client ; par exemple :</p>
 438
 439     <div class="example"><p><code>
 440       [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
 441       by server configuration: /usr/local/apache/htdocs/.htpasswd
 442     </code></p></div>
 443
 444     <p>Comme vous le voyez, les fichiers journaux ne consignent que ce qui
 445     s'est déjà produit ; ainsi, si le client a pu accéder au fichier
 446     <code>.htpasswd</code>, vous devriez avoir quelque chose du style :</p>
 447
 448     <div class="example"><p><code>
 449       foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
 450     </code></p></div>
 451
 452     <p>dans votre <a href="../logs.html#accesslog">journal des accès</a> ; ce
 453     qui signifie que vous avez probablement mis en commentaire ce qui suit dans
 454     le fichier de configuration de votre serveur :</p>
 455
 456     <div class="example"><p><code>
 457       &lt;Files ~ "^\.ht"&gt; <br />
 458         Order allow,deny <br />
 459         Deny from all <br />
 460       &lt;/Files&gt;
 461     </code></p></div>
 462
 463   </div></div>
 464 <div class="bottomlang">
 465 <p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
 466 <a href="../fr/misc/security_tips.html" title="Français">&nbsp;fr&nbsp;</a> |
 467 <a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
 468 <a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="Türkçe">&nbsp;tr&nbsp;</a></p>
 469 </div><div id="footer">
 470 <p class="apache">Copyright 2009 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
 471 <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div>
 472 </body></html>