| <!DOCTYPE html SYSTEM "about:legacy-compat"> | |
| <html lang="fr"><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8"> | |
| <meta content="width=device-width, initial-scale=1" name="viewport"> | |
| <!-- | |
| XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | |
| This file is generated from xml source: DO NOT EDIT | |
| XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | |
| --> | |
| <title>Conseils sur la sécurité - Serveur HTTP Apache Version 2.5</title> | |
| <link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet"> | |
| <link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size"> | |
| <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"> | |
| <script src="../style/scripts/prettify.min.js"> | |
| </script> | |
| <link href="../images/favicon.png" rel="shortcut icon"></head> | |
| <body id="manual-page"><div id="page-header"> | |
| <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="https://cwiki.apache.org/confluence/display/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a> | <a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2">Signaler un bug</a></p> | |
| <p class="apache">Serveur HTTP Apache Version 2.5</p> | |
| <img alt="" src="../images/feather.png"></div> | |
| <div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif"></a></div> | |
| <div id="path"> | |
| <a href="https://www.apache.org/">Apache</a> > <a href="https://httpd.apache.org/">Serveur HTTP</a> > <a href="https://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> | |
| <button aria-label="Toggle language list" class="lang-toggle"><svg xmlns="http://www.w3.org/2000/svg" stroke-width="2" stroke="currentColor" fill="none" viewBox="0 0 24 24" height="16" width="16"><circle r="10" cy="12" cx="12"/><line y2="12" x2="22" y1="12" x1="2"/><path d="M12 2a15.3 15.3 0 0 1 4 10 15.3 15.3 0 0 1-4 10 15.3 15.3 0 0 1-4-10 15.3 15.3 0 0 1 4-10z"/></svg></button> | |
| <div class="toplang"> | |
| <p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English"> en </a> | | |
| <a href="../es/misc/security_tips.html" hreflang="es" rel="alternate" title="Español"> es </a> | | |
| <a href="../fr/misc/security_tips.html" title="Français"> fr </a> | | |
| <a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> | | |
| <a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p> | |
| </div> | |
| <div class="outofdate">Cette traduction peut être périmée. Vérifiez la version | |
| anglaise pour les changements récents.</div> | |
| <p>Ce document propose quelques conseils et astuces concernant les | |
| problèmes de sécurité liés | |
| à l'installation d'un serveur web. Certaines suggestions seront à caractère | |
| général, tandis que d'autres seront spécifiques à Apache.</p> | |
| </div> | |
| <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif"> <a href="#uptodate">Maintenez votre serveur à jour</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#dos">Attaques de type "Déni de service" | |
| (Denial of Service - DoS)</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#serverroot">Permissions sur les répertoires de la racine du serveur</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#ssi">Inclusions côté serveur</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#cgi">Les CGI en général</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#nsaliasedcgi">CGI sans alias de script</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#saliasedcgi">CGI avec alias de script</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#dynamic">Autres sources de contenu dynamique</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#dynamicsec">Sécurité des contenus dynamiques</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#systemsettings">Protection de la configuration du système</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#protectserverfiles">Protection par défaut des fichiers du serveur</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#watchyourlogs">Surveillez vos journaux</a></li> | |
| <li><img alt="" src="../images/down.gif"> <a href="#merging">Fusion des sections de configuration</a></li> | |
| </ul></div> | |
| <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="uptodate">Maintenez votre serveur à jour <a title="Lien permanent" href="#uptodate" class="permalink">¶</a></h2> | |
| <p>Le serveur HTTP Apache a une bonne réputation en matière de sécurité | |
| et possède une communauté de développeurs très sensibilisés aux problèmes | |
| de sécurité. Mais il est inévitable de trouver certains problèmes | |
| -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour | |
| cette raison qu'il est crucial de se tenir informé des mises à jour. Si | |
| vous avez obtenu votre version du serveur HTTP directement depuis Apache, | |
| nous vous conseillons grandement de vous abonner à la <a href="http://httpd.apache.org/lists.html#http-announce">Liste de diffusion | |
| des annonces du serveur HTTP</a> qui vous informera de | |
| la parution des nouvelles versions et des mises à jour de sécurité. La | |
| plupart des distributeurs tiers d'Apache fournissent des services | |
| similaires.</p> | |
| <p>Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le | |
| code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes | |
| proviennent plutôt de code ajouté, de scripts CGI, ou du système | |
| d'exploitation sous-jacent. Vous devez donc vous tenir informé des | |
| problèmes et mises à jour concernant tous les logiciels présents sur | |
| votre système.</p> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="dos">Attaques de type "Déni de service" | |
| (Denial of Service - DoS) <a title="Lien permanent" href="#dos" class="permalink">¶</a></h2> | |
| <p>Tous les services réseau peuvent faire l'objet d'attaques de type | |
| "Déni de service" qui tentent de les empêcher de répondre aux clients en | |
| saturant leurs ressources. Il est impossible de se prémunir totalement | |
| contre ce type d'attaques, mais vous pouvez accomplir certaines actions | |
| afin de minimiser les problèmes qu'elles créent.</p> | |
| <p>Souvent, l'outil anti-DoS le plus efficace sera constitué par le | |
| pare-feu ou certaines configurations du système d'exploitation. Par | |
| exemple, la plupart des pare-feu peuvent être configurés de façon à | |
| limiter le nombre de connexions simultanées depuis une adresse IP ou un | |
| réseau, ce qui permet de prévenir toute une gamme d'attaques simples. | |
| Bien sûr, ceci n'est d'aucun secours contre les attaques de type | |
| "Déni de service" distribuées (DDoS).</p> | |
| <p>Certains réglages de la configuration d'Apache peuvent aussi | |
| minimiser les problèmes :</p> | |
| <ul> | |
| <li>La directive <code class="directive"><a href="../mod/mod_reqtimeout.html#requestreadtimeout">RequestReadTimeout</a></code> permet de | |
| limiter le temps que met le client pour terminer la négociation TLS et | |
| envoyer sa requête. En particulier, la phase <code>handshake</code> met | |
| hors délai les clients qui se figent lors de la négociation TLS.</li> | |
| <li>La valeur de la directive | |
| <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code> doit être diminuée sur les | |
| sites sujets aux attaques DoS. Une valeur de quelques secondes devrait | |
| convenir. Cependant, comme <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code> | |
| est actuellement concerné par de nombreuses opérations différentes, lui | |
| attribuer une valeur trop faible peut provoquer des problèmes avec les | |
| scripts CGI qui présentent un long temps de réponse.</li> | |
| <li>La valeur de la directive | |
| <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> doit aussi être | |
| diminuée sur les sites sujets aux attaques DoS. Certains sites | |
| désactivent même complètement le "maintien en vie" (keepalives) | |
| à l'aide de la directive | |
| <code class="directive"><a href="../mod/core.html#keepalive">KeepAlive</a></code>, ce qui bien sûr | |
| présente des inconvénients en matière de performances.</li> | |
| <li>Les valeurs des différentes directives fournies par d'autres modules | |
| et en rapport avec des délais doivent aussi être vérifiées.</li> | |
| <li>Les directives | |
| <code class="directive"><a href="../mod/core.html#limitrequestbody">LimitRequestBody</a></code>, | |
| <code class="directive"><a href="../mod/core.html#limitrequestfields">LimitRequestFields</a></code>, | |
| <code class="directive"><a href="../mod/core.html#limitrequestfieldsize">LimitRequestFieldSize</a></code>, | |
| <code class="directive"><a href="../mod/core.html#limitrequestline">LimitRequestLine</a></code>, et | |
| <code class="directive"><a href="../mod/core.html#limitxmlrequestbody">LimitXMLRequestBody</a></code> doivent être | |
| configurées avec prudence afin de limiter la consommation de ressources | |
| induite par les demandes des clients. | |
| </li> | |
| <li>Sur les systèmes d'exploitation qui le supportent, assurez-vous que | |
| la directive <code class="directive"><a href="../mod/core.html#acceptfilter">AcceptFilter</a></code> est | |
| activée afin de déléguer une partie du traitement des requêtes au | |
| système d'exploitation. Elle est activée par défaut dans le démon httpd | |
| d'Apache, mais peut nécessiter une reconfiguration de votre noyau.</li> | |
| <li>Optimisez la directive <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> de façon à définir le nombre | |
| maximum de connexions simultanées au dessus duquel les ressources | |
| s'épuisent. Voir aussi la <a href="perf-tuning.html">documentation sur l'optimisation des | |
| performances</a>.</li> | |
| <li>L'utilisation d'un <a href="../mpm.html">module mpm</a> threadé | |
| vous permet de traiter d'avantage de connexions simultanées, ce qui | |
| minimise l'effet des attaques DoS. Dans le futur, le module mpm | |
| <code class="module"><a href="../mod/event.html">event</a></code> utilisera un traitement asynchrone afin de ne pas | |
| dédier un thread à chaque connexion.</li> | |
| <li>Il existe de nombreux modules tiers qui peuvent restreindre les | |
| comportements de certains clients et ainsi minimiser les problèmes de | |
| DoS.</li> | |
| </ul> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="serverroot">Permissions sur les répertoires de la racine du serveur <a title="Lien permanent" href="#serverroot" class="permalink">¶</a></h2> | |
| <p>Typiquement, Apache est démarré par l'utilisateur root, puis il devient | |
| 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 | |
| pour toutes les commandes exécutées par root, vous devez vous assurer | |
| qu'elle n'est pas modifiable par les utilisateurs autres que root. Les | |
| fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne | |
| doivent être modifiables que par root. Par exemple, si vous avez choisi de | |
| placer la racine du serveur dans <code>/usr/local/apache</code>, il est conseillé de | |
| créer le répertoire en tant que root, avec des commandes du style :</p> | |
| <div class="example"><p><code> | |
| mkdir /usr/local/apache <br> | |
| cd /usr/local/apache <br> | |
| mkdir bin conf logs <br> | |
| chown 0 . bin conf logs <br> | |
| chgrp 0 . bin conf logs <br> | |
| chmod 755 . bin conf logs | |
| </code></p></div> | |
| <p>Nous supposerons que <code>/</code>, <code>/usr</code> et | |
| <code>/usr/local</code> ne sont modifiables que par | |
| root. Quand vous installez l'exécutable <code class="program"><a href="../programs/httpd.html">httpd</a></code>, vous | |
| devez vous assurer qu'il possède des protections similaires :</p> | |
| <div class="example"><p><code> | |
| cp httpd /usr/local/apache/bin <br> | |
| chown 0 /usr/local/apache/bin/httpd <br> | |
| chgrp 0 /usr/local/apache/bin/httpd <br> | |
| chmod 511 /usr/local/apache/bin/httpd | |
| </code></p></div> | |
| <p>Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres | |
| utilisateurs -- car root ne crée ni exécute aucun fichier dans ce | |
| sous-répertoire.</p> | |
| <p>Si vous permettez à des utilisateurs non root de modifier des fichiers | |
| que root écrit ou exécute, vous exposez votre système à une compromission | |
| de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire | |
| <code class="program"><a href="../programs/httpd.html">httpd</a></code> de façon à ce que la prochaine fois que vous le | |
| redémarrerez, il exécutera un code arbitraire. Si le répertoire des | |
| journaux a les droits en écriture (pour un utilisateur non root), quelqu'un | |
| pourrait remplacer un fichier journal par un lien symbolique vers un autre | |
| fichier système, et root pourrait alors écraser ce fichier avec des données | |
| arbitraires. Si les fichiers journaux eux-mêmes ont des droits en | |
| écriture (pour un utilisateur non root), quelqu'un pourrait | |
| modifier les journaux eux-mêmes avec des données fausses.</p> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="ssi">Inclusions côté serveur <a title="Lien permanent" href="#ssi" class="permalink">¶</a></h2> | |
| <p>Les inclusions côté serveur (Server Side Includes - SSI) exposent | |
| l'administrateur du serveur à de nombreux risques potentiels en matière de | |
| sécurité.</p> | |
| <p>Le premier risque est l'augmentation de la charge du serveur. Tous les | |
| fichiers où SSI est activé doivent être analysés par Apache, qu'ils | |
| contiennent des directives SSI ou non. L'augmentation de la charge induite | |
| est minime, mais peut devenir significative dans le contexte d'un | |
| serveur partagé.</p> | |
| <p>Les fichiers SSI présentent les mêmes risques que les scripts CGI en | |
| général. Les fichiers où SSI est activé peuvent exécuter tout script CGI | |
| ou autre programme à l'aide de la commande <code>"exec cmd"</code> avec les permissions | |
| des utilisateur et groupe sous lesquels Apache s'exécute, comme défini | |
| dans <code>httpd.conf</code>.</p> | |
| <p>Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout | |
| en tirant parti des bénéfices qu'ils apportent.</p> | |
| <p>Pour limiter les dommages qu'un fichier SSI agressif pourrait causer, | |
| l'administrateur du serveur peut activer<a href="../suexec.html">suexec</a> | |
| comme décrit dans la section <a href="#cgi">Les CGI en général</a>.</p> | |
| <p>L'activation des SSI pour des fichiers possédant des extensions | |
| <code>.html</code> ou | |
| <code>.htm</code> peut s'avérer dangereux. Ceci est particulièrement vrai dans un | |
| environnement de serveur partagé ou étant le siège d'un traffic élevé. Les | |
| fichiers où SSI est activé doivent posséder une extension spécifique, telle | |
| que la conventionnelle <code>.shtml</code>. Ceci permet de limiter la charge du serveur | |
| à un niveau minimum et de simplifier la gestion des risques.</p> | |
| <p>Une autre solution consiste à interdire l'exécution de scripts et | |
| programmes à partir de pages SSI. Pour ce faire, remplacez | |
| <code>Includes</code> par <code>IncludesNOEXEC</code> dans la directive | |
| <code class="directive"><a href="../mod/core.html#options">Options</a></code>. Notez que les utilisateurs | |
| pourront encore utiliser <code><--#include virtual="..." --></code> pour exécuter | |
| des scripts CGI si ces scripts sont situés dans des répertoires spécifiés | |
| par une directive | |
| <code class="directive"><a href="../mod/mod_alias.html#scriptalias">ScriptAlias</a></code>.</p> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="cgi">Les CGI en général <a title="Lien permanent" href="#cgi" class="permalink">¶</a></h2> | |
| <p>Tout d'abord, vous devez toujours garder à l'esprit que vous devez | |
| faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à | |
| vos compétences pour déceler les trous de sécurité potentiels dans les | |
| CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent | |
| essentiellement exécuter des commandes arbitraires sur votre système avec | |
| les droits de l'utilisateur du serveur web, et peuvent par conséquent être | |
| extrèmement dangereux s'ils ne sont pas vérifiés avec soin.</p> | |
| <p>Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent | |
| donc entrer en conflit (accidentellement ou délibérément) avec d'autres | |
| scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc | |
| un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez | |
| utiliser le programme <a href="../suexec.html">suEXEC</a> pour faire en | |
| sorte que les scripts s'exécutent sous des utilisateurs différents. Ce | |
| programme est inclus dans la distribution d'Apache depuis la version 1.2 | |
| et est appelé à partir de certaines portions de code du serveur Apache. Une | |
| autre méthode plus connue est l'utilisation de | |
| <a href="http://cgiwrap.sourceforge.net/">CGIWrap</a>.</p> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="nsaliasedcgi">CGI sans alias de script <a title="Lien permanent" href="#nsaliasedcgi" class="permalink">¶</a></h2> | |
| <p>Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI | |
| depuis n'importe quel répertoire que dans l'éventualité où :</p> | |
| <ul> | |
| <li>Vous faites confiance à vos utilisateurs pour ne pas écrire de | |
| scripts qui vont délibérément ou accidentellement exposer votre | |
| système à une attaque.</li> | |
| <li>Vous estimez que le niveau de sécurité dans les autres parties de | |
| votre site est si faible qu'un trou de sécurité de plus ou de moins | |
| n'est pas très important.</li> | |
| <li>Votre système ne comporte aucun utilisateur, et personne ne visite | |
| jamais votre site.</li> | |
| </ul> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="saliasedcgi">CGI avec alias de script <a title="Lien permanent" href="#saliasedcgi" class="permalink">¶</a></h2> | |
| <p>Le confinement des CGI dans des répertoires spécifiques permet à | |
| l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci | |
| est bien entendu mieux sécurisé que les CGI sans alias de script, mais | |
| seulement à condition que les utilisateurs avec les droits en écriture sur | |
| les répertoires soient dignes de confiance, et que l'administrateur ait la | |
| volonté de tester chaque programme ou script CGI à la recherche d'éventuels | |
| trous de sécurité.</p> | |
| <p>La plupart des sites choisissent cette approche au détriment des CGI | |
| sans alias de script.</p> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="dynamic">Autres sources de contenu dynamique <a title="Lien permanent" href="#dynamic" class="permalink">¶</a></h2> | |
| <p> | |
| Les options de scripting intégrées qui s'exécutent en tant que partie du | |
| serveur lui-même, comme <code>mod_php</code>, <code>mod_perl</code>, | |
| <code>mod_tcl</code>, et <code>mod_python</code>, | |
| s'exécutent sous le même utilisateur que le serveur (voir la directive | |
| <code class="directive"><a href="../mod/mod_unixd.html#user">User</a></code>), et par conséquent, | |
| les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources | |
| que le serveur. Certains moteurs de scripting peuvent proposer des | |
| restrictions, mais pour plus de sûreté, il vaut mieux partir du principe | |
| que ce n'est pas le cas.</p> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="dynamicsec">Sécurité des contenus dynamiques <a title="Lien permanent" href="#dynamicsec" class="permalink">¶</a></h2> | |
| <p>Quand vous utilisez des cadriciels à contenu dynamique — que ce soit à | |
| travers <code>mod_php</code>, <code>mod_perl</code>, <code>mod_python</code> | |
| ou tout autre générateur de contenu intégré ou externe — les responsabilités | |
| en matière de sécurité s’étendent au-delà de httpd lui-même. Chaque cadriciel | |
| possède ses propres modèle de sécurité, options de configuration et guides de | |
| durcissement. Consultez la documentation de la technologie que vous utilisez | |
| pour générer du contenu dynamique et maintenez cette dernière à jour.</p> | |
| <p>Les principes généraux s’appliquent à tout cadriciel :</p> | |
| <ul> | |
| <li>Accordez des privilèges minimaux à vos scripts et applications.</li> | |
| <li>Vérifiez et nettoyez toute entrée de l’utilisateur.</li> | |
| <li>Maintenez à jour votre cadriciel de contenu et ses dépendances.</li> | |
| <li>Vérifiez la configuration de la sécurité de votre cadriciel — les valeurs | |
| par défaut ne sont pas toujours appropriées en matière de sécurité.</li> | |
| </ul> | |
| <p>Au niveau de httpd, un pare-feu d’application web tel que <a href="https://modsecurity.org/">ModSecurity</a> peut fournir une couche | |
| supplémentaire de défense en inspectant et filtrant le trafic HTTP avant qu’il | |
| n’atteigne votre application.</p> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="systemsettings">Protection de la configuration du système <a title="Lien permanent" href="#systemsettings" class="permalink">¶</a></h2> | |
| <p>Pour contrôler étroitement votre serveur, vous pouvez interdire | |
| l'utilisation des fichiers <code>.htaccess</code> qui permettent de | |
| passer outre les fonctionnalités de sécurité que vous avez configurées. | |
| Voici un moyen pour y parvenir :</p> | |
| <p>Ajoutez dans le fichier de configuration du serveur</p> | |
| <pre class="prettyprint lang-config"><Directory "/"> | |
| AllowOverride None | |
| </Directory></pre> | |
| <p>Ceci interdit l'utilisation des fichiers <code>.htaccess</code> dans | |
| tous les répertoires, sauf ceux pour lesquels c'est explicitement | |
| autorisé.</p> | |
| <p>Notez que c'est la configuration par défaut depuis Apache 2.3.9.</p> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="protectserverfiles">Protection par défaut des fichiers du serveur <a title="Lien permanent" href="#protectserverfiles" class="permalink">¶</a></h2> | |
| <p>Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal | |
| compris. C'est à dire que, à moins que vous ne changiez explicitement ce | |
| comportement, si le serveur trouve son chemin vers un fichier en suivant | |
| les règles normales de correspondance URL - fichier, il peut le retourner | |
| aux clients.</p> | |
| <p>Considérons l'exemple suivant :</p> | |
| <div class="example"><p><code> | |
| # cd /; ln -s / public_html <br> | |
| puis accès à <code>http://localhost/~root/</code> | |
| </code></p></div> | |
| <p>Ceci permettrait aux clients de parcourir l'ensemble du système de | |
| fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration | |
| de votre serveur :</p> | |
| <pre class="prettyprint lang-config"><Directory "/"> | |
| Require all denied | |
| </Directory></pre> | |
| <p>ceci va interdire l'accès par défaut à tous les fichiers du système de | |
| fichiers. Vous devrez ensuite ajouter les blocs | |
| <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> appropriés correspondant | |
| aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,</p> | |
| <pre class="prettyprint lang-config"><Directory "/usr/users/*/public_html"> | |
| Require all granted | |
| </Directory> | |
| <Directory "/usr/local/httpd"> | |
| Require all granted | |
| </Directory></pre> | |
| <p>Portez une attention particulière aux interactions entre les directives | |
| <code class="directive"><a href="../mod/core.html#location">Location</a></code> et | |
| <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> ; par exemple, si une | |
| directive <code><Directory "/"></code> interdit un accès, une | |
| directive <code><Location "/"></code> pourra passer outre.</p> | |
| <p>De même, soyez méfiant en jouant avec la directive | |
| <code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code> ; la positionner à | |
| <code>"./"</code> aurait le même effet, pour root, que le premier exemple plus haut. | |
| Nous vous conseillons | |
| fortement d'inclure la ligne suivante dans le fichier de configuration de | |
| votre serveur :</p> | |
| <pre class="prettyprint lang-config">UserDir disabled root</pre> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="watchyourlogs">Surveillez vos journaux <a title="Lien permanent" href="#watchyourlogs" class="permalink">¶</a></h2> | |
| <p>Pour vous tenir informé de ce qui se passe réellement dans votre serveur, | |
| consultez régulièrement vos <a href="../logs.html">fichiers journaux</a>. | |
| Les fichiers journaux ne consignent que des évènements qui se sont déjà | |
| produits, mais ils vous informeront sur la nature des attaques qui sont | |
| lancées et vous permettront de vérifier si la configuration de votre | |
| sécurité est efficace.</p> | |
| <p>Quelques exemples :</p> | |
| <pre class="prettyprint lang-sh">grep -c "\.\.\/" access_log | |
| grep "client denied" error_log | tail -n 10</pre> | |
| <p>Le premier exemple compte les requêtes qui contiennent des séquences de | |
| traversée de chemin — un signe connu de recherche de vulnérabilités. Le | |
| second liste les dix « client denied » les plus récents ; par exemple :</p> | |
| <div class="example"><p><code> | |
| [Mon Apr 14 09:42:03.817295 2026] [authz_core:error] [pid 1234:tid 5678] | |
| [client 192.168.1.100:54312] AH01630: client denied by server configuration: | |
| /usr/local/apache2/htdocs/.env | |
| </code></p></div> | |
| <p>Comme vous pouvez le voir, les fichiers journaux ne mentionnent que ce | |
| qu’il s’est déjà produit. Si le client avait pu accéder au fichier | |
| <code>.env</code>, vous auriez vu une réponse <code>200</code> dans votre | |
| fichier <a href="../logs.html#accesslog">Access Log</a> — ce qui aurait | |
| signifié que la configuration de votre serveur devait être plus restrictive. | |
| Assurez-vous d’interdire l’accès aux fichiers sensibles :</p> | |
| <pre class="prettyprint lang-config"><FilesMatch "^\.(?!well-known)"> | |
| Require all denied | |
| </FilesMatch></pre> | |
| </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div> | |
| <div class="section"> | |
| <h2 id="merging">Fusion des sections de configuration <a title="Lien permanent" href="#merging" class="permalink">¶</a></h2> | |
| <p>La fusion des sections de configuration est complexe et dépend | |
| souvent des directives utilisées. Vous devez systématiquement tester | |
| vos modifications pour vérifier la manière dont les directives sont | |
| fusionnées.</p> | |
| <p>Concernant les modules qui n'implémentent aucune logique de | |
| fusion, comme <code class="module"><a href="../mod/mod_access_compat.html">mod_access_compat</a></code>, le | |
| comportement des sections suivantes est tributaire de la présence | |
| dans ces dernières de directives appartenant à ces modules. La | |
| configuration est héritée jusqu'à ce qu'une modification soit | |
| effectuée ; à ce moment, la configuration est <em>remplacée</em> et | |
| non fusionnée.</p> | |
| </div></div> | |
| <div class="bottomlang"> | |
| <p><span>Langues Disponibles: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English"> en </a> | | |
| <a href="../es/misc/security_tips.html" hreflang="es" rel="alternate" title="Español"> es </a> | | |
| <a href="../fr/misc/security_tips.html" title="Français"> fr </a> | | |
| <a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> | | |
| <a href="../tr/misc/security_tips.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p> | |
| </div><div id="footer"> | |
| <p class="apache">Copyright 2026 The Apache Software Foundation.<br>Autorisé sous <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> | |
| <p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="https://cwiki.apache.org/confluence/display/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a> | <a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2">Signaler un bug</a></p></div><script><!--//--><![CDATA[//><!-- | |
| if (typeof(prettyPrint) !== 'undefined') { | |
| prettyPrint(); | |
| } | |
| var langToggle = document.querySelector('.lang-toggle'); | |
| var topLang = document.querySelector('.toplang'); | |
| if (langToggle && topLang) { | |
| langToggle.addEventListener('click', function() { topLang.classList.toggle('open'); }); | |
| } | |
| var qv = document.getElementById('quickview'); | |
| if (qv) { | |
| document.body.appendChild(qv); | |
| var qvBtn = document.createElement('button'); | |
| qvBtn.className = 'qv-toggle'; | |
| qvBtn.setAttribute('aria-label', 'Toggle page navigation'); | |
| qvBtn.innerHTML = '☰'; | |
| document.body.appendChild(qvBtn); | |
| qvBtn.addEventListener('click', function() { | |
| var isOpen = qv.classList.toggle('open'); | |
| if (isOpen) { | |
| qv.style.top = window.scrollY + 10 + 'px'; | |
| } | |
| }); | |
| window.addEventListener('scroll', function() { qv.classList.remove('open'); }); | |
| } | |
| //--><!]]></script> | |
| </body></html> |