⚝
One Hat Cyber Team
⚝
Your IP:
216.73.216.19
Server IP:
178.33.27.10
Server:
Linux cpanel.dev-unit.com 3.10.0-1160.108.1.el7.x86_64 #1 SMP Thu Jan 25 16:17:31 UTC 2024 x86_64
Server Software:
Apache/2.4.57 (Unix) OpenSSL/1.0.2k-fips
PHP Version:
8.2.11
Buat File
|
Buat Folder
Eksekusi
Dir :
~
/
usr
/
local
/
apache
/
manual
/
misc
/
View File Name :
security_tips.html.fr.utf8
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" /> <!-- XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX This file is generated from xml source: DO NOT EDIT XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --> <title>Conseils sur la sécurité - Serveur HTTP Apache Version 2.4</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" type="text/javascript"> </script> <link href="../images/favicon.ico" rel="shortcut icon" /></head> <body id="manual-page"><div id="page-header"> <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> <p class="apache">Serveur HTTP Apache Version 2.4</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="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.4</a> > <a href="./">Documentations diverses</a></div><div id="page-content"><div id="preamble"><h1>Conseils sur la sécurité</h1> <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="../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> <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"><a href="https://www.apache.org/foundation/contributing.html" class="badge"><img src="https://www.apache.org/images/SupportApache-small.png" alt="Support Apache!" /></a><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="#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><h3>Voir aussi</h3><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div> <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> <div class="section"> <h2><a name="uptodate" id="uptodate">Maintenez votre serveur à jour</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><a name="dos" id="dos">Attaques de type "Déni de service" (Denial of Service - DoS)</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 envoyer sa requête.</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. De par la nature de la bibliothèque OpenSSL, le module mpm <code class="module"><a href="../mod/event.html">event</a></code> est actuellement incompatible avec le module <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> ainsi que d'autres filtres en entrée. Dans ces cas, son comportement se ramène à celui du module mpm <code class="module"><a href="../mod/worker.html">worker</a></code>.</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><a name="serverroot" id="serverroot">Permissions sur les répertoires de la racine du serveur</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><a name="ssi" id="ssi">Inclusions côté serveur</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><a name="cgi" id="cgi">Les CGI en général</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><a name="nsaliasedcgi" id="nsaliasedcgi">CGI sans alias de script</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><a name="saliasedcgi" id="saliasedcgi">CGI avec alias de script</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><a name="dynamic" id="dynamic">Autres sources de contenu dynamique</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><a name="systemsettings" id="systemsettings">Protection de la configuration du système</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><a name="protectserverfiles" id="protectserverfiles">Protection par défaut des fichiers du serveur</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><a name="watchyourlogs" id="watchyourlogs">Surveillez vos journaux</a></h2> <p>Pour vous tenir informé de ce qui se passe réellement dans votre serveur, vous devez consulter vos <a href="../logs.html">fichiers journaux</a>. Même si les fichiers journaux ne consignent que des évènements qui se sont déjà produits, ils vous informeront sur la nature des attaques qui sont lancées contre le serveur et vous permettront de vérifier si le niveau de sécurité nécessaire est atteint.</p> <p>Quelques exemples :</p> <div class="example"><p><code> grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br /> grep "client denied" error_log | tail -n 10 </code></p></div> <p>Le premier exemple listera les attaques essayant d'exploiter la <a href="http://online.securityfocus.com/bid/4876/info/">vulnérabilité d'Apache Tomcat pouvant provoquer la divulgation d'informations par des requêtes Source.JSP mal formées</a>, le second donnera la liste des dix dernières interdictions client ; par exemple :</p> <div class="example"><p><code> [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd </code></p></div> <p>Comme vous le voyez, les fichiers journaux ne consignent que ce qui s'est déjà produit ; ainsi, si le client a pu accéder au fichier <code>.htpasswd</code>, vous devriez avoir quelque chose du style :</p> <div class="example"><p><code> foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" </code></p></div> <p>dans votre <a href="../logs.html#accesslog">journal des accès</a> ; ce qui signifie que vous avez probablement mis en commentaire ce qui suit dans le fichier de configuration de votre serveur :</p> <pre class="prettyprint lang-config"><Files ".ht*"> Require all denied </Files></pre> </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div> <div class="section"> <h2><a name="merging" id="merging">Fusion des sections de configuration</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="../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="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Commentaires</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed 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 Libera.chat, or sent to our <a href="https://httpd.apache.org/lists.html">mailing lists</a>.</div> <script type="text/javascript"><!--//--><![CDATA[//><!-- var comments_shortname = 'httpd'; var comments_identifier = 'http://httpd.apache.org/docs/2.4/misc/security_tips.html'; (function(w, d) { if (w.location.hostname.toLowerCase() == "httpd.apache.org") { d.write('<div id="comments_thread"><\/div>'); var s = d.createElement('script'); s.type = 'text/javascript'; s.async = true; s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier; (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s); } else { d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>'); } })(window, document); //--><!]]></script></div><div id="footer"> <p class="apache">Copyright 2023 The Apache Software Foundation.<br />Autorisé sous <a href="http://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/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[//><!-- if (typeof(prettyPrint) !== 'undefined') { prettyPrint(); } //--><!]]></script> </body></html>