summaryrefslogtreecommitdiffstats
path: root/docs/manual/misc/security_tips.html.tr.utf8
blob: 16e196f556339882c04b2b6cfcd3406e20eb55e1 (plain)
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
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="tr" xml:lang="tr"><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
<!--
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              This file is generated from xml source: DO NOT EDIT
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      -->
<title>Güvenlik İpuçları - Apache HTTP Sunucusu Sürüm 2.5</title>
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="../style/css/prettify.css" />
<script src="../style/scripts/prettify.min.js" type="text/javascript">
</script>

<link href="../images/favicon.ico" rel="shortcut icon" /></head>
<body id="manual-page"><div id="page-header">
<p class="menu"><a href="../mod/">Modüller</a> | <a href="../mod/quickreference.html">Yönergeler</a> | <a href="http://wiki.apache.org/httpd/FAQ">SSS</a> | <a href="../glossary.html">Terimler</a> | <a href="../sitemap.html">Site Haritası</a></p>
<p class="apache">Apache HTTP Sunucusu Sürüm 2.5</p>
<img alt="" src="../images/feather.png" /></div>
<div class="up"><a href="./"><img title="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> &gt; <a href="http://httpd.apache.org/">HTTP Sunucusu</a> &gt; <a href="http://httpd.apache.org/docs/">Belgeleme</a> &gt; <a href="../">Sürüm 2.5</a> &gt; <a href="./">Çeşitli Belgeler</a></div><div id="page-content"><div id="preamble"><h1>Güvenlik İpuçları</h1>
<div class="toplang">
<p><span>Mevcut Diller: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
<a href="../es/misc/security_tips.html" hreflang="es" rel="alternate" title="Español">&nbsp;es&nbsp;</a> |
<a href="../fr/misc/security_tips.html" hreflang="fr" rel="alternate" title="Français">&nbsp;fr&nbsp;</a> |
<a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
<a href="../tr/misc/security_tips.html" title="Türkçe">&nbsp;tr&nbsp;</a></p>
</div>
<div class="outofdate">Bu çeviri güncel olmayabilir. Son değişiklikler için İngilizce sürüm geçerlidir.</div>

    <p>Bir HTTP Sunucusunu ayarlarken dikkat edilmesi gerekenler ve bazı
    ipuçları.  Öneriler kısmen Apache’ye özel kısmen de genel olacaktır.</p>
  </div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#uptodate">Güncel Tutma</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#dos">Hizmet Reddi (DoS) Saldırıları</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#serverroot"><code>ServerRoot</code> Dizinlerinin İzinleri</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#ssi">Sunucu Taraflı İçerik Yerleştirme</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#cgi">CGI Genelinde</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#nsaliasedcgi"><code>ScriptAlias</code>’sız CGI</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#saliasedcgi"><code>ScriptAlias</code>’lı CGI</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#dynamic">Devingen içerikli kaynaklar</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#dynamicsec">Devingen içeriğin güvenliği</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#systemsettings">Sistem Ayarlarının Korunması</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#protectserverfiles">Sunucu dosyalarının öntanımlı olarak korunması</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#watchyourlogs">Günlüklerin İzlenmesi</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#merging">Yapılandırma bölümlerinin birleştirilmesi</a></li>
