Microsoft, 29 Ekim 2026’da Azure Front Door Premium WAF üzerindeki iki HTTP DDoS kuralını genel kullanıma açtı. Policy’nize ruleset’i eklediğinizde kuralların varsayılan eylemi Log. 500100 bu ayarda eşleşen istekleri kaydediyor, engellemiyor; 500110 ise profil genelindeki eşik aşılınca yüksek riskli botları Log ayarında bile hemen engelliyor. Log ayarını bütün trafiği koruyan bir yaptırım sanıp uygulama yavaşladığında kayıtlara bakmak, farkı öğrenmek için geç bir zaman.
Benim kritik web uygulamaları için Azure servisleri yazımda anlattığım iki bölgeli App Service düzeninde Front Door hem yönlendirme hem WAF katmanında duruyor. O mimaride veritabanının tek bölgede kalması nasıl erişilebilirlik açığı bırakıyorsa, WAF policy’de görünen bir kuralın yaptırım uygulamaması da güvenlik planında boşluk bırakır. Burada ürünün belgelenmiş davranışından yola çıkıp öğrenmenin bittiğini nasıl anlayacağınızı ve kural eylemini değiştirmeden önce neye bakacağınızı anlatacağım.
GA geldi, kurallar tam olarak ne yapıyor?
Microsoft’un 29 Ekim duyurusunda per-IP 500100 ve 500110 kuralları GA olarak geçiyor. Aynı ruleset içindeki coğrafi 500310 ve 500320 kuralları ise hala preview. Policy’ye ekleyeceğiniz ad Microsoft_HTTPDDoSRuleSet_1.0, kullanabileceğiniz profil türü Azure Front Door Premium. Listedeki dört kuralın yayın durumu aynı değil.
Resmi HTTP DDoS ruleset belgesi başlangıçta her kuralın medium sensitivity ve Log action ile açık olduğunu söylüyor. Daha yüksek sensitivity daha düşük eşik demek. Ayarı gelişigüzel yükseltirseniz yoğun ama meşru trafiğe daha çabuk takılırsınız. 500100 seçili eylemi uygular; 500110 ise profil genelindeki eşik aşılınca Microsoft Threat Intelligence’ın yüksek riskli bot saydığı IP’leri Log ayarında bile hemen engeller.
Öğrenme bitmeden müdahale beklemeyin
Ruleset, isteklere bakıp profilin normal trafik seviyesini hareketli bir pencereyle hesaplıyor. Son yedi günün en az yarısında trafik alan bir profilde ilk baseline ve ani artış tespiti 24 ila 36 saat içinde başlayabiliyor. Yeterli trafik yoksa güvenilir seviye oluşana kadar algılama ve azaltma da yok. Trafiği hafta içi ile hafta sonu arasında belirgin değişen bir profilde 36 saati kesin bir son tarih sanmayın.
İki aşamalı eşik var. Önce profil genelindeki istek eşiği aşılacak, ardından IP başına dar eşik devreye girecek. Birkaç istemcinin tek başına artışı profil eşiğini geçmiyorsa per-IP yaptırımı başlamaz. Aynı WAF policy birden çok Front Door profiline bağlı olsa bile eşikler profil başına ayrı öğreniliyor. Policy’ye bakıp bütün profillerde tek bir trafik eşiği çalıştığını varsaymayın.
Benim Azure Site to Site VPN kurulumunda Connected durumunu görmem yetmemişti, uçtan uca bağlantıyı ayrıca test etmiştim. Burada da aynı kontrol alışkanlığını öneriyorum. Managed rules listesinde satırı gördükten sonra Azure Monitor’da Web Application Firewall HTTPDDoSRuleset Is Active metriğinin 1 olmasını kontrol edin. Bunu ilgili profil için yapın, çünkü eşikler her profilde ayrı öğreniliyor.
Log kaydı size ne söylüyor?
Active değerini gördükten sonra WAF loglarını ve rule name ile filtrelenmiş Web Application Firewall Request count metriğini birlikte açın. Hangi URI’larda, hangi IP’lerde, hangi zaman dilimlerinde eşleşme var? Bu soruların yanıtı iş yüküne bağlı. Bir alışveriş sitesinin kampanya trafiğiyle gece çalışan API istemcisinin ritmi aynı olmayacak. Log eylemi bu aşamada yalnızca kayıt üretir; 500100 ile eşleşen istek origin’e gitmeye devam eder.
İlk eşik ihlaline ait IP kaydını veya Match metriğini engellenmiş bütün isteklerin birebir dökümü sanmayın. Kuralın penalty box davranışında eşiği aşan IP’ye sonraki isteklerde seçili eylem uygulanır. Toplam etkiyi anlamak için istek sayacını WAF kayıtlarıyla karşılaştırın, uygulama yanıtlarına da bakın. Eşik değişikliğinin sağlık kontrolünü ya da düzenli bir partner çağrısını vurup vurmadığını böyle görürsünüz.
Sahada mimari çizerken sık döndüğüm soru uygulamanın hangi katmanda gerçekten ayakta kaldığı. Front Door trafiği başka bölgeye yönlendirebilir ama veritabanı tek bölgede duruyorsa yolun sonu yine kapalıdır. HTTP katmanındaki bu korumayı ağ katmanı DDoS önlemiyle veya her saldırıda sıfır kesinti vaadiyle karıştırmayın.
Sağlık kontrolünü nasıl ayıracaksınız?
Kuralları yaptırıma almadan önce güvenilir sağlık yoklamalarını ve synthetic monitoring isteklerini ayıklayın. Front Door exceptions belgesi HTTP DDoS için kural düzeyinde dar exceptions tarif ediyor. Custom Allow kuralı bu ruleset’i atlamıyor, üstelik diğer WAF incelemelerini atlayabiliyor. Yoklama sorununu çözmezsiniz, korumanın geri kalanında delik açmış olursunuz.
Exception match alanlarında remote IP, request URI ve request header var. Yalnızca gereken kurala exception tanımlayıp güvenilir kaynağa göre eşleştirin. Herkesin çağırabildiği bir URI’yi genişçe muaf tutmak, saldırgana da aynı yolu açar. Header kolay taklit edilebiliyorsa onu kimlik kanıtı gibi görmeyin. Mekanizma belgede preview statüsünde. Yeni nesil WAF engine ile DRS 2.1 veya sonrası koşulunu da portalda doğrulayın.
Log’dan sonra hangi düğmeye basılır?
İlk adım Premium profile bağlı policy’ye ruleset’i ekleyip 500100 ve 500110’u medium sensitivity ve Log eylemiyle izlemek. Öğrenmenin bittiğini metrikten görün, loglarda yanlış eşleşme ihtimalini inceleyin, gerekiyorsa dar exceptions ekleyin. Sonra GA kurallarının action ayarını uygulamanın trafik toleransına göre seçin ve yanıt sürelerini izleyin. Her iş yüküne körlemesine Block yazmayın.
Bir de WAF policy mode ayarı var. Detection modunda policy yalnızca kaydeder, Prevention modunda eşleşen kural için seçtiğiniz eylemi uygular. Kural action’ını değiştirmiş olmak tek başına yaptırım kanıtı sayılmaz. Kural Block olsa da policy Detection modundaysa istek origin’e ulaşır. İki ayarı da kontrol edin.
Coğrafi 500310 ve 500320 kurallarına aynı reçeteyi otomatik uygulamayın. Preview durumundalar. Ülke veya bölge eşiği aşıldığında o bölgedeki meşru kullanıcıların da seçilen eylemden etkilenmesi mümkün. Ben önce GA per-IP kurallarını kendi trafik kayıtlarınızla doğrulamanızı, erişilebilirlik sinyallerini ölçüp ardından coğrafi kapsamı ayrıca değerlendirmenizi daha makul buluyorum.
Policy’yi kapatmadan önce
- Active metriği ilgili profilde 1 mi, Log eşleşmeleri meşru trafikle karşılaştırıldı mı?
- Güvenilir yoklamalar için exception gerçekten dar mı, policy Prevention modunda mı?
- Seçilen action sonrası uygulamanın yanıtları ve WAF sayaçları birlikte izlendi mi?
İlk üretim değişikliğinden sonra Active metriği 1 kalsa bile uygulamanın yanıt sürelerine yeniden bakın; korumayı asıl o günkü trafik sınayacak. Kendi profilinizde öğrenme süresi veya yanlış eşleşme konusunda gördüklerinizi yorumlara yazın, birlikte bakalım.
