ModSecurity ve OWASP CRS ile WAF Kurulumu: Apache, Nginx ve False Positive Ayarı

ModSecurity ve OWASP Core Rule Set (CRS), kendi web sunucusunda açık kaynak bir Web Application Firewall kurmak isteyen ekiplerin en yaygın seçeneklerinden biridir. ModSecurity HTTP trafiğini inceleyen ve kuralları çalıştıran motordur; OWASP CRS ise SQL injection, XSS, dosya dahil etme, protokol ihlali ve tarayıcı saldırıları gibi genel kalıpları tespit eden güvenlik politikasını sağlar.

Bu ayrım önemlidir: ModSecurity tek başına kurulduğunda güçlü bir kural motorudur ama hangi isteğin zararlı sayılacağını belirleyen kapsamlı bir politika sunmaz. CRS ise ModSecurity veya uyumlu başka bir SecLang motoru olmadan çalışmaz. Güvenli bir dağıtım; doğru motor, doğrulanmış CRS sürümü, önce DetectionOnly gözlem, uygun anomaly score, düşük paranoia level ile başlangıç, uygulamaya özel dar kural istisnaları ve merkezi günlükleme adımlarının birlikte uygulanmasını gerektirir.

Bu rehber Apache ve Nginx için mimari seçenekleri, resmi CRS dosyalarının kurulmasını, Docker ile hızlı laboratuvarı, anomaly scoring ve paranoia level mantığını, yanlış pozitif ayıklamayı, audit log güvenliğini, sanal yama kullanımını ve üretime geçiş kontrol listesini ayrıntılı olarak açıklar.

WAF nedir, neyi çözer?

Web Application Firewall, HTTP istek ve yanıtlarını uygulama katmanında inceleyen ek bir güvenlik sınırıdır. Ağ güvenlik duvarı IP, port ve bağlantı durumuna odaklanırken WAF; URL, başlık, cookie, sorgu parametresi, istek gövdesi ve uygun yapılandırmada yanıt içeriği gibi web protokolü ayrıntılarını değerlendirebilir.

WAF'ın gerçekçi amacı “uygulamadaki bütün açıkları kapatmak” değildir. Genel saldırı kalıplarını engellemek, saldırı yüzeyine görünürlük kazandırmak, güvenlik açığı yamanana kadar dar bir sanal yama uygulamak ve olay müdahalesine ayrıntılı HTTP kanıtı sunmaktır.

Kontrol	Güçlü olduğu alan	Tek başına çözemediği alan
ModSecurity + CRS	SQLi, XSS, path traversal, protokol anomalisi ve bilinen genel kötü girdi kalıpları	İş mantığı hatası, eksik nesne yetkilendirmesi, çalınmış geçerli oturum
Uygulama doğrulaması	Alan türü, iş kuralı, nesne sahipliği ve yetki kontrolü	Kenar katmanda kaba saldırı hacmini azaltma
Güvenli kod ve yama	Kök nedeni ortadan kaldırma	Yama öncesi pencere ve bilinmeyen kötü trafik görünürlüğü
Rate limiting	Deneme ve kaynak tüketimini sınırlama	Tek istekli mantık hatası veya yetkili saldırı
EDR/SIEM	Süreç ve olay korelasyonu	HTTP girişini uygulamaya ulaşmadan engelleme

CRS belgeleri, uygulamaya özgü mantık kusurlarının genel imzalarla güvenilir biçimde tespit edilemeyeceğini açıkça belirtir. Örneğin geçerli bir yöneticinin yanlış müşteri kaydına erişmesi sıradan bir HTTP isteği gibi görünebilir. Bu nedenle WAF, güvenli yazılım geliştirme ve nesne düzeyi yetkilendirmenin yerine konulmamalıdır.

ModSecurity ve OWASP CRS farkı

ModSecurity, Apache, Nginx ve IIS gibi web sunucularıyla bütünleşebilen açık kaynak WAF motorudur. HTTP işlemlerini farklı fazlarda inceler, SecRule dilini çalıştırır, değişkenleri dönüştürür, günlük kaydı üretir ve kural kararına göre isteği engelleyebilir.

OWASP CRS, bu motor üzerinde çalışan genel saldırı tespit kurallarıdır. Kurallar farklı saldırı aileleri için düzenlenmiş .conf dosyalarından oluşur. CRS'in varsayılan yaklaşımı tek bir imza eşleşmesinde hemen engellemek yerine, eşleşmelerin işlem boyunca bir anomali puanına katkıda bulunması ve toplam puan eşiğe ulaştığında karar verilmesidir.

