İçeriğe geç
NetDevOps
12 dk okuma Güvenlik

ModSecurity WAF Kurulumu

İnternet'e açık her web sunucusu, saniyede binlerce kötü niyetli isteğe maruz kalır. SQL injection girişimleri, XSS payload'ları, path traversal denemeleri, brute force saldırıları... Bu tehditlerin tamamı uygulama katmanında, HTTP seviyesinde gerçekleşir ve standart bir firewall ya da network seviyesi koruması bunları yakalayamaz. Burada devreye Web Application Firewall (WAF) girer. Bu yazıda, dünyanın en yaygın açık kaynak WAF çözümü olan ModSecurity'yi Nginx ile kurmayı, OWASP Core Rule Set (CRS) ile yapılandırmayı ve false positive'lerle başa çıkmayı detaylı şekilde ele alacağız.

Web Application Firewall Nedir ve Neden Gereklidir

Geleneksel ağ güvenlik duvarları, TCP/IP seviyesinde çalışır. Bir portu kapatır, bir IP'yi blocklar, bağlantı sayısını sınırlar. Ancak HTTP trafiğinin içeriğine bakmazlar. Bir saldırgan POST /login isteğinin body'sine admin' OR '1'='1 gibi bir SQL injection string'i gönderdiğinde, standart firewall bunu normal bir istek olarak görür ve geçirir. İşte WAF tam bu noktada devreye girer: HTTP isteklerinin parametrelerini, header'larını, cookie'lerini ve body içeriklerini analiz eder ve kötü niyetli kalıpları tespit ederek engeller.

ModSecurity, bu analizi yapan açık kaynak bir WAF motorudur. Apache, Nginx ve IIS web sunucularıyla entegre çalışabilir. Kuralları (rules) ModSecurity'nin kendi diliyle yazılır ve OWASP CRS gibi hazır rule set'ler ile binlerce bilinen saldırı kalıbına karşı koruma sağlar. OWASP CRS'in arkasındaki topluluk, düzenli olarak yeni saldırı tekniklerini analiz eder ve kural setlerini günceller. Bu sayede sıfır gün exploit'lerine karşı bile belirli bir koruma seviyesi sağlanabilir.

Bir WAF'ın sağladığı koruma kategorileri şunlardır: SQL injection (SQLi), Cross-Site Scripting (XSS), Local File Inclusion (LFI) ve Remote File Inclusion (RFI), Remote Code Execution (RCE), Command Injection, HTTP Protocol Violations, Session Hijacking girişimleri, Brute Force denemeleri ve bilinen CVElere dayalı saldırı kalıpları. Bu saldırıların büyük çoğunluğu, bir web uygulamasındaki en zayıf halkayı hedef alır ve uygulamanın kendisini değil, sunucu tarafındaki zafiyetleri sömürür.

Kurulum Öncesi Hazırlık ve Sistem Gereksinimleri

ModSecurity kurulumuna geçmeden önce sunucunun hazır olduğundan emin olmalısınız. Nginx'in kurulu olması gerekir ve bu kurulum sırasında ModSecurity modülünü de aynı anda derlemeniz gerekebilir, çünkü Nginx ModSecurity desteği resmi Nginx paketlerinde varsayılan olarak kapalı gelir. Ubuntu ve Debian tabanlı sistemlerde nginx-module-modsecurity paketi doğrudan kurulabilirken, CentOS veya Rocky Linux gibi sistemlerde kaynak koddan derleme gerekebilir.

Sunucunuzda yeterli RAM olduğundan emin olun. ModSecurity, her HTTP isteğini parse edip kural setleriyle karşılaştırdığı için CPU ve bellek tüketimi artacaktır. Düşük profilli sanal sunucularda bile sorun yaşanmaz, ancak yüksek trafikli sitelerde ek kaynak planlaması yapılmalıdır. Ayrıca mevcut Nginx yapılandırmanızın yedeğini almayı unutmayın.

Nginx ModSecurity Kurulumu (Ubuntu/Debian)

Ubuntu 22.04 ve sonrası ile Debian 12 üzerinde kurulum oldukça kolaylaşmıştır. Tek paket kurulumu ile hem ModSecurity motorunu hem de Nginx modülünü edinebilirsiniz:

