Başlangıç

Mod güvenlik, Apache, Nginx ve IIS ile çalışan ücretsiz bir Web Uygulama Güvenlik Duvarıdır (WAF). Basit ve karmaşık işlemleri gerçekleştirmek için esnek bir kural motorunu destekler ve SQL injection, cross site scripting, Trojans, bad user agents, session hijacking ve diğer birçok kötüye kullanma için kurallara sahip olan bir Core Rule Set (CRS) ile gelir. Apache için, kurulumunu ve yapılandırmasını kolaylaştıran ek bir modüldür.

Bu öğreticiyi tamamlamak için sunucunuzda LAMP ‘in kurulmuş olması gerekir.

 Mod_security Kurulumu

Modsecurity Debian/Ubuntu veri havuzunda mevcuttur:

apt-get install libapache2-modsecurity

 Mod_security modülünün yüklenip yüklenmediğini doğrulayın.

apachectl -M | grep --color security

 Modülün yüklendiğini gösteren security2_module (shared) isimli bir modül görmeniz gerekiyor.

 Modsecurity kurulumu, yeniden adlandırılması gereken, önerilen bir konfigürasyon dosyası içermektedir:

mv /etc/modsecurity/modsecurity.conf{-recommended,}

 Apache’yi yeniden yükleyin

service apache2 reload

 Mod_security için Apache log dizininde yeni bir log dosyası bulacaksınız:

root@droplet:~# ls -l /var/log/apache2/modsec_audit.log
-rw-r----- 1 root root 0 Oct 19 08:08 /var/log/apache2/modsec_audit.log

Mod_security’ i Yapılandırmak

Kutunun dışında, modsecurity çalışması için kurallara ihtiyaç duyduğundan hiçbir şey yapmaz. Varsayılan yapılandırma dosyası, kural eşleşmelerine göre istekleri kaydeden ve hiçbir şeyi bloke etmeyen DetectionOnly olarak ayarlanmıştır. Bu, modsecurity.conf dosyasını düzenleyerek değiştirilebilir:

nano /etc/modsecurity/modsecurity.conf

 Bu satırı bulun

SecRuleEngine DetectionOnly

Ve buna değiştirin:

SecRuleEngine On

Bunu bir üretim sunucusunda deniyorsanız, bu direktifi sadece tüm kurallarınızı test ettikten sonra değiştirin.

Değiştirilecek başka bir direktif SecResponseBodyAccess’ tir. Bu, response body’lerin korunup korunmadığını konfigüre eder (örn; read by modsecurity). Bu yalnızca veri sızıntısı tespiti ve korunmasına ihtiyaç duyulduğunda gereklidir. Bu nedenle, On ‘da bırakarak droplet kaynaklarını kullanacak ve log dosyası boyutunu artıracaktır.

 Bunu bulun

SecResponseBodyAccess On

Ve şuna değiştirin:

SecResponseBodyAccess Off

Şimdi, web uygulamanıza gönderilebilecek maksimum verileri sınırlayacağız. Bunları iki yönerge yapılandırır:

SecRequestBodyLimit
SecRequestBodyNoFilesLimit

  SecRequestBodyLimit yönergesi maksimum POST veri boyutunu belirler. Bir istemci tarafından daha büyük herhangi bir şey gönderilirse, sunucu 413 Request Entity Too Large hatası ile yanıt verir. Web uygulamanızın herhangi dosya yüklemeleri yoksa, bu değer büyük ölçüde azaltılabilir.  

Yapılandırma dosyasında belirtilen değer şudur:  

SecRequestBodyLimit 13107200

Bu da 12.5 MB’ dir.  

Buna benzeyen SecRequestBodyNoFilesLimit yönergesidir. Tek fark, bu yönergenin Post veri boyutu eksi dosya yüklemelerini sınırlandırmasıdır—bu değer “as low as practical” olmalıdır.  

Yapılandırma dosyasındaki değer;   

SecRequestBodyNoFilesLimit 131072

bu da 128KB’ dir.  

Bu yönerge satırları boyunca, sunucu performansını etkileyen bir başka şey vardır:SecRequestBodyInMemoryLimit. Bu yönerge, büyük ölçüde açıklayıcıdır; bu “request body” verisinin (POSTed veri) ne kadarının bellekte (RAM) tutulması gerektiğini,  sabit diske daha fazlasının yerleştirileceğini belirtir (takas yapmak gibi). Droplet (sanal sunucu) SSD kullandıkları için, bu çok fazla sorun değildir; ancak yine de, depolayacak RAM alanına sahipseniz, uygun bir değerde kurulabilir.  

