Kullanıcılarım "418" hatası alıyor; ne oluyor?

Kısa cevap

418, WAF'ın engelleme yanıtında varsayılan olarak kullandığı Blocking Status Code değeridir; bu yanıtı alan istek Kurum Servisine gönderilmemiştir. WAF kaynaklı 418 iki yoldan oluşur: host grubu Blocking Mode'dayken isteğin saldırı puanı engelleme eşiğine ulaşır (kaynak IP'nin kara listede olması da puana eklenir) ya da Blocking mode'da WAF taraması 2 saniyelik süre sınırı içinde tamamlanamaz (Request Body Limits penceresindeki Fail-open kapalıyken, varsayılan). Teşhis için kullanıcının gördüğü engelleme sayfasındaki Request ID değeri vService'in Event Logs ekranında Request Unique ID alanına yazılır: kayıt varsa Attacks sekmesi tetiklenen kuralı gösterir ve false positive Allow / Teach ile öğretilir; kayıt yoksa istek ya tarama zaman aşımıyla engellenmiştir ya da kaydı WAF Log Suppression Condition ile listeden gizlenmiştir; ikisi Debug Mode Logs kaydında ayırt edilir (zaman aşımında "Attack blocked — scan timed out"). 418, durum kodu olarak seçildiği bir Load Balancer Block aksiyonundan ya da Kurum Servisinin kendisinden de gelebilir. İnceleme sürerken trafiği açmak için host grubu Monitor Mode'a alınır; bu, o gruptaki kural, kara liste ve tarama zaman aşımı kaynaklı bütün WAF engellerini durdurur.

Sorun: Kullanıcılar 418 Yanıtı Alıyor

Kullanıcılar tarayıcıda "Your Access To This Page Has Been Blocked!" başlıklı sayfayı, API istemcileri ise HTTP 418 yanıtını görüyor. Yerleşik engelleme sayfası isteğin zamanını, Request ID değerini ve istemcinin IP Address bilgisini gösterir (Engelleme sayfasında hangi Smart Variable'ları kullanabilirim (%UID, %SRCIP, %WAFSCORE, %WAFINFO …); saldırı detayını göstermek güvenli mi?). Engelin hangi katmandan geldiği ve hangi kuralın tetiklendiği bulunmadan doğru düzeltme seçilemez.

Olası Nedenler

Neden	Hangi modda engeller	Event Logs'ta	Debug Mode Logs kaydının WAF kutusunda
Saldırı puanı engelleme eşiğine ulaştı (imza ya da yapısal kural)	Yalnızca Blocking Mode	Kayıt var; karar Attack blocked, Attacks sekmesinde imza ya da kural adı	Verdict = Attack blocked
Kaynak IP kara listede	Yalnızca Blocking mode	Kayıt var; Attack Name = Blacklisted IP, Severity = Blacklist	Verdict = Attack blocked
Puan ya da kara liste engeli var, ancak istek WAF Log Suppression Condition'a uyuyor	Yalnızca Blocking mode	Kayıt yazılır ama listelenmez	Verdict = Attack blocked
WAF taraması 2 saniyelik süre sınırı içinde tamamlanamadı	Yalnızca Blocking mode (kurallar yüklenirken oluşabilen bir istisna dışında; Fail-open kapalıyken, varsayılan)	Kayıt yok	Verdict = Attack blocked — scan timed out, Triggered Rules = 369999
Load Balancer Block aksiyonunda durum kodu 418 seçilmiş	-	Kayıt yok	WAF kutusu yok
Kurum Servisinin kendisi 418 döndürüyor	-	Kayıt yok	WAF kutusu yok

Kesin kurallar:

• WAF engellemesinin durum kodu Blocking Status Code alanından gelir (varsayılan 418). Conditional Blocking Pages satırına özel durum kodu seçilmişse koşula uyan isteklerde o kod döner; bu yüzden WAF engeli 418 dışında bir kodla da gelebilir.
• Learning Mode'daki host grubunda, Conditional Learning kimliğiyle gelen istekte ve Teacher tarafından tanınan istekte saldırı puanı engellemez; taraması süre sınırı içinde tamamlanamayan istek de, kurallar yüklenirken oluşabilen bir istisna dışında, geçirilir. Bu isteklerde WAF 418 döndürmez; görülen 418 WAF dışındaki bir katmandan gelir.
• Monitor Mode'da eşiği aşan istek ve kara listedeki kaynak engellenmez, yalnızca Event Logs kaydı yazılır (karar Not blocked — Monitor mode).
• Whitelist Condition'a uyan, statik içerik sayılan ve AGS Root Path ile başlayan istekler WAF'a hiç girmez; bu isteklere WAF kaynaklı 418 dönmez.

Nereden İzlenir?

Ekran	Yol	Ne gösterir
Event Logs	Left Monitor Panel → WAF-Protected vServices → vService → Event Logs	Puan ve kara liste kaynaklı engeller; tetiklenen imzalar, eşleşen kural, öğretme önerisi
Global WAF Event Log	Configuration Menu → WAF → Global WAF Event Log	Bütün WAF korumalı vService'lerin kayıtları; vService bilinmiyorsa Request Unique ID araması burada yapılır
Debug Mode Logs	Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → Debug Mode Logs	Her isteğin Security action değeri ve WAF kutusu (Verdict, Attacks, Triggered rules); zaman aşımı yalnızca burada görünür
HTTP Logs	Aynı sekmede HTTP logs kaynağı	Yanıt durum kodu (418) ve yanıtı üreten taraf (Backend service: TR7 ya da sunucunun adı)

Nasıl Teşhis Edilir?

1. Kullanıcıdan engelleme sayfasındaki Request ID değeri ve olayın saati alınır. API istemcisi sayfa gövdesini göstermiyorsa yanıt gövdesi kaydedilir ya da saat ve istemci IP'si not edilir.
2. Left Monitor Panel → WAF-Protected vServices → vService → Event Logs açılır; sunucu filtresinde Request Unique ID alanına değer yazılır, Date Range (varsayılan Last 7 day(s)) olay saatini kapsayacak şekilde seçilir ve Save & Get Logs tıklanır (Belirli bir isteği Request Unique ID ile nasıl bulurum?). vService bilinmiyorsa aynı arama Global WAF Event Log ekranında yapılır.
3. Kayıt geldiyse satıra tıklanır; önizlemenin Attacks sekmesinde Corresponding Rule, Attack Name, Attack Area, Description (eşleşen bölüm vurgulu) ve Learning Suggestion okunur. Attack Name = Blacklisted IP ise engel kara listedendir. Kayıt gerçek bir saldırıysa bir şey değiştirilmez.
4. Kayıt gelmediyse Load Balancer → Load Balancer vService List ekranında vService'in düzenleme formu açılır, Status alanında Debug mode seçilip Save tıklanır ve istek kullanıcıdan tekrarlatılır; Debug mode yalnızca açıldıktan sonra gelen istekleri kaydeder (Debug Mode ne kaydeder; ne kadar süre açık tutmalıyım?). 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).
5. Left Monitor Panel → Load Balancer vServices → vService → Logs & Tracking → Debug Mode Logs açılır; varsayılan olarak gizli Security Action kolonu Columns menüsünden eklenir. Değer WAF · Attack blocked — scan timed out · 1 attacks ise ve satırın Summary sekmesindeki WAF kutusunda Triggered rules = 369999 yazıyorsa istek tarama zaman aşımıyla engellenmiştir: 418 alan bir istek Event Logs'ta neden görünmüyor?. Değer WAF · Attack blocked · … ise engel puandan ya da kara listedendir ve kayıt WAF Log Suppression Condition ile listeden gizlenmiştir; koşul WAF Management'taki Log Settings kartında görülür.
6. Satırda WAF kutusu yoksa ve Security action - ise engel WAF'tan gelmemiştir; HTTP logs'ta Backend Service sunucunun adıysa 418'i Kurum Servisi üretmiştir, TR7 ise Load Balancer aksiyonları incelenir (Meşru kullanıcılar engelleniyor; hangi kuralın engellediğini nasıl bulurum?).
7. İnceleme bitince Status yeniden Enabled yapılıp kaydedilir.

Çözüm: Dört Yöntem

Yöntemler birbirinin alternatifidir. Kalıcı düzeltme Yöntem 1'dir; Yöntem 2 inceleme sürerken trafiği açar, Yöntem 3 yalnızca istemciye dönen kodu değiştirir.

Durumunuz	Uygun yöntem
Event Logs'ta kayıt var ve engel false positive (kara liste isabeti dahil)	Yöntem 1: Event Logs'tan Allow / Teach
Engel incelenirken trafiğin hemen açılması gerekiyor	Yöntem 2: Host grubunu Monitor mode'a almak
API istemcileri 418'i işleyemiyor; başka bir kod isteniyor	Yöntem 3: Blocking Status Code
Mod ya da durum kodu komut satırından değiştirilecek	Yöntem 4: WEB-CLI
Aynı imza bu vService'in her yerinde false positive üretiyor	Bir imzayı tüm cihazda değil yalnızca tek bir vService'te kapatabilir miyim?
Event Logs'ta kayıt yok; Debug Mode Logs zaman aşımı gösteriyor	418 alan bir istek Event Logs'ta neden görünmüyor?
Engel WAF'tan gelmiyor	Meşru kullanıcılar engelleniyor; hangi kuralın engellediğini nasıl bulurum?

Yöntem 1: Event Logs'tan Allow / Teach Önerilen

• Nasıl çalışır Kayıttaki saldırı false positive olarak öğretilir: imza o alan için OWASP istisnasına alınır, yapısal sınır genişletilir ya da kara liste isabetinde adres Frontend Blacklist Exclusions listesine eklenir. Yapılacak değişiklik Learning Suggestion satırında önceden yazar.
• Nerede açılır Left Monitor Panel → WAF-Protected vServices → vService → Event Logs → kayıt → Attacks
• Gereksinim WAF değiştirme yetkisi; kaydın Event Logs'ta bulunması (host grubu Monitor ya da Blocking mode'da)
• vService tipi HTTP

Adım adım yapılandırma

1

Adım 1 Event Logs ekranını aç

Left Monitor Panel'de WAF-Protected vServices kategorisi seçilir, vService'e tıklanır ve Event Logs sekmesi açılır.

2

Adım 2 Kaydın kapsamını gir

Filtre şeridinin başındaki sunucu filtresi sekmesinde Request Unique ID alanına kullanıcının verdiği Request ID yazılır; Date Range olay saatini kapsayacak şekilde seçilir (sunucu filtresi).

3

Adım 3 Kaydı getir

Save & Get Logs tıklanır; yalnızca bu isteğin kaydı listelenir.

4

Adım 4 Kaydı aç

Satıra tıklanır ve sağda açılan önizlemede Attacks sekmesi seçilir. Sekme ilk saldırıyı seçili açar; Corresponding Rule, Attack Name, Description ve Learning Suggestion okunur.

5

Adım 5 False positive saldırıyı seç

Saldırı tablosunda yalnızca false positive olan saldırının satır başındaki kutusu işaretlenir. Gerçek bir saldırı da işaretlenirse o da öğretilir.

6

Adım 6 Allow / Teach'e tıkla

Tablonun üstündeki buton tıklanır. Buton engellenmiş bir kayıtta Allow, izlenen ya da Teacher tarafından geçirilmiş bir kayıtta Teach adını taşır (Allow / Teach).

7

Adım 7 Onayla

Are you sure? sorusunda Yes tıklanır. Değişiklik ayrı bir kaydetme ya da dağıtım adımı olmadan uygulanır; kayıttaki Attacks kolonunun ilk sayısı düşer, bütün saldırılar öğretildiyse satır yeşile döner. Cluster kurulumunda değişiklik varsayılan auto-sync ile eş cihaza da gönderilir; Manual Sync Mode açıksa Synchronize ile gönderilir. Ayrıntı: Yanlışlıkla engellenen bir isteğe nasıl izin veririm?

Kara liste isabeti

Attack Name = Blacklisted IP olan bir saldırıda öğretme, adresi vService'in Frontend Blacklist Exclusions listesine ekler; aynı işlem önizlemedeki Attacker IP satırının menüsündeki Add to Whitelist seçeneğiyle (seçeneğin yanında vService'in adı yazar) de yapılır. İki yol da adresi yalnızca kara listeden çıkarır; WAF denetimi sürer (Event Logs'taki "Add to Whitelist (vService)" bir IP'yi WAF incelemesinden muaf tutar mı, yoksa yalnızca kara liste istisnası mı ekler?).

