ModSecurity ile Web Uygulama Güvenliği - Kurulum, Kullanım ve Kurallar
Bu yazı açık kaynak bir güvenlik duvarının kurulum, kullanım ve kuralları hakkında olacak.
Mod Security WAF
Web uygulamalar için geliştirilmiş web servislerde gömülü çalışan açık kaynak bir web uygulama güvenlik duvarıdır. Genel olarak HTTP trafiğini dinleyip analiz eder.
Web uygulamalar için saldırı tespit (IDS) ve engelleme (IPS) görevi görür.
Kurulum
Ubuntu/Debian
- $ sudo apt-get install libapache2-mod-security
- $ sudo a2enmod mod-security
- $ sudo /etc/init.d/apache2 force-reload
Fedora/CentOS
- $ sudo yum install mod_security
- $ sudo /etc/init.d/httpd restart
Microsoft IIS (MSI Installer)
Paketleri kurduktan sonra güvenlik duvarının sağlıklı çalışması için birkaç konfigürasyon yapmamız gerekecek. Ben bugün Debian OS üzerinden anlatacağım web servis olarak Apache kullanacağım.
Kurulum bittikten sonra Apache servisimizi
$ service apache2 restart
komutu ile yeniden başlatıyoruz.
Ardından gerekli modulümüzü apachectl ile (HTTP Servisi için bir denetleme aracı) kurulmuşmu kontrol edeceğiz.
$ apachectl -M |grep security
security2_module(shared) ile modülümüzün ayakta olduğunu görüyoruz.
Sırada ön tanımlı gelen konfigürasyon dosyamız üzerinde birkaç değişiklik yapacağız
$ mv /etc/modsecurity/modsecurity.conf{-recommended,}
komutu ile konfigürasyon dosyamızın ismini modsecurity.conf yapıyoruz ardından nano editörümüz ile açıyoruz.
2 adet kural motorunda düzenleme yapacağız
SecRuleEngine
Güvenlik duvarının kural motorlarından biridir ve 3 farklı parametre alır.
- On -- ( Kuralları uygular)
- Off -- (Kuralları uygulamaz)
- DetectionOnly -- (Kuralları uygular fakat bloklamaz)
SecResponseEngine
2007'de yazılan kaliteli bir kaynakta default olarak kapalı geldiği yazılmış. Ne zamandır böyle bilmiyorum fakat artık default olarak açık geliyor ve cevapları tamponlamaya, analiz etmeye ve ya bunları yapmamaya yarıyor. 2 farklı parametre alır.
- On -- (Cevapların ulaşılma durumu aktif)
- Off -- (Cevaplara ulaşılmaz)
SecRuleEngine olan satırı buluyoruz ve DetectionOnly modundan On moda alıyoruz
Hemen ardından SecResponseBodyAccess kısmını On modundan Off moduna alıyoruz.
Konfigürasyon dosyasının içerisinde POST methodu ile alınacak verinin boyutuna kadar birçok ayar yapabilirsiniz.
Apache servisimizi tekrar başlatıyoruz.
$ service apache2 restart
Hemen ardından /var/log/apache2/ dizini altında modsec_audit.log adında modsecurity’nin dinlediği trafiği kaydettiği günlük dosyasının oluşması gerekiyor.
Şimdi güvenlik zaafiyeti içeren bir php dosyası oluşturacağım ardından web servisine payload göndererek sağlıklı çalışıyor mu inceleyeceğim.
Güvenlik Zaafiyeti Olan PHP Dosyası
Koddan anlayacağımız üzere çok basit bir Cross Site Scripting (XSS) zaafiyeti. HTTP GET isteği ile gelen "a" girdisi üzerinden veriyi alıp ekrana bastıracak.
Şimdide basit bir XSS payload'ı <script>alert(1)</script> gönderelim.
Arka tarafta modsecurity’nin trafiği kaydettiği günlük dosyası, gelen isteğin /usr/share/modsecurity/rules dizini altında bulunan kuralda, XSS zaafiyetini sömürmeye yönelik zararlı javascript kodu olduğunu anlıyor ve isteğe 403 cevabı döndererek engelliyor.
Kural yazma aşamasına geçmeden önce biraz kuralların olduğu dizinde dolaşıp olayı anlamaya çalışıyorum.
/usr/share/modsecurity-crs/rules dizini altında .conf ve .data şeklinde iki farklı dosya tipi olduğunu görüyorum.
.data dosyaları içerisinde kural dosyalarının zaafiyete göre çok yer kaplamaması için payload listeleri var. Örneğin Response ve SQL Injection ile ilgili konfigürasyon dosyasında normal şartlarda sqli zaafiyetinin anomalisinin bozulup eğer error based ise ekrana hata vermesi gerekirken, payload dosyası yani sql-response.data dosyasından response da olan bir şey yakalarsa engelliyor.
Örneğin : You have an in error sql syntax - mysql error vs
Bir bakıma conf dosyasına başka bir dosya içerisinde bulunan payloadları dahil etme işini yapıyor.
Kurallar
Kural yazmaya başlamadan önce değişkenleri, operatörleri anlayabilmek için bir kural açıp incelemeye başlayalım.
Biraz incelerseniz sentaksı hakkında fikir sahibi olabilirsiniz. Örnek bir kod bloğu aşağıdaki gibidir.
Hashtag ile yorum satırları yazılmış. Biraz yukarda bahsettiğimiz gibi dosyaya payloadları eklemek yerine @pmFromFile scanners-user-agents.data dosyasından dahil ediyor. O dosyasının içeriğine bakalım
Burdan anlayacağımız üzere güvenlik tarayıcı uygulama/ürünler yaptıkları bazı web isteklerinde bu user-agentları kullanıyormuş. Neden kullanıyor sorusuna da basitinden şöyle cevap verebiliriz. Bazı web uygulamalar X-Forwardad-For HTTP header'i ile istemcinin ip adresini aynı zamanda user-agent değerini sayfa kaynağına yazarlar.
Güvenlik tarayıcısı user-agent'ı kendine göre düzenleyip gönderdiği zaman response'u inceler ve eğer user-agent'ı sayfa kaynağına yazdığını anlarsa XSS Code injection gibi çeşitli zaafiyetlerinin payloadlarını user-agent header'ında yollar.
Şimdi en başından başlayıp kuralı inceleyelim ardından bizde bir kural yazalım.
SecRule REQUEST_HEADERS:User-Agent "@pmFromFile scanners-user-agents.data" \
SecRule belkide modsec'e ait en önemli özellik bunun ile gelen giden verinin üzerinde denetleme mekanizması oluşturabiliyoruz. Yukardaki kuralda da İstek Gövdesi içerisinde ki HTTP header'i olan User-Agent scanners-user-agents.data içerisinde bulunan bir kelime içeriyorsa engelle denilmiş.
Hızlıca alt satırdaki kuralı incelemeye başlayalım
"msg:'Found User-Agent associated with security scanner',\
msg etkiler altında bulunan bir fonksiyon görevi ise hata mesajını yazdırmak. Burda küçük bir not düşmemiz gerekirse hatayı ekrana yazdırmaz. Apache hata günlük dosyasına (error.log) ve modsec'e ait audit.log dosyasına yazar.
severity yine etkiler altında bulunan bir fonksiyon isteğin seviyesini belirler.
id kurala kimlik vermemize yarar ve id vereceğimiz değer için belli aralıklar vardır. Bu aralıkları şuradaki kaynakta 38. sayfada bulabilirsiniz
rev kuralın kaç kere gözden geçirildiğini,güncelleme yapıldığını belirten etki
phase kuralın inceleneceği aşamayı belirtir burdaki phase:request kuralın sadece istek aşamasında inceleneceğini belirtir
Tüm etkileri google da arama yaparak öğrenebilirsiniz. Biz şimdi basit bir kural yazalım.
Kuralı yazmaya başlamadan önce sorunumuzun ne olduğuna karar verelim ve buna göre bir çözüm geliştirelim. Sorunumuz hassas dizinlerin keşfedilmesi olsun bizde buna çözüm olarak içerisinde belirlediğim dizinler olan istekleri engelleyelim.
İki adet dosya oluşturacağız birincisi .conf uzantılı konfigürasyon dosyamız ikinci ise hassas dizin payloadları olan .data dosyamız.
REQUEST-922-DIZINTARAMASI.conf
backup.data
Aşağıdaki gibi GET /www.berkdusunur..net şeklinde gelen istekleri engelleyecek.
Aynı zamanda error.log ve modsec_audit.log dosyalarına da belirttiğimiz hata mesajı ile beraber düştü.
Okuduğunuz için teşekkür ederim faydalandığım bazı kaynakları aşağıya bırakıyorum.
https://www.modsecurity.org/download.html
https://www.webguvenligi.org/docs/ModSecurity_2.1.0_Turkish.pdf
https://www.webguvenligi.org/wp-content/uploads/2007/05/modsec_owasp_06052007.pdf
https://www.syslogs.org/mod_security-kurulumu/
https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_security-with-apache-on-debian-ubuntu
https://github.com/SpiderLabs/ModSecurity
berkdusunurx@protonmail.com