sudo apt update
sudo apt install libmodsecurity3 nginx-module-modsecurity -y

Kurulum tamamlandıktan sonra Nginx yapılandırma dizinini oluşturun ve ModSecurity'nin önerilen konfigürasyon dosyasını indirin. Bu dosya, ModSecurity motorunun temel davranış ayarlarını içerir ve üzerinde değişiklik yaparak motoru istediğiniz gibi ayarlayabilirsiniz.

sudo mkdir -p /etc/nginx/modsec
sudo wget -P /etc/nginx/modsec https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended
sudo mv /etc/nginx/modsec/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

Şimdi en kritik ayarı yapalım: SecRuleEngine. Bu direktif, ModSecurity'nin kuralları nasıl çalıştıracağını belirler. Üç değer alabilir: On kuralları aktif olarak çalıştırır ve kötü niyetli istekleri engeller. DetectionOnly ise kuralları tetikler ve loglar ama istekleri engellemez. Off ise tamamen kapatır. Canlıya almadan önce kesinlikle DetectionOnly modda başlayın.

sudo sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/' /etc/nginx/modsec/modsecurity.conf

ModSecurity motoru kuruldu, ancak tek başına bir işe yaramaz. Kural seti indirmemiz gerekiyor.

OWASP Core Rule Set Kurulumu ve Yapılandırması

OWASP CRS, ModSecurity'nin kalbidir. Bu rule set, bilinen saldırı kalıplarını içeren yüzlerce kuraldan oluşur ve sürekli güncellenir. Git ile en güncel sürümü indirin:

cd /etc/nginx/modsec
sudo git clone https://github.com/coreruleset/coreruleset.git
sudo mv coreruleset/crs-setup.conf.example coreruleset/crs-setup.conf

crs-setup.conf dosyası, rule set'in davranışını kontrol eden anahtarları içerir. Bu dosyayı açarak paranoia level, anomaly threshold ve sampling percentage gibi ayarları özelleştirebilirsiniz. Paranoia level, ne kadar agresif kural seti kullanacağınızı belirler. PL1 varsayılan ve önerilen seviyedir. PL2, PL3 ve PL4 daha fazla kural içerir ama false positive riski de artar.

Şimdi ana ModSecurity konfigürasyon dosyasını oluşturalım. Bu dosya, Nginx'in ModSecurity'yi nasıl yükleyeceğini ve hangi kuralları uygulayacağını tanımlar:

``

Include /etc/nginx/modsec/modsecurity.conf

Include /etc/nginx/modsec/coreruleset/crs-setup.conf

