<-
Apache > HTTP Sunucusu > Belgeleme > Sürüm 2.4 > ?e?itli Belgeler

Güvenlik ?pu?lar?

Mevcut Diller:  en  |  fr  |  ko  |  tr 

Bir HTTP Sunucusunu ayarlarken dikkat edilmesi gerekenler ve baz? ipu?lar?. ?neriler k?smen Apache’ye ?zel k?smen de genel olacakt?r.

Support Apache!

Ayr?ca bak?n?z:

top

Güncel Tutma

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 Apache HTTP Sunucusu Duyuru Listesine 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.

?ü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.

top

Hizmet Reddi (DoS) Sald?r?lar?

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.

?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.

Bunlar?n yan?nda Apache HTTP Sunucusunun da sorunlar? azalt?c? tedbirler al?nmas?n? sa?layacak baz? yap?land?rmalar? vard?r:

top

ServerRoot Dizinlerinin ?zinleri

Normalde, Apache root kullan?c? taraf?ndan ba?lat?l?r ve hizmetleri sunarken User 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 /usr/local/apache olmas?na karar verdiyseniz, bu dizini root olarak ??yle olu?turman?z ?nerilir:

mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs

/, /usr, /usr/local dizinlerinde sadece root taraf?ndan de?i?iklik yap?labilece?i kabul edilir. httpd ?al??t?r?labilirini kurarken de benzer bir ?nlemin al?nd???ndan emin olmal?s?n?z:

cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd

Di?er kullan?c?lar?n de?i?iklik yapabilece?i bir dizin olarak bir htdocs 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.

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 httpd ?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.

top

Sunucu Tarafl? ??erik Yerle?tirme

SSI sayfalar? bir sunucu y?neticisi a??s?ndan ?e?itli olas? risklere kaynakl?k edebilir.

?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.

SSI sayfalar?, CGI betikleriyle ilgili riskleri de ta??r. exec cmd 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.

SSI sayfalar?n?n yararl? ?zelliklerinden yararlan?rken güvenli?ini de artt?rman?n baz? yollar? vard?r.

Sunucu y?neticisi, bir ba??bozuk SSI sayfas?n?n sebep olabilece?i zararlar? bertaraf etmek i?in CGI Genelinde b?lümünde a??kland??? gibi suexec’i etkin k?labilir.

SSI sayfalar?n? .html veya .htm 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 .shtml 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.

Di?er bir ??züm de SSI sayfalar?ndan betik ve program ?al??t?rmay? iptal etmektir. Bu, Options y?nergesine de?er olarak Includes yerine IncludesNOEXEC vererek sa?lan?r. Ancak, e?er betiklerin bulundu?u dizinde ScriptAlias y?nergesiyle CGI betiklerinin ?al??mas? mümkün k?l?nm??sa, kullan?c?lar?n <--#include virtual="..." --> ile bu betikleri ?al??t?rabileceklerine dikkat ediniz.

top

CGI Genelinde

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.

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 suEXEC diye bir program vard?r. Ba?ka bir yol da CGIWrap kullanmakt?r.

top

ScriptAlias’s?z CGI

Kullan?c?lar?n sitenin her yerinde CGI betiklerini ?al??t?rmalar?na izin vermek ancak ?u ko?ullarda mümkün olabilir:

top

ScriptAlias’l? CGI

CGI’yi belli dizinlerle s?n?rlamak y?neticiye bu dizinlerde daha iyi denetim imkan? sa?lar. Bu ka??n?lmaz olarak ScriptAlias’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.

?o?u site y?neticisi ScriptAlias’s?z CGI yerine bu yakla??m? se?er.

top

Devingen i?erikli kaynaklar

