1 <?xml version="1.0" encoding="ISO-8859-1" ?>
2 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
4 <!-- English revision : 1330882 -->
5 <!-- French translation : Lucien GENTIS -->
6 <!-- Reviewed by : Vincent Deffontaines -->
9 Licensed to the Apache Software Foundation (ASF) under one or more
10 contributor license agreements. See the NOTICE file distributed with
11 this work for additional information regarding copyright ownership.
12 The ASF licenses this file to You under the Apache License, Version 2.0
13 (the "License"); you may not use this file except in compliance with
14 the License. You may obtain a copy of the License at
16 http://www.apache.org/licenses/LICENSE-2.0
18 Unless required by applicable law or agreed to in writing, software
19 distributed under the License is distributed on an "AS IS" BASIS,
20 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
21 See the License for the specific language governing permissions and
22 limitations under the License.
25 <manualpage metafile="security_tips.xml.meta">
26 <parentdocument href="./">Documentations diverses</parentdocument>
28 <title>Conseils sur la sécurité</title>
31 <p>Ce document propose quelques conseils et astuces concernant les
32 problèmes de sécurité liés
33 à l'installation d'un serveur web. Certaines suggestions seront à caractère
34 général, tandis que d'autres seront spécifiques à Apache.</p>
37 <section id="uptodate"><title>Maintenez votre serveur à jour</title>
39 <p>Le serveur HTTP Apache a une bonne réputation en matière de sécurité
40 et possède une communauté de développeurs très sensibilisés aux problèmes
41 de sécurité. Mais il est inévitable de trouver certains problèmes
42 -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour
43 cette raison qu'il est crucial de se tenir informé des mises à jour. Si
44 vous avez obtenu votre version du serveur HTTP directement depuis Apache,
45 nous vous conseillons grandement de vous abonner à la <a
46 href="http://httpd.apache.org/lists.html#http-announce">Liste de diffusion
47 des annonces du serveur HTTP</a> qui vous informera de
48 la parution des nouvelles versions et des mises à jour de sécurité. La
49 plupart des distributeurs tiers d'Apache fournissent des services
52 <p>Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le
53 code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes
54 proviennent plutôt de code ajouté, de scripts CGI, ou du système
55 d'exploitation sous-jacent. Vous devez donc vous tenir informé des
56 problèmes et mises à jour concernant tous les logiciels présents sur
57 votre système.</p>
63 <title>Attaques de type "Déni de service"
64 (Denial of Service - DoS)</title>
66 <p>Tous les services réseau peuvent faire l'objet d'attaques de type
67 "Déni de service" qui tentent de les empêcher de répondre aux clients en
68 saturant leurs ressources. Il est impossible de se prémunir totalement
69 contre ce type d'attaques, mais vous pouvez accomplir certaines actions
70 afin de minimiser les problèmes qu'elles créent.</p>
72 <p>Souvent, l'outil anti-DoS le plus efficace sera constitué par le
73 pare-feu ou certaines configurations du système d'exploitation. Par
74 exemple, la plupart des pare-feu peuvent être configurés de façon à
75 limiter le nombre de connexions simultanées depuis une adresse IP ou un
76 réseau, ce qui permet de prévenir toute une gamme d'attaques simples.
77 Bien sûr, ceci n'est d'aucun secours contre les attaques de type
78 "Déni de service" distribuées (DDoS).</p>
80 <p>Certains réglages de la configuration d'Apache peuvent aussi
81 minimiser les problèmes :</p>
84 <li>La directive <directive
85 module="mod_reqtimeout">RequestReadTimeout</directive> permet de
86 limiter le temps que met le client pour envoyer sa requête.</li>
88 <li>La valeur de la directive
89 <directive module="core">TimeOut</directive> doit être diminuée sur les
90 sites sujets aux attaques DoS. Une valeur de quelques secondes devrait
91 convenir. Cependant, comme <directive module="core">TimeOut</directive>
92 est actuellement concerné par de nombreuses opérations différentes, lui
93 attribuer une valeur trop faible peut provoquer des problèmes avec les
94 scripts CGI qui présentent un long temps de réponse.</li>
96 <li>La valeur de la directive
97 <directive module="core">KeepAliveTimeout</directive> doit aussi être
98 diminuée sur les sites sujets aux attaques DoS. Certains sites
99 désactivent même complètement le "maintien en vie" (keepalives)
100 à l'aide de la directive
101 <directive module="core">KeepAlive</directive>, ce qui bien sûr
102 présente des inconvénients en matière de performances.</li>
104 <li>Les valeurs des différentes directives fournies par d'autres modules
105 et en rapport avec des délais doivent aussi être vérifiées.</li>
108 <directive module="core">LimitRequestBody</directive>,
109 <directive module="core">LimitRequestFields</directive>,
110 <directive module="core">LimitRequestFieldSize</directive>,
111 <directive module="core">LimitRequestLine</directive>, et
112 <directive module="core">LimitXMLRequestBody</directive> doivent être
113 configurées avec prudence afin de limiter la consommation de ressources
114 induite par les demandes des clients.
117 <li>Sur les systèmes d'exploitation qui le supportent, assurez-vous que
118 la directive <directive module="core">AcceptFilter</directive> est
119 activée afin de déléguer une partie du traitement des requêtes au
120 système d'exploitation. Elle est activée par défaut dans le démon httpd
121 d'Apache, mais peut nécessiter une reconfiguration de votre noyau.</li>
123 <li>Optimisez la directive <directive
124 module="mpm_common">MaxRequestWorkers</directive> de façon à définir le nombre
125 maximum de connexions simultanées au dessus duquel les ressources
126 s'épuisent. Voir aussi la <a
127 href="perf-tuning.html">documentation sur l'optimisation des
128 performances</a>.</li>
130 <li>L'utilisation d'un <a href="../mpm.html">module mpm</a> threadé
131 vous permet de traiter d'avantage de connexions simultanées, ce qui
132 minimise l'effet des attaques DoS. Dans le futur, le module mpm
133 <module>event</module> utilisera un traitement asynchrone afin de ne pas
134 dédier un thread à chaque connexion. De par la
135 nature de la bibliothèque OpenSSL, le module mpm <module>event</module> est actuellement incompatible
136 avec le module <module>mod_ssl</module> ainsi que d'autres filtres
137 en entrée. Dans ces cas, son comportement se ramène à celui
138 du module mpm <module>worker</module>.</li>
140 <li>Il existe de nombreux modules tiers disponibles à <a
141 href="http://modules.apache.org/">http://modules.apache.org/</a> qui
142 peuvent retreindre les comportements de certains clients et ainsi
143 minimiser les problèmes de DoS.</li>
150 <section id="serverroot">
152 <title>Permissions sur les répertoires de la racine du serveur</title>
154 <p>Typiquement, Apache est démarré par l'utilisateur root, puis il devient
155 la propriété de l'utilisateur défini par la directive <directive
156 module="mod_unixd">User</directive> afin de répondre aux demandes. Comme
157 pour toutes les commandes exécutées par root, vous devez vous assurer
158 qu'elle n'est pas modifiable par les utilisateurs autres que root. Les
159 fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne
160 doivent être modifiables que par root. Par exemple, si vous avez choisi de
161 placer la racine du serveur dans <code>/usr/local/apache</code>, il est conseillé de
162 créer le répertoire en tant que root, avec des commandes du style :</p>
165 mkdir /usr/local/apache <br />
166 cd /usr/local/apache <br />
167 mkdir bin conf logs <br />
168 chown 0 . bin conf logs <br />
169 chgrp 0 . bin conf logs <br />
170 chmod 755 . bin conf logs
173 <p>Nous supposerons que <code>/</code>, <code>/usr</code> et
174 <code>/usr/local</code> ne sont modifiables que par
175 root. Quand vous installez l'exécutable <program>httpd</program>, vous
176 devez vous assurer qu'il possède des protections similaires :</p>
179 cp httpd /usr/local/apache/bin <br />
180 chown 0 /usr/local/apache/bin/httpd <br />
181 chgrp 0 /usr/local/apache/bin/httpd <br />
182 chmod 511 /usr/local/apache/bin/httpd
185 <p>Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres
186 utilisateurs -- car root ne crée ni exécute aucun fichier dans ce
187 sous-répertoire.</p>
189 <p>Si vous permettez à des utilisateurs non root de modifier des fichiers
190 que root écrit ou exécute, vous exposez votre système à une compromission
191 de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire
192 <program>httpd</program> de façon à ce que la prochaine fois que vous le
193 redémarrerez, il exécutera un code arbitraire. Si le répertoire des
194 journaux a les droits en écriture (pour un utilisateur non root), quelqu'un
195 pourrait remplacer un fichier journal par un lien symbolique vers un autre
196 fichier système, et root pourrait alors écraser ce fichier avec des données
197 arbitraires. Si les fichiers journaux eux-mêmes ont des droits en
198 écriture (pour un utilisateur non root), quelqu'un pourrait
199 modifier les journaux eux-mêmes avec des données fausses.</p>
205 <title>Inclusions côté serveur</title>
207 <p>Les inclusions côté serveur (Server Side Includes - SSI) exposent
208 l'administrateur du serveur à de nombreux risques potentiels en matière de
209 sécurité.</p>
211 <p>Le premier risque est l'augmentation de la charge du serveur. Tous les
212 fichiers où SSI est activé doivent être analysés par Apache, qu'ils
213 contiennent des directives SSI ou non. L'augmentation de la charge induite
214 est minime, mais peut devenir significative dans le contexte d'un
215 serveur partagé.</p>
217 <p>Les fichiers SSI présentent les mêmes risques que les scripts CGI en
218 général. Les fichiers où SSI est activé peuvent exécuter tout script CGI
219 ou autre programme à l'aide de la commande <code>"exec cmd"</code> avec les permissions
220 des utilisateur et groupe sous lesquels Apache s'exécute, comme défini
221 dans <code>httpd.conf</code>.</p>
223 <p>Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout
224 en tirant parti des bénéfices qu'ils apportent.</p>
226 <p>Pour limiter les dommages qu'un fichier SSI agressif pourrait causer,
227 l'administrateur du serveur peut activer<a href="../suexec.html">suexec</a>
228 comme décrit dans la section <a href="#cgi">Les CGI en général</a>.</p>
230 <p>L'activation des SSI pour des fichiers possédant des extensions
231 <code>.html</code> ou
232 <code>.htm</code> peut s'avérer dangereux. Ceci est particulièrement vrai dans un
233 environnement de serveur partagé ou étant le siège d'un traffic élevé. Les
234 fichiers où SSI est activé doivent posséder une extension spécifique, telle
235 que la conventionnelle <code>.shtml</code>. Ceci permet de limiter la charge du serveur
236 à un niveau minimum et de simplifier la gestion des risques.</p>
238 <p>Une autre solution consiste à interdire l'exécution de scripts et
239 programmes à partir de pages SSI. Pour ce faire, remplacez
240 <code>Includes</code> par <code>IncludesNOEXEC</code> dans la directive
241 <directive module="core">Options</directive>. Notez que les utilisateurs
242 pourront encore utiliser <code><--#include virtual="..." --></code> pour exécuter
243 des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
245 <directive module="mod_alias">ScriptAlias</directive>.</p>
251 <title>Les CGI en général</title>
253 <p>Tout d'abord, vous devez toujours garder à l'esprit que vous devez
254 faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à
255 vos compétences pour déceler les trous de sécurité potentiels dans les
256 CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent
257 essentiellement exécuter des commandes arbitraires sur votre système avec
258 les droits de l'utilisateur du serveur web, et peuvent par conséquent être
259 extrèmement dangereux s'ils ne sont pas vérifiés avec soin.</p>
261 <p>Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent
262 donc entrer en conflit (accidentellement ou délibérément) avec d'autres
263 scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc
264 un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez
265 utiliser le programme <a href="../suexec.html">suEXEC</a> pour faire en
266 sorte que les scripts s'exécutent sous des utilisateurs différents. Ce
267 programme est inclus dans la distribution d'Apache depuis la version 1.2
268 et est appelé à partir de certaines portions de code du serveur Apache. Une
269 autre méthode plus connue est l'utilisation de
270 <a href="http://cgiwrap.sourceforge.net/">CGIWrap</a>.</p>
274 <section id="nsaliasedcgi">
276 <title>CGI sans alias de script</title>
278 <p>Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI
279 depuis n'importe quel répertoire que dans l'éventualité où :</p>
282 <li>Vous faites confiance à vos utilisateurs pour ne pas écrire de
283 scripts qui vont délibérément ou accidentellement exposer votre
284 système à une attaque.</li>
285 <li>Vous estimez que le niveau de sécurité dans les autres parties de
286 votre site est si faible qu'un trou de sécurité de plus ou de moins
287 n'est pas très important.</li>
288 <li>Votre système ne comporte aucun utilisateur, et personne ne visite
289 jamais votre site.</li>
294 <section id="saliasedcgi">
296 <title>CGI avec alias de script</title>
298 <p>Le confinement des CGI dans des répertoires spécifiques permet à
299 l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci
300 est bien entendu mieux sécurisé que les CGI sans alias de script, mais
301 seulement à condition que les utilisateurs avec les droits en écriture sur
302 les répertoires soient dignes de confiance, et que l'administrateur ait la
303 volonté de tester chaque programme ou script CGI à la recherche d'éventuels
304 trous de sécurité.</p>
306 <p>La plupart des sites choisissent cette approche au détriment des CGI
307 sans alias de script.</p>
311 <section id="dynamic">
313 <title>Autres sources de contenu dynamique</title>
316 Les options de scripting intégrées qui s'exécutent en tant que partie du
317 serveur lui-même, comme <code>mod_php</code>, <code>mod_perl</code>,
318 <code>mod_tcl</code>, et <code>mod_python</code>,
319 s'exécutent sous le même utilisateur que le serveur (voir la directive
320 <directive module="mod_unixd">User</directive>), et par conséquent,
321 les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources
322 que le serveur. Certains moteurs de scripting peuvent proposer des
323 restrictions, mais pour plus de sûreté, il vaut mieux partir du principe
324 que ce n'est pas le cas.</p>
328 <section id="systemsettings">
330 <title>Protection de la configuration du système</title>
332 <p>Pour contrôler étroitement votre serveur, vous pouvez interdire
333 l'utilisation des fichiers <code>.htaccess</code> qui permettent de
334 passer outre les fonctionnalités de sécurité que vous avez configurées.
335 Voici un moyen pour y parvenir :</p>
337 <p>Ajoutez dans le fichier de configuration du serveur</p>
339 <highlight language="config">
345 <p>Ceci interdit l'utilisation des fichiers <code>.htaccess</code> dans
346 tous les répertoires, sauf ceux pour lesquels c'est explicitement
351 <section id="protectserverfiles">
353 <title>Protection par défaut des fichiers du serveur</title>
355 <p>Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal
356 compris. C'est à dire que, à moins que vous ne changiez explicitement ce
357 comportement, si le serveur trouve son chemin vers un fichier en suivant
358 les règles normales de correspondance URL - fichier, il peut le retourner
361 <p>Considérons l'exemple suivant :</p>
364 # cd /; ln -s / public_html <br />
365 puis accès à <code>http://localhost/~root/</code>
368 <p>Ceci permettrait aux clients de parcourir l'ensemble du système de
369 fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration
370 de votre serveur :</p>
372 <highlight language="config">
379 <p>ceci va interdire l'accès par défaut à tous les fichiers du système de
380 fichiers. Vous devrez ensuite ajouter les blocs
381 <directive module="core">Directory</directive> appropriés correspondant
382 aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,</p>
384 <highlight language="config">
385 <Directory /usr/users/*/public_html>
389 <Directory /usr/local/httpd>
395 <p>Portez une attention particulière aux interactions entre les directives
396 <directive module="core">Location</directive> et
397 <directive module="core">Directory</directive> ; par exemple, si une
398 directive <code><Directory /></code> interdit un accès, une
399 directive <code><Location /></code> pourra passer outre.</p>
401 <p>De même, soyez méfiant en jouant avec la directive
402 <directive module="mod_userdir">UserDir</directive> ; la positionner à
403 <code>"./"</code> aurait le même effet, pour root, que le premier exemple plus haut.
404 Nous vous conseillons
405 fortement d'inclure la ligne suivante dans le fichier de configuration de
408 <highlight language="config">UserDir disabled root</highlight>
412 <section id="watchyourlogs">
414 <title>Surveillez vos journaux</title>
416 <p>Pour vous tenir informé de ce qui se passe réellement dans votre
417 serveur, vous devez consulter vos
418 <a href="../logs.html">fichiers journaux</a>. Même si les fichiers journaux
419 ne consignent que des évènements qui se sont déjà produits, ils vous
420 informeront sur la nature des attaques qui sont lancées contre le serveur
421 et vous permettront de vérifier si le niveau de sécurité nécessaire est
424 <p>Quelques exemples :</p>
427 grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log <br />
428 grep "client denied" error_log | tail -n 10
431 <p>Le premier exemple listera les attaques essayant d'exploiter la
432 <a href="http://online.securityfocus.com/bid/4876/info/">vulnérabilité
433 d'Apache Tomcat pouvant provoquer la divulgation d'informations par des
434 requêtes Source.JSP mal formées</a>, le second donnera la liste des dix
435 dernières interdictions client ; par exemple :</p>
438 [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
439 by server configuration: /usr/local/apache/htdocs/.htpasswd
442 <p>Comme vous le voyez, les fichiers journaux ne consignent que ce qui
443 s'est déjà produit ; ainsi, si le client a pu accéder au fichier
444 <code>.htpasswd</code>, vous devriez avoir quelque chose du style :</p>
447 foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
450 <p>dans votre <a href="../logs.html#accesslog">journal des accès</a> ; ce
451 qui signifie que vous avez probablement mis en commentaire ce qui suit dans
452 le fichier de configuration de votre serveur :</p>
454 <highlight language="config">
462 <section id="merging">
464 <title>Fusion des sections de configuration</title>
466 <p>La fusion des sections de configuration est complexe et dépend
467 souvent des directives utilisées. Vous devez systématiquement tester
468 vos modifications pour vérifier la manière dont les directives sont
469 fusionnées.</p>
471 <p>Concernant les modules qui n'implémentent aucune logique de
472 fusion, comme <directive>mod_access_compat</directive>, le
473 comportement des sections suivantes est tributaire de la présence
474 dans ces dernières de directives appartenant à ces modules. La
475 configuration est héritée jusqu'à ce qu'une modification soit
476 effectuée ; à ce moment, la configuration est <em>remplacée</em> et
477 non fusionnée.</p>
projects / apache / blob