Doğrulama

1Attacks kolonuTR7 tarafı

Event Logs'ta öğretilen kaydın Attacks kolonuna bakılır.

Beklenenİlk sayı 0; satır yeşil

Kolonun ilk sayısı aynı isteğin bugünkü kural setiyle kaç saldırı tetikleyeceğini gösterir (Attacks kolonu).

2Tekrar istekİstemci tarafı

Kullanıcı aynı işlemi tekrarlar.

BeklenenUygulamanın normal yanıtı; Event Logs'ta yeni kayıt yok

Yöntem 2: Host Grubunu Monitor Mode'a Almak

• Nasıl çalışır Monitor mode'da denetim ve puanlama sürer, eşiği aşan istekler engellenmez, yalnızca Event Logs'a yazılır; kara listedeki kaynak da engellenmez. Taraması süre sınırı içinde tamamlanamayan istek de bu modda geçirilir (tek istisna, taramanın WAF kuralları yüklenirken ve host grubu belirlenmeden kesilmesidir: vService'te Blocking mode'da bir grup varsa bu istek engellenir (WAF Mode · Blocking Mode)).
• Nerede açılır Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → mod kartı → Edit
• Gereksinim WAF alanında değiştirme yetkisi
• vService tipi HTTP

Adım adım yapılandırma