Sunucunun bir par?as? gibi ?al??an, mod_php, mod_perl, mod_tcl ve mod_python gibi g?mülü betik ?al??t?rma se?enekleri sunucuyu ?al??t?ran kullan?c?n?n aidiyetinde ?al???rlar (User 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.

top

Devingen i?eri?in güvenli?i

mod_php, mod_perl veya mod_python gibi devingen i?eri?i yap?land?r?rken güvenlikle ilgili de?erlendirmelerin ?o?u httpd'nin kapsam?ndan ??kar ve bu modüllerin belgelerini incelemek ihtiyac? duyars?n?z. ?rne?in, PHP ?o?u zaman kapal? tutulan Güvenli Kip ayar?n? etkin k?lman?z? ?nerir. Daha fazla güvenlik i?in bir di?er ?rnek bir PHP eklentisi olan Suhosin'dir. Bunlar hakk?nda daha ayr?nt?l? bilgi i?in her projenin kendi belgelerine ba?vurun.

Apache seviyesinde, mod_security 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.

top

Sistem Ayarlar?n?n Korunmas?

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 .htaccess dosyalar?n? kullanabilmelerinin de ?nüne ge?melisiniz. Bunu yapman?n tek bir yolu vard?r.

Sunucu yap?land?rma dosyan?za ?unu yerle?tirin:

<Directory "/">
    AllowOverride None
</Directory>

B?ylece, belli dizinlerde ?zellikle etkinle?tirilmedik?e bütün dizinlerde .htaccess dosyalar?n?n kullan?m?n? engellemi? olursunuz.

Bu ayar Apache 2.3.9 itibariyle ?ntan?ml?d?r.

top

Sunucu dosyalar?n?n ?ntan?ml? olarak korunmas?

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.

?rne?in, a?a??daki durumu ele alal?m:

# cd /; ln -s / public_html

Ve, taray?c?n?za http://localhost/~root/ yaz?n.

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:

<Directory "/">
    Require all denied
</Directory>

Bu suretle, dosya sisteminize ?ntan?ml? eri?imi yasaklam?? olursunuz. Eri?ime izin vermek istedi?iniz dizinler i?in uygun Directory b?lümleri eklemeniz yeterli olacakt?r. ?rnek:

<Directory "/usr/users/*/public_html">
    Require all granted
</Directory>
<Directory "/usr/local/httpd">
    Require all granted
</Directory>

Location ve Directory y?nergelerinin etkile?imine de ?zellikle ?nem vermelisiniz; ?rne?in <Directory "/"> eri?imi yasaklarken bir <Location "/"> y?nergesi bunu ortadan kald?rabilir.

UserDir y?nergesi de size buna benzer bir oyun oynayabilir; y?nergeye ./ 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:

UserDir disabled root
top

Günlüklerin ?zlenmesi

Sunucunuzda olup biteni günü gününe bilmek istiyorsan?z günlük dosyalar?na 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.

Baz? ?rnekler:

grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
grep "client denied" error_log | tail -n 10

?lk ?rnek, Apache Tomcat Source.JSP Bozuk ?stek Bilgilerini ?f?a A????n? istismar etmeyi deneyen sald?r?lar?n say?s?n? verirken ikinci ?rnek, reddedilen son on istemciyi listeler; ?rnek:

[Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd

G?rdü?ünüz gibi günlük dosyalar? sadece ne olup bitti?ini raporlar, bu bak?mdan e?er istemci .htpasswd dosyas?na eri?ebiliyorsa eri?im günlü?ünüzde ?una benzer bir kay?t g?rürsünüz:

foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"

Bu, sunucu yap?land?rma dosyan?zda a?a??daki yap?land?rmay? iptal etti?iniz anlam?na gelir:

<Files ".ht*">
    Require all denied
</Files>
top

Yap?land?rma b?lümlerinin birle?tirilmesi

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.

mod_access_compat 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 yerleri de?i?tirildi?inde fakat bir kat??t?rma yap?lmad???nda, yap?land?rma bir de?i?iklik yap?lana kadar miras al?n?r.

Mevcut Diller:  en  |  fr  |  ko  |  tr 

top

Yorum

Notice:
This is not a Q&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 mailing lists.
白小姐透特期期