</ul><h3>Ayrıca bakınız:</h3><ul class="seealso"><li><a href="#comments_section">Yorum</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">Güncel Tutma</a><a title="Permanent link" href="#uptodate" class="permalink">&para;</a></h2>

    <p>Apache HTTP Sunucusu iyi bir güvenlik sicilinin yanında güvenlik
      konularıyla oldukça ilgili bir geliştirici topluluğuna sahiptir. Fakat,
      bir yazılımın dağıtılmasının ardından küçük ya da büyük bazı sorunların
      keşfedilmesi kaçınılmazdır. Bu sebeple, yazılım güncellemelerinden
      haberdar olmak oldukça önem kazanır. HTTP sunucunuzu doğrudan
      Apache’den temin ediyorsanız yeni sürümler ve güvenlik güncellemeleri
      ile ilgili bilgileri tam zamanında alabilmek için <a href="http://httpd.apache.org/lists.html#http-announce">Apache
      HTTP Sunucusu Duyuru Listesi</a>ne mutlaka üye olmanızı öneririz.
      Apache yazılımının üçüncü parti dağıtımlarını yapanların da buna benzer
      hizmetleri vardır.</p>

    <p>Şüphesiz, bir HTTP sunucusu, sunucu kodunda bir sorun olmasa da
      tehlike altındadır. Eklenti kodları, CGI betikleri hatta işletim
      sisteminden kaynaklanan sorunlar nedeniyle bu ortaya çıkabilir. Bu
      bakımdan, sisteminizdeki tüm yazılımların sorunları ve güncellemeleri
      hakkında bilgi sahibi olmalısınız.</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">Hizmet Reddi (DoS) Saldırıları</a><a title="Permanent link" href="#dos" class="permalink">&para;</a></h2>
    

    <p>Tüm ağ sunucuları, istemcilerin sistem kaynaklarından yararlanmalarını
      engellemeye çalışan hizmet reddi saldırılarına (HRS) maruz kalabilir.
      Bu tür saldırıları tamamen engellemek mümkün değildir, fakat
      yarattıkları sorunları azaltmak için bazı şeyler yapabilirsiniz.</p>

    <p>Çoğunlukla en etkili anti-HRS aracı bir güvenlik duvarı veya başka bir
      işletim sistemi yapılandırmasıdır. Örneğin, çoğu güvenlik duvarı
      herhangi bir IP adresinden aynı anda yapılan bağlantıların sayısına bir
      sınırlama getirmek üzere yapılandırılabilir. Böylece basit saldırılar
      engellenebilir. Ancak bunun dağıtık hizmet reddi saldırılarına (DHRS)
      karşı bir etkisi olmaz.</p>

    <p>Bunların yanında Apache HTTP Sunucusunun da sorunları azaltıcı
      tedbirler alınmasını sağlayacak bazı yapılandırmaları vardır:</p>

    <ul>
      <li><code class="directive"><a href="../mod/mod_reqtimeout.html#requestreadtimeout">RequestReadTimeout</a></code>
        yönergesi bir istemcinin isteği göndermek için harcadığı zamanı
        sınırlamayı sağlar.</li>

      <li>HRS’ye maruz kalması olası sitelerde <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code> yönergesinin değeri düşürülmelidir. Birkaç
        saniye gibi mümkün olduğunca düşük bir ayar uygun olabilir. Ancak
        <code class="directive"><a href="../mod/core.html#timeout">TimeOut</a></code> başka işlemlerde de
        kullanıldığından çok düşük değerler, örneğin, uzun süre çalışan CGI
        betiklerinde sorunlar çıkmasına sebep olabilir.</li>

      <li>HRS’ye maruz kalması olası sitelerde <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> yönergesinin değeri de düşürülebilir.
        Hatta bazı siteler başarımı arttırmak amacıyla <code class="directive"><a href="../mod/core.html#keepalive">KeepAlive</a></code> yönergesi üzerinden kalıcı
        bağlantıları tamamen kapatabilirler.</li>

      <li>Zaman aşımıyla ilgili yönergeler bakımından diğer modüller de
        araştırılmalıdır.</li>

      <li><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> ve
      <code class="directive"><a href="../mod/core.html#limitxmlrequestbody">LimitXMLRequestBody</a></code> yönergeleri,
        istemci girdileri ile tetiklenen özkaynak tüketimini sınırlamak için
        yapılandırılırken dikkatli olunmalıdır.</li>

      <li>İşletim sisteminiz desteklediği takdirde, işletim sisteminin isteği
        işleyen kısmını yüksüz bırakmak için <code class="directive"><a href="../mod/core.html#acceptfilter">AcceptFilter</a></code> yönergesinin etkin olmasını sağlamalısınız.
        Bu, Apache HTTP Sunucusunda zaten öntanımlı olarak etkindir.
        Yapacağınız şey işletim sistemi çekirdeğini buna göre yapılandırmak
        olacaktır.</li>

      <li>Sunucu tarafından özkaynakları tüketmeden aynı anda işlenebilecek
        bağlantıların sayısını sınırlamak için <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> yönergesini kullanın. Ayrıca, <a href="perf-tuning.html">başarım arttırma belgesine</a> de
        bakabilirsiniz.</li>

      <li>HRS’lerin etkilerini azaltmak için aynı andaki bağlantı sayısını
        arttırabilecek evreli <a href="../mpm.html">MPM</a>’lerden birini
        kullanmak iyi olabilir. Dahası, <code class="module"><a href="../mod/event.html">event</a></code> MPM’i
        her bağlantıya yeni bir evre atanmaması için eşzamansız işlem yapar.
        OpenSSL kütüphanesinin doğası nedeniyle
        <code class="module"><a href="../mod/event.html">event</a></code> MPM’i <code class="module"><a href="../mod/mod_ssl.html">mod_ssl</a></code> ve diğer girdi
        süzgeçleri ile henüz uyumlu değildir. Bu durumlarda,
        <code class="module"><a href="../mod/worker.html">worker</a></code> MPM'inin davranışına geri döner.</li>

      <li><a href="http://modules.apache.org/">http://modules.apache.org/</a>
        adresinde, belli istemci davranışlarını sınırlayacak ve HRS ile
        ilgili sorunları azaltmaya yardımcı olacak üçüncü parti modüller
        bulunabilir.</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"><code>ServerRoot</code> Dizinlerinin İzinleri</a><a title="Permanent link" href="#serverroot" class="permalink">&para;</a></h2>
    

    <p>Normalde, Apache root kullanıcı tarafından başlatılır ve hizmetleri
      sunarken <code class="directive"><a href="../mod/mod_unixd.html#user">User</a></code> yönergesi
      tarafından tanımlanan kullanıcının aidiyetinde çalışır. Root tarafından
      çalıştırılan komutlarda olduğu gibi, root olmayan kullanıcıların
      yapacakları değişikliklerden korunmak konusunda da dikkatli
      olmalısınız. Dosyaların sadece root tarafından yazılabilir olmasını
      sağlamak yeterli değildir, bu dizinler ve üst dizinler için de
      yapılmalıdır. Örneğin, sunucu kök dizininin
      <code>/usr/local/apache</code> olmasına karar verdiyseniz, bu dizini
      root olarak şöyle oluşturmanız önerilir:</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><code>/</code>, <code>/usr</code>, <code>/usr/local</code>
      dizinlerinde sadece root tarafından değişiklik yapılabileceği kabul
      edilir. <code class="program"><a href="../programs/httpd.html">httpd</a></code> çalıştırılabilirini kurarken de benzer
      bir önlemin alındığından emin olmalısınız:</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>Diğer kullanıcıların değişiklik yapabileceği bir dizin olarak bir
      <code>htdocs</code> dizini oluşturabilirsiniz. Bu dizine root
      tarafından çalıştırılabilecek dosyalar konulmamalı ve burada root
      tarafından hiçbir dosya oluşturulmamalıdır.</p>

    <p>Diğer kullanıcılara root tarafından yazılabilen ve çalıştırılabilen
      dosyalarda değişiklik yapma hakkını tanırsanız, onlara root
      kullanıcısını ele geçirilebilme hakkını da tanımış olursunuz. Örneğin,
      biri <code class="program"><a href="../programs/httpd.html">httpd</a></code> çalıştırılabilirini zararlı bir programla
      değiştirebilir ve o programı tekrar çalıştırdığınız sırada program
      yapacağını yapmış olur. Günlükleri kaydettiğiniz dizin herkes
      tarafından yazılabilen bir dizin olduğu takdirde, birileri bir günlük
      dosyasını bir sistem dosyasına sembolik bağ haline getirerek root
      kullanıcısının bu dosyaya ilgisiz şeyler yazmasına sebep olabilir.
      Günlüklerin dosyaları herkes tarafından yazılabilir olduğu takdirde ise
      birileri dosyaya yanıltıcı veriler girebilir.</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">Sunucu Taraflı İçerik Yerleştirme</a><a title="Permanent link" href="#ssi" class="permalink">&para;</a></h2>
    

    <p>SSI sayfaları bir sunucu yöneticisi açısından çeşitli olası risklere
      kaynaklık edebilir.</p>

    <p>İlk risk, sunucu yükündeki artış olasılığıdır. Tüm SSI sayfaları,  SSI
      kodu içersin içermesin Apache tarafından çözümlenir. Bu küçük bir artış
      gibi görünürse de bir paylaşımlı sunucu ortamında önemli bir yük haline
      gelebilir.</p>

    <p>SSI sayfaları, CGI betikleriyle ilgili riskleri de taşır. <code>exec
      cmd</code> elemanı kullanılarak bir SSI sayfasından herhangi bir CGI
      betiğini veya bir sistem programını Apache’nin aidiyetinde olduğu
      kullanıcının yetkisiyle çalıştırmak mümkündür.</p>

    <p>SSI sayfalarının yararlı özelliklerinden yararlanırken güvenliğini de
      arttırmanın bazı yolları vardır.</p>

    <p>Sunucu yöneticisi, bir başıbozuk SSI sayfasının sebep olabileceği
      zararları bertaraf etmek için <a href="#cgi">CGI Genelinde</a>
      bölümünde açıklandığı gibi <a href="../suexec.html">suexec</a>’i etkin
      kılabilir.</p>

    <p>SSI sayfalarını <code>.html</code> veya <code>.htm</code>
      uzantılarıyla etkinleştirmek tehlikeli olabilir. Bu özellikle
      paylaşımlı ve yüksek trafikli bir sunucu ortamında önemlidir. SSI
      sayfalarını normal sayfalardan farklı olarak <code>.shtml</code> gibi
      bildik bir uzantıyla etkinleştirmek gerekir. Bu, sunucu yükünü asgari
      düzeyde tutmaya ve risk yönetimini kolaylaştırmaya yarar.</p>

    <p>Diğer bir çözüm de SSI sayfalarından betik ve program çalıştırmayı
      iptal etmektir. Bu, <code class="directive"><a href="../mod/core.html#options">Options</a></code>
      yönergesine değer olarak <code>Includes</code> yerine
      <code>IncludesNOEXEC</code> vererek sağlanır. Ancak, eğer betiklerin
      bulunduğu dizinde <code class="directive"><a href="../mod/mod_alias.html#scriptalias">ScriptAlias</a></code>
      yönergesiyle CGI betiklerinin çalışması mümkün kılınmışsa,
      kullanıcıların <code>&lt;--#include virtual="..." --&gt;</code> ile bu
      betikleri  çalıştırabileceklerine dikkat ediniz.</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">CGI Genelinde</a><a title="Permanent link" href="#cgi" class="permalink">&para;</a></h2>
    

    <p>Herşeyden önce ya CGI betiğini/programını yazanlara ya da kendinizin
      CGI'deki güvenlik açıklarını (ister kasıtlı olsun ister tesadüfi)
      yakalama becerinize güvenmek zorundasınız. CGI betikleri esasen
      sisteminizdeki komutları site kullanıcılarının izinleriyle
      çalıştırırlar. Bu bakımdan dikkatle denenmedikleri takdirde oldukça
      tehlikeli olabilirler.</p>

    <p>CGI betiklerinin hepsi aynı kullanıcının aidiyetinde çalışırsa diğer
      betiklerle aralarında çelişkilerin ortaya çıkması ister istemez
      kaçınılmazdır. Örneğin A kullanıcısının B kullanıcısına garezi varsa
      bir betik yazıp B’nin CGI veritabanını silebilir. Bu gibi durumların
      ortaya çıkmaması için betiklerin farklı kullanıcıların aidiyetlerinde
      çalışmasını sağlayan ve 1.2 sürümünden beri Apache ile dağıtılan <a href="../suexec.html">suEXEC</a> diye bir program vardır. Başka bir yol
      da <a href="http://cgiwrap.sourceforge.net/">CGIWrap</a> kullanmaktır.</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"><code>ScriptAlias</code>’sız CGI</a><a title="Permanent link" href="#nsaliasedcgi" class="permalink">&para;</a></h2>
    

    <p>Kullanıcıların sitenin her yerinde CGI betiklerini çalıştırmalarına
      izin vermek ancak şu koşullarda mümkün olabilir:</p>

    <ul>
      <li>Kullanıcılarınızın kasıtlı ya da kasıtsız sistemi saldırıya açık
        hale getirecek betikler yazmayacaklarına tam güveniniz vardır.</li>
      <li>Sitenizin güvenliği zaten o kadar kötüdür ki, bir delik daha
        açılmasının mahzuru yoktur.</li>
      <li>Sitenizin sizden başka kullanıcısı yoktur ve sunucunuzu sizden
        başka hiç kimsenin ziyaret etmesi mümkün değildir.</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"><code>ScriptAlias</code>’lı CGI</a><a title="Permanent link" href="#saliasedcgi" class="permalink">&para;</a></h2>
    

    <p>CGI’yi belli dizinlerle sınırlamak yöneticiye bu dizinlerde daha iyi
      denetim imkanı sağlar. Bu kaçınılmaz olarak <code class="directive"><a href="../mod/mod_alias.html#scriptalias">ScriptAlias</a></code>’sız CGI’den çok daha
      güvenlidir, ancak bu dizinlere yazma hakkı olan kullanıcılarınız
      güvenilir kişiler olması ve site yöneticisinin de olası güvenlik
      açıklarına karşı CGI betiklerini ve programlarını denemeye istekli
      olması şartıyla.</p>

    <p>Çoğu site yöneticisi <code>ScriptAlias</code>’sız CGI yerine bu
      yaklaşımı seçer.</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">Devingen içerikli kaynaklar</a><a title="Permanent link" href="#dynamic" class="permalink">&para;</a></h2>
    

    <p>Sunucunun bir parçası gibi çalışan, <code>mod_php</code>,
      <code>mod_perl</code>, <code>mod_tcl</code> ve <code>mod_python</code>
      gibi gömülü betik çalıştırma seçenekleri sunucuyu çalıştıran
      kullanıcının aidiyetinde çalışırlar (<code class="directive"><a href="../mod/mod_unixd.html#user">User</a></code> yönergesine bakınız). Bu bakımdan bu betik
      yorumlayıcılar tarafından çalıştırılan betikler, sunucu kullanıcısının
      eriştiği herşeye erişebilirler. Bazı betik yorumlayıcıların getirdiği
      bazı sınırlamalar varsa da bunlara pek güvenmemek, gerekli sınamaları
      yine de yapmak gerekir.</p>

  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="dynamicsec" id="dynamicsec">Devingen içeriğin güvenliği</a><a title="Permanent link" href="#dynamicsec" class="permalink">&para;</a></h2>
    

    <p><code>mod_php</code>, <code>mod_perl</code> veya
      <code>mod_python</code> gibi devingen içeriği yapılandırırken
      güvenlikle ilgili değerlendirmelerin çoğu <code>httpd</code>'nin
      kapsamından çıkar ve bu modüllerin belgelerini incelemek ihtiyacı
      duyarsınız. Örneğin, PHP çoğu zaman kapalı tutulan
      <a href="http://www.php.net/manual/en/ini.sect.safe-mode.php">Güvenli
      Kip</a> ayarını etkin kılmanızı önerir. Daha fazla güvenlik için bir
      diğer örnek bir PHP eklentisi olan
      <a href="http://www.hardened-php.net/suhosin/">Suhosin</a>'dir. Bunlar
      hakkında daha ayrıntılı bilgi için her projenin kendi belgelerine
      başvurun.</p>

    <p>Apache seviyesinde, <a href="http://modsecurity.org/">mod_security</a>
      adı verilen modülü bir HTTP güvenlik duvarı gibi ele alabilir, devingen
      içeriğin güvenliğini arttırmanıza yardımcı olmak üzere inceden inceye
      yapılandırabilirsiniz.</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">Sistem Ayarlarının Korunması</a><a title="Permanent link" href="#systemsettings" class="permalink">&para;</a></h2>
    

    <p>Güvenliği gerçekten sıkı tutmak istiyorsanız, kullanıcılarınızın
      yapılandırmanızdaki güvenlik ayarlarını geçersiz kılmak için
      <code>.htaccess</code> dosyalarını kullanabilmelerinin de önüne
      geçmelisiniz. Bunu yapmanın tek bir yolu vardır.</p>

    <p>Sunucu yapılandırma dosyanıza şunu yerleştirin:</p>

    <div class="example"><p><code>
      &lt;Directory /&gt;
      <span class="indent">
        AllowOverride None
      </span>
      &lt;/Directory&gt;
    </code></p></div>

    <p>Böylece, belli dizinlerde özellikle etkinleştirilmedikçe bütün
      dizinlerde <code>.htaccess</code> dosyalarının kullanımını engellemiş
      olursunuz.</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">Sunucu dosyalarının öntanımlı olarak korunması</a><a title="Permanent link" href="#protectserverfiles" class="permalink">&para;</a></h2>
    

    <p>Apache’nin ister istemez yanlış anlaşılan yönlerinden biri öntanımlı
      erişim özelliğidir. Yani siz aksine bir şeyler yapmadıkça, sunucu normal
      URL eşleme kurallarını kullanarak bir dosyayı bulabildiği sürece onu
      istemciye sunacaktır.</p>

    <p>Örneğin, aşağıdaki durumu ele alalım:</p>

    <div class="example"><p><code>
      # cd /; ln -s / public_html
    </code></p></div>

    <p>Ve, tarayıcınıza <code>http://localhost/~root/</code> yazın.</p>

    <p>Böylece, istemcilerin tüm dosya sisteminizi gezmelerine izin vermiş
      olursunuz. Bu işlemin sonuçlarının önünü almak için sunucu yapılandırma
      dosyanıza şunları yazın:</p>

    <div class="example"><p><code>
      &lt;Directory /&gt;
      <span class="indent">
        Order Deny,Allow <br />
        Deny from all
      </span>
      &lt;/Directory&gt;
    </code></p></div>

    <p>Bu suretle, dosya sisteminize öntanımlı erişimi yasaklamış olursunuz.
      Erişime izin vermek istediğiniz dizinler için uygun <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> bölümleri eklemeniz yeterli
      olacaktır. Örnek:</p>

    <div class="example"><p><code>
      &lt;Directory /usr/users/*/public_html&gt;
      <span class="indent">
        Order Deny,Allow <br />
        Allow from all
      </span>
      &lt;/Directory&gt; <br />
      &lt;Directory /usr/local/httpd&gt;
      <span class="indent">
        Order Deny,Allow <br />
        Allow from all
      </span>
      &lt;/Directory&gt;
    </code></p></div>

    <p><code class="directive"><a href="../mod/core.html#location">Location</a></code> ve <code class="directive"><a href="../mod/core.html#directory">Directory</a></code> yönergelerinin etkileşimine de
      özellikle önem vermelisiniz; örneğin <code>&lt;Directory /&gt;</code>
      erişimi yasaklarken bir <code>&lt;Location /&gt;</code> yönergesi bunu
      ortadan kaldırabilir.</p>

    <p><code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code> yönergesi de size
      buna benzer bir oyun oynayabilir; yönergeye <code>./</code> atamasını
      yaparsanız, root kullanıcısı söz konusu olduğunda yukarıda ilk örnekteki
      durumla karşılaşırız. Sunucu yapılandırma dosyanızda aşağıdaki satırın
      mutlaka bulunmasını öneririz:</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">Günlüklerin İzlenmesi</a><a title="Permanent link" href="#watchyourlogs" class="permalink">&para;</a></h2>
    

    <p>Sunucunuzda olup biteni günü gününe bilmek istiyorsanız <a href="../logs.html">günlük dosyalarına</a> bakmalısınız. Günlük dosyaları
      sadece olup biteni raporlamakla kalmaz, sunucunuza ne tür saldırılar
      yapıldığını ve güvenlik seviyenizin yeterli olup olmadığını anlamanızı da
      sağlarlar.</p>

    <p>Bazı örnekler:</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>İlk örnek, <a href="http://online.securityfocus.com/bid/4876/info/">Apache Tomcat Source.JSP Bozuk İstek Bilgilerini İfşa Açığı</a>nı
      istismar etmeyi deneyen saldırıların sayısını verirken ikinci örnek,
      reddedilen son on istemciyi listeler; örnek:</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>Gördüğünüz gibi günlük dosyaları sadece ne olup bittiğini raporlar, bu
      bakımdan eğer istemci <code>.htpasswd</code> dosyasına erişebiliyorsa <a href="../logs.html#accesslog">erişim günlüğünüzde</a> şuna benzer bir
      kayıt görürsünüz:</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>Bu, sunucu yapılandırma dosyanızda aşağıdaki yapılandırmayı iptal
      ettiğiniz anlamına gelir:</p>

    <div class="example"><p><code>
      &lt;Files ".ht*"&gt;
      <span class="indent">
        Order allow,deny <br />
        Deny from all
      </span>
      &lt;/Files&gt;
    </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="merging" id="merging">Yapılandırma bölümlerinin birleştirilmesi</a><a title="Permanent link" href="#merging" class="permalink">&para;</a></h2>

    

    <p>Yapılandırma bölümlerinin birleştirilmesi karmaşık bir işlem olup bazı
      durumlarda yönergelere bağlıdır. Yönergeleri bir araya getirirken
      aralarındaki bağımlılıkları daima sınayın.</p>

    <p><code class="directive">mod_access_compat</code> gibi henüz yönerge katıştırma
      mantığını gerçeklememiş modüller için sonraki bölümlerdeki davranış, bu
      modüllerin yönergelerini içerip içermemesine bağlıdır. Yapılandırmada
      yönergelerin <em>yerleri değiştirildiğinde</em> fakat bir katıştırma
      yapılmadığında, yapılandırma bir değişiklik yapılana kadar miras
      alınır.</p>
  </div></div>
<div class="bottomlang">
<p><span>Mevcut Diller: </span><a href="../en/misc/security_tips.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
<a href="../es/misc/security_tips.html" hreflang="es" rel="alternate" title="Español">&nbsp;es&nbsp;</a> |
<a href="../fr/misc/security_tips.html" hreflang="fr" rel="alternate" title="Français">&nbsp;fr&nbsp;</a> |
<a href="../ko/misc/security_tips.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
<a href="../tr/misc/security_tips.html" title="Türkçe">&nbsp;tr&nbsp;</a></p>
</div><div class="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Yorum</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&amp;A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
<script type="text/javascript"><!--//--><![CDATA[//><!--
var comments_shortname = 'httpd';
var comments_identifier = 'http://httpd.apache.org/docs/trunk/misc/security_tips.html';
(function(w, d) {
    if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
        d.write('<div id="comments_thread"><\/div>');
        var s = d.createElement('script');
        s.type = 'text/javascript';
        s.async = true;
        s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
        (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
    }
    else {
        d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
    }
})(window, document);
//--><!]]></script></div><div id="footer">
<p class="apache">Copyright 2019 The Apache Software Foundation.<br /><a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a> altında lisanslıdır.</p>
<p class="menu"><a href="../mod/">Modüller</a> | <a href="../mod/quickreference.html">Yönergeler</a> | <a href="http://wiki.apache.org/httpd/FAQ">SSS</a> | <a href="../glossary.html">Terimler</a> | <a href="../sitemap.html">Site Haritası</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!--
if (typeof(prettyPrint) !== 'undefined') {
    prettyPrint();
}
//--><!]]></script>
</body></html>