diff options
| author | Vincent Deffontaines <gryzor@apache.org> | 2009-02-08 14:33:05 +0000 |
|---|---|---|
| committer | Vincent Deffontaines <gryzor@apache.org> | 2009-02-08 14:33:05 +0000 |
| commit | eaea2d4e8f27cd1c6f1e47aa1da07435400ae47b (patch) | |
| tree | 0d0965ad2a783a39b584438d55959bd78a353848 | |
| parent | 2cb161dafc735c7b8d133c5080a82a1880dceb20 (diff) | |
| download | httpd-eaea2d4e8f27cd1c6f1e47aa1da07435400ae47b.tar.gz | |
New french translation for security tips.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@742108 13f79535-47bb-0310-9956-ffa450edef68
| -rw-r--r-- | docs/manual/misc/security_tips.html | 4 | ||||
| -rw-r--r-- | docs/manual/misc/security_tips.html.en | 2 | ||||
| -rw-r--r-- | docs/manual/misc/security_tips.html.fr | 472 | ||||
| -rw-r--r-- | docs/manual/misc/security_tips.xml.fr | 461 | ||||
| -rw-r--r-- | docs/manual/misc/security_tips.xml.meta | 1 |
5 files changed, 940 insertions, 0 deletions
diff --git a/docs/manual/misc/security_tips.html b/docs/manual/misc/security_tips.html index 893872b54b..4745c0d8a9 100644 --- a/docs/manual/misc/security_tips.html +++ b/docs/manual/misc/security_tips.html @@ -4,6 +4,10 @@ URI: security_tips.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: security_tips.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 + URI: security_tips.html.ko.euc-kr Content-Language: ko Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/misc/security_tips.html.en b/docs/manual/misc/security_tips.html.en index a852b687e7..c407dc4142 100644 --- a/docs/manual/misc/security_tips.html.en +++ b/docs/manual/misc/security_tips.html.en @@ -19,6 +19,7 @@ <a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.3</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>Security Tips</h1> <div class="toplang"> <p><span>Available Languages: </span><a href="../en/misc/security_tips.html" title="English"> en </a> | +<a href="../fr/misc/security_tips.html" hreflang="fr" rel="alternate" 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> @@ -423,6 +424,7 @@ </div></div> <div class="bottomlang"> <p><span>Available Languages: </span><a href="../en/misc/security_tips.html" title="English"> en </a> | +<a href="../fr/misc/security_tips.html" hreflang="fr" rel="alternate" 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"> diff --git a/docs/manual/misc/security_tips.html.fr b/docs/manual/misc/security_tips.html.fr new file mode 100644 index 0000000000..d1f83a1e5b --- /dev/null +++ b/docs/manual/misc/security_tips.html.fr @@ -0,0 +1,472 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<!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><!-- + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + This file is generated from xml source: DO NOT EDIT + XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX + --> +<title>Conseils sur la sécurité - Serveur Apache HTTP</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 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="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p> +<p class="apache">Serveur Apache HTTP Version 2.3</p> +<img alt="" src="../images/feather.gif" /></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.3</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"><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> +</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 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#maxclients">MaxClients</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 expérimental + <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. Il est en cours d'étude à + l'heure actuelle et n'est pas encore entièrement implémenté. En + particulier, le 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.</li> + + <li>Il existe de nombreux modules tiers disponibles à <a href="http://modules.apache.org/">http://modules.apache.org/</a> qui + peuvent retreindre 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/mpm_common.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.unixtools.org/">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/mpm_common.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> + + <div class="example"><p><code> + <Directory /> <br /> + AllowOverride None <br /> + </Directory> + </code></p></div> + + <p>Ceci interdit l'utilisation des fichiers <code>.htaccess</code> dans + tous les répertoires, sauf ceux pour lesquels c'est explicitement + autorisé.</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> + + <div class="example"><p><code> + <Directory /> <br /> + Order Deny,Allow <br /> + Deny from all <br /> + </Directory> + </code></p></div> + + <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> + + <div class="example"><p><code> + <Directory /usr/users/*/public_html> <br /> + Order Deny,Allow <br /> + Allow from all <br /> + </Directory> <br /> + <Directory /usr/local/httpd> <br /> + Order Deny,Allow <br /> + Allow from all <br /> + </Directory> + </code></p></div> + + <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. + Si vous utilisez Apache version 1.3 ou supérieure, nous vous conseillons + fortement d'inclure la ligne suivante dans le fichier de configuration de + votre serveur :</p> + + <div class="example"><p><code> + UserDir disabled root + </code></p></div> + + </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> + + <div class="example"><p><code> + <Files ~ "^\.ht"> <br /> + Order allow,deny <br /> + Deny from all <br /> + </Files> + </code></p></div> + + </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 id="footer"> +<p class="apache">Copyright 2009 The Apache Software Foundation.<br />Authorisé 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="../faq/">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div> +</body></html>
\ No newline at end of file diff --git a/docs/manual/misc/security_tips.xml.fr b/docs/manual/misc/security_tips.xml.fr new file mode 100644 index 0000000000..a93c720cd4 --- /dev/null +++ b/docs/manual/misc/security_tips.xml.fr @@ -0,0 +1,461 @@ +<?xml version="1.0" encoding="ISO-8859-1" ?> +<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> +<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> +<!-- English revision : 686267 --> +<!-- French translation : Lucien GENTIS --> +<!-- Reviewed by : Vincent Deffontaines --> + +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> + +<manualpage metafile="security_tips.xml.meta"> + <parentdocument href="./">Documentations diverses</parentdocument> + + <title>Conseils sur la sécurité</title> + + <summary> + <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> + </summary> + + <section id="uptodate"><title>Maintenez votre serveur à jour</title> + + <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> + + </section> + + <section id="dos"> + + <title>Attaques de type "Déni de service" + (Denial of Service - DoS)</title> + + <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 valeur de la directive + <directive module="core">TimeOut</directive> doit être diminuée sur les + sites sujets aux attaques DoS. Une valeur de quelques secondes devrait + convenir. Cependant, comme <directive module="core">TimeOut</directive> + 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 + <directive module="core">KeepAliveTimeout</directive> 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 + <directive module="core">KeepAlive</directive>, 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 + <directive module="core">LimitRequestBody</directive>, + <directive module="core">LimitRequestFields</directive>, + <directive module="core">LimitRequestFieldSize</directive>, + <directive module="core">LimitRequestLine</directive>, et + <directive module="core">LimitXMLRequestBody</directive> 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 <directive module="core">AcceptFilter</directive> 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 <directive + module="mpm_common">MaxClients</directive> 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 expérimental + <module>event</module> utilisera un traitement asynchrone afin de ne pas + dédier un thread à chaque connexion. Il est en cours d'étude à + l'heure actuelle et n'est pas encore entièrement implémenté. En + particulier, le mpm <module>event</module> est actuellement incompatible + avec le module <module>mod_ssl</module> ainsi que d'autres filtres + en entrée.</li> + + <li>Il existe de nombreux modules tiers disponibles à <a + href="http://modules.apache.org/">http://modules.apache.org/</a> qui + peuvent retreindre les comportements de certains clients et ainsi + minimiser les problèmes de DoS.</li> + + </ul> + + </section> + + + <section id="serverroot"> + + <title>Permissions sur les répertoires de la racine du serveur</title> + + <p>Typiquement, Apache est démarré par l'utilisateur root, puis il devient + la propriété de l'utilisateur défini par la directive <directive + module="mpm_common">User</directive> 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> + + <example> + 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 + </example> + + <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 <program>httpd</program>, vous + devez vous assurer qu'il possède des protections similaires :</p> + + <example> + 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 + </example> + + <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 + <program>httpd</program> 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> + + </section> + + <section id="ssi"> + + <title>Inclusions côté serveur</title> + + <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 + <directive module="core">Options</directive>. 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 + <directive module="mod_alias">ScriptAlias</directive>.</p> + + </section> + + <section id="cgi"> + + <title>Les CGI en général</title> + + <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.unixtools.org/">CGIWrap</a>.</p> + + </section> + + <section id="nsaliasedcgi"> + + <title>CGI sans alias de script</title> + + <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> + + </section> + + <section id="saliasedcgi"> + + <title>CGI avec alias de script</title> + + <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> + + </section> + + <section id="dynamic"> + + <title>Autres sources de contenu dynamique</title> + + <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 + <directive module="mpm_common">User</directive>), 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> + + </section> + + <section id="systemsettings"> + + <title>Protection de la configuration du système</title> + + <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> + + <example> + <Directory /> <br /> + AllowOverride None <br /> + </Directory> + </example> + + <p>Ceci interdit l'utilisation des fichiers <code>.htaccess</code> dans + tous les répertoires, sauf ceux pour lesquels c'est explicitement + autorisé.</p> + + </section> + + <section id="protectserverfiles"> + + <title>Protection par défaut des fichiers du serveur</title> + + <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> + + <example> + # cd /; ln -s / public_html <br /> + puis accès à <code>http://localhost/~root/</code> + </example> + + <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> + + <example> + <Directory /> <br /> + Order Deny,Allow <br /> + Deny from all <br /> + </Directory> + </example> + + <p>ceci va interdire l'accès par défaut à tous les fichiers du système de + fichiers. Vous devrez ensuite ajouter les blocs + <directive module="core">Directory</directive> appropriés correspondant + aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,</p> + + <example> + <Directory /usr/users/*/public_html> <br /> + Order Deny,Allow <br /> + Allow from all <br /> + </Directory> <br /> + <Directory /usr/local/httpd> <br /> + Order Deny,Allow <br /> + Allow from all <br /> + </Directory> + </example> + + <p>Portez une attention particulière aux interactions entre les directives + <directive module="core">Location</directive> et + <directive module="core">Directory</directive> ; 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 + <directive module="mod_userdir">UserDir</directive> ; la positionner à + <code>"./"</code> aurait le même effet, pour root, que le premier exemple plus haut. + Si vous utilisez Apache version 1.3 ou supérieure, nous vous conseillons + fortement d'inclure la ligne suivante dans le fichier de configuration de + votre serveur :</p> + + <example> + UserDir disabled root + </example> + + </section> + + <section id="watchyourlogs"> + + <title>Surveillez vos journaux</title> + + <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> + + <example> + grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br /> + grep "client denied" error_log | tail -n 10 + </example> + + <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> + + <example> + [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied + by server configuration: /usr/local/apache/htdocs/.htpasswd + </example> + + <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> + + <example> + foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1" + </example> + + <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> + + <example> + <Files ~ "^\.ht"> <br /> + Order allow,deny <br /> + Deny from all <br /> + </Files> + </example> + + </section> + +</manualpage> diff --git a/docs/manual/misc/security_tips.xml.meta b/docs/manual/misc/security_tips.xml.meta index e63cccdf2b..a8c89c44e9 100644 --- a/docs/manual/misc/security_tips.xml.meta +++ b/docs/manual/misc/security_tips.xml.meta @@ -8,6 +8,7 @@ <variants> <variant>en</variant> + <variant>fr</variant> <variant outdated="yes">ko</variant> <variant>tr</variant> </variants> |