Motor kurulmadan CRS dosyalarını kopyalamak koruma sağlamaz.
CRS kurulmadan yalnız ModSecurity'yi etkinleştirmek kapsamlı saldırı politikası sağlamaz.
Kural dosyasını doğrudan düzenlemek güncellemeleri zorlaştırır; istisnalar ayrı dosyalarda tutulmalıdır.
Engelleme moduna doğrudan geçmek meşru trafiği kesebilir; önce gözlem ve ayarlama gerekir.
Yalnız HTTP 403 görmek WAF'ın doğru çalıştığını kanıtlamaz; rule ID, anomaly score ve audit log doğrulanmalıdır.

Doğru motor ve entegrasyon seçimi

Resmi CRS genişletilmiş kurulum belgesi, Apache için güncel ModSecurity 2.x dalını; Nginx için ModSecurity 3.x ve ilgili connector yapısını önerir. Belgede Nginx + ModSecurity 2 ve Apache + ModSecurity 3 kombinasyonlarının desteklenmediği özellikle belirtilir.

Platform	Önerilen motor	Bağlantı biçimi	Operasyon notu
Apache HTTP Server	ModSecurity 2.9.x	mod_security2 modülü	CRS için en olgun referans kombinasyon
Nginx	libModSecurity 3.x	ModSecurity-nginx connector	Motor ayrı kitaplık, Nginx connector üzerinden çağırır
Container	Resmi modsecurity-crs imajları	Apache/ModSecurity 2 veya Nginx/ModSecurity 3 varyantı	Laboratuvar ve ters proxy dağıtımı hızlıdır
Uyumlu SecLang motoru	Ürüne göre	Motorun kendi entegrasyonu	CRS uyumluluk ve test yüzdesi ayrıca doğrulanmalıdır

Dağıtım paketlerinin sürümleri dağıtıma göre geride kalabilir. İşletim sistemi paketini kullanmak bakım kolaylığı sağlar; ancak motorun sürümü, güvenlik güncellemeleri ve CRS uyumluluğu resmi sürüm notlarıyla kontrol edilmelidir. Kaynaktan derleme daha güncel özellik sunabilir fakat bağımlılık, imza, derleme bayrakları ve güncelleme sorumluluğunu ekibe yükler.

Üretim öncesi mimari plan

Kuruluma başlamadan önce WAF'ın nerede çalışacağı ve hangi trafiği göreceği belirlenmelidir:

Kapsam: Hangi alan adları, API yolları, HTTP yöntemleri ve içerik türleri korunacak?
TLS sonlandırma: ModSecurity şifre çözülmüş HTTP verisini hangi noktada görecek? TLS başka proxy'de sonlanıyorsa WAF'ın arkasına şifreli olmayan güvensiz ağ bırakılmamalı.
İstemci IP'si: Reverse proxy zincirinde gerçek kaynak IP hangi güvenilir başlıktan alınacak? Her istemcinin X-Forwarded-For değerine güvenilmemeli.
Gövde boyutu: JSON, form ve dosya yükleme sınırları nedir? Çok düşük limit işlevi bozar; sınırsız inceleme kaynak tüketimine yol açar.
Hata davranışı: WAF motoru hata verdiğinde trafik fail-open mı fail-closed mu olacak? Karar hizmet kritikliğine göre belgelenmeli.
Günlük gizliliği: Parola, token, cookie, kişisel veri ve yüklenen dosya içeriği audit log'a girebilir; maskeleme ve erişim politikası hazırlanmalı.
Geri dönüş: Yanlış pozitif artarsa yalnız son istisnayı veya engelleme modunu hızla geri alacak kontrollü yol bulunmalı.

Bu plan yoksa WAF kurulumu güvenlik projesinden çok kesinti kaynağına dönüşebilir. En iyi başlangıç, üretim trafiğini temsil eden test ortamı ve gerçek gözlem verisidir.

Apache üzerinde ModSecurity ve CRS kurulumu

Paket adları dağıtıma göre değişir. Debian/Ubuntu ailesinde tipik kurulum aşağıdaki gibi olabilir; üretim komutları uygulanmadan önce kullanılan dağıtım deposundaki sürüm ve güvenlik desteği doğrulanmalıdır:

CODE TERMINAL

sudo apt update
sudo apt install libapache2-mod-security2
sudo a2enmod security2
apachectl -M | grep security2

