Kılavuz Sürümü 1.9 / Düzeltme 1
(6 Kasım 2005)
Copyright © 2002-2005 Thinking Stone (http://www.thinkingstone.com/)
İçerik Tablosu
ModSecurity, web uygulamaları için açık kaynak
kodlu saldırı tespit ve önleme motorudur (engine). ModSecurity aynı zamanda web
uygulama güvenlik duvarı olarak da adlandırılabilir. ModSecurity web sunucunun
içine gömülmüş bir şekilde, güçlü bir şemsiye gibi davranarak uygulamaları
saldırılardan korumaya çalışır.
ModSecurity web saldırıları ile başa çıkma gücünüzü
arttırarak web sunucu ile bütünleşir. Bahsetmeye değer bazı özellikleri:
·
İstek filtreleme; gelen istekler, web
sunucusu veya diğer başka bir modül tarafından alınmadan önce, anında analiz
edilir. (Daha kesin olarak, ModSecurity’e ulaşmadan önce istekler
üzerinde bazı işlemeler yapılır ama bu gömülü olarak çalışmanın
gerekliliğindendir.)
·
Anti-atlatma teknikleri: yollar (paths)
ve parametreler, atlatma teknikleri ile savaşmak için analiz edilmeden önce
normalize edilirler.
·
HTTP protokolü; motor HTTP’den
anladığı için, çok spesifik ve detaylı seviyede filtreleme yapar. Örnek olarak,
bireysel parametrelere veya isimli cookie değerlerine bakmak mümkündür.
·
POST veri analizi; ModSecurity motoru
(engine) POST metodu kullanılarak gönderilen içerikleri de yakalar.
·
Denetleme kaydı; her istekğin (POST
dahil olmak üzere) bütün detayları sonradan adli analiz için kullanılabilir.
·
HTTPS filtreleme; motor web sunucusuna gömüldüğü
için, veriye şifre çözme işlemi uygulandıktan sonra erişir.
·
Sıkıştırılmış içerik filtreleme;
yukarıdaki gibi, motor, istek verisine şifre çözme işlemi uygulandıktan sonra
erişir.
ModSecurity saldırıları saptamada veya önlemede
kullanılabilir.
ModSecurity iki lisans altında kullanılabilir. Kullanıcılar, Açık
Kaynak Kodlu / Bedava Yazılım ürünü olarak GNU General Public
License (http://www.gnu.org/licenses/gpl.html)
gerekleri altında yazılımı kullanmayı tercih edebilirler. Alternatif olarak:
bireysel veya site-boyu üretim için son kullanıcı lisansları, uygulamalar, web
sunucuları veya güvenlik araçları ile kapalı kaynak dağıtımı için OEM ticari
lisansları kullanılabilir. Ticari lisanslar ile alakalı daha fazla bilgi için
lütfen Thinking Stone ile bağlantıya geçin.
Thinking <contact@thinkingstone.com>
Bu modül, Apache web sunucusunu üreten ve Apache
modül programlamayı öğrendiğim, saatlerini Apache modüllerini yapmak için
harcayan güzel insanlar olmasaydı mümkün olmazdı.
ModSecurity, Ivan Ristic ve Thinking Stone
tarafından geliştirilmiştir. Yorumlar ve özellik isteklerinizi iletebilirsiniz.
Lütfen e-maillerinizi <ivanr@webkreator.com>’a
yollayın.
Not
Lütfen destek isteklerinizi kişisel e-mail adresime
yollamayın. Destek isteklerini cevaplamaya zaman harcıyorum ama artık özel
olarak yanıtlamıyorum. Çünkü bu diğer kullanıcıların cevapları bulmak için mail
arşivlerini kullanmalarını engelliyor.
Çeviri
bedirhan urgun, e-mailleriniz için: urgunb@hotmail.com. İnteraktif bir web uygulama güvenliği
sözlüğü için: http://sozluk.enderunix.org/webappsec.
Kurulum
Kuruluma başlamadan önce, tercih ettiğiniz kurulum
metodunu seçmeniz gerekecektir. İlk olarak, CVS’ten ModSecurity’nin
en yeni versiyonunu (en iyi özelliklerle ama daha kararsız) mu kuracağınızı
veya en son kararlı dağıtımı mı kullanacağınızı seçmeniz gerekir.
Aşağıdaki bir kaç sayfa, bir metodu diğerine
seçmenizdeki avantajları hakkında size bilgiler verecek.
Bilgisayarınıza kaynak kodunu indirmek için
aşağıdaki iki komutu çalıştırmanız gerekir:
$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/mod-security login
$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/mod-security \
> co mod_security
İlk
satır sizin anonim kullanıcı olarak girişinizi sağlayacak, ve ikinci depodaki
bütün mevcut dosyaları indirecektir.
Eğer
CVS’i istemiyor ama hala en yeni sürümü istiyorsanız, gecelik
tarball’ı aşağıdaki adresten indirilebilirsiniz:
http://www.modsecurity.org/download/snapshot/mod_security-snapshot.tar.gz
Yeni
özellikler mod_security’e, her yeni değişiklikten sonra doğrulama
testleri uygulanarak bir bir eklenir. Bu, CVS’teki her sürümün her zaman
kullanılabilir olmasını sağlar.
Sabit
(kararlı) dağıtımları indirmek için http://www.modsecurity.org/download/
adresine gidin. İkili (binary) dağıtımlar her zaman hazır değildir.
Kaynaktan
kurarken iki seçeneğiniz vardır: modülü web sunucusuna kurmak,
mod_security.c’yi dinamik paylaşılan nesnesine (DSO) derlemek.
DSO
olarak kurmak daha kolaydır, ve prosedür bütün Apache dalları için aynıdır. İlk
olarak, dağıtımı bir yere açın (her hangi bir yer olur), ve modülle beraber
derleyin:
# /apachehome/bin/apxs -cia mod_security.c
Bundan
sonra Apache’yi durdurup ve başlatmanız gerekir (
# /apachehome/bin/apachectl stop
# /apachehome/bin/apachectl start
Not
apxs
aracının kurulu olmadığı platformlar hakkında insanlardan şikayet e-postaları
almıştım. Bazı Unix dağıtımlarında bu araç (apxs) ayrı bir pakette
dağıtılmaktadır. Problem bu paketin kurulum ile gelmediğinde ortaya
çıkmaktadır. Bu problemi çözmek için sağlayıcınızın verdiği ve kendi özel yapım
modülünüzü nasıl ekleyeceğinizi açıklayan dokümanını okuyun. (Bazı RedHat
platformlarında apxs aracına erişmek için http-devel paketini
kurmanızı gerekir.)
Bir
modül statik olarak derlendiğinde, web sunucunun gövdesine gömülür. Bu metod
bir miktar daha hızlı bir çalıştırılabilir (executable) üretir ama derleme
metodu (ve daha sonra yönetimi) biraz daha karmaşıktır.
$ cd <apache1-source>
$ cp <modsecurity-source>/apache1/mod_security.c ./src/modules/extra
$ ./configure \
> --activate-module=src/modules/extra/mod_security \
> --enable-module=security
Normal
olarak yaptığınız gibi web sunucusunu derleyin, kurun ve başlatın.
Apache
2.x ile statik derleme için tek yapmanız gereken modülün kaynak kodunu Apache
kaynak kodu ağacına kopyalamanız ve Apache’i yeniden yapılandırmanızdır:
$ cd <apache2-source>
$ cp <modsecurity-source>/apache2/mod_security.c ./modules/proxy
$ ./configure \
> -enable-security \
> --with-module=proxy:mod_security.c
mod_security’i
Apache 2.x kurulumuna entegre etmeyi seçebilirsiniz.
$ cd <modsecurity-source>/apache2
$ mkdir -r <apache2-source>/modules/security
$ cp mod_security.c Makefile.in config.m4 <apache2-source>/modules/security
$ cd <apache2-source>
$ ./buildconf
Bu
noktadan sonra mod_security, Apache’iye kurulum ile beraber gelen diğer
modüller gibi görünecektir ama varsayılı olarak (by default) derlenmeyecektir.
Çalışır duruma getirmek için aşağıdakileri uygulayın:
$ ./configure --enable-security
Bazı
durumlarda, modülü ikili (binary) olarak kurmak isteyeceksinizdir. Şu an
itibariyle indirmek için sadece Windows ikililerini bulunduruyorum. İkiliden
kurarken, dağıtımda büyük ihtimalle her iki Apache dalına ait iki DSO
kütüphanesine sahip olacaksınız. Kullandığınız sürüm için uygun olanı seçin.
Sonra aşağıdaki gibi devam edin:
mod_security.so (Unix
için) veya mod_security.dll (Windows için) dosyalarını libexec/ dizinine
(bu dizin Apache kurulumuna bağıldır, kaynak ağacına değil) kopyalayın. Daha
sonra httpd.conf dosyasına aşağıdaki satırı ekleyin.
LoadModule security_module libexec/mod_security.so
Hali
hazırdaki yapılandırmanıza bağlı olarak (modül yükleme sırasını açık olarak
belirtmiş olabilirsiniz) AddModule direktifi ile modülü kullanmayı
aktive etmeniz gerekebilir.
AddModule mod_security.c
Çoğu
durumunda satırı nereye eklediğiniz önemlidir. mod_security’i modül
zincirinde son olarak çalıştırmanız önerilir (ve aslında dahili chroot
özelliğini kullanmayı amaçlıyorsanız bu adım gereklidir). Daha fazla bilgi için “chroot desteği
için gerekli modül sıralaması (Apache 1.x)” bölümünü okuyun.
ModSecurity
yapılandırma direktifleri yapılandırma dosyanıza (tipik olarak httpd.conf) direk
olarak eklenir. Web sunucu çalışmaya başladığında, modülün çalışıp
çalışmayacağının belli olmadığı (modülün var olup olmadığı) durumlarda
geleneksel olarak modülün yapılandırma direktifleri <IfModule>
kap etiketlerinin (container tag) içine eklenir. Bu Apache’nin, modül
aktif olmadığı zamanlarda yapılandırma direktiflerini görmezden gelmesini
sağlar.
<IfModule mod_security.c>
# mod_security configuration directives
# ...
</IfModule>
Apache,
yapılandırma verilerinin birden fazla dosyada bulunmasına izin verdiği için
ModSecurity yapılandırma direktiflerini tek bir dosyada (mesela modsecurity.conf) gruplamak
ve httpd.conf
‘dan Include direktifi ile içermek mümkündür.
Include conf/modsecurity.conf
Varsayılı
olarak filtreleme motoru kapalıdır. İstekleri gözlemek için aşağıdakini
yapılandırma dosyanıza ekleyin:
SecFilterEngine On
Bu
parametre için desteklenen parametre değerleri:
·
On - her isteği analiz et
·
Off - hiçbirşey yapma
·
DynamicOnly - Sadece yürütme esnasında
dinamik olarak üretilen istekleri analiz et. Bu seçeneği kullanarak web
sunucunuzun değerli CPU çevrimlerini (cycle) statik dosyalar için gönderilen
istekleri kontrol etmek için harcamasına engel olabilirsiniz.
ModSecurity’nin, bir isteğin dinamik olarak üretilip üretilmediğine nasıl
karar verdiğini anlamak için "Neyin kaydedileceğini seçme" bölümünü okuyun.
İstek
gövde verisi (veya POST verisi) tarama özelliği varsayılı olarak (by default)
kapalıdır. Kullanmak için açmanız gerekir:
SecFilterScanPOST On
mod_security,
istek gövdesi için iki kodlama tipini destekler:
·
application/x-www-form-urlencoded - form
verisini iletmek için kullanılır
·
multipart/form-data - dosya
iletmek için kullanılır
Diğer
kodlamalar çoğu web uygulamaları tarafından kullanılmazlar. Sadece bu kodlama
tiplerinin web sunucusu tarafından
SecFilterSelective HTTP_Content-Type \
"!(^$|^application/x-www-form-urlencoded$|^multipart/form-data;)"
İstek bazında
POST verisi tarama özelliğini kapatmak mümkündür. Eğer ModSecurity, MODSEC_NOPOSTBUFFERING çevre
değişkeninin tanımlı olduğunu görürse POST veri taramasını yapmayacaktır.
Mesela, karşıdan dosya yüklemeleri için POST veri tamponlama özelliğini kapatmak
için aşağıdakini kullanın:
SetEnvIfNoCase Content-Type \
"^multipart/form-data;" "MODSEC_NOPOSTBUFFERING=Do not buffer file uploads"
Neden
tamponlamanın kapatıldığını açıklamak için MODSEC_NOPOSTBUFFERING
değişkenine atanan değer, hata ayıklama (debug) kaydına yazılacaktır.
İstek
bazında ModSecurity’i açmak veya kapatmak da mümkündür. Bu da MODSEC_ENABLE çevre
değişkeni ve SetEnvIf ve SetEnvIfNoCase direktifleri
ile mümkündür. Eğer MODSEC_ENABLE tanımlı
değilse SecFilterEngine ile belirlenen yapılandırma kullanılacaktır. Eğer MODSEC_ENABLE
tanımlı ise SecFilterEngine direktifinin değeri görmezden gelinecektir. MODSEC_ENABLE
değerler aynı SecFilterEngine direktifindeki gibidir: On, Off, veya DynamicOnly.
HTTP
protokolü, veri boyutunun önceden bilinmediği hallerde kullanılan bir istek
transfer metodunu destekler. İsteğin gövdesi (body) parçalar halinde ulaştırılır.
Ve metodun ismi (bölünmüş transfer kodlama) de buradan gelir. ModSecurity
şimdilik parçalanmış transfer isteklerini desteklemez; parçalanmış kodlama
kullanılan bir istek yapıldığında isteğin gövdesini (body) görmezden gelir.
Apache bu kodlama metodunu desteklese de çoğu modül (mesela, Apache 1.3.x PHP
modülü) desteklemez.
Açık
bırakıldığında bu metod saldırgana kötü amaçlı verileri gizleyerek yollama
imkanı tanır. Saldırganların bu zayıflığı gerçeklemelerini önlemek için
aşağıdaki satırı yapılandırma dosyanıza ekleyin:
SecFilterSelective HTTP_Transfer-Encoding "!^$"
Bu
durum, parçalanmış (bölünmüş) transfer kodlama kullanma yoluyla cevap yollama
kabiliyetinizi etkilemez.
Ne
zaman bir kural bir istekle eşleşse, bir veya daha fazla işlem uygulanır.
Bireysel filtreler kendi işlemlerini içerebilir ama bütün filtreler için
varsayılı bir işlem kümesi tanımlamak daha kolaydır. (İsterseniz her kural için
işlem de koyabilirsiniz.) Varsayılı işlemleri SecFilterDefaultAction
direktifi ile tanımlarsınız. Mesela, aşağıdaki satır, motoru her kural
eşleşmesinde kayıt tutacak ve isteği 404 durum kodu ile reddecek şekilde
yapılandıracaktır.
SecFilterDefaultAction "deny,log,status:404"
SecFilterDefaultAction
direktifi sadece bir parametre
Not
1.8.6’dan
itibaren, log,pass) tanımlarsanız böyle bir işlem listesi ilklendirme
(initialization) safhasında görmezden gelinecektir. İlklendirme safhası istek
hakkında bilgi edinmek için dizayn edilmiştir. Hayati olmayan işlemlere izin
vermek, isteğin bazı bölümlerinin kaybolmasına neden olacaktır. Bu bilgiler
dahili süreç için gerekli olacağından bu tür işlemler
Not
Bazı
işlemler varsayılı listede bulunamaz. Bunlar; id, rev, skipnext, chain, chained.