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