RHEL uyumlu dağıtımlarda EPEL etkinleştirildikten sonra paket adı genellikle mod_security olur. Paket kurulduktan sonra modülün gerçekten yüklendiği Apache modül listesi ve başlangıç logundan doğrulanmalıdır.

CRS sürümünü resmi sürümler sayfasından indirin ve yayın imzasını doğrulayın. Sürüm numarasını bu rehberden körlemesine kopyalamak yerine desteklenen güncel sürümü seçip sabitleyin:

CODE TERMINAL

# Örnek değişken; gerçek desteklenen sürümü resmi releases sayfasından seçin
CRS_VERSION="4.x.y"

curl -fLO "https://github.com/coreruleset/coreruleset/archive/refs/tags/v${CRS_VERSION}.tar.gz"
curl -fLO "https://github.com/coreruleset/coreruleset/releases/download/v${CRS_VERSION}/coreruleset-${CRS_VERSION}.tar.gz.asc"
gpg --verify "coreruleset-${CRS_VERSION}.tar.gz.asc" "v${CRS_VERSION}.tar.gz"

İmza doğrulaması başarısızsa dosyayı kullanmayın. Yalnız HTTPS üzerinden indirilmiş olması, yanlış veya değiştirilmiş varlığı fark etmek için imza kontrolünün yerini tutmaz.

Dosyaları sürümlü bir dizine çıkarıp sembolik bağlantıyla etkin sürümü göstermek geri dönüşü kolaylaştırır:

CODE TERMINAL

sudo mkdir -p /etc/crs/releases
sudo tar -xzf "v${CRS_VERSION}.tar.gz" -C /etc/crs/releases
sudo ln -sfn "/etc/crs/releases/coreruleset-${CRS_VERSION}" /etc/crs/current

sudo cp /etc/crs/current/crs-setup.conf.example /etc/crs/current/crs-setup.conf
sudo cp /etc/crs/current/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example \
  /etc/crs/current/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
sudo cp /etc/crs/current/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example \
  /etc/crs/current/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

Apache include sırası önemlidir. Önce ModSecurity motor ayarları, sonra CRS kurulumu, before-CRS istisnaları, kurallar ve after-CRS istisnaları yüklenmelidir:

CODE TERMINAL

