418 alan bir istek Event Logs'ta neden görünmüyor?
Kısa cevap
En olası neden, Blocking Mode'daki bir host grubunda isteğin WAF taramasının 2 saniyelik süre sınırı içinde tamamlanamamasıdır. Denetlenmemiş istek Kurum Servisine ulaşmasın diye engellenir ve olağan engelleme yanıtı (Blocking Status Code, varsayılan 418) döner; ancak tarama kaydı yazacak aşamaya ulaşmadığı için istek Event Logs'ta, Global WAF Event Log'da ve WAF Inspection Distribution panelinde görünmez. İz Debug Mode Logs kaydında (Security Action WAF · Attack blocked — scan timed out, Triggered rules 369999) ve log sunucusuna giden WAF bilgisinde (wafTime 2000) kalır; Debug Mode geriye dönük kayıt tutmaz, olay anında açık olmalıdır. Learning ve Monitor modundaki gruplarda bu engel oluşmaz. Süre sınırı değiştirilemez; çözüm, taraması uzun süren isteği bulup taranan gövdeyi küçültmektir (Max. Body Size to Process(kB)). Engeller hizmeti etkiliyor ve istek küçültülemiyorsa Request Body Limits penceresindeki Fail-open açılır; açıkken bu istekler taranmadan geçirilir. Diğer olasılıklar: kaydın WAF Log Suppression Condition ile listeden gizlenmesi, Event Logs ekranındaki Date Range, Line Limit, Request Unique ID ya da Log Filter kapsamının kaydı dışarıda bırakması, isteğin başka bir vService'e gitmesi ve 418'in WAF dışındaki bir katmandan gelmesi.
Sorun: 418 Alan İsteğin Kaydı Bulunmuyor
Kullanıcı 418 aldığını ve engelleme sayfasındaki Request ID'yi bildiriyor, ancak Event Logs'ta Request Unique ID ile yapılan aramada kayıt çıkmıyor. Kayıt olmadığı için engeli veren kural görülemiyor ve Allow / Teach ile öğretme yapılamıyor (Kullanıcılarım "418" hatası alıyor; ne oluyor?).
Olası Nedenler
| Neden | Nasıl ayırt edilir |
|---|---|
| WAF taraması 2 saniyelik süre sınırı içinde tamamlanamadı (yalnızca Blocking Mode'da, Fail-open kapalıyken; kurallar yüklenirken oluşabilen bir istisna dışında) | Debug Mode Logs'ta Security Action = WAF · Attack blocked — scan timed out · 1 attacks; satırın WAF kutusunda Triggered rules = 369999 |
| Kayıt WAF Log Suppression Condition'a uyuyor | WAF Management'taki Log Settings kartında "WAF logging is suppressed for requests matching:" satırı var; Debug Mode Logs'ta Security action WAF · Attack blocked · … (zaman aşımı değil) |
| Event Logs kapsamı kaydı dışarıda bırakıyor | Sunucu filtresi sekmesinin başlığında görünen zaman aralığı olay saatini kapsamıyor, Line Limit dolmuş ya da tanımlı bir Log Filter var |
| İstek başka bir vService'e gitti | Aynı Request ID Global WAF Event Log'da bulunuyor |
| 418 WAF'tan gelmiyor (Load Balancer Block aksiyonunda 418 seçilmiş ya da Kurum Servisi 418 döndürüyor) | Debug Mode Logs'ta WAF kutusu yok; HTTP Logs'ta Backend Service TR7 ya da sunucunun adı |
Kesin kurallar:
- Event Logs kaydı yalnızca taramanın sonunda yazılır ve yalnızca iki durumda oluşur: puan engelleme eşiğine ulaştığında ya da Monitor durumundaki bir imza tetiklendiğinde. Tarama süre sınırında kesilen istek bu aşamaya ulaşmaz. Learning Mode'daki host grubunda ve Conditional Learning kimliğiyle gelen istekte Event Logs kaydı hiç oluşmaz.
- Zaman aşımı engeli yalnızca Blocking mode'daki host grubunda ve Request Body Limits penceresindeki Fail-open kapalıyken (varsayılan) oluşur. Learning mode ve Monitor Mode'daki gruplarda, Teacher tarafından tanınan ve Conditional learning kimliğiyle gelen isteklerde ve Fail-open açıkken taraması tamamlanamayan istek geçirilir (Learning ve Monitor mode'daki gruplar için tek istisna: tarama kurallar yüklenirken ve host grubu belirlenmeden kesildiyse ve vService'te Blocking mode'da bir grup varsa istek engellenir); bu istek Debug Mode Logs dahil hiçbir yerde WAF izi bırakmaz.
- 2 saniyelik süre bir ayar değildir; arayüzden ve WEB-CLI'dan değiştirilemez. Süre yalnızca taramanın kendisini sayar; gövdenin ağdan gelmesini beklemek bu süreye girmez (Tarama belirli bir süreyi aşarsa istek ne olur (2 saniyelik tarama sınırı)?).
- Whitelist Condition'a uyan ve statik içerik sayılan istekler WAF'a hiç girmediği için zaman aşımına da uğramaz.
- Zaman aşımına uğrayan istek WAF Inspection Distribution panelinin hiçbir serisinde (Whitelisted, Clean, Blocked, Monitor, Teacher, Learning) sayılmaz.
- Bastırılan kayıt diske yazılmaya devam eder; Event Logs ve Global WAF Event Log listelerinde gösterilmez.
Zaman Aşımında İz Nerede Kalır?
| Yüzey | Zaman aşımıyla engellenen istek |
|---|---|
| Event Logs · Global WAF Event Log | Görünmez |
| WAF Inspection Distribution · WAF Blocked Requests | Sayılmaz |
| Debug Mode Logs (Debug mode olay anında açıksa) | Security action = WAF · Attack blocked — scan timed out · 1 attacks; Summary sekmesindeki WAF kutusunda Verdict = Attack blocked — scan timed out, Attacks = 1, Triggered rules = 369999 |
| HTTP Logs (vService'te LOG açıksa) | Durum kodu 418 (ya da seçilen Blocking Status Code) |
| Log sunucusu (CEF, TR7 JSON, TR7 WAF Log biçimleri) | wafInfo içinde kural 369999, puan 100, wafTime 2000: Debug Mode Logs veya SIEM kayıtlarında 369999 numaralı kural görüyorum; bu nedir? |
Nasıl Teşhis Edilir?
- Event Logs'un sunucu filtresi sekmesinde Date Range olay saatini kapsayacak şekilde genişletilir, tanımlı bir Log Filter varsa Remove Filter ile kaldırılır, Request Unique ID alanına Request ID yazılır ve Save & Get Logs tıklanır (sunucu filtresi). Kayıt çıkmazsa aynı arama Configuration Menu → WAF → Global WAF Event Log ekranında yapılır (Belirli bir isteği Request Unique ID ile nasıl bulurum?).
- Left Monitor Panel → WAF-Protected vServices → vService → WAF Management açılır; Learning & Reporting bölümündeki Log Settings kartında "WAF logging is suppressed for requests matching:" satırı varsa koşulun isteği kapsayıp kapsamadığına bakılır.
- Kayıt hâlâ yoksa Load Balancer → Load Balancer vService List ekranında vService'in düzenleme formunda Status = Debug mode seçilip Save tıklanır. Yoğun trafikte Debug altındaki koşul alanıyla kayıt kullanıcının IP'sine daraltılır (koşullu debug). Kayıt yalnızca bu andan sonra gelen istekler için oluşur. Debug mode'u açmak Load Balancer alanında değiştirme, Debug Mode Logs'u görmek Load Balancer alanında izleme yetkisi ister; yalnız WAF yetkisi olan kullanıcıda bu ekranlar açılmaz (Logs & Tracking).
- Kullanıcıdan isteği tekrarlaması istenir.
- Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → Debug Mode Logs açılır. Filter şeridindeki Security action sekmesinde
WAF · Timeoutseçilir ya da Columns menüsünden varsayılan olarak gizli Security action kolonu eklenir. - Satıra tıklanır; Summary sekmesindeki WAF kutusunda Verdict = Attack blocked — scan timed out ve Triggered Rules = 369999 görülüyorsa istek tarama zaman aşımıyla engellenmiştir. İsteğin Path değeri, gövde boyutu ve Content-Type başlığı not edilir; olağan taramalar milisaniyeler sürdüğünden zaman aşımı genellikle taranması olağan dışı uzun süren bir isteğe (çok büyük ya da derin bir gövde, çok sayıda parametre) işaret eder.
- Satırda WAF kutusu yoksa engel WAF'tan gelmemiştir: Meşru kullanıcılar engelleniyor; hangi kuralın engellediğini nasıl bulurum?
- İnceleme bitince Status yeniden Enabled yapılıp kaydedilir.
Çözüm: Üç Yöntem
Zaman aşımı kaydı Event Logs'a taşınamaz ve süre sınırı değiştirilemez. Kalıcı çözüm, taraması uzun süren isteği bulup taranan gövdeyi küçültmektir (Yöntem 1); bu yapılamıyor ve engeller hizmeti etkiliyorsa Fail-open açılır (Yöntem 2). Bastırma koşulu kaydı gizliyorsa koşul daraltılır (Yöntem 3). Yöntemler farklı nedenlere yöneliktir; zaman aşımında önce Yöntem 1 denenir.
| Durumunuz | Uygun yol |
|---|---|
| Zaman aşımı büyük gövdeli isteklerde oluşuyor; vService genelinde taranan gövde küçültülebilir | Yöntem 1: Taranan gövdeyi küçültmek |
| Zaman aşımı yalnızca belirli bir uçtaki büyük isteklerde (POST, JSON) oluşuyor | Büyük POST istekleri engelleniyor veya yarıda kesiliyor; neden? |
| Zaman aşımı dosya yüklemelerinde oluşuyor | Dosya yüklemeleri WAF tarafından engelleniyor; nasıl çözerim? |
| Zaman aşımı yalnızca güvenilir bir kaynaktan gelen belirli bir uçta oluşuyor | Belirli IP'leri veya istekleri WAF incelemesinden tamamen muaf tutabilir miyim (Whitelist Condition)? |
| Engeller hizmeti etkiliyor ve istek küçültülemiyor | Yöntem 2: Fail-open |
| Kayıt WAF Log Suppression Condition yüzünden listelenmiyor | Yöntem 3: WAF Log Suppression Condition'ı daraltmak |
| Süre sınırının kendisi ve moda göre sonucu | Tarama belirli bir süreyi aşarsa istek ne olur (2 saniyelik tarama sınırı)? |
Yöntem 1: Taranan Gövdeyi Küçültmek Önerilen
- Nasıl çalışır Taranan gövde, Max. Body Size to Process(kB) ile vService Limits profilindeki Buffer Size(kB) değerlerinin büyüğüyle sınırlıdır. Sınır küçülünce büyük gövdeler çözümlenmez ve taranmaz; bu gövdelerin akıbetini sayfa tipinin Raw sekmesindeki Block Unparsed Contents ayarı belirler.
- Nerede açılır Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Inspection & Blocking → Request Body Limits kartı
- Gereksinim WAF alanında değiştirme yetkisi. vService Limits profilindeki Buffer size(kB) daha büyükse sınır o değerde kalır; o profilde de düşürülür (profil başka vService'lere de atanmışsa onlar da etkilenir)
- Kapsam vService geneli; bütün host grupları ve sayfa tipleri
- Gövdesi sınırı aşan istek Sayfa tipinde Block Unparsed Body seçiliyse Block Unparsed Contents ihlaliyle puanlanır ve Blocking mode'da engellenir; bu kez Event Logs'ta kaydı oluşur. Gövdenin taranmadan geçmesi isteniyorsa o sayfa tipinde Allow Unparsed Body seçilir (Büyük POST istekleri engelleniyor veya yarıda kesiliyor; neden?)
Adım adım yapılandırma
Left Monitor Panel → WAF-Protected vServices → vService → WAF Management açılır.
Inspection & Blocking bölümündeki Request Body Limits kartının kalem ikonu tıklanır; Request Body Limits penceresi açılır (Edit ekranı).
Max. Body Size to Process(kB) alanına, uygulamanın taranması gereken olağan isteklerini kapsayan daha küçük bir değer yazılır (1 – 262144; WAF açılışta 4096). Zaman aşımına uğrayan isteğin Debug Mode Logs'ta not edilen gövde boyutu bu değerden büyük olmalıdır.
Edit tıklanır; WAF yapılandırması ayrı bir dağıtım adımı olmadan yeniden üretilip uygulanır. Yeni değer istek tamponunu (iki değerden büyüğü) değiştirirse kayıtla birlikte vService yeniden başlatılır; arayüz bunun için ayrıca uyarı göstermez, bu yüzden değişiklik bakım penceresinde yapılır (Büyük istek gövdeleri (dosya yükleme) WAF performansını nasıl etkiler?). Cluster kurulumunda değişiklik varsayılan auto-sync ile eş cihaza da gönderilir; Manual Sync Mode açıksa Synchronize ile gönderilir.
Doğrulama
vService Debug mode'dayken kullanıcı isteği tekrarlar; Security action kolonuna bakılır.
WAF · Attack blocked — scan timed out satırı yokYöntem 2: Fail-open
- Nasıl çalışır Blocking mode'da taraması süre sınırı içinde tamamlanamayan isteği engellemek yerine taranmadan geçirir. Taraması tamamlanan istekler eskisi gibi denetlenir ve engellenir; Learning ve Monitor modlarında bu istekler zaten geçirildiği için bu modlarda etkisi yoktur.
- Nerede açılır Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Inspection & Blocking → Request Body Limits penceresi → Fail-open (varsayılan kapalı)
- Gereksinim WAF alanında değiştirme yetkisi
- Kapsam vService geneli; vService'teki bütün Blocking mode host grupları
- Dikkat Açıkken taramayı bilerek uzatan bir istek WAF'ı atlatabilir. Yalnızca bu engeller hizmeti etkiliyorsa ve Yöntem 1 uygulanamıyorsa açılır
- WEB-CLI
waf options update poolId <vService> --failOpen true(Gövde işleme); birden çok vService'ewaf options update-manyile yazılır
Adım adım yapılandırma
Left Monitor Panel → WAF-Protected vServices → vService → WAF Management açılır.
Inspection & Blocking bölümündeki Request Body Limits kartının kalem ikonu tıklanır; Request Body Limits penceresi açılır.
Max. Body Size to Process(kB), Max. Body Size to Log(kB), Wait for body for a time ve Time to Wait Body alanlarının altındaki Fail-open anahtarı açılır. Alana tıklanınca arayüz, seçeneğin güvenlik etkisini anlatan uyarıyı gösterir.
Edit tıklanır; ayar ayrı bir dağıtım adımı olmadan uygulanır. Cluster kurulumunda değişiklik varsayılan auto-sync ile eş cihaza da gönderilir; Manual Sync Mode açıksa Synchronize ile gönderilir.
Doğrulama
Request Body Limits kartının kalem ikonuyla pencere yeniden açılır.
Fail-open açıkvService Debug mode'dayken kullanıcı isteği tekrarlar; satır açılır.
Yanıt Kurum Servisinden gelir; WAF · Attack blocked — scan timed out satırı yokYöntem 3: WAF Log Suppression Condition'ı Daraltmak
- Nasıl çalışır Bastırma koşulu yalnızca listelemeyi etkiler; koşuldan çıkarılan isteklerin bundan sonraki kayıtları Event Logs'ta görünür. Bastırma kaydın yazıldığı anda işaretlendiği için koşul değişmeden önce yazılmış kayıtlar listede görünmeye başlamaz.
- Nerede açılır Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Learning & Reporting → Log Settings kartı
- Gereksinim WAF alanında değiştirme yetkisi
- Kapsam vService geneli; bütün host grupları
Adım adım yapılandırma
Left Monitor Panel → WAF-Protected vServices → vService → WAF Management açılır.
Learning & Reporting bölümündeki Log Settings kartının kalem ikonu tıklanır; Log Settings penceresi açılır (Log Settings Edit ekranı).
WAF Log Suppression Condition alanında incelenmek istenen istekleri kapsayan koşul kaldırılır ya da yalnızca bastırılması gereken trafiği (ör. health check yolu) seçecek biçimde daraltılır. Alan yalnızca istek tarafına ait HTTP koşullarını kabul eder (Health Check veya probe trafiğinin WAF loglarını nasıl durdururum (WAF Log Suppression Condition)?).
Edit tıklanır; ayar ayrı bir dağıtım adımı olmadan uygulanır. Cluster kurulumunda değişiklik varsayılan auto-sync ile eş cihaza da gönderilir; Manual Sync Mode açıksa Synchronize ile gönderilir.
Doğrulama
Kullanıcı isteği tekrarlar; Event Logs'ta yeni Request ID ile arama yapılır (Save & get logs).
Yeni istek listelenirSık Yapılan Hatalar
- Zaman aşımı engelini kaldırmak için host grubunu Monitor ya da Learning mode'a almak. Bu modlarda zaman aşımı engeli oluşmaz, ancak WAF'ın bütün engellemesi de durur. Önce taranan gövde küçültülür; gerekirse yalnızca bu engelleri kaldıran Fail-open açılır.
- Fail-open'ı ilk çözüm olarak açmak. Fail-open açıkken bu istekler taranmadan geçer ve zaman aşımları hiçbir ekranda görünmez; taraması uzun süren istek bulunup küçültülmeden açılmaz.
- Süre sınırını artıracak bir ayar aramak. 2 saniyelik süre bir ayar değildir; ağır meşru istekler için ayar Max. Body Size to Process(kB)'dır.
- Debug mode'u olaydan sonra açıp eski isteği aramak. Debug mode yalnızca açıldıktan sonra gelen istekleri kaydeder; istek tekrarlatılır.
- 369999'u Signature & Rule Library'de aramak. Bu kimlik bir imza değildir; taramanın süre sınırı içinde tamamlanamadığını gösteren işarettir.
- Dashboard'da zaman aşımı sayısı aramak. Zaman aşımına uğrayan istekler WAF panellerinin hiçbir serisinde sayılmaz; tek ekran içi iz Debug Mode Logs'tur.
- Bastırma koşulunun isteği engellemeden çıkardığını sanmak. Koşul yalnızca listelemeyi etkiler; istek yine denetlenir ve gerekiyorsa engellenir.
- Debug mode'u açık unutmak. Debug mode her isteği ayrıntılı kaydeder; inceleme bitince Status yeniden Enabled yapılır (Debug Mode ne kaydeder; ne kadar süre açık tutmalıyım?).
Dokümantasyonda nasıl yapılır