SecRequestBodyInMemoryLimit 131072

Yapılandırma dosyasında belirtilen değer (128KB) budur. 

SQL Bağlamayı Test Etme

Yapılandırma kuralları ile devam etmeden önce, SQL Bağlama’ya açık olan bir PHP komut dizisi oluşturacağız ve deneyeceğiz. Unutmayın ki bu, hiçbir oturum işlemesi olmayan sadece temel bir PHP giriş komut dizisidir. Veritabanına bağlanması için aşağıdaki komut dizisinde MySQL şifresini değiştirdiğinizden emin olun:

/var/www/login.php

Logged in
A Secret for you....
';
    }
    else
    {
?>
        

            Username: 

            Password: 

            
        

Bu komut dosyası bir giriş dosyası görüntüleyecek. Doğru kimlik bilgilerinin girilmesi, “Sizin için bir sır” mesajını görüntüleyecektir.

Veritabanında kimlik bilgilerine ihtiyacımız var. Bir MySQL veritabanı ve bir tablo oluşturun, ardından kullanıcı adı ve şifreleri girin.

mysql -u root -p

Bu sizi 

mysql>

 komut istemine götürecek.

create database sample;
connect sample;
create table users(username VARCHAR(100),password VARCHAR(100));
insert into users values('jesin','pwd');
insert into users values('alice','secret');
quit;

Tarayıcınızı açın,  http://yourwebsite.com/login.php sayfasına gelin ve doğru kimlik çiftini girin.

Username: jesin
Password: pwd

Başarılı girişi gösteren bir mesaj göreceksiniz. Şimdi geri gelin ve yanlış kimlik çiftini girin—Geçersiz kullanıcı adı veya şifresi mesajını göreceksiniz.

Komut isteminin doğru çalıştığını doğrulayabiliriz. Bir sonraki iş, giriş sayfasını atlamak için SQL bağlama ile elimizle denemek. Kullanıcı adı alanı için aşağıdakini girin:

' or true -- 

“—“ işaretinden sonra bir boşluk olması gerektiğini unutmayın, bu bağlama boşluk olmadan çalışmayacaktır. Şifre alanını boş bırakın ve giriş butonuna basın.

İşte! Komut, kimliği doğrulanmış kullanıcılar için yazılan mesajı gösterir.

Kuralları Koyma

Hayatınızı kolaylaştırmak için, mod_security ile birlikte kurulmuş birçok kural vardır. Bunlara CRS (Core Rule Set) denir ve

root@droplet:~# ls -l /usr/share/modsecurity-crs/
total 40
drwxr-xr-x 2 root root  4096 Oct 20 09:45 activated_rules
drwxr-xr-x 2 root root  4096 Oct 20 09:45 base_rules
drwxr-xr-x 2 root root  4096 Oct 20 09:45 experimental_rules
drwxr-xr-x 2 root root  4096 Oct 20 09:45 lua
-rw-r--r-- 1 root root 13544 Jul  2  2012 modsecurity_crs_10_setup.conf
drwxr-xr-x 2 root root  4096 Oct 20 09:45 optional_rules
drwxr-xr-x 3 root root  4096 Oct 20 09:45 util

İçinde yer alır.

Dökümantasyon,

root@droplet1:~# ls -l /usr/share/doc/modsecurity-crs/
total 40
-rw-r--r-- 1 root root   469 Jul  2  2012 changelog.Debian.gz
-rw-r--r-- 1 root root 12387 Jun 18  2012 changelog.gz
-rw-r--r-- 1 root root  1297 Jul  2  2012 copyright
drwxr-xr-x 3 root root  4096 Oct 20 09:45 examples
-rw-r--r-- 1 root root  1138 Mar 16  2012 README.Debian
-rw-r--r-- 1 root root  6495 Mar 16  2012 README.gz

 Komut dosyasında hazır bulunur.

Bu kuralları yüklemek için Apache’ ye bu dizinleri araştırmasını söylemeliyiz.  modsecurity.conf dosyasını düzenleyin.

nano /etc/apache2/mods-enabled/modsecurity.conf

  içine aşağıdaki dizinleri ekleyin.

Include "/usr/share/modsecurity-crs/*.conf"
Include "/usr/share/modsecurity-crs/activated_rules/*.conf"

activated_rules dizini Apache’nin  dizini ile benzerdir. Kurallar şu dizinlerde mevcuttur:

/usr/share/modsecurity-crs/base_rules
/usr/share/modsecurity-crs/optional_rules
/usr/share/modsecurity-crs/experimental_rules

Bunları aktif hale getirmek için  activated_rules dizininin içinde sembolik bağlantılar oluşturulmalıdır. SQL bağlama kurallarını aktive edelim.

cd /usr/share/modsecurity-crs/activated_rules/
ln -s /usr/share/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf 

Kuralların etkisini göstermesi için Apache’ nin yeniden yüklenmesi gerekir.

service apache2 reload

Şimdi, daha önce oluşturduğumuz giriş sayfasını açın ve kullanıcı adı alanında SQL bağlama sorgusunu kullanmayı deneyin. SecRuleEngine yönergesini On’ a değiştirmiş olsaydınız, bir 403 Forbidden hatasını görürdünüz. DetectionOnly seçeneğine bırakılsaydı, bağlama başarılı olur, ancak deneme modsec_audit.log  dosyasına kaydedilirdi.

Kendi mod_security Kurallarınızı Yazmak

Bu bölümde, bir HTML formuna belirli "spam" kelimelerinin girilmesi durumunda talebi engelleyen bir kural zinciri oluşturacağız. Öncelikle, girişi bir metin kutusundan alan ve onu kullanıcıya tekrar görüntüleyen bir PHP komut dosyası oluşturacağız.

/var/www/form.php

    
        
                

                        Enter something here:
                        
                
        
    

Yapılandırma dosyalarının herhangi birine özel kurallar eklenebilir veya modsecurity dizinlerine yerleştirilebilir. Kurallarımızı ayrı bir yeni dosyaya yerleştireceğiz.

nano /etc/modsecurity/modsecurity_custom_rules.conf

Aşağıdakileri bu dosyaya ekleyin:

SecRule REQUEST_FILENAME "form.php" "id:'400001',chain,deny,log,msg:'Spam detected'"
SecRule REQUEST_METHOD "POST" chain
SecRule REQUEST_BODY "@rx (?i:(pills|insurance|rolex))"

Dosyayı kaydedin ve Apache’yi yeniden yükleyin. Tarayıcıda http://yourwebsite.com/form.php açın ve bu kelimelerin herhangi birini içeren metni girin: pills, insurance, rolex.

Ya bir 403 sayfası ve bir log girişi ya da sadece SecRuleEngine  kurulumuna dayalı bir log girişi göreceksiniz. SecRule için sözdizimi

SecRule VARIABLES OPERATOR [ACTIONS]

Dir.

Burada REQUEST_FILENAME değişkenlerini form.php ile, REQUEST_METHOD’ u POST ile ve REQUEST_BODY ‘ yi regular expression (@rx) string (pills|insurance|rolex) ile eşleştirmek için chain eylemini kullandık. ?i: duyarsız bir eşleşme durumu yapar.
Tüm bu üç kuralın başarılı bir eşleşmesinde, EYLEM "Spam algılandı" mesajı ile reddetmek ve oturum açmaktır. Zincir eylemi bu üç kuralı eşleştirmek için mantıksal AND taklidi yapar.

Sunucuları ve Dizinleri Çıkarma

Bazen, phpMyAdmin gibi bir uygulamayı modsecurity olarak çalıştırıyorsa ve SQL sorgularını engelliyorsa, belirli bir dizini veya alan adını çıkarmak mantıklıdır. Ayrıca, WordPress gibi CMS uygulamalarının yönetici sunucu uygulamalarını çıkarmak daha iyidir.

Mod_security'yi tam bir VirtualHost için devre dışı bırakmak için aşağıdakini

    SecRuleEngine Off

 bölümüne yerleştirin.

Belli bir dizin için:

    
        SecRuleEngine Off
    

Modsecurity'i tamamen devre dışı bırakmak istemiyorsanız, kimliğini belirterek belirli bir kuralı veya kural zincirini kaldırmak için SecRuleRemoveById yönergesini kullanın.

    
        SecRuleRemoveById 981173