Belirli IP'leri veya istekleri WAF incelemesinden tamamen muaf tutabilir miyim (Whitelist Condition)?
Kısa cevap
Evet. Whitelist & Blacklist penceresindeki Whitelist Condition açılıp bir koşul seçildiğinde, koşula uyan istekler WAF'a hiç girmez: imza taraması, yapısal denetimler, kara liste denetimi ve öğrenme yapılmaz, Event Logs'a kayıt yazılmaz; istek Dashboard'da Whitelisted kategorisinde sayılır. Belirli IP'ler için önce Conditions ekranında (Load Balancer → Conditions) Source IP koşulu oluşturulur; Path, Host ya da HTTP Header koşullarıyla istek bazlı muafiyet de yapılabilir. Yalnızca istek tarafındaki HTTP koşulları seçilebilir ve koşul alanı boş bırakılarak kaydedilemez. Muaf trafik WAF kaydı bırakmadığı için koşul dar tutulur; denetlenip engellenmemesi istenen kaynaklar için Teacher kullanılır.
Sorun: Güvenilen Kaynak WAF Tarafından Denetleniyor
İç ağdaki bir tarama aracı, güvenilir bir entegrasyon ya da belirli bir path, WAF denetimine girmeden geçmeli. Muafiyetin yalnızca hedeflenen trafiği kapsaması ve muaf isteklerin WAF kaydı bırakmayacağının bilinmesi gerekir.
Çözüm: İki Yöntem
İki yöntem aynı ayarı yazar; biri seçilir.
| Durumunuz | Uygun yöntem |
|---|---|
| Muafiyeti arayüzden tanımlayacağım | Yöntem 1: Whitelist condition |
| Betik ya da komut satırıyla tanımlayacağım | Yöntem 2: WEB-CLI |
| Kaynak denetlensin ama engellenmesin | Teacher: Belirli bir kullanıcı grubunun (ör. iç ağ, test ekibi) hiç engellenmemesini nasıl sağlarım? |
Yöntem 1: Whitelist Condition Önerilen
- Nasıl çalışır Koşula uyan istek için WAF hiç çalışmaz; istek doğrudan Kurum Servisine iletilir.
- Nerede açılır Left Monitor Panel → WAF-Protected vServices → vService → WAF Management → Whitelist & Blacklist kartı → kalem ikonu
- Gereksinim İstek tarafında değerlendirilen bir HTTP koşulu (yoksa önce oluşturulur; koşul oluşturmak Load Balancer alanında değiştirme yetkisi ister) · WAF alanında değiştirme yetkisi
- Kapsam vService geneli; bütün host gruplarında ortak. Kara liste denetiminden önce uygulanır
Adım adım yapılandırma
Kullanılacak koşul yoksa Load Balancer → Conditions ekranında Add tıklanır (nasıl eklenir).
IP muafiyeti için Criteria = Source IP, Source IP Type = Manual seçilir ve IP ya da CIDR yazılır (ör. 203.0.113.0/24). İstek bazlı muafiyet için Path ya da HTTP Header koşulu kullanılır. TR7'nin önünde proxy varsa ve vService'te Trusted Proxy tanımlıysa koşul çözülen istemci IP'sini görür (Trusted Proxy ile çözülen IP hangi bileşenlerde kullanılır (log, condition, WAF, Bot & DDoS Protection)?).
Add tıklanır; koşul listeye eklenir.
Left Monitor Panel → WAF-Protected vServices → vService → WAF Management sekmesinde Inspection & Blocking bölümündeki Whitelist & blacklist kartının sağ üstündeki kalem ikonuna tıklanır.
Whitelist Condition anahtarı açılır; altında etiketsiz koşul alanı görünür (boşken Never yazar).
Koşul alanında 3. adımdaki koşul seçilir; birden fazla koşul and / or ile birleştirilebilir ve yerinden yeni koşul oluşturulabilir. Listede yalnızca istek tarafındaki HTTP koşulları bulunur. Alan boş bırakılırsa Empty condition hatası görünür ve kayıt yapılamaz.
Edit tıklanır; değişiklik ayrı bir dağıtım adımı olmadan uygulanır. Cluster kurulumunda varsayılan auto-sync ile eş cihaza da gönderilir; Manual Sync Mode açıksa eş cihaza elle gönderilir.
Doğrulama
WAF Management sekmesindeki Whitelist & blacklist kartına bakılır.
Requests matching this condition skips WAF inspection: + koşulMuaf kaynaktan istek gönderilir ve vService Dashboard'unda WAF Inspection Distribution paneline bakılır.
Whitelisted kategorisi artar; Event Logs'ta kayıt oluşmazYöntem 2: WEB-CLI
- Nasıl çalışır Anahtar ve koşul WEB-CLI ile yazılır; koşul kimliğiyle verilir.
- Nerede açılır WEB-CLI →
lb condition list·waf options update - Gereksinim WEB-CLI erişimi; tanımlı bir istek koşulu; koşul kimliğini
lb condition listile görmek için Load Balancer alanında görme yetkisi (yalnız WAF yetkisi olan hesap koşul tablosunu görmez) - Kapsam vService geneli
Adım adım yapılandırma
Koşul adıyla değil kimliğiyle verilir; kimlik listenin id sütunundadır (lbConditions- ile başlar):
lb condition list<koşul-kimliği> yerine 1. adımdaki kimlik yazılır; --wafCondition alanı yalnızca --wafConditionEnabled true ile birlikte kabul edilir:
waf options update poolId <vService> --syncWithDefaultFwRules false --wafConditionEnabled true --wafCondition <koşul-kimliği>Doğrulama
vService'in WAF ayarları görüntülenir.
Komut: waf options show poolId <vService>
wafConditionEnabled true ve wafCondition satırında koşulSık Yapılan Hatalar
- Geniş koşul yazmak. Koşula uyan trafik WAF denetiminin ve kaydının tümüyle dışında kalır; saldırı içerse de engellenmez ve Event Logs'ta görünmez. Koşul yalnızca gereken kaynak ya da path'i kapsar.
- Muafiyetin kaldırıldığını doğrulamamak. Muafiyet anahtar kapatılarak kaldırıldıktan sonra kartta Conditional whitelist is off satırı görülür ve koşula uyan isteklerin Dashboard'da Whitelisted kategorisinden çıktığı kontrol edilir.
- Frontend blacklist exclusions'ı whitelist sanmak. O liste yalnızca kara liste isabetini iptal eder; istek WAF denetiminden geçmeye devam eder (Event Logs'taki "Add to Whitelist (vService)" bir IP'yi WAF incelemesinden muaf tutar mı, yoksa yalnızca kara liste istisnası mı ekler?).
- False positive'i whitelist ile çözmek. Yanlışlıkla engellenen istek Event Logs'tan öğretilerek ilgili kurala yazılır; böylece denetim sürer (Yanlışlıkla engellenen bir isteğe nasıl izin veririm?).
- Proxy arkasında bağlantı IP'sine göre koşul yazmak. Trusted proxy tanımlı değilse bütün trafik proxy adresinden geliyor görünür ve koşul ya hiçbir isteğe ya da bütün isteklere uyar.
Dokümantasyonda nasıl yapılır
