- Konu sahibi
- #1
WAF yanlış pozitiflerini araştırmanın doğru yolu, engellenen isteği WAF günlüklerinden belirleyip isteğin neden kurala takıldığını uygulama günlükleriyle karşılaştırmak, ardından aynı isteği güvenli bir test ortamında yeniden üretmektir. Sorun doğrulanırsa WAF’ı tamamen kapatmak yerine yalnızca gerekli kuralı, endpoint’i veya güvenilir koşulu mümkün olan en dar kapsamda istisna yapmak gerekir.
Yanlış pozitif, WAF’ın saldırı olmayan meşru bir isteği şüpheli görerek engellemesi veya izlemeye almasıdır. Örneğin bir yönetim panelindeki arama alanı, kullanıcı tarafından girilen JSON metni ya da ürün açıklamasındaki HTML benzeri içerik; SQL enjeksiyonu, XSS veya komut çalıştırma belirtisi arayan bir kuralla eşleşebilir.
Önce isteğin gerçekten meşru olduğunu doğrulayın. Bir isteğin yalnızca WAF tarafından engellenmiş olması, otomatik olarak yanlış pozitif olduğu anlamına gelmez. İstek saldırı belirtisi taşıyabilir veya ele geçirilmiş bir oturumdan geliyor olabilir.
Bir ürün yönetim ekranı, açıklama alanını JSON içinde gönderiyor ve WAF bu isteği XSS kuralıyla engelliyor. Günlükte eşleşmenin URL yolunda değil, JSON içindeki açıklama alanında olduğu görülüyor. Uygulama bu alanı güvenli biçimde işliyor ve değer yalnızca yetkili editörlerden geliyor.
Bu durumda tüm XSS korumasını kapatmak hatalıdır. İstisna yalnızca ürün güncelleme endpoint’inde, ilgili JSON alanında ve gereken HTTP yönteminde uygulanır. Aynı alanın ziyaretçi yorumlarında da kullanıldığı görülürse bu alanı istisna yapmak yerine uygulamanın çıktıyı kodlaması veya girdiyi doğrulaması gerekir.
CRS kullanan sistemlerde “inbound anomaly score exceeded” toplam engelleme kuralını görmek tek başına tetikleyen alanı açıklamaz; puanı artıran asıl kural eşleşmelerini inceleyin. Alan bazlı exclusion ürün tarafından desteklenmiyorsa belgelenen en dar kural override’ını seçin; endpoint var diye tüm güvenlik aşamalarını skip etmeyin. Log/payload ayrıntısı her üründe ve planda bulunmayabilir; hassas içeriği koruyun.
İstisnanın nerede uygulanacağı, eşleşmenin kaynağına ve iş akışına göre seçilmelidir:
Tablodaki istisna seçenekleri WAF ürününe göre farklı adlandırılabilir. Ürün destekliyorsa kuralı kaldırmak yerine belirli kuralın belirli alan üzerindeki denetimini daraltın. İstisnayı açıklayan bir not, değişiklik sahibi ve geri alma yöntemi de kaydedin.
Bütün WAF’ı kapatmak: Tek bir isteği düzeltmek için tüm korumayı kaldırmak, başka endpoint’lerdeki saldırıları görünmez hâle getirir.
Yalnızca IP adresine güvenmek: IP adresleri değişebilir, ortak kullanılabilir veya paylaşımlı NAT/proxy veya ele geçirilmiş bir ağ üzerinden gelebilir. Kurulmuş normal HTTPS bağlantısında IP spoofing ile yanıtlı oturum kurmak kolay bir genelleme değildir; proxy başlıklarının sahteciliği ayrıca değerlendirilir. IP istisnası ancak geçici ve doğrulanmış bir teşhis adımı olarak düşünülmelidir.
Kural kimliğine bakıp içeriği incelememek: Aynı kural farklı alanlarda farklı sonuçlar doğurabilir. Eşleşen alanı ve uygulamanın beklenen veri biçimini birlikte değerlendirin.
Düzeltmeyi izlemeden bırakmak: İstisna sonrası meşru işlem çalışıyor olsa bile saldırı tespitinin başka trafiklerde devam edip etmediğini kontrol edin. Sorun uygulamanın giriş veya çıktı işleme biçimindeyse kalıcı çözüm WAF istisnası değil, uygulama düzeltmesidir.
İstek kimliği ve zaman damgasıyla ters proxy, web sunucusu ve uygulama günlüklerini eşleştirin. Gerekli teşhis alanları kaydedilmiyorsa ayrıntılı günlüklemeyi yalnızca kontrollü bir süre ve hassas verileri maskeleyerek etkinleştirin.
Hayır. İstisnanın doğru katmanda ve doğru alanda uygulanıp uygulanmadığını kontrol edin. Tekrarlama, uygulamanın aynı veriyi farklı endpoint’lerde işlediğini veya kural dışında bir doğrulama sorunu bulunduğunu gösterebilir.
Yanlış pozitif nedir?
Yanlış pozitif, WAF’ın saldırı olmayan meşru bir isteği şüpheli görerek engellemesi veya izlemeye almasıdır. Örneğin bir yönetim panelindeki arama alanı, kullanıcı tarafından girilen JSON metni ya da ürün açıklamasındaki HTML benzeri içerik; SQL enjeksiyonu, XSS veya komut çalıştırma belirtisi arayan bir kuralla eşleşebilir.
Önce isteğin gerçekten meşru olduğunu doğrulayın. Bir isteğin yalnızca WAF tarafından engellenmiş olması, otomatik olarak yanlış pozitif olduğu anlamına gelmez. İstek saldırı belirtisi taşıyabilir veya ele geçirilmiş bir oturumdan geliyor olabilir.
Araştırma akışı
- WAF olay kaydında zaman, istek kimliği, istemci IP’si, HTTP yöntemi, host, yol, sorgu parametreleri, kural kimliği, eşleşen alan ve uygulanan eylemi kaydedin. İstek gövdesi hassas veri içeriyorsa tamamını gereksiz yere kopyalamayın.
- Aynı zaman aralığında web sunucusu, uygulama ve kimlik doğrulama günlüklerini karşılaştırın. Kullanıcı hangi işlemi yapıyordu, istek uygulamaya ulaştı mı ve uygulama bir hata döndürdü mü belirleyin.
- Eşleşen veriyi inceleyin. Sorun çoğunlukla sorgu parametresinde, form alanında, JSON gövdesinde, çerezde veya başlıkta bulunur. Değeri güvenli ve beklenen bir iş akışının parçası olarak açıklayamıyorsanız istisna uygulamayın.
- Aynı kullanıcı işlemini test ortamında, mümkünse aynı HTTP yöntemi ve benzer veriyle yeniden üretin. WAF’ı tamamen devre dışı bırakmak yerine ilgili kuralı yalnızca test için gözlemleme moduna almak daha açıklayıcıdır.
- Üretimde gerekli istisnayı en dar kapsamda tanımlayın. Öncelik sırasıyla tek endpoint, tek parametre veya gövde alanı, belirli HTTP yöntemi ve mümkünse kimlik doğrulanmış beklenen trafik olmalıdır.
- Değişiklikten sonra hem meşru işlemi hem de ilgili saldırı sınıfını temsil eden güvenli testleri kontrol edin. Olay sayısını, uygulama hatalarını ve kuralın hâlâ diğer isteklerde çalıştığını izleyin.
Somut örnek
Bir ürün yönetim ekranı, açıklama alanını JSON içinde gönderiyor ve WAF bu isteği XSS kuralıyla engelliyor. Günlükte eşleşmenin URL yolunda değil, JSON içindeki açıklama alanında olduğu görülüyor. Uygulama bu alanı güvenli biçimde işliyor ve değer yalnızca yetkili editörlerden geliyor.
Bu durumda tüm XSS korumasını kapatmak hatalıdır. İstisna yalnızca ürün güncelleme endpoint’inde, ilgili JSON alanında ve gereken HTTP yönteminde uygulanır. Aynı alanın ziyaretçi yorumlarında da kullanıldığı görülürse bu alanı istisna yapmak yerine uygulamanın çıktıyı kodlaması veya girdiyi doğrulaması gerekir.
CRS kullanan sistemlerde “inbound anomaly score exceeded” toplam engelleme kuralını görmek tek başına tetikleyen alanı açıklamaz; puanı artıran asıl kural eşleşmelerini inceleyin. Alan bazlı exclusion ürün tarafından desteklenmiyorsa belgelenen en dar kural override’ını seçin; endpoint var diye tüm güvenlik aşamalarını skip etmeyin. Log/payload ayrıntısı her üründe ve planda bulunmayabilir; hassas içeriği koruyun.
Karar verirken kapsamı daraltma
İstisnanın nerede uygulanacağı, eşleşmenin kaynağına ve iş akışına göre seçilmelidir:
| Gözlenen durum | Uygun yaklaşım | Kaçınılacak yaklaşım |
|---|---|---|
| Tek bir parametre beklenen metinle eşleşiyor | Yalnızca ilgili alanı ve endpoint’i daraltmak | Tüm site için kuralı kapatmak |
| Bir endpoint’in tüm istekleri yanlış engelleniyor | İstek yöntemi, oturum durumu ve endpoint’i doğrulayarak istisna tanımlamak | IP adresine kalıcı güven vermek |
| Aynı kural farklı sayfalarda saldırıları yakalıyor | Uygulamadaki veri işleme sorununu düzeltmek | Genel kural hassasiyetini düşürmek |
| Neden belirsiz veya trafik şüpheli | İsteği istisna vermeden incelemek ve gerekirse engellemeyi sürdürmek | Kullanıcı şikâyetiyle hemen izin vermek |
Tablodaki istisna seçenekleri WAF ürününe göre farklı adlandırılabilir. Ürün destekliyorsa kuralı kaldırmak yerine belirli kuralın belirli alan üzerindeki denetimini daraltın. İstisnayı açıklayan bir not, değişiklik sahibi ve geri alma yöntemi de kaydedin.
Sık yapılan hatalar
Bütün WAF’ı kapatmak: Tek bir isteği düzeltmek için tüm korumayı kaldırmak, başka endpoint’lerdeki saldırıları görünmez hâle getirir.
Yalnızca IP adresine güvenmek: IP adresleri değişebilir, ortak kullanılabilir veya paylaşımlı NAT/proxy veya ele geçirilmiş bir ağ üzerinden gelebilir. Kurulmuş normal HTTPS bağlantısında IP spoofing ile yanıtlı oturum kurmak kolay bir genelleme değildir; proxy başlıklarının sahteciliği ayrıca değerlendirilir. IP istisnası ancak geçici ve doğrulanmış bir teşhis adımı olarak düşünülmelidir.
Kural kimliğine bakıp içeriği incelememek: Aynı kural farklı alanlarda farklı sonuçlar doğurabilir. Eşleşen alanı ve uygulamanın beklenen veri biçimini birlikte değerlendirin.
Düzeltmeyi izlemeden bırakmak: İstisna sonrası meşru işlem çalışıyor olsa bile saldırı tespitinin başka trafiklerde devam edip etmediğini kontrol edin. Sorun uygulamanın giriş veya çıktı işleme biçimindeyse kalıcı çözüm WAF istisnası değil, uygulama düzeltmesidir.
Kaynaklar
Sık sorulan sorular
WAF günlüğünde eşleşen alan görünmüyorsa ne yapılmalı?
İstek kimliği ve zaman damgasıyla ters proxy, web sunucusu ve uygulama günlüklerini eşleştirin. Gerekli teşhis alanları kaydedilmiyorsa ayrıntılı günlüklemeyi yalnızca kontrollü bir süre ve hassas verileri maskeleyerek etkinleştirin.
Aynı yanlış pozitif tekrar oluşuyorsa istisna yeterli midir?
Hayır. İstisnanın doğru katmanda ve doğru alanda uygulanıp uygulanmadığını kontrol edin. Tekrarlama, uygulamanın aynı veriyi farklı endpoint’lerde işlediğini veya kural dışında bir doğrulama sorunu bulunduğunu gösterebilir.
