ModSecurity, web sunucusunun içinde çalışan açık kaynak bir web uygulama güvenlik duvarı (WAF) motorudur. HTTP isteklerini ve yanıtlarını SecRules (SecLang) dilinde yazılmış kurallara göre inceler; eşleşme olduğunda isteği loglayabilir veya engelleyebilir. Coraza ise aynı kural dilini destekleyen, Go ile yazılmış açık kaynak bir WAF motorudur. İkisi de kendi başına saldırı bilgisi taşımaz; korumayı çoğunlukla OWASP CRS (Core Rule Set) adlı genel amaçlı kural seti sağlar.
Bu yazıda ModSecurity v3'ü (libmodsecurity) Nginx ile kullanmanın mantığını, Coraza'nın nerede durduğunu, CRS paranoia seviyelerini, DetectionOnly ile On modları arasındaki farkı ve yanlış pozitif (false positive) ayarlamasını resmi belgelerden alınmış kısa örneklerle anlatıyoruz. Firewall kavramlarına yabancıysanız önce güvenlik duvarı (firewall) nedir yazısını okuyun.
Bileşenler: motor, bağlayıcı ve kural seti
| Bileşen | Ne işe yarar | Proje sayfasında belirtilen lisans |
|---|---|---|
| libmodsecurity (ModSecurity v3) | SecRules kurallarını yükleyip bağlayıcının verdiği HTTP içeriğine uygulayan kütüphane | Apache-2.0 |
| ModSecurity-nginx | libmodsecurity ile Nginx arasındaki bağlayıcı (connector) modül | Apache-2.0 |
| OWASP CRS | ModSecurity veya uyumlu WAF motorları için genel saldırı tespit kuralları | Okunan sayfalarda belirtilmiyor |
| Coraza | Go ile yazılmış, SecLang kurallarını destekleyen WAF motoru | Apache-2.0 |
ModSecurity v3 ve proje durumu
ModSecurity deposu bugün GitHub'da owasp-modsecurity organizasyonu altında yer alıyor ve güvenlik bildirimleri için OWASP'a ait bir e-posta adresi veriliyor. README'de geliştirmenin Trustwave sponsorluğunda yapıldığı ve bu sponsorluğun 1 Temmuz 2024'te sona ereceği yazıyor. Projenin lisansı depoda Apache-2.0 olarak gösteriliyor.
README'ye göre libmodsecurity, ModSecurity v3 projesinin bir bileşenidir ve ModSecurity platformunun Apache bağımlılığı olmayan, baştan yazılmış (C++17) halidir. Kütüphane, SecRules biçimindeki kuralları yükler ve bağlayıcıların (connector) sağladığı HTTP içeriğine uygular. Apache modülü olan eski v2.x dalı ise ayrı bir dalda bakımda ve erişilebilir durumda.
ModSecurity-nginx bağlayıcısı
Nginx bağlayıcısı ayrı bir GitHub projesi olarak tutuluyor. Önce libmodsecurity kurulmalı, ardından Nginx kaynak dizininde modül derlenmelidir. README'deki iki seçenek:
# statik modül
./configure --add-module=/path/to/ModSecurity-nginx
# dinamik modül
./configure --add-dynamic-module=/path/to/ModSecurity-nginx --with-compatDinamik modülde README, derlediğiniz Nginx kaynak sürümünün çalıştırdığınız Nginx sürümüyle aynı olması gerektiğini belirtiyor. Dinamik modül nginx.conf'un en üstünde şöyle yüklenir (CRS belgesindeki satır):
load_module modules/ngx_http_modsecurity_module.so;Modülün dört direktifi vardır ve hepsi http, server ve location bağlamlarında kullanılabilir:
| Direktif | Görevi |
|---|---|
| modsecurity on | off | Modülü açar veya kapatır (varsayılan off) |
| modsecurity_rules_file | Bir kural/yapılandırma dosyasını yükler |
| modsecurity_rules | Kuralları doğrudan Nginx yapılandırmasına gömer |
| modsecurity_transaction_id | İşlem kimliğini Nginx tarafında belirler (ör. log eşleştirme için) |
README'deki örneğin sadeleştirilmiş hali:
server {
modsecurity on;
location / {
root /var/www/html;
modsecurity_rules_file /etc/my_modsecurity_rules.conf;
}
}Nginx server block yapısına yabancıysanız Nginx yapılandırma rehberi yazısına bakabilirsiniz.
DetectionOnly mi, On mu?
ModSecurity'nin davranışını SecRuleEngine direktifi belirler. v3 başvuru kılavuzuna göre sözdizimi SecRuleEngine On|Off|DetectionOnly, varsayılan değer ise Off'tur:
| Değer | Davranış (Reference Manual v3.x) |
|---|---|
| On | Kuralları işler |
| Off | Kuralları işlemez |
| DetectionOnly | Kuralları işler ama block, deny, drop, allow, proxy ve redirect gibi kesintiye yol açan (disruptive) eylemleri hiçbir zaman uygulamaz |
Projenin önerilen yapılandırma dosyası modsecurity.conf-recommended da bu yüzden DetectionOnly ile başlar ve açıklamasında, kurulum sonrası kesinti riskini en aza indirmek için başlangıçta yalnızca tespit modunun kullanılmasını önerir:
SecRuleEngine DetectionOnly
SecRequestBodyAccess On
SecAuditEngine RelevantOnlyAynı dosyadaki açıklamaya göre SecRequestBodyAccess kapalı olursa ModSecurity POST parametrelerini göremez. SecAuditEngine RelevantOnly ise bir kuralın işaretlediği işlemleri ve sunucu hatası üreten istekleri audit log'a yazar.
OWASP CRS: kural seti
CRS sitesi projeyi "ModSecurity veya uyumlu WAF'larla kullanılmak üzere genel saldırı tespit kuralları" olarak tanımlıyor; hedefi OWASP Top Ten dahil saldırılara karşı en az yanlış alarmla koruma sağlamak. 3 Kasım 2026 itibarıyla resmi sitede en güncel sürüm 4.30.0, uzun süreli destek (LTS) sürümü 4.25.2 olarak gösteriliyor; 3.3.x serisinin ise ömrünü tamamladığı (end of life) belirtiliyor.
CRS belgesine göre Nginx için yükleme sırası şöyledir (dizin yolunu kendi kurulumunuza göre değiştirin):
Include modsecurity.d/modsecurity.conf
Include /etc/nginx/coreruleset/crs-setup.conf
Include /etc/nginx/coreruleset/plugins/*-config.conf
Include /etc/nginx/coreruleset/plugins/*-before.conf
Include /etc/nginx/coreruleset/rules/*.conf
Include /etc/nginx/coreruleset/plugins/*-after.confBu satırları bir dosyada toplayıp Nginx'te modsecurity_rules_file ile o dosyayı göstermek yaygın bir düzendir. Kullanmak istediğiniz CRS eklentilerini (plugin) de ayrıca dahil etmeniz gerektiğini CRS belgesi hatırlatıyor.
Paranoia seviyeleri
CRS kurallarını dört paranoia seviyesine (PL) ayırır. Seviye yükseldikçe daha fazla kural devreye girer ve yanlış pozitif ihtimali artar:
| Seviye | CRS belgesindeki tanım |
|---|---|
| PL 1 | İnternetteki her HTTP sunucusu için temel koruma; yanlış alarm nadirdir. Varsayılan seviye. |
| PL 2 | Gerçek kullanıcı verisi işleyen siteler (ör. online mağaza) için ek kurallar; ayarlama gerektiren bazı yanlış pozitifler beklenir. |
| PL 3 | Online bankacılık gibi yüksek güvenlik gerektiren servisler; yanlış pozitifler kabul edilir ve beklenir. |
| PL 4 | En sıkı seviye; neredeyse her saldırıyı yakalar ama çok fazla meşru trafiği de işaretler, risk size aittir. |
Seviye crs-setup.conf içindeki 900000 numaralı kuralla ayarlanır. Örnek dosyadaki yorum satırı halindeki kuralın açılmış hali (ver etiketi kullandığınız sürüme göre farklıdır):
SecAction \
"id:900000,\
phase:1,\
pass,\
t:none,\
nolog,\
tag:'OWASP_CRS',\
setvar:tx.blocking_paranoia_level=1"Örnek dosyaya göre tx.detection_paranoia_level değerine kadar olan kurallar çalışır, ancak yalnızca tx.blocking_paranoia_level değerine kadar olanlar anomali puanını etkiler. Varsayılan olarak detection seviyesi blocking seviyesine eşittir ve ondan düşük olamaz. Bu sayede bir üst seviyeyi engelleme yapmadan, sadece gözlem için çalıştırabilirsiniz. Anomali puanı eşikleri de aynı dosyada 900110 numaralı kuralla (tx.inbound_anomaly_score_threshold ve tx.outbound_anomaly_score_threshold) ayarlanır.
Yanlış pozitif (false positive) ayarlama
Yanlış pozitif, meşru bir isteğin genel bir CRS kuralı tarafından saldırı sanılmasıdır. CRS belgesi çözüm olarak CRS dosyalarını düzenlemeyi değil, kural istisnası (rule exclusion) yazmayı öneriyor; çünkü CRS dosyalarındaki değişiklikler her güncellemede ezilir. İstisnalar iki türdür:
| Tür | Ne zaman uygulanır | Nereye yazılır |
|---|---|---|
| Configure-time | Sunucu yapılandırmayı yüklerken bir kez | CRS include satırından sonra (kuralın önce var olması gerekir) |
| Runtime | Her işlemde (transaction) ayrı ayrı | CRS include satırından önce (kural çalışmadan değiştirilmeli) |
Configure-time örneği: uygulamanız PHP kullanmıyorsa CRS belgesindeki gibi 933151 numaralı kuralı tamamen kaldırabilirsiniz:
SecRuleRemoveById 933151Runtime örneği: belgedeki örnekte yalnızca /dynamic/new_post adresine gelen isteklerde text_input parametresi 941150 numaralı XSS kuralının dışında bırakılıyor:
# CRS Rule Exclusion: 941150 - XSS Filter - Category 5: Disallowed HTML Attributes
SecRule REQUEST_URI "@beginsWith /dynamic/new_post" \
"id:1020,\
phase:1,\
pass,\
t:none,\
nolog,\
ctl:ruleRemoveTargetById=941150;ARGS:text_input"CRS belgesi ayrıca bazı popüler web uygulamaları için hazır istisna paketleri bulunduğunu belirtiyor. Mümkün olduğunda bütün kuralı kapatmak yerine yalnızca ilgili parametreyi ve adresi hedefleyen dar istisnalar yazın.
Coraza: Go ile yazılmış alternatif
OWASP Coraza, coraza.io'da "API'ler ve web uygulamaları için açık kaynak web uygulama güvenlik duvarı" olarak tanımlanıyor ve OWASP Production Project olarak listeleniyor. GitHub deposunda lisans Apache-2.0 olarak gösteriliyor; proje ModSecurity SecLang kural setlerini desteklediğini ve OWASP Core Rule Set v4 ile "%100 uyumlu" olduğunu belirtiyor.
Coraza'nın GitHub sayfasında listelenen entegrasyonlar ve durumları:
| Entegrasyon | Durum (GitHub README) |
|---|---|
| Caddy eklentisi | Kararlı, bakımcı aranıyor |
| Proxy-WASM (Envoy vb.) | Kararlı, geliştirme sürüyor |
| Traefik WASM | Deneysel |
| HAProxy SPOE | Deneysel |
| libcoraza (Nginx ve diğerleri için C kütüphanesi) | Deneysel |
Sınırlar ve ne zaman başka çözüm gerekir?
- ModSecurity veya Coraza uygulama katmanında çalışır; ağ katmanındaki hacimsel DDoS saldırılarını durduramaz. Bunun için DDoS koruma rehberi yazısına bakın.
- Kural motoru ek işlemci yükü getirir; paranoia seviyesini artırmadan önce sunucu kaynaklarını izleyin.
- Bot yönetimi, hesap ele geçirme koruması ve yönetilen kural güncellemesi gibi özellikler ticari ürünlerde hazır gelir. Örnekler: Cloudflare WAF, FortiWeb, F5 BIG-IP Advanced WAF, Imperva WAF, Barracuda WAF.
- WAF tek başına yeterli değildir; sunucu tarafında SSH sertleştirme ve güncelleme disiplini için VPS güvenlik sertleştirme yazısına bakın.
Sık Sorulan Sorular
ModSecurity ücretsiz mi?
Evet, açık kaynaktır. GitHub deposunda lisans Apache-2.0 olarak gösteriliyor. Nginx bağlayıcısı ve Coraza da Apache-2.0 lisanslı olarak listeleniyor.
ModSecurity projesi hâlâ geliştiriliyor mu?
Depo GitHub'da owasp-modsecurity organizasyonu altında duruyor ve güvenlik bildirimleri OWASP adresine yönlendiriliyor. README, Trustwave sponsorluğunun 1 Temmuz 2024'te sona erdiğini belirtiyor. Güncel sürüm ve değişiklikler için deponun release sayfasını takip edin.
DetectionOnly modunda saldırılar engellenir mi?
Hayır. DetectionOnly kuralları işler ve eşleşmeleri loglar, ancak block, deny, drop gibi kesintiye yol açan eylemleri uygulamaz. Engelleme için SecRuleEngine On gerekir.
Hangi paranoia seviyesini seçmeliyim?
CRS'de varsayılan PL 1'dir ve CRS belgesi bunu internetteki her HTTP sunucusu için temel koruma olarak tanımlıyor. Kullanıcı verisi işleyen siteler için PL 2 öneriliyor, ancak ek ayarlama gerektirir.
Coraza ModSecurity yerine kullanılabilir mi?
Coraza kendini ModSecurity yerine kullanılabilecek (drop-in replacement) bir motor olarak tanımlıyor ve SecLang ile CRS v4'ü destekliyor. Ancak Nginx bağlayıcısı deneysel olduğundan Nginx'te kullanmadan önce durumunu kontrol edin.
Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.
İlgili içerikler: Güvenlik duvarı nedir · Cloudflare WAF kuralları · FortiWeb nedir · F5 BIG-IP Advanced WAF nedir · Imperva WAF nedir · Barracuda WAF nedir · Nginx yapılandırma rehberi · IDS/IPS nedir