Apache için ModSecurity Kullanıcı Kılavuzu

Kılavuz Sürümü 1.9 / Düzeltme 1 (6 Kasım 2005)

Copyright © 2002-2005 Thinking Stone (http://www.thinkingstone.com/)

Thinking Stone Tel: +44 20 8141 2161 Fax: +44 87 0762 3934 http://www.thinkingstone.com/ <[email protected]>

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. Eğer cevaplara çabucak ihtiyacınız varsa veya garantili cevap zamanlarına ihtiyacınız varsa Thinking Stone’dan ticari destek almayı düşünün.

$ cvs -d:pserver:[email protected]:/cvsroot/mod-security login

$ cvs -z3 -d:pserver:[email protected]:/cvsroot/mod-security \

> co mod_security

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 (Eğer yeniden başlatmaya (restart) çalışırsanız bir segfault alabilirsiniz).

# /apachehome/bin/apachectl stop

# /apachehome/bin/apachectl start

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

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.

mod_security.so (Unix için) veya mod_security.dll (Windows için) dosyalarını modules/ 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    modules/mod_security.so

SecFilterEngine On

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

SecFilterScanPOST On

·         application/x-www-form-urlencoded - form verisini iletmek için kullanılır

·         multipart/form-data - dosya iletmek için kullanılır

SecFilterSelective HTTP_Content-Type \

"!(^$|^application/x-www-form-urlencoded$|^multipart/form-data;)"

SetEnvIfNoCase Content-Type \

"^multipart/form-data;" "MODSEC_NOPOSTBUFFERING=Do not buffer file uploads"

SecFilterSelective HTTP_Transfer-Encoding "!^$"

SecFilterDefaultAction "deny,log,status:404"

Not

1.8.6’dan itibaren, eğer hayati olmayan (non-fatal) varsayılı işlem listesi (istekleri reddetmeyen bir liste, mesela 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 kabul edilemez. Eğer ModSecurity’nin “sadece algıla” modunda çalışmasını istiyorsanız bütün örtülü denetlemeleri kapatmalısınız (URL kodlama denetlemesi, Evrensel kod -Unicode- kodlama denetlemesi, cookie format denetlemesi, ve bayt aralığı kısıtlaması).

Not

Bazı işlemler varsayılı listede bulunamaz. Bunlar; id, rev, skipnext, chain, chained.

Not

1.9dev4 ile beraber evrensel kod denetimi ilk örtülü istek denetiminin parçası olduğunda Referer başlığına uygulanmaz. Bunun nedeni, bu başlığın çoğunlukla diğer web sitelerinden bilgiler içermesidir, ve bu sitelerdeki kodlamanın korunan sitenin kodlamasından farklı olmasıdır.

SecFilterInheritance Off

Not

Yapılandırma ve kural kalıtımı varsayılı olarak (by default) her zaman açıktır. Eğer kalıtım özelliği kapatılan kapsam altında alt kapsamınız varsa ve eğer bu alt kapsamda da kalıtımı kapatmak istiyorsanız kalıtımı tekrar doğrudan, direktif yardımı ile, kapatmanız gerekecektir.

·         SecFilterImport - üst kapsamdan tek bir kural dahil etmek için. Bu direktif alt kapsamda baştan başlamak için ve üst kapsamdan sadece seçilen kuralları dahil etmek için faydalıdır.

·         SecFilterRemove - hali hazırdaki kapsamdan bir kural çıkarmak için. Bu direktif üst kapsamdaki ile aynı kural kümesi ile başlamak ve sadece seçilen kuralları silmek istediğiniz zaman faydalıdır.

Not

Eğer bir hedef kural ID’si zincirin bir parçası olan kuralı gösterirse, import ve remove direktifleri sadece ID’inin gösterdiği kuralı değil bütün zinciri etkileyecektir.

SecFilter XXX id:1001

SecFilter YYY id:1002

SecFilter ZZZ id:1003

<Location /subcontext/>

    SecFilterInheritance Off

    SecFilterImport 1003

</Location>

SecFilter XXX id:1001

SecFilter YYY id:1002

SecFilter ZZZ id:1003

<Location /subcontext/>

    SecFilterRemove 1001 1002

</Location>

Not

Apache web sunucusu çok çeşitli kapsamları destekler (mesela, <Directory>, <Location>, <Files>, ...). Kapsamların birleştirildikleri sıra önemlidir. Kalıtımı ve çeşitli kapsamları birleştirmeyi denememelisiniz. Eğer birleştirmek zorundaysanız, düşündüğünüz gibi çalıştığını doğrulamak için yapılandırmayı test edin ve Apache kapsam birleştirme dokümanlarını dikkatlice okuyun: http://httpd.apache.org/docs-2.0/sections.html#mergin.

Not

Kullanıcılarınıza güvenmiyorsanız (mesela, web hizmeti veriyorsanız), ModSecurity’e ulaşmalarına asla izin vermemelisiniz. .htaccess olanağı ModSecurity yapılandırmasını uygulama kodunda tuttuğundan, kısıtlı yönetim kontrol yetki dağıtımı için faydalıdır. Ama kullanıcıların yapılandırmayı değiştirme olasılıkları olan durumlarda değil. Eğer kötü niyetli (güvensiz) bir ortamdaysanız, .htaccess özelliğini ModSecurity’i -DDISABLE_HTACCESS_CONFIG sekmesi ile derleyerek tamamen kapatmalısınız.

SecFilterInheritanceMandatory On

Not

SecFilterInheritance özelliğinin kapsamda açık olması gibi, SecFilterInheritanceMandatory özelliği de, üst kapsamda kullanılan değerler ne olursa olsun, bir kapsamda her zaman kapalıdır.

SecFilter XXX id:1001

SecFilterInheritanceMandatory On

<Location /subcontext/>

    SecFilterInheritance Off

    SecFilter YYY id:1002

    SecFilter ZZZ id:1003,mandatory

</Location>

<Location /subcontext/another/>

    SecFilterRemove 1001 1002 1003

    SecFilter QQQ id:1004

</Location>

Not

skip işlemini kullanan kurallarını içermeden veya silmeden kaçınmalısınız. Eğer çok dikkatli değilseniz, istediğinizin dışında bir şeyler yapan bir yapılandırma ile karşılaşabilirsiniz.

SecFilterCheckURLEncoding On

Not

Bu direktif multipart/form-data (dosya yükleme) kullanıldığında bir POST verisindeki kodlamayı kontrol etmez. Gerekmez çünkü bu kodlamada URL kodlama kullanılmaz.

Not

Evrensel kod ve UTF-8 kodlama hakkında daha fazla bilgi RFC 2279’da bulunabilir (http://www.faqs.org/rfcs/rfc2279.html).

SecFilterCheckUnicodeEncoding On

·         Yetersiz bayt.  UTF-8 iki, üç, dört, beş ve altı baytlık kodlamaları destekler. ModSecurity bir veya daha fazla baytın eksik olduğu durumları bulur.

·         Geçersiz kodlama. Bir çok karakterin ilk iki bitlerinin 0x80 olması gerekmektedir. Saldırganlar bunu kullanarak evrensel kod çözücülerini alt etmek için kullanabilirler.

·         Çok uzun karakterler. ASCII karakterleri evrensel kod uzayına direk olarak eşlenirler ve bu nedenle sadece 1 bayt ile gösterilirler. Ama, bir çok ASCII karakterleri iki, üç, dört, beş ve altı karakterler şeklinde de kodlanabilir ve böylece kod çözücüleri bu karakterlerin farklı karakterler olduğuna inandırabilirler (ve böylece güvenlik kontrollerini geçebilirler).

SecFilterForceByteRange 32 126

Not

Bu direktif POST içerisindeki bayt aralıklarını multipart/form-data kodlama kullanıldığında (karşıdan dosya yükleme) kontrol etmez. Bu şekilde ikili (binary) dosyaların karşıdan yüklenmesi bir problemle karşılanmaz. Ama, bu tür bir istekten parametreler alındıktan sonra geçerli bayt aralıkları kontrol edilir.

SecFilter KEYWORD

SecFilter /bin/sh

·         Sadece Windows’da, \ işaretini / işaretine çevirir.

·         /./ işaretlerini / işaretine çevirir.

·         // işaretlerini / işaretine çevirir.

·         URL kodlanmış karakterleri çözer.

·         URL kodlamayı denetleme

·         Belli aralıktaki baytları kullanmayı

SecFilter hidden

GET /one/two/three?p=visible%00hidden HTTP/1.0

SecFilter KEYWORD [ACTIONS]

·         Perl-uyumlu düzenli ifadeler yardım sayfası, http://www.pcre.org/pcre.txt

·         Perl Düzenli İfadeler, http://www.perldoc.com/perl5.6/pod/perlre.html

·         Düzenli İfadelere Hakim Olma, http://www.oreilly.com/catalog/regex/

·         Düzenli İfadeler için Google araması, http://www.google.com/search?q=regular%20expressions

·         Wikipedia girişi, http://en.wikipedia.org/wiki/Regular_expression

·         POSIX düzenli ifadeleri, http://www.wellho.net/regex/posix.html

Not

Apache 1.x ve Apache 2.x için iki farklı düzenli ifade motoru (regular expression engine) kullanılmıştır. Apache 1.x’in düzenli ifade motoru POSIX uyumludur. Apache 2.x’in düzenli ifade motoru PCRE uyumludur. Ana kural olarak, Apache 1.x’de çalışan düzenli ifadeler Apache 2.x’de de çalışır, ama diğer şekilde değil. Eğer her ikisinde de çalışması gereken kurallar yazmanız gerekirse, iyi test etmeniz gerekir.

SecFilter !php

SecFilterSelective LOCATION KEYWORD [ACTIONS]

SecFilterSelective "REMOTE_ADDR|REMOTE_HOST" KEYWORD

·         REMOTE_ADDR

·         REMOTE_HOST

·         REMOTE_USER

·         REMOTE_IDENT

·         REQUEST_METHOD

·         SCRIPT_FILENAME

·         PATH_INFO

·         QUERY_STRING

·         AUTH_TYPE

·         DOCUMENT_ROOT

·         SERVER_ADMIN

·         SERVER_NAME

·         SERVER_ADDR

·         SERVER_PORT

·         SERVER_PROTOCOL

·         SERVER_SOFTWARE

·         TIME_YEAR

·         TIME_MON

·         TIME_DAY

·         TIME_HOUR

·         TIME_MIN

·         TIME_SEC

·         TIME_WDAY

·         TIME

·         API_VERSION

·         THE_REQUEST

·         REQUEST_URI

·         REQUEST_FILENAME

·         IS_SUBREQ

·         POST_PAYLOAD - POST isteğinin gövdesini filterele

·         ARGS - filtre argümanları, QUERY_STRING|POST_PAYLOAD ile aynı

·         ARGS_NAMES - sadece değişken/parametre isimleri

·         ARGS_VALUES - sadece değişken/parametre değerleri

·         COOKIES_NAMES - sadece cookie isimleri

·         COOKIES_VALUES - sadece cookie değerleri

·         SCRIPT_UID

·         SCRIPT_GID

·         SCRIPT_USERNAME

·         SCRIPT_GROUPNAME

·         SCRIPT_MODE

·         ARGS_COUNT

·         COOKIES_COUNT

·         HEADERS

·         HEADERS_COUNT

·         HEADERS_NAMES

·         HEADERS_VALUES

·         FILES_COUNT

·         FILES_NAMES

·         FILES_SIZES

·         HTTP_header - istek başlığı "header"’ı  ara (1.9 ile beraber HEADER_header’de kullanılabilir)

·         ENV_variable - variable çevre değişkenini ara

·         ARG_variable - variable istek değişkeni/parametresini ara

·         COOKIE_name - name ismindeki cookie’yi ara

·         FILE_NAME_variable - variable isminde karşıdan yüklenen dosyayı ara

·         FILE_SIZE_variable - variable isminde karşıdan yüklenen dosyayının büyüklüğünü ara

·         OUTPUT – bütün cevap gövdesi

·         OUTPUT_STATUS – cevap durum kodu

SecFilterSelective "ARGS|!ARG_param" KEYWORD

# enable version 1 (RFC 2965) cookies

SecFilterCookieFormat 1

SecFilterNormalizeCookies On

Not

Sürüm 1.8.7’e kadar ModSecurity SecFilterCheckCookieFormat direktifini desteklerdi. 1.8.7’de yapılan yeni değişiklikler sebebiyle bu direktif şu an yürürlükten kaldırılmıştır. Yapılandırmada hala kullanılabilir ancak bir etkisi yoktur. Bu direktif 1.9.x sürümlerinde tamamen kaldırılacaktır.

SecFilterScanOutput On

SecFilterSelective OUTPUT "credit card numbers"

SecFilterSelective OUTPUT "Fatal error:" deny,status:500

ErrorDocument 500 /php-fatal-error.html

Not

skipnext ve chain işlemleri çıktı filtreleri olmadan çalışmazlar.

SecFilterOutputMimeTypes "(null) text/html text/plain"

Not

Çıktı tamponlaması (biriktirmesi, buffering) kullanılması ModSecurity’nin bütün sayfa çıktısını, ne kadar büyük olursa olsun, hafızada tutmasını sağlayacaktır. Bu nedenle hafıza tüketimi sayfa büyüklüğünün iki katından fazladır.

1.      Gözetlenmeyen bir Content-Type kullanabilir. (Performans nedenlerinden ötürü, bütün içerik tiplerinin gözetlenmesi mümkün değildir.)

2.      Çıktıyı bir şekilde kodlar. Basit bir kodlama bile gözetleme işini atlatacaktır.

SecFilterDefaultAction "deny,log,status:500"

SecFilterDefaultAction "deny,log,status:'Hello World!'"

Not

1.8.6 ile birlikte, eğer hayati olmayan bir işlem (log,pass gibi) belirtirseniz ilklendirme fazında görmezden gelineceklerdir. İlklendirme fazı, istek hakkında bilgi edinmek için dizayn edilmiştir. Hayati olmayan işlem belirtmek, isteklerin bazı kısımlarının kaçırılmasını (ModSecurity’nin dahili çalışması için) sağlardı. Bu nedenle ModSecurity’nin “sadece bul” modunda çalışmasını isterseniz bütün örtülü denetlemeleri (URL kodlama, evrensel kod, cookie formatı, bayt aralığı denetimleri) kapatmalısınız.

Not

Yardımcı veri (meta-data) işlemleri (id, rev, msg, severity) ve kuralların akışını kontrol eden işlemler (skip/skipnext, chain) SecFilterDefaultAction direktifinde bulunamazlar.

1.      İşlem listesi başına sadece bir ana işleme izin verilir. Bir “kural başına işlem” varsayılı listedeki ana işlemi iptal eder.

2.      Kural başına yapılandırmasında belirtilen işlemler varsayılı işlem listesindeki eş işlemleri iptal eder.

3.      Kısıtlı mod (SecFilterActionsRestricted direktifini görün) açıkken sadece yardımcı veri işlemleri kural başına işlem listesinde bulunabilirler.

4.      Kurallar yapılandırma zamanında (sezgisel olarak tercih edilen) veya yürütme zamanında (sezgisel olarak daha az tercih edilen) birleştirilebilirler. Aradaki farklar için okumaya devam edin.

1.9RC1’dan bu yana kullanılan SecFilterSignatureAction direktifi kural kümelerini yönetmeyi kolaylaştırır. 1.9RC1’dan önce eğer birisi kural başına işlem listesi kullanmak isteseydi bütün işlem listeleri tam olmalıydı, yani her işlem listesi ana işlemi, durum kodunu, vb. belirtmeliydi. Bu durum kuralların yapılandırma politikasından ayrılmasını çok zor kılıyordu. SecFilterSignatureAction direktifi tek bir yapılandırma kapsamında birden fazla yerde belirtilebilir ve hemen onu izleyen bütün kurallara uygulanır. Tutarlı olması açısından özel yapım işlemleri içermeyen kurallar bu direktiften işlem listelerini kalıtır. Örnek olarak:

SecFilterDefaultAction log,deny,status:500

# Aşağıdaki kural çalıştırıldığı kapsamdaki 

# işlemler ile yanıt verir

# Bir kuralın çalıştırıldığı kapsam 

# yazıldığı kapsam olmayabileceğine dikkat etmelisiniz.

# Kalıtım yolu ile bir kural birden fazla 

# kapsamda çalıştırılabilir.

SecFilter 000

# Uyarı kuralları

SecFilterSignatureAction log,pass

SecFilter 111 id:1

SecFilter 222 id:2

# Hata kuralları

SecFilterSignatureAction log,deny,status:403

SecFilter 333 id:3

SecFilter 444 id:4

# Aşağıdaki kural da, 403 durum kodu ile reddeder

SecFilter 555

SecFilterActionsRestricted ile beraber kullanıldığında bu direktif yapılandırmaya üçüncü parti kural kümelerinin konulmasını kolaylaştırır.

SecFilterSignatureAction log,deny,status:403

SecFilterActionsRestricted On

Include conf/third-party-rules.conf

Filtre eşleşmesinde isteğin devam etmesini sağlar. Bu işlem, eşleşmeyi sadece kaydetmek (başka bir işlem yapmamayı) istediğinizde kullanışlıdır.

SecFilter KEYWORD "log,pass"

Bu bir önceki filtrenin daha güçlü versiyonudur. Bu işlem uygulandıktan sonra istek diğer hiçbir filtre uygulanmadan devam edecektir:

# filtreleme işlemini yöneticinin bilgisayarından

# gelen istekler için durdur

SecFilterSelective REMOTE_ADDR "^192\.168\.2\.99$" allow

Filtre eşlemesinde işlemi kes. Durum kodu da kullanılmadığı takdirde, ModSecurity hemen HTTP 500 hata kodu dönecektir. Bir istek reddedildiğinde mod_security-action başlığı istek başlık listesine eklenecektir. Bu başlık kullanılan durum kodunu içerecektir.

İstek reddedildiğinde belirtilen HTTP durum kodunu kullan. Aşağıdaki kural:

SecFilter KEYWORD "deny,status:404"

Tetiklendiğinde "Page not found" dönecektir. Eğer yapılandırma dosyasında var ise Apache ErrorDocument direktifi tetiklenecektir. Bu nedenle eğer daha önceden belirtilen bir durum kodu için özel yapım bir hata sayfası tanımladıysanız, bu sayfa çalıştırılacak ve kullanıcıya gösterilecektir.

Filtre eşleşmesinde kullanıcıyı verilen URL’ye yönlendir. Örnek olarak:

SecFilter KEYWORD "redirect:http://www.modsecurity.org"

Bu yapılandırma direktifi her zaman HTTP durum kodunu veya deny anahtar kelimesini silecektir (override). URL virgül içermemelidir.

Filtre eşleşmesi durumunda dahili ters vekil (inverse proxy) yolu ile isteği yeniden yaz (rewrite):

SecFilter KEYWORD "proxy:http://www.example.com"

Bu işlemin çalışması için mod_proxy kurulmuş olması gerekir.

Filtre eşleşmesinde bir ikili (binary) çalıştır. İkili için tam yol belirtilmelidir:

SecFilter KEYWORD "exec:/home/ivanr/report-attack.pl"

Bu direktif var olduğunda ana işlemleri etkilemez. Bu işlem, betiği bütün çevre değişken bilgilerini sağlayarak ama parametresiz çağıracaktır. Normalde bulunan bütün CGI çevre değişkenleri sağlanacaktır.

Her filtre eşleşmesinde tek bir ikili çalıştırabilirsiniz. Bu işlem mod_security-executed başlığını istek başlıklarına ekleyecektir.

Filtre eşleşmesini Apache hata dosyasına kaydet.

Filtre eşleşmesini kaydetme. Bu aynı zamanda denetleme (audit) kaydının da olmasını engelleyecektir

Bu işlem bir veya birden fazla kuralı atlamanıza izin verir. Bu işlemi bazı isteklerde daha fazla test gerçekleştirmeyi istemediğinizde kullanacaksınız. Varsayılı olarak (by default), işlem diğer kurala atlar. Opsiyonel parametreyi sağlamanız durumunda istediğiniz kadar kural atlayabilir.

SecFilterSelective ARG_p value1 skipnext:2

SecFilterSelective ARG_p value2

SecFilterSelective ARG_p value3

Kural zincirlemesi bir çok kuralı daha büyük bir test haline getirmenize izin verir. Sadece zincirdeki en son kural zinciri etkileyecektir ama ona ulaşmak için diğer bütün kurallar da eşleşmelidir. İşte bu özelliği nasıl kullanabileceğinize bir örnek:

Yönetici hesabına sadece belli bir IP’den girilmesini istiyorum. Ama yönetici giriş paneli diğer kullanıcılar ile paylaştırılmış ve bu nedenle Apache’nin standard özelliklerini kullanamıyorum. Bu nedenle bu iki kuralı kullandım:

SecFilterSelective ARG_username admin chain

SecFilterSelective REMOTE_ADDR "!^SİZİN_IP_ADRESİNİZ_BURAYA$"

İlk kural sadece username parametresi varsa ve değeri admin ise eşleşir. Ondan sonra ikinci kural çalışır ve istekteki istemcinin adresini belli bir IP adresine eşleştirmeye çalışır. Eğer bir eşleşme olmazsa (baştaki ünlem işaretine dikkat edin) istek reddedilir.

Bir isteğe cevap vermeden belli bir milisaniye kadar bekle. Bu bazı otomatik web tarayıcılarının yavaşlatmak veya tamamen kafasını karıştırmak için kullanışlıdır. Eğer bekleme süresi çok fazla ise bazı tarayıcılar taramayı bırakır.

İşlem bilgisini denetleme (audit) kaydına kaydet.

İşlem bilgisini denetleme (audit) kaydına kaydetme.

Bu dört işlemin hepsi bir parametre ister ve ModSecurity tarafından çıktı olarak üretilen her kayıt mesajında bu parametreleri koyarlar. Buradaki fikir problemleri sınıflandırmak ve hata kayıt dosyalarına daha fazla bilgi koymabilmektir.

Her ne kadar id işlemi her hangi bir yazıyı içerebilse de, sadece tam sayıların kullanılması önerilir. Geçerli kural ID’lerinin ilerde sadece tam sayıları içermeyeceğini kimse garanti edemez. Eğer kurallarınızı halka açmayı düşünmüyorsanız, yerel aralığı kullanmalısınız: 1-99,999. Bunlar ayrılmış aralıklardır:

Aralık rezervasyonu için Ivan Ristic ile bağlantı kurun.

Bu işlemi bir kuralı veya bir kurallar zincirini alt kapsamlarda zorunlu kalıtılacak (inherited) şeklinde işaretlemek için kullanın. Daha detaylı bilgi için filtre kalıtımı bölümünü okuyun.

Örnek olarak:

SecFilter 111 mandatory

veya

SecFilter 111 mandatory,chain

SecFilter 222

Bu iki işlem, Apache’nin veya çevre değişkeninin değerini değiştirir veya kaldırır. Kullanabileceğiniz üç format vardır.

İsim ve değer:

SecFilter KEYWORD setenv:name=value

Sadece isim, bir değer olarak “1” kabul edilecektir:

SecFilter KEYWORD setenv:name

Varolan bir değişkeni, değişken isminin başına bir ünlem işareti koyarak silin:

SecFilter KEYWORD setenv:!name

·         mod_security-executed; çalıştırılan ikiliye (binary) olan yol ile

·         mod_security-action; dönülen durum kodu ile

·         mod_security-message; tespit edilen problem hakkındaki ve hata kaydına eklenen mesajla

LogFormat "%h %l %u %t \"%r\" %>s %{mod_security-body}n 

Not

Eğer istek multipart/request-data (karşıdan dosya yüklemek) tipindeyse, gerçek istek gövdesi taklit bir application/x-www-form-urlencoded içeriği ile değiştirilir. 

·         Saldırgan uygulamaya direk olarak erişir ama gerçek kaynak IP adresi olarak rasgele veya geçerli bir IP adresi koyarak bir vekilmiş gibi davranır. Eğer bu bilgiyi göz önünde bulundurarak istekleri reddetmeye başlarsak, saldırgan IP adresini değiştirip devam edecektir. Sonuç olarak saldırgan uygulamanın açıklıklarını bulmaya çalışırken geçerli kullanıcıları reddetmiş oluruz.

ModSecurity her zaman dosyaları geçici bir dizine yükleyecektir. Bu dizini SecUploadDir direktifi ile belirtebilirsiniz:

SecUploadDir /tmp

Sadece web sunucu kullanıcısının ulaşabileceği bir dosya alanın kullanılması daha iyidir. Öteki türlü, diğer sunucu kullanıcıları web sunucu tarafından yüklenen dosyalara erişebilirler.

Web sunucusundan uygulamaya geçmeden dosyaların doğruluklarını sağlayacak harici bir betik çalıştırmayı seçebilirsiniz. SecUploadApproveScript direktifi bu fonksiyonu kullanmaya açar. Aşağıdaki örnekte ki gibi:

SecUploadApproveScript /full/path/to/the/script.sh

Betiğe komut satırından sadece bir parametre sağlanır – karşıdan yüklenen dosyanın tam yolu. Betik dosya ile istediği her şeyi yapabilir. Dosyayı işledikten sonra, cevabını standard çıktıya (stdout) yazmalıdır. Eğer cevabının ilk karakteri “1” olursa dosya kabul edilir. Bunun dışında herşey dosyanın reddedilmesine sebep olur. Betiğiniz satırın geri kalanını daha yararlı bir hata mesajı için kullanabilir. Bu mesaj hata ayıklama kaydına (debug log) yazılacaktır.

Web sunucu aracılığı ile karşıdan yüklediğiniz dosyaları tutmak isteyebilirsiniz. Aşağıdaki satırı yapılandırmanıza ekleyin:

SecUploadKeepFiles On

SecUploadDir direktifi tarafından belirtilen yere dosyalarınız depolanacaktır. Eğer sadece seçtiğiniz bazı dosyalarınızı tutmak istiyorsanız:

SecUploadKeepFiles RelevantOnly

Böylece sadece ilgili olarak tanımlanmış isteklerinize ait dosyalar depolanacaktır.

Geri plandaki diğer programlarınızla etkileşime izin vermek için (mesela daha sonra açıklanacağı gibi ClamAV), 1.9dev1 ile birlikte dosyalar, grup okumasına izin verecek şekilde gevşetilmiş izinlerle oluşturulmaktadırlar. Bunu yapmak için, Apache’nin httpd ve geri plandaki programın clamav olarak koştuğunu farzedersek:

# mkdir /tmp/webfiles

# chown httpd:clamav /tmp/webfiles

# chmod 2750 /tmp/webfiles

Bu yapılandırma sonrası, clamav kullanıcısı dizine ulaşabilecektir. Aynı şey, clamav grup sahibi olduğundan, diğer dosyalar için de geçerlidir. Dosyaları /tmp/webfiles dizinine yüklemek için SecUploadDir direktifini kullanmayı unutmayın.

ModSecurity, dosya kabul mekanizmasını ClamAV virüs tarayıcısı ile bütünleştirmek için bir betik içerir. Bu özellikle, karşıdan dosya yükleme yolu ile web sunucusuna bulaşan virüsleri ve etkileyen açıklıkları engellemek için kullanışlıdır.

#!/usr/bin/perl

#

# modsec-clamscan.pl

# mod_security, http://www.modsecurity.org

# Copyright (c) 2002-2004 Ivan Ristic <[email protected]>

#

# $Id: modsecurity-manual.xml,v 1.7 2005/11/01 13:59:55 ivanr Exp $

#

# This script is an interface between mod_security and its

# ability to intercept files being uploaded through the

# web server, and ClamAV

# by default use the command-line version of ClamAV,

# which is slower but more likely to work out of the

# box

$CLAMSCAN = "/usr/bin/clamscan";

# using ClamAV in daemon mode is faster since the

# anti-virus engine is already running, but you also

# need to configure file permissions to allow ClamAV,

# usually running as a user other than the one Apache

# is running as, to access the files

# $CLAMSCAN = "/usr/bin/clamdscan";

if (@ARGV != 1) {

    print "Usage: modsec-clamscan.pl <filename>\n";

    exit;

}

my ($FILE) = @ARGV;

$cmd = "$CLAMSCAN --stdout --disable-summary $FILE";

$input = `$cmd`;

$input =~ m/^(.+)/;

$error_message = $1;

$output = "0 Unable to parse clamscan output [$1]";

if ($error_message =~ m/: Empty file\.$/) {

    $output = "1 empty file";

}

elsif ($error_message =~ m/: (.+) ERROR$/) {

    $output = "0 clamscan: $1";

}

elsif ($error_message =~ m/: (.+) FOUND$/) {

    $output = "0 clamscan: $1";

}

elsif ($error_message =~ m/: OK$/) {

    $output = "1 clamscan: OK";

}

print "$output\n";

Apache 1.x istek yakalamak için yeterli bir alt yapı sağlamaz. Ancak tamamen işlem hafızasında tutabilinen istekler yakalanabilir. Apache 1.x ile iki seçenek mevcuttur: multipart/form-data isteklerini aynı hafızada analiz etmek veya hiç analiz etmemek.

Ama Apache 2.x ile beraber ayrıştırmak (parse) isteğiniz multipart/form-data isteklerine hafızada ayrılacak büyüklüğü tanımlayabilirsiniz. Eğer istek belirttiğinizden daha fazla hafıza kaplıyorsa, geçici bir dosya kullanılacaktır. Varsayılı değer 60 KB’dir ama SecUploadInMemoryLimit direktifi kullanılarak limit değiştirilebilir:

SecUploadInMemoryLimit 125000

SecServerSignature "Microsoft-IIS/5.0"

[Fri Jun 11 04:02:28 2004] [notice] Microsoft-IIS/5.0 mod_ssl/2.8.12 OpenSSL/0.9.6b \

configured -- resuming normal operations

Not

Bu direktifin çalışması için ServerTokens için Full değerini vermeniz gerekir.

[Fri Jun 11 04:02:28 2004] [notice] mod_security/1.9dev1 configured - Apache/2.0.52 \

(Unix) PHP/4.3.10 proxy_html/2.4

ModSecurity, Apache dosya sistemi izolasyonuna, diğer bir deyişle chrooting işlemine destek verir. Chrooting, bir uygulamayı dosya sisteminin bazen “hapishane” de denilen belli bir bölümüne hapsetmektir. Chroot (change root’ın kısaltılmışı) operasyonu uygulandığında uygulama, hapishanenin dışındakilere artık ulaşamaz. Sadece root kullanıcısı hapishaneden kaçabilir. Chrooting işleminin hayati bölümlerinden bir tanesi, root ile alakalı herhangi bir şeyin (root işlerinin -processes- veya root suid ikililerinin -binary-) hapishane içine erişememesidir. Ana fikir, herhangi bir saldırgan web sunucusunu kırmayı başarsa da çok fazla bi şey yapamayacaktır, çünkü o da hapishanede olacağı için kaçacak bir yeri olmayacaktır.

Uygulamalar chrooting’e destek vermek zorunda değildirler. Chroot ikilisi (binary) kullanılarak herhangi bir uygulama chroot içinde kullanılabilir. Aşağıdaki satır:

chroot /chroot/apache /usr/local/web/bin/apachectl start

dosya sistemini /chroot/apache dizinin altında ne varsa değiştirerek Apache’yi başlatacaktır.

Ne yazık ki, işler bu kadar kolay değildir. Uygulamaların düzgün çalışmak için paylaşılan kütüphanelere (shared libraries) ve diğer bir çok dosyalara ve ikililere ihtiyaç duymaları problem yaratır. Bu nedenle, ihtiyaç duydukları dosyaların kopyalarını alıp hapishane içine koymanız gerekir. Bu kolay bir iş değildir (Apache web sunucusunu chroot yapmak üzerine bilgiler için buraya bakınız: http://www.modsecurity.org/documentation/modsecurity-apache-manual-1.9.html???).

Apache’ye chrooting işlemi yaparken sıkılmış ve işlemi daha basitleştirmek için yollar aramaya başlamıştım. Sonuç olarak, chrooting özelliğini mod_security modülünün kendisine ekleyerek bütün işlemi daha az karmaşık hale getirdim. Yapılandırma dosyasına sadece bir satır eklemeniz gerekir:

SecChrootDir /chroot/apache

ve böylece web sunucunuza başarılı bir şekilde chroot işlemini uygulamış olacaksınız.

Basitliği bir tarafa, ModSecurity chrooting işlemi diğer bir avantajı da beraberinde getirir. Harici chrooting’den (daha önce bahsedildiği gibi) farklı olarak, ModSecurity chrooting hapishanede bulunmak için extra dosyalara ihtiyaç duymaz. Chroot çağrısı web sunucu ilklendirmesinden sonra ama sürecin başlatılmasından (forking) önce yapılır. Bütün bunlardan dolayı, bütün paylaşılan kütüphaneler çoktan yüklenmiş, bütün web sunucu modülleri ilklendirilmiş ve kayıt dosyaları açılmıştır. Sadece bilgilerinizin hapishanede bulunması gerekecektir.

Ancak CGI betikleri ve sistem ikililerini çalıştırmak istediğinizde hapishaneye koymanız gereken ek dosyalar olacaktır. Bu dosyaların kendi dosya gereksinimleri olabilir. Eğer bu kategoride iseniz normalde yapacağınız gibi harici chroot prosedürünü uygulamanız gerekir.

Kimlik doğrulama için Apache tarafından kullanılan dosyalar her istek sırasında açıldıklarından hapishane içerisinde olmalıdırlar.

ClearModuleList

AddModule mod_security.c

AddModule ...

AddModule ...

AddModule ...

./httpd -l

# mkdir -p /chroot/apache/usr/local

# cd /usr/local

# mv apache /chroot/apache/usr/local

# ln -s /chroot/apache/usr/local/apache

SecChrootDir /chroot/apache

/usr/local/apache/bin/apachectl startssl

1.9dev1’de ModSecurity’nin Apache 2 sürümünde performans ölçümü için deneysel bir destek getirmiştim. İstemciler yavaş bir bağlantı üzerinde iseler betik performansının ölçülmesi bazen zordur. Cevap hem üretilip hem de istemciye yollandığından ikisini birbirinden ayırmak mümkün değildir. Performansı ölçmenin tek yolu cevabı parçalar halinde göndermeyip, sadece tam olarak üretimi bittiğinde yollamaktır. ModSecurity’nin de tam olarak yaptığı budur (güvenlik sebeplerinden) ve böylece bu durumu performans ölçümünde kullanmak mantıklı hale gelir. Üç zaman ölçümü yapılır ve sonuçlar Apache notlarında kayıt edilir. Bütün zamanlar mikrosaniye biriminde süreç başlangıcına göre ölçülür.

Bu değerleri özel yapım bir kayıt dosyasında kullanmak için şunu yapın (tekrar, bu sadece Apache 2’de çalışır):

CustomLog logs/timer_log "%h %l %u %t \"%r\" %>s %b - \

%<{mod_security-time1}n %<{mod_security-time2}n \

%<{mod_security-time2}n %D"

Kayıttaki her eleman aşağıdaki gibi gözükecektir:

82.70.94.182 - - [19/Nov/2004:11:33:52 +0000] "GET /cgi-bin/modsec-test.pl HTTP/1.1" \

200 1418 - 532 1490 13115 14120

Yukarıdaki örnekte işlemin ModSecurity’e ulaşması 532 mikrosaniye sürmüştür. ModSecurity tanımlanmış kuralları çalıştırmak için 958 mikrosaniye (1490 - 532) harcamıştır ve CGI betiğinin çıktıyı üretmesi 11652 mikrosaniye (13155 - 1490) sürmüştür ve Apache’nin isteği istemciye yollaması 965 mikrosaniye sürmüştür. 

SecFilterDebugLog logs/modsec_debug_log

SecFilterDebugLevel 4

·         0 – hiç (bu değer üretim sistemlerinde her zaman kullanılmalıdır)

·         1 – önemli olaylar (bunlar aynı zamanda error_log dosyasında da raporlanacaktır)

·         2 – bilgilendirici mesajları

·         3 – daha detaylı bilgilendirici mesajlar

Not

ModSecurity dahili olarak 9’a kadar kayıt seviyeri kullanır ama bunlar sadece hata ayıklama amaçları için faydalıdır.

SecAuditEngine On

SecAuditLog logs/audit_log

========================================

Request: 192.168.0.2 - - [[18/May/2003:11:20:43 +0100]] "GET /cgi-bin/printenv?p1=666 \

HTTP/1.0" 406 822

Handler: cgi-script

----------------------------------------

GET /cgi-bin/printenv?p1=666 HTTP/1.0

Host: wkx.dyndns.org:8080

User-Agent: mod_security regression test utility

Connection: Close

mod_security-message: Access denied with code 406. Pattern match "666" at \

ARGS_SELECTIVE

mod_security-action: 406

HTTP/1.0 406 Not Acceptable

========================================

Not

Denetleme kayıt verilerini işlerken dikkat edin. Dosyalar ağ üzerinden alınmış ama filtrelenmemiş ikili (binary) veriyi bulundurabilir. Bu veriler doğru şekilde halledilmezse tehlikerli olabilir (mesela terminal değişim karakterlerini içerebilirler).

Not

Kayıt tutma alt sistemi zamanı dolan istekleri kaydetmez.

Not

Kayıt başlıkları Date ve Server çıktı başlıklarını içermez. Bu, Apache’nin bu başlıkları cevap üretme işleminin en sonunda ekleyip bir modülün onları elde etmesini imkansız hale getimesindendir.

1.9 ile beraber ModSecurity, istekleri uyarı veya hata üretmeseler bile seçmeli olarak denetleme kaydına düşürmek için kullanılan SecAuditLogRelevantStatus direktifini destekler. Web sunucusu üzerindeki uygulamalar ile basit bir iletişim kanalı kurmak gerçekten faydalı olabilir. Mesela, eğer uygulamanın her hangi bir dahili hata durumunda veya saldırı olduğunda her zaman HTTP 500 durum kodu ile cevapladığını bilirseniz, ModSecurity’i bu tür istekleri tam olarak kayıt edecek şekilde yapılandırabilirsiniz:

SecAuditLogRelevantStatus ^5

Bu direktif bir parametre kabul eder; cevap durum kodu ile eşleşen bir düzenli ifade (regular expression). Eğer bir eşleşme olursa, işlem ilgili kabul ve kaydedilir.

If you add mod_unique_id to the Apache configuration mod_security will detect it and use the environment variable it generates (UNIQUE_ID). Its value will be written to the audit log. You could write the unique ID in an error page to the user and use it later to track and fix a false positive.

Eğer Apache yapılandırmasına mod_unique_id eklerseniz,  mod_security anlar ve ürettiği çevre değişkenini kullanır (UNIQUE_ID). Değeri denetleme kaydına yazılır. Kullanıcıya hata sayfası içerisinde

SecAuditEngine parametresi 4 değerden birini alır:

ModSecurity’i dinamik isteklerin de kaydını almasına çalışmak yapılandırmanıza bağlı olarak bazen biraz iş gerektirir. Apache teorisinde, bir isteğe cevap işleyici (handler) ismi verilen bir yapı tarafından üretilir. Eğer bir isteğe bağlanan bir işleyici varsa, dinamik bir yapı olarak düşünülmelidir. Pratikte ise, Apache dinamik sayfalar servisini işleyicileri kullanmadan da verebilir (MIME çeşidine göre modülü seçer). Bu, eğer PHP’yi ana dağıtımda gelen şekilde yapılandırırsanız olur:

AddType application/x-httpd-php .php

Bu çalışır ama tam olarak doğru değildir. Ancak, eğer yukarıdaki satırı aşağıdaki ile değiştirirseniz:

AddHandler application/x-httpd-php .php

PHP’nin normal çalışacağı gibi Apache’nin de isteğe atanmış bir işleyicisi olacak ve denetleme kaydedicisi seçmeli olarak kayıt tutabilecektir.

1.9 ile beraber denetleme kaydedicisi bir şeyin ilgili olup olmadığına karar vermek için cevap kodunu dikkate alır. Şu an itibarıyle 4xx ve 5xx ilgili sayılmaktadırlar. Bu herhangi bir web uygulamasında gelen istekler üzerinde denetleme kaydının yapılmasını kolaylaştırır. Bir hata oluştuğunda normalde vereceğiniz gibi cevap verin ama sadece cevap kodunu mesela 500’e çevirin.

Yeni denetleme kayıt çeşidi ModSecurity 1.9 ile beraber getirildi. Eski denetleme kayıt çeşidi gelişi güzel kayıt kullanımı için hala kullanışlıdır. Yeni denetleme kayıt çeşidi performansı arttırmak (paralel istekler arasında yazma işlemini senkronize etme işlemini ortadan kaldırmak için her yeni işlem için bir dosya oluşturulması), kaydı tutulan bilgi miktarını arttırmak ve gerçek zamanlı denetleme kaydı bir araya getirilmesi (aggregation) amacıyla oluşturuldu. Yeni denetleme kayıt çeşidi cevap gövdelerini (body) de kaydedebilir.

Örnek yapılandırma:

# Yes, we want to use the new format

SecAuditLogType Concurrent

# Directory where the files will be stored

# MUST NOT BE THE SAME AS THE APACHE LOGS FOLDER

SecAuditLogStorageDir /var/www/audit_log/

# The index of all files created

SecAuditLog /var/www/audit_log/index

# Choose what to log – everything (default is ABCFHZ)

SecAuditLogParts ABCDEFGHZ

Her denetleme kayıt dosyası için index dosyasında bir satır giriş oluşturulacaktır. Gerçek zamanlı denetleme kaydı bir araya getirilmesi (aggregation) gerçeklemek isteyenler kanallama kayıt mekanizmasını kullanarak denetleme kayıt girişleri hakkında bilgi almak için bir betik yapılandırmaları gerekir.

Tipik bir kayıt girişi aşağıdaki şekilde gözükür:

192.168.2.101 192.168.2.11 - - [15/Jul/2005:11:56:52 +0100] \

"POST /form.php HTTP/1.1" 403 3 "http://192.168.2.101:8080/form.php" \

"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 \

Firefox/1.0.4" G3yTd38AAAEAAAM7BLwAAAAA "-" \

/20050715/20050715-1156/20050715-115652-G3yTd38AAAEAAAM7BLwAAAAA 0 1031 \

md5:dc910f6d647d47b32ae6e47326f0ca42

Satır bir “vcombined” kayıt formatı ile başlar ama sonra aşağıdaki alanları ekler:

Tipik bir kayıt girişi aşağıdaki şekilde gözükebilir:

--67458b6b-A--

[15/Jul/2005:11:56:52 +0100] G3yTd38AAAEAAAM7BLwAAAAA \

192.168.2.11 4236 192.168.2.101 8080

--67458b6b-B--

POST /form.php HTTP/1.1

Host: 192.168.2.101:8080

User-Agent: Mozilla/5.0

Accept: */*

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-9,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://192.168.2.101:8080/form.php

Content-Type: application/x-www-form-urlencoded

Content-Length: 5

--67458b6b-C--

f=111

--67458b6b-E--

403 (Response body)

--67458b6b-F--

HTTP/1.1 403 Forbidden

Last-Modified: Fri, 08 Jul 2005 14:25:30 GMT

ETag: "decb4-3-34b96a80"

Accept-Ranges: bytes

Content-Length: 19

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html

--67458b6b-H--

Message: Pattern match "111" at POST_PAYLOAD \

[id "1"] [rev "2"] [msg "3"] [severity "4"]

Apache-Handler: application/x-httpd-php

Stopwatch: 1126536042708000 11024 (7276* 7375 9842)

--67458b6b-Z--

Kullanılabilir denetleme kayıt bölümleri:

SecGuardianLog |/path/to/httpd-guardian

CustomLog logs/modsec_custom_log \

"%h %l %u %t \"%r\" %>s %b %{mod_security-message}i" \

env=mod_security-relevant

Cookie: innocent="; nasty=payload; third="

$ ./run-test.pl

Usage: ./run-test.pl host[:port] testfile1, testfile2, ...

·         Host: hostname

·         User-Agent: mod_security regression testing utility

·         Connection: Close

# 01 Simple keyword filter

#

# mod_security is configured not to allow

# the "/cgi-bin/keyword" pattern

#

GET /cgi-bin/keyword HTTP/1.0

# 10 Keyword in POST

#

POST /cgi-bin/printenv HTTP/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 5

p=333

# 14 Redirect action (requires 302)

GET /cgi-bin/test.cgi?p=xxx HTTP/1.0

Eğer betiğiniz dosya sistemi ile uğraşıyorsa o zaman bazı yardımcı karakterlere ve yapılara dikkat etmeniz gerekir. Mesela, bir dizindeki ../ karakter kombinasyonu dizin seviyesinde bir seviye yukarı çıkmak isteği anlamına gelir.

Normalde bu karakter kombinasyonunun isteklerde bulunmasına gerek yoktur ve aşağıdaki filtreyi kullanarak yasaklayabilirsiniz:

SecFilter "\.\./"

Siteler arası betik çalıştırma (XSS) saldırıları, saldırgan Web sayfalarına HTML ve/veya JavaScript kodu enjekte eder ve sonra bu kod daha sonra diğer kullanıcılar tarafından çalıştırılır. Bu genellikle beklemediğiniz yerlere HTML eklemekle olur. Başarılı bir XSS saldırısı saldırganın oturumunuzun cookiesini elde etmesi ile ve uygulamaya tam yetki ike erişmesiyle sonuçlanabilir.

Bu saldırı için düzgün savunma parametre filtrelemesidir (yani zararlı HTML/Javascript’ların silinmesi) ama genellikle hali hazırda bulunan uygulamaları değiştirmeden korumanız gerekir. Bu aşağıdaki filtrelerden herhangi birisi ile yapılabilir:

SecFilter "<script"

SecFilter "<.+>"

İlk filtre, <script> etiketi (tag) ile yapılan JavaScript enjeksiyonuna karşı koruma sağlar. İkinci ise daha geneldir ve parametreler içerisindeki bütün HTML kodunu reddeder.

Bu tür bir filtreyi uygularken çok dikkat etmeniz gerekir çünkü bir çok uygulama parametrelerde HTML ister (mesela, CMS uygulamaları, forumlar, v.b.). Bunu seçmeli filtreleme ile başarabilirsiniz. Örneğin, ikinci filtreyi genel bir site-boyu kuralı olarak alabilir ama daha sonra belli uygulamalar için aşağıdaki kodla durumu gevşetebilirsiniz:

<Location /cms/article-update.php>

    SecFilterInheritance Off

    # other filters here ...

    SecFilterSelective "ARGS|!ARG_body" "<.+>"

</Location>

Bu kod parçası sadece isimli parametre gövdesindeki HTML’I kabul edecektir. Gerçekte bu listeye bir kaç daha fazla isimli parametre eklemek isteyebilirsiniz.

Şimdilerde bir çok web uygulaması veri manipulasyonu için çoğu zaman veritabanlarını kullanılırlar. Veritabanı erişimi büyük bir özenle güvenli hale getirilmezse, bir saldırgan gelişigüzel SQL komutlarını veritabanına enjekte edebilir. Bu da saldırganın hassas verileri okuması, değiştirmesi veya silmesi ile sonuçlanabilir.

Aşağıdaki gibi filtreler:

SecFilter "delete[[:space:]]+from"

SecFilter "insert[[:space:]]+into"

SecFilter "select.+from"

sizi bir çok SQL ile ilgili saldırıdan koruyabilir. Bunlar sadece örnektirler ve gerçekte kullandığınız veritabanı motoruna göre dikkatlice filtreler hazırlamanız gereklidir.

Web uygulamaları bazen işlemler gerçekleştirmek için işletim sistemi komutları çalıştıracak şekilde yazılırlar. Kararlı bir saldırgan bu kapsamda bir açıklık bulursa, sistemde gelişigüzei komutlar çalıştırabilir.

Aşağıdaki gibi bir filtre:

SecFilterSelective ARGS "bin/"

Unix gibi işletim sistemlerinde değişik dizinlerde bulunan ikililerin (binaries) çalıştırılmasını engeller.

Arabellek taşırması bir programın yürütme yığıtını taşırmak ve çalıştırma amacıyla assembly komutlarını ekleme tekniğidir. Bazı durumlarda aşağıdakine benzer bir satır ile bu tür saldırıları engellemek mümkündür:

SecFilterByteRange 32 126

Çünkü böylece sadece bazı bayt aralığında olan istekler kabul edilecektir. Bu tür bir korumayı kullanıp kullanmayacağınız nasıl bir uygulamanız olduğuna ve hangi karakter kodlamalarının kabul edildiğine göre değişir.

Birden fazla aralığı desteklemek isterseniz, düzenli ifadeleri (regular expression) kullanabilirsiniz. Bunun gibi bir şey kullanabilirsiniz:

SecFilterSelective THE_REQUEST "!^[\x0a\x0d\x20-\x7f]+$"

PHP uygulamalarını korumak amaçlı kod yazarken PHP’ye has özelliklerin akılda bulundurulması gerekir. Çoğu zaman kendi kendinize saldırırken çalışan bir kuralın başka bir saldırı çeşidini kaçırması kolaydır. Aşağıda bildiğim bazı durumların listesi vardır:

Bu günlerde, PHP’nin register_globals özelliğinin kullanılmasının güvenlik açıkları oluşturduğu kabul edilir, ama her zaman böyle değildir (bu özelliğin ne olduğunu bilmiyorsanız, büyük ihtimalle kullanmıyorsunuzdur, ama okumaya devam ederseniz bilginiz artmış olur). Aslında, register_globals özelliği 4.2.0 sürümüne kadar varsayılı olarak açıktı. Sonuç olarak, varolan bir çok uygulama bu özelliğe bağımlıdır (daha fazla detay için http://www.php.net/register_globals).

Eğer bir seçme şansınız varsa, bu özelliği kullanmayacak şekilde kodu değiştirmek en iyisidir. Ama o veya bu şekilde bunu yapamazsanız, bir uygulamayı bilinen bir açıklıktan ModSecurity kullanarak koruyabilirsiniz. Problemli kod parçası genellikle şu şekilde gözükür:

<?php

// this is the beginning of the page

if ($authorised) {

    // do something protected

}

// the rest of the page here

?>

Ve saldırgan bu durumu URL’ye ek bir parametre ekleyerek avantaj elde eder. Mesela, http://www.modsecurity.org/examples/test.php?authorised=1

Problemdeki parametreyi doğrudan belirten istekleri reddetmek uygulamayı bütün saldırganlardan korumaya yeterli olacaktır:

<Location /vulnerable-application/>

    SecFilterSelective ARG_authorised "!^$"

    SecFilterSelective COOKIE_authorised "!^$"

</Location>

Yukarıdaki filtre, “authorised” değişkeninin boş olmadığı bütün istekleri reddeder. Aynı zaman filtrelemeyi web sunucusunun sadece ilgili parçalarına uygulamak için <Location> başlıklarını kullandığımızı görebilirsiniz.

Tecrübelerime göre, hız farkı önemsenmez haldedir. Bir çok düzenli ifadeler (regular expressions) sadece bir kaç micro saniyede biter. Ve ModSecurity’i sadece dinamik isteklerde etkin hale getirirseniz fark daha da az olacaktır. Gerçek hayat web sitelerinde bir dinamik sayfaya erişim diğer bir çok statik sayfaya erişimi de beraberinde getirir (CSS, JavaScript, images). Performans etkisi yapılandırmanın karmaşıklığına bağlıdır. Apache 2 sürümündeki modülün performans ölçümünü kullanıp ModSecurity’nin her istekte tam olarak ne kadar zaman harcadığını görebilirsiniz. Testlerimde genellikle bir kaç yüz kural için 2-4 milisaniye idi (2 GHz işlemci üzerinde).

Bir isteği analiz etmek için, ModSecurity istek verisini hafızada tutar. Bir çok durumda istekler küçük olduğundan bu durum bir sorun yaratmaz. Ama, web sitesinin, dosyaların karşıdan yüklendiği bölümlerinde bir problem oluşturabilir. Bu problemi önlemek için web sitesinin o bölümlerinde istek gövde (body) tamponlamasını kapatmanız gerekir (Bu sadece Apache 1.x sürümünde bir problem yaratır. Apache 2.x bir istek saklamak için çok büyük olduğunda disk üzerinde geçici bir dosya kullanacaktır). Her durumda Apache yapılandırmasında bazı kısıtlandırmaları değerlendirmeli ve yapılandırmalısınız (İlgili direktifler LimitRequestBody, LimitRequestsFields, LimitRequestFieldsize and LimitRequestLine için http://httpd.apache.org/docs/mod/core.html#limitrequestbody).

Hata ayıklama özelliği gerçekten yardımcı olabilir ama her istek için büyük ölçülerde veriyi dosyaya yazar. Bu nedenle meşgul sunucular için bir dar boğaz yaratır. Üretim sunucularında hata ayıklama özelliğini açık tutmak için hiçbir neden yoktur.

Denetleme kayıt özelliği de aynı şekildedir ve dahası açık tutulduğunda iki dar boğaz yaratır. Öncelikle, büyük ölçülerdeki veri diske yazılır ve ikincisi dosyaya erişim senkronizasyonlu olmalıdır. Eğer yine de denetleme kaydını kullanmak istiyorsanız, senkronizasyon performans kaybını minimize etmek için bir çok denetleme kayıt dosyası (sunucuda çalışan her uygulama için) oluşturmaya çalışın (bu öneri Apache 2.x’deki performans kaybını ortadan kaldırmaz çünkü senkronizasyon merkezi bir mutex tarafından sağlanmaktadır).

·         Yapılandırma dosyasına eklediğiniz her filtrenin etkisini dikkatlice düşünmelisiniz. Özellikle erişimi, çok geniş kurallar kullanarak, kapatmak istemezsiniz. Geniş kurallar çoğunlukla yanlış artılar (false positives) yaratırlar.

·         ModSecurity .htaccess dosyalarında (bunu yapabilmek için AllowOverride Options gereklidir) kullanılabilse de, güvenmediğiniz kişiler tarafından kullanılabilecek şekilde açılmamalıdır. Eğer bu konuda paranoyaksanız, bu özelliği ModSecurity’i -DDISABLE_HTACCESS_CONFIG parametresi ile derleyebilirsiniz (apxs aracına bir parametre olarak).

·         Apache işlemeden geçersiz istekleri yakalamak artık mümkün olmalıdır

·         Diğer türlü, Apache tarafından işlenecek istekleri değerlendirmek mümkün olacaktır (mesela TRACE)

·         Sadece sunucu boyu kurallar koşacaktır. Çünkü bu noktada Apache isteği yola eşleştirmemiştir.

SecFilterSelective ARG_parameter "!^[0-9]{1,5}$"

# Reject requests with header "Content-Type" set

# to "multipart/form-data"

SecFilterSelective HTTP_CONTENT_TYPE multipart/form-data

# Only for the script that performs upload

<Location /upload.php>

    # Do not inherit filters from the parent folder

    SecFilterInheritance Off

</Location>

# Only for the FormMail script

<Location /cgi-bin/FormMail>

    # Reject request where the value of parameter "recipient"

    # does not end with "@webkreator.com"

    SecFilterSelective ARG_recipient "![a-zA-Z0-9][email protected]\.com$">

</Location>