1

Adım 1 WAF Management sekmesini aç

Left Monitor Panel → WAF-Protected vServices → vService → WAF Management açılır. En üstte her host grubu için bir mod kartı bulunur; birden çok grup varsa engellenen isteğin düştüğü grup Event Logs önizlemesindeki Request & Location sekmesinin Host Group satırında görülür.

2

Adım 2 Host grubu penceresini aç

İlgili mod kartındaki Edit tıklanır; host grubu penceresi açılır (WAF Mode Edit ekranı).

3

Adım 3 Monitor mode'u seç

WAF Mode alanında Monitor mode seçilir.

4

Adım 4 Kaydet

Penceredeki Edit tıklanır; mod 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. False positive giderildikten sonra aynı adımlarla Blocking Mode'a dönülür.

Doğrulama

1Event Logs kararıTR7 tarafı

Aynı istek tekrarlanır ve Event Logs'ta yeni kaydın Action ikonunun üzerine gelinir.

BeklenenNot blocked — Monitor mode

İstek hâlâ 418 alıyorsa engel bu host grubundan gelmiyordur: istek Blocking mode'daki başka bir host grubuna düşüyor ya da 418 WAF dışındaki bir katmandan geliyordur; Debug Mode Logs kaydındaki WAF kutusuyla ayırt edilir.

