ModSecurity Yanlış Pozitiflerini Doğrulamak
Bir ödeme akışında yalnız bazı isteklerin başarısız olduğunu düşünün. Neden uygulama, ödeme sağlayıcısı veya WAF olabilir; yalnız bir hata mesajıyla karar verilmez. ModSecurity günlüğündeki kural kimliği, eşleşen alan ve uygulama kaydı aynı istekle ilişkilendirilmelidir. Meşru bir isteğin kural nedeniyle engellendiği doğrulanırsa yanlış pozitif üzerinde çalışılabilir.
Bu rehber, ModSecurity ve OWASP CRS yanlış pozitiflerini azaltmak için gözlem, anomali puanlaması, paranoya seviyeleri ve dar kapsamlı dışlamaları ele alır. WordPress, WooCommerce ve Laravel örnekleri varsayımsaldır. Amaç; uygulama akışlarını ve gerekli denetimleri birlikte doğrulamak, performans değişikliklerini ölçmek ve her ayar için geri dönüş yolu hazırlamaktır.
Meşru Bir İstek Neden Kural Tetikler?
ModSecurity, etkin olduğu HTTP trafiğini seçilen kurallar, gövde işleyicileri ve boyut sınırları içinde inceler; ağdaki her paketi veya sınırsız büyüklükte her alanı denetlemez. OWASP CRS bu incelemeye saldırı kalıpları ve protokol kontrolleri sağlar. Meşru bir yorumdaki özel karakterler, WooCommerce filtre parametreleri veya bir webhook gövdesi de kural tetikleyebilir. Bu nedenle eşleşme kaydını, gerçek isteği ve uygulamanın beklediği biçimi birlikte incelemek gerekir. Bir eşleşme tek başına kötü niyeti kanıtlamaz.
Yanlış pozitif; uygulamanın kabul ettiği veri biçimiyle bir kuralın eşleşmesinden veya gövdenin beklenen biçimde işlenmemesinden kaynaklanabilir. Kural seti, gövde işleyicisi ve yönlendirme davranışı birlikte incelenmelidir. CRS anomali puanlamasında eşleşmeler puan ekler; etkin engelleme yapılandırmasında toplam ilgili eşiğe ulaştığında veya onu aştığında istek engellenebilir. Bu, istemcinin IP adresine otomatik kalıcı yasak uygulandığı anlamına gelmez.
DetectionOnly ve Anomali Eşiğinin Sınırları
Yeni yapılandırmayı önce hazırlık ortamında veya mevcut üretim engellemesinin arkasındaki ayrı gözlem katmanında deneyin. DetectionOnly kuralları çalıştırır, ancak engelleyici eylemleri uygulamaz; çalışan üretim WAF’ını sırf gözlem için bu moda geçirmek mevcut korumayı kaldırır. Temsilî meşru istekleri ve denetimli saldırı testlerini karşılaştırın. Süreyi birkaç gün gibi sabit bir reçeteye bağlamak yerine ödeme, giriş, API ve yükleme akışlarının kapsandığını doğrulayın. Kural kimliği, yol ve eşleşen alanı araştırmaya yetecek günlükleri tutun; erişim, saklama ve hassas veri kapsamını ayrıca belirleyin.
DetectionOnly, engelleme kararı uygulamadan kural eşleşmelerini incelemek içindir. Engelleme modunda eşiği yükseltmek bazı yanlış pozitifleri durdurabilir, ancak saldırı puanı yeni eşiğin altında kalan istekleri de geçirebilir. Bu nedenle eşik artışını genel çözüm olarak kullanmayın; önce yanlış pozitife neden olan kuralı ve alanı belirleyin. Birden fazla eşleşme de tek başına saldırı kanıtı değildir.
Uygulamada Ne İşe Yarar?
Varsayımsal bir WooCommerce örneğinde yeni temanın filtre parametresi SQLi kuralıyla eşleşebilir. Önce hazırlık ortamında aynı isteği tekrar üretin; kural kimliğini, eşleşen parametreyi ve uygulama doğrulamasını inceleyin. Yanlış pozitif doğrulanırsa yalnız gereken yol, kural ve parametreye ait istisnayı değerlendirin. Ardından meşru filtre isteklerini, benzer saldırı girdilerini ve istisna dışındaki yolları sınayın. Sonuçlar uygun olduğunda kontrollü yayın ve geri dönüş planı kullanın. Dışlanan hedefte ilgili kuralın kontrolü azalır; bu işlem saldırıların yakalanacağını veya tüm kullanıcı akışlarının sorunsuz kalacağını garanti etmez.
Paranoya Seviyesi ile Eşiği Ayrı Değerlendirin
Paranoya seviyesi yükseldikçe ek kurallar çalışır ve yanlış pozitifleri inceleme ihtiyacı artabilir. Yeni dağıtımda PL1 temelini doğrulayın; daha yüksek seviyeleri hazırlık ortamında değerlendirin. CRS 4, blocking_paranoia_level ve detection_paranoia_level ayarlarını ayırır: daha yüksek seviyenin kuralları değerlendirilirken doğrulanmış düşük seviyedeki engelleme korunabilir. Algılama seviyesi engelleme seviyesinin altında olmamalıdır; ek kurallar yine işlem maliyeti getirir. Kurulu CRS sürümünün ayar adlarını ve davranışını doğrulayın.
Anomali puan eşiği ile paranoiayı birlikte düşünmek gerekir. Paranoya seviyesi daha fazla kuralı devreye alır; anomali eşiği ise engelleme kararını belirler. Seviyeyle birlikte eşiği orantılı artırmak gerekmez. Yeni yanlış pozitifleri dar kapsamlı dışlamalarla düzeltmek, eşiği yükselterek saldırıları da geçirme riskini azaltır. Ayarı küçük adımlarla yapmak, yaşanan her değişikliğin etkisini görmek için iyi bir yöntem. Büyük sıçramalar, nerede hata yaptığınızı anlamayı zorlaştırır.
Bir Küçük Not
Kural davranışlarının sürpriz yapmaması için resmi belgeler her zaman el altında olsun. OWASP CRS’in yol gösterici ve anlaşılır dokümantasyonu işinizi kolaylaştırır. Bu konuda OWASP CRS dokümantasyonunda güzel anlatımlar ve yanlış pozitifleri tanıyıp ayıklamak için pratik başlıklar var. Özellikle false positive kavramı üzerine yazılan rehber kısa sürede çok yol aldırır.
Yol, Kural ve Parametreye Göre Dar Dışlama
WordPress admin-ajax veya bir Laravel webhook isteği beklenen veri içerdiği hâlde kural tetikleyebilir. Önce ilgili isteğin meşru olduğunu ve uygulamanın veriyi nasıl doğruladığını belirleyin. Sonra yalnız gereken yol, kural ve parametre için dışlama değerlendirin. Bu yaklaşım diğer kontrolleri korur, ancak dışlanan kuralın o alanı incelemesini kaldırır; güvenliğin veya akışın değişmeden kalacağı varsayılamaz.
Dışlamayı iki adımda düşünün. Önce “hedefi daraltın”. Yani bütün siteyi gevşetmek yerine, sadece belli yol ya da parametre için esnetin. Ardından “hangi kuralları” kenara aldığınızı görün. Genelde birkaç kural, belirli bir şablon yüzünden sürekli tetiklenir. Dar dışlamalar diğer denetimleri korur, ancak dışlanan kural-hedef çiftinde koruma azalır. WooCommerce’de sepete ekleme ve varyasyon filtrelerini, ilgili saldırı örnekleriyle birlikte yeniden kontrol etmek gerekir.
JSON Gövde ve Dosya Yükleme Üzerine
API ağırlıklı uygulamalarda, gövdeyi doğru okumak kritik. JSON içeriği düzgün çözümlenmezse kurallar yanlış alarmlar üretebilir. Dosya yüklemeleri statik içerik istekleri değildir. Boyut sınırlarını uygulamanın ihtiyacına göre belirleyin; yükleme isteğinin parametrelerini ve multipart yapısını denetimde tutun. Dosya türü ve içerik doğrulamasını uygulama da yapmalıdır.
Performans Değişikliğini Koruma Kapsamıyla Ölçün
Gecikme ve kaynak kullanımını aynı trafik profili altında karşılaştırın. Yalnızca statik içerik sunduğu ve uygulamaya yönlenmediği doğrulanan yollar için denetimi daraltmak değerlendirilebilir. Dosya uzantısı tek başına yeterli değildir; yöntem, başlıklar ve parametreler de denetim hedefi olabilir. Hangi kontrolün kaldırıldığını kaydedin ve performans kazancını ölçün.
Yanıt gövdesi incelemesini kapatmak, bu gövdedeki sızıntı ve saldırı kontrollerini de kaldırır; bunu genel hız ayarı olarak önermeyin. Günlükleri azaltırken olay incelemesi için gereken kural, yol ve hata bilgilerini koruyun. İstek gövdesi sınırlarını uygulama, web sunucusu ve WAF arasında uyumlu belirleyin. SecRequestBodyLimitAction Reject sınırı aşan gövdeyi reddeder; ProcessPartial yalnız sınıra sığan bölümünü inceler, kalan bölüm denetim dışında geçebilir. DetectionOnly modunda limit davranışı otomatik olarak ProcessPartial olur. Meşru büyük istekleri ve sınır aşımını ayrıca test edin; eşzamanlı istekler, geçici disk, CPU ve PHP-FPM/veritabanı kuyruklarını birlikte ölçün.
Bir başka güçlü kombinasyon da önbellekleme ve kenar (edge) politikaları. Önbellek WAF’tan önce yanıt veriyorsa o WAF’ın yükü azalabilir; WAF önbellekten önce çalışıyorsa istek denetimi sürer. Bu konuda pratik dokunuşlar için WordPress’te tam sayfa önbellekleme üzerine anlattığımız rehberi göz atılacak güzel bir kaynak olarak kenara bırakıyorum.
Kenar ve Ön Kapı Arasında Uyum
Kenar WAF, oran sınırlama ve ModSecurity farklı noktalarda denetim sağlayabilir. İsteklerin hangi sırayla işlendiğini ve origin sunucuya kenar katmanı atlanarak erişilip erişilemediğini kontrol edin. Bir katmandaki engelleme diğerinin kapsamını otomatik tamamlamaz. Birlikte kullanım için WAF ve bot koruması rehberindeki örnek senaryoları değerlendirebilirsiniz.
Uygulama Örnekleri: WordPress, WooCommerce ve Laravel API
WordPress tarafında görülebilen meselelerden biri admin-ajax ve REST API çağrıları. Bir eklenti beklenmedik parametreler ekliyor, bir filtreleme eklentisi URL’e görece keskin desenler koyuyor ve CRS bunları şüpheli buluyor. İlk iş, log’larda yanlış pozitifi doğrulamak; ardından dışlamayı ilgili endpoint, kural ve parametreyle sınırlamak. Tam siteyi gevşetmek yok, nokta atışı esneme var. WooCommerce’de sepete ekleme ve varyasyon filtreleri, özellikle kampanya dönemlerinde yoğunlaştığı için, akışı kesmeye en az hevesli yerler olmalı.
Laravel tarafında ise genellikle webhook’lar ve JSON post eden mobil uygulamalar konuyu alevlendiriyor. Ödeme ve bildirim servisleri, içerikte özel karakterler taşıyabiliyor. JSON gövdeyi doğru çözümlemek ve yanlış pozitif doğrulanırsa dışlamayı ilgili webhook, kural ve parametreyle sınırlamak gerekir. /webhook/ öneki isteği güvenilir yapmaz; uygulama sağlayıcının imza doğrulamasını ve tekrar oynatma kontrollerini uygulamalıdır.
Bu akışların önüne küçük setler çekmek için kenarda tutacağınız bir katman işinizi kolaylaştırır. Oran sınırlama gibi ön kapı taktikleri, gereksiz yoğunluğu törpüler. Anlatması kolay, uygulaması basit örnekler için Cloudflare WAF kuralları ve oran sınırlama ile WordPress’i bot’lardan koruma notları tam tadında bir eşlikçi olur.
Küçük Bir Senaryo
Varsayımsal bir kampanya senaryosunda sepet işlemleri aksasın ve log’larda iki kural belirli parametrelerde tetiklensin. Yanlış pozitif doğrulanırsa yalnızca ilgili URL, kural ve parametreler için dışlama denenebilir. Eşiği yükseltmek kuralın puanını düşürmez; engelleme için gereken toplam puanı artırır. Her değişiklik ayrı ölçülmeli; hızlanma veya korumanın değişmediği varsayılmamalıdır.
Günlükler, Ölçüm ve Geri Alma
Günlük politikasını yalnız kayıt sayısını azaltmak için değiştirmeyin. Yanlış pozitif ve saldırı incelemesi için kural kimliği, istek yolu, eşleşen alan ve hata bağlamı gerekir. Hassas değerleri koruyun; erişim, saklama ve döndürme politikasını belirleyin. Debug kaydı ile audit kaydı farklı amaç taşır. Sessiz günlükler, denetimin yeterli olduğunu veya uygulamanın sorunsuz çalıştığını kanıtlamaz.
Gecikme, işlemci kullanımı, hata oranı, gövde işleme hataları ve beklenen kural eşleşmelerini birlikte izleyin. Artan gecikme tek başına WAF kaynaklı sorunu, büyüyen günlük de gereksiz kaydı kanıtlamaz. Uygulama ve altyapı ölçümlerini aynı zaman aralığında karşılaştırın. Prometheus ve Grafana ile uyarı kurma rehberi bu izleme düzenini planlamaya yardımcı olabilir.
Deneme, Geri Alma, Küçük Adımlar
Bir seferde sınanabilir kapsamda değişiklik yapın. Değişiklik öncesi çalışan yapılandırmayı, beklenen sonuçları ve geri alma yöntemini kaydedin. Yeni bir kullanıcı akışı engellenirse veya saldırı testi beklenen biçimde yakalanmazsa, neden araştırılırken son doğrulanmış yapılandırmaya dönülebilmelidir. Genel olarak WAF’ı kapatmak bu geri alma planının yerine geçmez.
Yayın Kararı İçin Gerekli Kayıtlar
Yayın kaydına kullanılan ModSecurity, bağlayıcı ve CRS sürümlerini; etkin eşikleri; dışlamanın gerekçesini; sorumlusunu ve yeniden inceleme koşulunu yazın. Hazırlık ortamı veya mevcut üretim engellemesini koruyan ayrı gözlem katmanındaki test sonuçlarını ekleyin. Ödeme, giriş, API ve yükleme akışlarının hangilerinin sınandığı açık olmalıdır; geçen gün sayısı temsilî kapsamın yerini tutmaz.
Yayın ve geri alma ölçütlerini değişiklikten önce belirleyin: meşru akışların beklenen sonucu, kontrollü saldırılarda beklenen algılama veya engelleme, kabul edilebilir hata ve gecikme aralığı. İncelenmemiş kritik akış ya da açıklanamayan denetim kaybı varsa değişikliği genişletmeyin. CRS güncellemesi, yeni eklenti veya yönlendirme değişikliği aynı testlerin tekrarını gerektirebilir; artık gerekmeyen istisnaları kaldırmayı da değerlendirin.
Bu noktada resmi referans elinizin altında olsun. ModSecurity’nin davranış detaylarına dair, kullandığınız sürümle karşılaştırmanız gereken bilgilere ModSecurity referans el kitabından bakmak, “bu ayar neye dokunuyor” sorusunu dakikalar içinde cevaplatır.
Doğrulanmış Ayarlarla İlerleyin
İlk adım, sorunlu tek bir akışı seçip yanlış pozitifi günlük ve uygulama davranışıyla doğrulamaktır. Dar değişikliği hazırlık ortamında veya ayrı gözlem katmanında sınarken mevcut üretim engellemesini koruyun. Paranoya seviyesini ancak temsilî meşru istekler ve kontrollü saldırı testleri beklenen sonuçları verdiğinde artırın; düşük alarm sayısı yeterli karar ölçütü değildir.
Performans için önbellek ve kenar denetimlerinin konumunu kaydedin. Önbellek ModSecurity’den önce yanıt veriyorsa iç WAF yükü azalabilir; sonra çalışıyorsa istek denetimi sürer. Ölçülmüş sonuç, belgelenmiş koruma kapsamı ve uygulanabilir geri alma planı birlikte uygun olduğunda değişikliği kontrollü yayımlayın.
