security_tips.html.fr revision 51b60896224b408a35684bd6ec0fafe5e4abe322
<?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">
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 rel="stylesheet" type="text/css" href="/style/css/prettify.css" />
</script>
<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.5</p>
<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.5</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="/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>
(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="#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="#merging">Fusion des sections de configuration</a></li>
</ul></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 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
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#limitrequestfieldsize">LimitRequestFieldSize</a></code>,
<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>
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
<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 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
cr�er le r�pertoire en tant que root, avec des commandes du style :</p>
<div class="example"><p><code>
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
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>
</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 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
<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,
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
<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
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
<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 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 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
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 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 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 />
</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>
Order Deny,Allow <br />
Allow from all <br />
</Directory> <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#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>
<div class="example"><p><code>
UserDir disabled root
</code></p></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
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 "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
</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>
</code></p></div>
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 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="directive">mod_access_compat</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="/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 2012 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="/faq/">FAQ</a> | <a href="/glossary.html">Glossaire</a> | <a href="/sitemap.html">Plan du site</a></p></div><script type="text/javascript">
if (typeof(prettyPrint) !== undefined) {
prettyPrint();
}
</script>
</body></html>