Yöntem 3: Blocking Status Code

• Nasıl çalışır WAF'ın engelleme yanıtındaki durum kodu değiştirilir (ör. 403). Engelleme kararı değişmez; yalnızca istemciye dönen kod değişir.
• Nerede açılır Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Inspection & Blocking → Blocking Page kartı
• Gereksinim WAF alanında değiştirme yetkisi
• vService tipi HTTP (ayar vService'in bütün host gruplarında ortaktır)

Adım adım yapılandırma

1

Adım 1 WAF Management sekmesini aç

Left Monitor Panel → WAF-Protected vServices → vService → WAF Management açılır.

2

Adım 2 Blocking page penceresini aç

Inspection & Blocking bölümündeki Blocking Page kartının kalem ikonu tıklanır; Blocking Page penceresi açılır (Blocking Page Edit ekranı).

3

Adım 3 Durum kodunu seç

Blocking Status Code listesinden yeni kod seçilir (varsayılan 418; liste gövde taşıyabilen kodları içerir, serbest sayı girilmez). Conditional Blocking Pages satırlarında Use Default Status Code seçili olanlar da bu kodu kullanır.

4

Adım 4 Kaydet

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. Ayrıntı: Engellemede neden varsayılan olarak 418 durum kodu dönüyor; bunu değiştirebilir miyim?

Doğrulama

1Engellenen istekİstemci tarafı

Engellendiği bilinen bir istek tekrarlanır.

Komut: curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/

BeklenenSeçilen kod (ör. 403)

Blocking page kartındaki cümle de yeni kodu gösterir (with status 403).

Yöntem 4: WEB-CLI

• Nasıl çalışır Yöntem 2 ve Yöntem 3'teki ayarlar WEB-CLI komutlarıyla değiştirilir.
• Nerede açılır WEB-CLI → waf host-groups · waf options
• Gereksinim WEB-CLI erişimi ve WAF değiştirme yetkisi
• vService tipi HTTP

Adım adım yapılandırma

1

Adım 1 Host grubunun kimliğini al

id alanı host grubunun adını değil kimliğini alır; kimlik listeden okunur (waf host-groups):

waf host-groups list poolId <vService>

2

Adım 2 Host grubunu Monitor mode'a al

<grup-kimliği> yerine 1. adımdaki kimlik yazılır:

waf host-groups update poolId <vService> id <grup-kimliği> --mode monitor

Engelleme modu --mode blocking ile geri alınır.

3

Adım 3 Durum kodunu değiştir (gerekiyorsa)

waf options update poolId <vService> --blockingStatusCode 403 --syncWithDefaultFwRules false

--syncWithDefaultFwRules saklanan bir ayar değil, bir yazma tetiğidir: yalnız true yazıldığında Any paths kuralı varsayılan tanımıyla yeniden kurulur; komutta yazılmazsa kural setine dokunulmaz. Komuttaki false bunu açıkça belirtir (Sync with Default WAF Rules; temel denetimler).

Doğrulama

1KayıtTR7 tarafı

Host grubu kaydı yeniden görüntülenir.

Komut: waf host-groups show poolId <vService> <grup-kimliği>

Beklenenmode monitor

Sık Yapılan Hatalar

• Event Logs'ta kayıt yoksa engeli WAF dışında aramak. Tarama zaman aşımıyla engellenen istekler Event Logs'a yazılmaz; Debug Mode Logs'taki WAF kutusuna bakılır (418 alan bir istek Event Logs'ta neden görünmüyor?).
• Her 418'i WAF'a bağlamak. Load Balancer Block aksiyonunda da durum kodu olarak 418 seçilebilir ve Kurum Servisi kendisi 418 dönebilir; Debug Mode Logs'ta WAF kutusu yoksa engel başka bir katmandandır.
• Monitor mode'a almanın WAF dışındaki 418'leri de durduracağını varsaymak. Monitor mode yalnızca o host grubundaki WAF engellerini (tarama zaman aşımı dahil) durdurur; Load Balancer Block aksiyonundan ya da Kurum Servisinden gelen 418 sürer (Learning veya Monitor modundayken de bir istek 418 ile engellenebilir mi?).
• Kaydın bütün saldırılarını öğretmek. Aynı istekte gerçek bir saldırı da varsa o da öğretilir; yalnızca false positive saldırı işaretlenir.
• Monitor mode'u açık unutmak. False positive giderildikten sonra host grubu yeniden Blocking Mode'a alınmazsa saldırılar engellenmez.
• Durum kodunu 200 gibi bir başarı koduna çevirmek. Engellenen istek istemciye başarılı görünür ve test araçları engeli fark etmez.

Dokümantasyonda nasıl yapılır

• Event Logs · Request Unique ID
• Event Logs · Attacks sekmesi
• Blocking Page · Blocking Status Code
• WAF Mode · Blocking Mode
• Debug Logs · Summary sekmesi

İlgili sorular

• Engellenen kullanıcı ne görür?
• Meşru bir isteğin WAF tarafından engellendiğini nasıl anlarım?
• 418 alan bir istek Event Logs'ta neden görünmüyor?
• WAF bir istek için hangi kararları verir; Event Logs'taki Action ve Debug Mode Logs'taki Verdict ne anlama gelir?