1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
|
<?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> |
<a href="../zh-cn/misc/security_tips.html" hreflang="zh-cn" rel="alternate" title="Simplified Chinese"> zh-cn </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 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 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.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/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.
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> |
<a href="../zh-cn/misc/security_tips.html" hreflang="zh-cn" rel="alternate" title="Simplified Chinese"> zh-cn </a></p>
</div><div id="footer">
<p class="apache">Copyright 2011 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>
</body></html>
|
