ModSecurity ile Web Uygulama Güvenliği - Kurulum, Kullanım ve Kurallar

3 Aralık 2018 Pazartesi

ModSecurity ile Web Uygulama Güvenliği - Kurulum, Kullanım ve Kurallar


Herkese Selamlar,

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

  1. $ sudo apt-get install libapache2-mod-security
  2. $ sudo a2enmod mod-security
  3. $ sudo /etc/init.d/apache2 force-reload


Fedora/CentOS


  1. $ sudo yum install mod_security
  2. $ sudo /etc/init.d/httpd restart

Microsoft IIS (MSI Installer)


  1. $ 32 Bits Installer
  2. $ 64 Bits 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.

  1. On  -- ( Kuralları uygular)
  2. Off -- (Kuralları uygulamaz)
  3. 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.


  1. On -- (Cevapların ulaşılma durumu aktif)
  2. 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




0 yorum :

Yorum Gönder