Include /etc/nginx/modsec/coreruleset/rules/*.conf

`

modsecurity.conf dosyasında birkaç önemli ayar daha bulunur. SecRequestBodyAccess On parametresi, POST isteklerinin body içeriğinin incelenmesini sağlar. SecResponseBodyAccess On ise sunucu yanıtlarının loglanmasını açar. Bunlar performans etkisini artırabilir, bu nedenle yalnızca gerekli durumlarda açık tutulmalıdır. Log dosyalarının rotasyonu için SecAuditLog ve SecDebugLog ayarlarını da kontrol edin.

Nginx Konfigürasyonunda ModSecurity Aktifleştirme

ModSecurity'yi Nginx'te aktif hale getirmek için Nginx konfigürasyonunda iki değişiklik yapmanız gerekir. Birincisi, nginx.conf dosyasının en üstüne modül yükleme satırını ekleyin:

load_module modules/ngx_http_modsecurity_module.so;

İkincisi, korumak istediğiniz server bloklarına ModSecurity direktiflerini ekleyin:

server {
    listen 443 ssl;
    server_name example.com;

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

Değişiklikleri yaptıktan sonra Nginx'i yeniden başlatmadan önce konfigürasyon sözdizimini kontrol edin:

sudo nginx -t
sudo systemctl reload nginx

Eğer nginx: [emerg] unknown directive "modsecurity" gibi bir hata alırsanız, ModSecurity modülü doğru yüklenememiştir. Bu durumda Nginx'in ModSecurity desteğiyle yeniden derlenmesi gerekebilir.

DetectionOnly Modda Log İnceleme

Canlı trafiği engellemeden önce en az birkaç gün, idealde bir iş döngüsü boyunca (maaş günü, kampanya günleri, batch job'lar dahil) DetectionOnly modda çalıştırın. Bu sürede toplanan loglar, false positive'leri tespit etmenizi sağlar.

ModSecurity logları iki katmanlıdır: modsec_debug.log hata ayıklama mesajlarını, modsec_audit.log ise tetiklenen kuralların detaylarını içerir. Audit log'u incelemek için:

tail -f /var/log/nginx/modsec_audit.log

Bir kural tetiklendiğinde log satırında kural ID'si, tetiklenme nedeni ve isteğin detayları yer alır. Örneğin:

`

[id "942100"] [data "detected SQLi"]

`

Bu ID numarasını kullanarak hangi kuralın false positive ürettiğini tespit edebilirsiniz. Meşru bir kullanıcının gönderdiği normal bir isteğin engellenmesi, false positive demektir.

False Positive Yönetimi ve Rule Exclusion

OWASP CRS kuralları genel amaçlı tasarlanmıştır ve her web uygulamasına uygun değildir. Özellikle içerik yönetim sistemleri, REST API'ler ve özel javascript kütüphaneleri sıkça false positive üretir. Bunları yönetmek için ModSecurity'nin exclusion mekanizmalarını kullanmalısınız.

En yaygın yöntem, belirli bir kuralı belirli bir URL için devre dışı bırakmaktır. Örneğin WordPress admin-ajax.php dosyası sıkça SQLi kurallarını tetikler:

`

SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \

"id:1000,phase:1,pass,nolog,ctl:ruleRemoveById=942100"

`

Burada id:1000 kural exclusion kuralının kendi ID'sidir. Bu ID'yi 900000'den büyük bir değer olarak belirlemeniz önerilir, böylece CRS kurallarıyla çakışmaz. ctl:ruleRemoveById=942100 ise SQLi kuralını bu URL için devre dışı bırakır.

Daha granüler kontrol için IP bazlı exclusion da yapabilirsiniz:

`

SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \

"id:1001,phase:1,pass,nolog,ctl:ruleRemoveById=920350"

`

Ayrıca belirli parametrelere (REQUEST_FILENAME, ARGS, HEADER) özel muamele yapılabilir. Örneğin bir form'dan gelen q parametresinin özel karakter içermesi normal karşılanmalı:

`

SecRule ARGS:q "@rx ^[a-zA-Z0-9\s\-]+$" \

"id:1002,phase:2,pass,nolog,ctl:ruleRemoveById=941310"

`

CRS paranoid level'ını düşürmek de bir seçenektir. crs-setup.conf dosyasında:

`

SecAction "id:900000,phase:1,pass,setvar:tx.paranoia_level=1"

`

Paranoia level arttıkça daha fazla kural aktif olur ve false positive riski artar. PL1 varsayılan ve en güvenli başlangıç noktasıdır.

Anomaly Threshold ile Hassasiyet Ayarlama

OWASP CRS, anomaly scoring modeli kullanır. Her kural tetiklendiğinde isteğe bir puan eklenir. Anomaly threshold ise bir isteğin engellenmesi için gereken minimum puandır. Varsayılan threshold değerleri yüksektir ve çoğu kurulumda false positive'e neden olmaz, ancak bazı durumlarda ince ayar gerekebilir.

Threshold'u düşürmek agresifleştirir, yükseltmek yumuşatır. Ancak anlık olarak çok düşük threshold'a geçmeyin. Süreç şu şekilde olmalıdır: Önce threshold'u 10000 gibi çok yüksek bir değere çıkarın, bir iş döngüsü boyunca trafiği izleyin. Ardından sırasıyla 1000, 500, 100, 50 ve 20 değerlerine düşürün. Her adımda false positive'leri kontrol edin. Son olarak 5 civarında sabitleyin. Bu kademeli yaklaşım, anlık olarak meşru trafiği kesmenizi engeller.

CRS'in crs-setup.conf dosyasında bu değerler şu şekilde ayarlanır:

`

SecAction \

"id:900001,\

phase:1,\

pass,\

t:none,\

setvar:tx.inbound_anomaly_score_threshold=100,\

setvar:tx.outbound_anomaly_score_threshold=100"

`

Performans İyileştirme

ModSecurity her isteği analiz ettiği için performans etkisi kaçınılmazdır, ancak bazı optimizasyonlarla bu etki minimize edilebilir. İlk olarak, yalnızca gerekli phase'leri aktif hale getirin. ModSecurity istekleri dört phase'de işler: request headers, request body, response headers ve response body. Uygulamanız response body taraması gerektirmiyorsa SecResponseBodyAccess Off olarak kapatın.

İkinci olarak, SecRequestBodyLimit ve SecRequestBodyNoFilesLimit değerlerini uygun şekilde ayarlayın. Çok büyük dosya upload'ları veya POST body'leri beklenmiyorsa bu limitleri düşürmek hem güvenliği artırır hem de performansı iyileştirir.

Üçüncü olarak, sampling percentage kullanın. Tüm trafiği değil, yalnızca bir yüzdesini tarayarak CPU yükünü azaltabilirsiniz. Bu, yüksek trafikli ortamlarda kabul edilebilir bir denge sağlar:

`

SecAction "id:900010,phase:1,pass,t:none,setvar:tx.sampling_percentage=50"

`

Son olarak, CRS'in regex kural sayısını azaltmak için gerekmedikçe yüksek paranoia level kullanmayın. PL1 çoğu web sitesi için yeterli koruma sağlar.

Virtual Patching ile Hızlı Müdahale

ModSecurity'nin en güçlü özelliklerinden biri virtual patching'tir. Bir web uygulamasında sıfır gün zafiyet keşfedildiğinde, uygulama kodu hemen düzeltilemeyebilir. Virtual patching, bu zafiyete karşı gelen istekleri ModSecurity seviyesinde engeller ve uygulama koduna erişim olmaksızın koruma sağlar.

Örneğin, /api/user endpoint'inde bir IDOR (Insecure Direct Object Reference) zafiyeti tespit edildi:

`

SecRule REQUEST_URI "@beginsWith /api/user" \

"id:2000,phase:2,deny,status:403,\

msg:'IDOR protection for /api/user endpoint',\

logdata:'Blocked request to potentially vulnerable endpoint'"

`

Bu kural, henüz düzeltilmemiş endpoint'e gelen istekleri 403 ile reddeder. Uygulama kodu düzeltildiğinde bu kural kaldırılabilir.

Monitoring ve Sürekli Bakım

WAF tek seferlik kurulum değildir. Sürekli izleme ve bakım gerektirir. Audit log'larını merkezi bir log yönetim sistemine (ELK Stack, Graylog, Splunk) yönlendirmek, uzun vadeli analiz için kritiktir. ModSecurity logrotate yapılandırması:

`

/var/log/nginx/modsec_audit.log {

daily

rotate 30

compress

missingok

notifempty

create 0640 www-data www-data

}

``

Ayrıca OWASP CRS'in düzenli güncellemesini takip etmelisiniz. Her yeni sürüm, yeni saldırı kalıplarını ve düzeltmeleri içerir. Güncelleme komutları:

cd /etc/nginx/modsec/coreruleset
sudo git pull origin master
sudo nginx -t && sudo systemctl reload nginx

Sonuç

ModSecurity ve OWASP CRS ile Nginx üzerinde kurumsal seviyede bir Web Application Firewall oluşturmak, modern web güvenliğinin temel taşlarından biridir. Doğru yapılandırıldığında, SQL injection'dan XSS'e, RCE'den brute force saldırılarına kadar geniş bir yelpazede koruma sağlar.

Ancak unutulmamalıdır ki WAF, web uygulamasının kendisinin güvenli kod yazma alışkanlığının yerini almaz. WAF, ek bir savunma katmanıdır — derinlemesine savunma stratejisinin bir parçasıdır. Uygulama kodundaki zafiyetler WAF ile kapatılmaz, yalnızca istismar edilmeden önce bir miktar zaman kazanılır. Yine de saldırı yüzeyini daraltmak ve otomatik saldırılara karşı proaktif koruma sağlamak için ModSecurity, açık kaynak dünyasının en olgun ve güvenilir çözümüdür.