IncludeOptional /etc/modsecurity/modsecurity.conf
    IncludeOptional /etc/crs/current/crs-setup.conf
    IncludeOptional /etc/crs/current/plugins/*-config.conf
    IncludeOptional /etc/crs/current/plugins/*-before.conf
    IncludeOptional /etc/crs/current/rules/*.conf
    IncludeOptional /etc/crs/current/plugins/*-after.conf

Yollar dağıtım paketine göre değişir. Apache'yi yeniden yüklemeden önce apachectl configtest çalıştırın. Test başarısızsa canlı süreci yeniden başlatmayın.

Nginx üzerinde libModSecurity ve connector

Nginx entegrasyonunda libModSecurity 3 motoru ile ModSecurity-nginx connector birlikte gerekir. Dinamik modül kullanılıyorsa derlenen modülün Nginx'in tam sürümü ve derleme bayraklarıyla uyumlu olması zorunludur. Rastgele bir depodan alınmış .so dosyasını üretim Nginx'e yüklemek güvenli değildir.

Nginx ana yapılandırmasında modül yüklenir ve korunacak server/location bağlamında ModSecurity etkinleştirilir:

CODE TERMINAL

load_module modules/ngx_http_modsecurity_module.so;

http {
    server {
        listen 443 ssl http2;
        server_name app.example.com;

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

        location / {
            proxy_pass http://application_backend;
        }
    }
}

Nginx yalnız bir ana ModSecurityConfig/modsecurity_rules_file girişinden ek dosyaları içeri alacağı için include dosyası düzenli tutulmalıdır:

CODE TERMINAL

Include /etc/nginx/modsec/modsecurity.conf
Include /etc/crs/current/crs-setup.conf
Include /etc/crs/current/plugins/*-config.conf
Include /etc/crs/current/plugins/*-before.conf
Include /etc/crs/current/rules/*.conf
Include /etc/crs/current/plugins/*-after.conf

Yapılandırmayı nginx -t ile doğrulayın. Motor başlangıç logunda connector ve yüklenen kural sayısını kontrol edin. Nginx yapılandırmasının sözdizimsel olarak geçerli olması, CRS kurallarının gerçekten işlendiğini tek başına kanıtlamaz; kontrollü test isteği ve audit log eşleşmesi gerekir.

Resmi container imajıyla hızlı laboratuvar

CRS projesi, Apache + ModSecurity 2 ve Nginx + ModSecurity 3 varyantları için resmi modsecurity-crs container imajları yayımlar. Bunlar deneme, ters proxy ve tekrarlanabilir laboratuvar için hızlıdır.

Üretimde kayan latest etiketi kullanmayın. Resmi depo, rolling tag'lerin yeni kararlı yayınlarla değiştiğini ve üretim için uygun olmadığını belirtiyor. İmajı desteklenen sürüm etiketi ve mümkünse digest ile sabitleyin:

CODE TERMINAL

services:
  waf:
    image: ghcr.io/coreruleset/modsecurity-crs:@sha256:
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      BACKEND: "http://app:3000"
      PARANOIA: "1"
      ANOMALY_INBOUND: "5"
      ANOMALY_OUTBOUND: "4"
    read_only: true
    tmpfs:
      - /tmp
      - /var/run
    security_opt:
      - no-new-privileges:true

Ortam değişkenlerinin isimleri ve desteklenen değerler imaj sürümüne göre değişebilir; yukarıdaki örnek doğrudan üretime kopyalanmamalı, kullanılan resmi imajın README dosyasıyla karşılaştırılmalıdır. WAF container'ına Docker socket, ana sistem kökü veya gereksiz sır bağlanmamalıdır.

Container kullanmak WAF'ı otomatik olarak güvenli yapmaz. Backend'e giden ağ, gerçek istemci IP'si, TLS, health check, log saklama, kaynak limitleri ve fail-open/fail-closed davranışı ayrıca tasarlanmalıdır.

DetectionOnly ile güvenli başlangıç

Yeni kurulumu doğrudan engelleme modunda açmak, ödeme, arama, dosya yükleme veya API çağrılarında beklenmeyen kesintilere yol açabilir. İlk aşamada motoru DetectionOnly modunda çalıştırın:

CODE TERMINAL

SecRuleEngine DetectionOnly
SecRequestBodyAccess On
SecResponseBodyAccess Off

DetectionOnly, kuralların eşleşmesini ve log üretmesini sağlar fakat istekleri engellemez. Bu mod güvenlik sağlamayan kalıcı bir rahatlık ayarı değil, ayarlama dönemidir. Başlangıç ve bitiş tarihi, sorumlu ekip, başarı ölçütü ve engelleme moduna geçiş planı tanımlanmalıdır.

Gözlem süresinde aşağıdakiler ölçülmelidir:

En çok eşleşen CRS rule ID'leri
Hangi endpoint ve parametrelerin yanlış pozitif ürettiği
İstek başına anomaly score dağılımı
İstemci, bot, sağlık kontrolü ve entegrasyon trafiği ayrımı
Audit log hacmi, disk kullanımı ve işleme gecikmesi
Büyük JSON/form/dosya yüklemelerinde gövde limiti davranışı
Uygulamanın 4xx/5xx hata oranı ve p95/p99 gecikmesi

Önce PL1 ve varsayılan eşiklerle gözlem yapmak, aynı anda çok fazla değişkeni oynatmayı önler. Bir rule ID'yi kapatmadan önce gerçek istek örnekleri kişisel veriler temizlenerek incelenmelidir.

Anomaly scoring nasıl çalışır?

CRS'in anomaly scoring modelinde her tespit kuralı doğrudan isteği kesmek yerine işlem puanını artırır. İstek fazındaki tüm ilgili kurallar çalıştıktan sonra toplam inbound anomaly score eşikle karşılaştırılır. Eşik aşılmışsa işlem engellenir. Yanıt kuralları etkinse outbound score ayrı değerlendirilir.

Aşama	İşlem	Operasyonel anlam
1	İstek kuralları çalışır	Başlık, URI, argüman ve gövde üzerinde tespitler oluşur
2	Eşleşmeler puan ekler	Kritik/yüksek/orta tespitler ağırlığa göre toplamı büyütür
3	Inbound eşik değerlendirilir	Eşik karşılanırsa istek backend'e gitmeden engellenebilir
4	Yanıt kuralları çalışır	Etkinse uygulama yanıtı ayrıca incelenir
5	Outbound eşik değerlendirilir	Hassas veri veya hata sızıntısı kalıpları yanıtı durdurabilir

Eşiği yükseltmek yanlış pozitifleri azaltabilir fakat tek bir güçlü tespitin engellenmeden geçmesine yol açabilir. Eşiği aşırı düşürmek ise tek zayıf sinyalde meşru trafiği kesebilir. Doğru yöntem; varsayılan eşiği körlemesine değiştirmek yerine hatalı rule/parametre eşleşmesini dar bir istisnayla düzeltmek ve puan dağılımını izlemektir.

CRS yapılandırmasında anomaly threshold değişkenleri sürüme göre örnek kural içinde sunulur. Değişiklikten sonra etkisi test isteği ve audit log üzerindeki toplam puanla doğrulanmalıdır.

Paranoia level seçimi

Paranoia level, hangi sıkılıkta ek kuralların etkin olduğunu belirler. Seviye yükseldikçe saldırı kapsamı artar; aynı zamanda normal fakat karmaşık girdilerin yanlış pozitif üretme olasılığı yükselir.

Seviye	Uygun başlangıç	Beklenen maliyet
PL1	Genel web uygulamaları, yeni kurulumlar, çok sayıda farklı site	En düşük yanlış pozitif; temel geniş koruma
PL2	Deneyimli ekip, orta-yüksek güvenlik gereksinimi	Daha fazla SQLi/XSS ve kod enjeksiyonu kontrolü; ayarlama gerekir
PL3	Yüksek güvenlikli uygulama ve olgun WAF operasyonu	Düzenli yanlış pozitif ve daha kapsamlı istisna ihtiyacı
PL4	Çok kritik dar yüzey, uzman ekip	Çok yüksek yanlış pozitif olasılığı ve yoğun bakım

CRS resmi FAQ belgesi PL1'i varsayılan ve çoğu kurulum için önerilen başlangıç olarak tanımlar. PL2 daha gelişmiş ve gizlenmiş saldırıları yakalamak için ek kurallar açar; PL3 ve PL4 ise güçlü fakat maliyetli ayarlama ister.

Tüm siteyi tek seferde PL4 yapmak iyi hardening değildir. Ödeme API'si, yönetim paneli ve genel içerik sitesi farklı profillere ihtiyaç duyabilir. Paranoia level sanal host veya uygulama bağlamında, ölçülmüş risk ve yanlış pozitif bütçesiyle yönetilmelidir.

Yanlış pozitif ayıklama: Kuralı değil hedefi daralt

Yanlış pozitif, meşru isteğin saldırı kuralına uymasıdır. Örneğin ürün açıklamasındaki SQL kelimesi, bir JSON alanındaki HTML parçası veya dosya adındaki özel karakter tespit üretebilir. Çözüm tüm SQLi/XSS kural grubunu kapatmak değil, yanlış eşleşen endpoint ve parametreyi en dar kapsamda hariç tutmaktır.

CRS iki ana istisna türü sunar:

Configure-time exclusion: Sunucu yüklenirken uygulanır. SecRuleRemoveById, SecRuleRemoveByTag, SecRuleUpdateTargetById gibi direktifler kullanılır.
Runtime exclusion: Her işlemde koşula göre uygulanır. ctl:ruleRemoveById veya ctl:ruleRemoveTargetById gibi eylemler kullanılır.

Yalnız belirli parametreyi bir rule ID'nin hedefinden çıkarma örneği:

CODE TERMINAL

# Kural dosyaları yüklendikten sonra uygulanır
SecRuleUpdateTargetById 942100 "!ARGS:product_description"

Yalnız belirli endpoint'te runtime istisna örneği:

CODE TERMINAL

# CRS kurallarından önce yüklenir
SecRule REQUEST_URI "@beginsWith /api/catalog/import" \
  "id:100001,phase:1,pass,nolog,ctl:ruleRemoveTargetById=942100;ARGS:product_description"

Rule ID ve parametre adı örnektir; gerçek ortamda audit logdaki eşleşmeye göre belirlenmelidir. İstisna dosyasında gerekçe, uygulama sahibi, açılış tarihi, test bağlantısı ve gözden geçirme tarihi tutulmalıdır.

CRS belgelerine göre configure-time istisnalar CRS kuralları yüklendikten sonra, runtime istisnalar ise kurallar çalışmadan önce yerleştirilmelidir. Projeyle gelen BEFORE-CRS ve AFTER-CRS örnek dosyalarını kullanmak bu sırayı ve güncelleme uyumluluğunu korur.

Kötü istisna örnekleri

Aşağıdaki yaklaşımlar kısa vadede hatayı sustursa da korumayı gereksiz biçimde zayıflatır:

SecRuleEngine Off ile tüm motoru kapatmak
Tek parametre sorunu için bütün SQL injection etiketini kaldırmak
Kural dosyasının içinden rule satırını silmek
Tüm /api yolunu inceleme dışı bırakmak
Anomaly threshold değerini gerçek saldırıların geçeceği kadar yükseltmek
Yanlış pozitif kanıtı olmadan rule ID aralığını kapatmak
İstisnayı süre ve sahip bilgisi olmadan kalıcı bırakmak

İyi istisna; tek host, tek yol, tek yöntem, tek parametre ve tek rule ID birleşimine mümkün olduğunca yaklaşır. Uygulama düzeltildiğinde veya CRS güncellendiğinde istisnanın hâlâ gerekli olup olmadığı yeniden test edilir.

Audit log ve hassas veri güvenliği

ModSecurity audit logları istek başlığı, cookie, gövde ve eşleşen veri parçalarını içerebilir. Bu görünürlük olay müdahalesi için değerlidir; fakat parola, erişim tokenı, kişisel veri veya ödeme verisi sızıntısı riski oluşturur.

Güvenli günlükleme ilkeleri:

Yalnız gereken audit log parçalarını etkinleştirin; “her şeyi sonsuza kadar sakla” yaklaşımından kaçının.
Authorization, Cookie ve uygulamaya özgü sır başlıklarını maskeleyin.
Parola, kart, kimlik ve token alanları için SecAction/SecRuleUpdateTargetById ile log sanitization seçeneklerini değerlendirin.
Log dizinini web kökü dışında, dar dosya izinleri ve ayrı disk kotasıyla tutun.
SIEM aktarımını TLS ve kimlik doğrulamayla koruyun; başarısız aktarımda yerel disk taşmasını izleyin.
Saklama süresini olay müdahalesi, KVKK/GDPR ve kurum politikasına göre belirleyin.
Geliştiriciye örnek gönderirken gerçek cookie, token ve kişisel verileri temizleyin.

Audit logun kendisi yüksek değerli güvenlik verisidir. Saldırganın oturum tokenlarını veya gönderilen sırları logdan almasını önlemek için dosya sahipliği, merkezi erişim ve bütünlük izleme uygulanmalıdır.

İstek gövdesi, JSON ve dosya yükleme sınırları

CRS'in API ve form trafiğini inceleyebilmesi için request body erişimi açık olmalıdır. Ancak büyük dosya yüklemeleri, çok derin JSON veya sıkıştırılmış içerik kaynak tüketebilir. Motor ve reverse proxy limitleri birbiriyle uyumlu ayarlanmalıdır.

Alan	Risk	Kontrol
SecRequestBodyAccess	Kapalıysa POST/JSON saldırıları görünmez kalabilir	Uygun yollarda On; kontrollü istisna
Request body limit	Çok düşükse meşru yükleme kesilir, çok yüksekse DoS yüzeyi artar	Uygulama endpoint'ine göre ölçülmüş limit
JSON depth/arg count	Aşırı yapı CPU/bellek tüketebilir	Motor ve uygulamada bağımsız sınır
Dosya yükleme	İçerik loga veya geçici diske yazılabilir	Boyut, tür, tarama ve ayrı geçici alan
Response body	Hassas veri tespiti sağlar fakat gecikme/RFDoS riski ekler	Varsayılan kapalı veya dar MIME/endpoint kapsamı

Limit aşımı davranışı test edilmelidir. WAF'ın gövdeyi kısmen işleyip isteği geçirmesi, bütün gövdenin incelendiği yönünde yanlış güven oluşturabilir. Audit logda request body processor ve limit hataları için alarm kurun.

Kontrollü güvenlik testi

Üretim dışı ortamda temel doğrulama için zararsız test dizeleri kullanılabilir. Test yalnız size ait sistemde ve izinli kapsamda yapılmalıdır:

CODE TERMINAL

# Normal istek geçmeli
curl -i "https://waf-test.example/health"

# SQLi benzeri test girdisi; laboratuvar endpoint'i olmalı
curl -i --get \
  --data-urlencode "q=1 UNION SELECT password FROM users" \
  "https://waf-test.example/search"

# Path traversal benzeri test
curl -i --get \
  --data-urlencode "file=../../../../etc/passwd" \
  "https://waf-test.example/download"

DetectionOnly modunda istek uygulamaya ulaşabilir ama logda ilgili rule ID ve anomaly score görülmelidir. Engelleme modunda beklenen durum genellikle 403'tür; ancak özel hata politikası farklı olabilir.

Test sonucunda şunları birlikte doğrulayın:

WAF logunda benzersiz istek kimliği
Eşleşen CRS rule ID, mesaj ve tag
Inbound anomaly score ve eşik
Backend erişim logunda isteğin ulaşıp ulaşmadığı
İstemciye dönen durum kodu
SIEM alarmı ve olay bağlamı

Yalnız istemci tarafında 403 görmek başka proxy kuralı, rate limit veya uygulama hatası olabilir. Kural eşleşmesinin WAF katmanından geldiği logla kanıtlanmalıdır.

Sanal yama nasıl yazılır?

Uygulamaya özel yeni bir açık için CRS güncellemesini beklemek yerine dar bir ModSecurity kuralı geçici sanal yama olarak kullanılabilir. Örneğin yalnız yönetim endpoint'ine beklenmeyen HTTP yöntemini kapatmak:

CODE TERMINAL

SecRule REQUEST_URI "@streq /admin/export" \
  "id:100100,phase:1,deny,status:403,log,msg:'Temporary virtual patch: method restriction',chain"
  SecRule REQUEST_METHOD "!@within GET HEAD"

Kural ID'si yerel özel aralıktan seçilmeli ve CRS rule ID'leriyle çakışmamalıdır. Kuralın bypass varyantları; URL kodlama, çift slash, büyük/küçük harf, sorgu dizesi, farklı içerik türleri ve proxy normalizasyonu ile test edilmelidir.

Sanal yama için son kullanma tarihi zorunludur. Uygulama kök nedeni düzelttiğinde kural kaldırılmalı; aksi hâlde yıllar içinde anlaşılmaz ve çelişen bir WAF politikası oluşur.

İzleme ve performans

WAF metriği yalnız engellenen istek sayısı değildir. Aşağıdaki göstergeler panoya alınmalıdır:

İstek ve host başına WAF işleme gecikmesi
Rule ID ve tag bazında eşleşme/engelleme sayısı
Inbound ve outbound anomaly score dağılımı
Yanlış pozitif geri bildirim ve istisna sayısı
Audit log yazma hatası, disk kullanımı ve kuyruk gecikmesi
Request body limit veya parser hataları
WAF motoru kapalı/bypass olmuş trafik oranı
CRS sürümü ve yüklenen kural sayısı

Yüksek hacimli tek bir kötü istek log fırtınası yaratabilir. Rate limiting, log örnekleme ve SIEM birleştirme uygulanabilir; ancak kanıt kaybına yol açacak kör filtrelerden kaçınılmalıdır. CPU ve gecikme artışı rule ID, body boyutu, regex yoğunluğu ve paranoia level ile ilişkilendirilmelidir.

CRS'in sampling mode özelliği, ilk dağıtımda yalnız trafiğin belirli yüzdesinde kuralları çalıştırmaya izin verir. Bu yöntem kesinti riskini azaltabilir fakat örnek dışındaki trafiğe koruma sağlamaz ve başka ModSecurity kural setlerini de devre dışı bırakabilir. Bu nedenle kısa süreli, izlenen ve artan yüzde planıyla kullanılmalıdır.

CRS güncelleme ve geri dönüş stratejisi

Yeni CRS sürümü yeni tespitler ve yanlış pozitif düzeltmeleri getirebilir. Güncelleme doğrudan canlı dosyaların üzerine açılmamalıdır:

Desteklenen sürümü resmi release kaynağından indirip imzasını doğrulayın.
Sürümlü ayrı dizine çıkarın; özel istisnaları kural setinin dışında tutun.
Yapılandırma ve kural yükleme testlerini CI ortamında çalıştırın.
Temsili normal istek ve kötü girdi regresyon setini yeni sürüme uygulayın.
Rule ID değişikliklerinin mevcut istisnaları geçersiz bırakıp bırakmadığını kontrol edin.
Önce küçük trafik yüzdesi veya canary host üzerinde gözlemleyin.
Anomali, gecikme ve yanlış pozitif eşiği aşılırsa eski sürüm sembolik bağlantısına dönün.
Başarılı dağıtımdan sonra sürüm, tarih, imza ve test sonucunu değişiklik kaydına yazın.

Resmi container kullanılıyorsa aynı süreç image tag ve digest üzerinden yürütülmelidir. Kayan etiket, planlanmamış CRS veya motor değişikliğini yeniden başlatma anında canlıya taşıyabilir.

Sık yapılan ModSecurity hataları

Hata	Sonuç	Düzeltme
Motor kurulmuş ama CRS include edilmemiş	Kapsamlı politika yok	Başlangıç logu ve kural sayısını doğrula
DetectionOnly kalıcı bırakılmış	Alarm var, engelleme yok	Tarihli geçiş planı ve sahip ata
PL4 ile doğrudan üretim	Kesinti ve çok sayıda yanlış pozitif	PL1 gözlem, ölçülü yükseltme
CRS dosyalarını doğrudan değiştirme	Güncellemede değişiklik kaybı	BEFORE/AFTER istisna dosyaları
Tüm rule tag'ini kapatma	Büyük tespit boşluğu	Tek endpoint/parametre/rule istisnası
Audit logda token/cookie bırakma	Yeni sır sızıntısı yüzeyi	Maskeleme, erişim ve saklama politikası
Kayan container etiketi	Kontrolsüz sürüm değişimi	Sürüm + digest sabitleme
Yalnız curl 403 testi	Yanlış güven	Rule ID, score, backend ve SIEM doğrulaması
Response body'yi körlemesine açma	Gecikme ve RFDoS riski	Dar MIME/endpoint kapsamı veya kapalı başlangıç
WAF'ı yama yerine kullanma	Kök neden devam eder	Uygulama düzeltmesi ve süreli sanal yama

Üretime geçiş kontrol listesi

Apache/ModSecurity 2 veya Nginx/ModSecurity 3 destekli kombinasyonu seçildi.
Motor ve CRS sürümü resmi kaynak, imza ve checksum ile doğrulandı.
CRS include sırası ve özel BEFORE/AFTER dosyaları test edildi.
DetectionOnly gözlem süresi tamamlandı; rule ID bazlı yanlış pozitif listesi çıkarıldı.
Başlangıç paranoia level ve anomaly threshold değişiklik kaydına yazıldı.
İstisnalar tek host/yol/parametre/rule kapsamına daraltıldı ve son kullanma tarihi aldı.
Request body, dosya yükleme ve JSON limitleri gerçek uygulama trafiğiyle test edildi.
Audit logda cookie, token, parola ve kişisel veri maskelemesi doğrulandı.
Normal kullanıcı akışları ile SQLi/XSS/path traversal laboratuvar testleri birlikte geçti.
Backend logu, WAF logu ve SIEM olayı ortak istek kimliğiyle ilişkilendirildi.
CPU, bellek, disk, gecikme ve log hacmi için alarm eşikleri tanımlandı.
Canary dağıtım, hızlı geri dönüş ve eski CRS sürümüne dönüş yolu denendi.
Uygulama ekibine engellenen isteği inceleme ve istisna talep süreci verildi.

Sonuç

ModSecurity ve OWASP CRS, web uygulamalarına genel saldırı tespiti, görünürlük ve geçici sanal yama sağlayan güçlü bir açık kaynak WAF katmanıdır. Güvenlik değeri yalnız paketi kurmaktan değil; desteklenen motor kombinasyonu, doğrulanmış sürüm, doğru include sırası, DetectionOnly gözlem, anomaly scoring, uygun paranoia level ve dar yanlış pozitif istisnalarının birlikte yönetilmesinden gelir.

Çoğu ekip için güvenli başlangıç; Apache'de ModSecurity 2.x veya Nginx'te libModSecurity 3.x, CRS PL1, ölçülmüş varsayılan eşikler, response body incelemesi kapalı/dar kapsamlı ve merkezi audit log yaklaşımıdır. Gerçek trafik gözlemlendikten sonra koruma kademeli artırılmalı; rule set dosyaları doğrudan değiştirilmemeli ve her istisna süreli olmalıdır.

WAF hiçbir zaman güvenli kod, yama, nesne düzeyi yetkilendirme, rate limiting ve olay izleme yerine geçmez. Doğru konumlandırıldığında bu kontrolleri tamamlar: bilinen kötü girdiyi uygulamaya ulaşmadan azaltır, saldırı denemelerini ayrıntılı kaydeder ve kök düzeltme hazırlanırken dar bir savunma penceresi sağlar.

Kaynaklar

TR Siber Ekibi Yazar · X

Kaynak bağlantısı ← Ana sayfaya dön