Apache HTTP Sunucusu Sürüm 2.4
Bir HTTP Sunucusunu ayarlarken dikkat edilmesi gerekenler ve bazı ipuçları. Öneriler kısmen Apache’ye özel kısmen de genel olacaktır.
ServerRoot
Dizinlerinin İzinleriScriptAlias
’sız CGIScriptAlias
’lı CGIApache 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.
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:
RequestReadTimeout
yönergesi bir istemcinin isteği göndermek için harcadığı zamanı
sınırlamayı sağlar.TimeOut
yönergesinin değeri düşürülmelidir. Birkaç
saniye gibi mümkün olduğunca düşük bir ayar uygun olabilir. Ancak
TimeOut
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.KeepAliveTimeout
yönergesinin değeri de düşürülebilir.
Hatta bazı siteler başarımı arttırmak amacıyla KeepAlive
yönergesi üzerinden kalıcı
bağlantıları tamamen kapatabilirler.LimitRequestBody
,
LimitRequestFields
,
LimitRequestFieldSize
,
LimitRequestLine
ve
LimitXMLRequestBody
yönergeleri,
istemci girdileri ile tetiklenen özkaynak tüketimini sınırlamak için
yapılandırılırken dikkatli olunmalıdır.AcceptFilter
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.MaxRequestWorkers
yönergesini kullanın. Ayrıca, başarım arttırma belgesine de
bakabilirsiniz.event
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
event
MPM’i mod_ssl
ve diğer girdi
süzgeçleri ile henüz uyumlu değildir. Bu durumlarda,
worker
MPM'inin davranışına geri döner.ServerRoot
Dizinlerinin İzinleriNormalde, 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.
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.
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.
ScriptAlias
’sız CGIKullanıcıların sitenin her yerinde CGI betiklerini çalıştırmalarına izin vermek ancak şu koşullarda mümkün olabilir:
ScriptAlias
’lı CGICGI’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.
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.
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.
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.
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
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>
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.