Uygulama (katman 7) DDoS koruması

Geçerlidir: ✔️ Application Gateway V2 ✔️ Front Door Premium

Azure Web Uygulaması Güvenlik Duvarı (WAF), dağıtık hizmet reddi (DDoS) saldırılarını önlemeye yardımcı olan çeşitli savunma mekanizmalarını içerir. DDoS saldırıları hem ağ katmanını (L3/L4) hem de uygulama katmanını (L7) hedefleyebilir. Azure DDoS Koruması sizi büyük ağ katmanı hacimli saldırılara karşı korur. 7. katmanda çalışan Azure WAF, web uygulamalarını HTTP flood saldırıları gibi L7 DDoS saldırılarına karşı korur. Bu savunmalar birlikte, saldırganların uygulamanıza ulaşmasını ve kullanılabilirliğini ve performansını etkilemesini engeller.

Uygulama katmanı saldırıları başlatması ucuz ve meşru trafikten ayırt etmek zordur: her istek kendi başına geçerli görünür ve saldırıyı ortaya çıkaran sadece toplam oran, dağıtım ve istemci karışımıdır. Bu nedenle etkili L7 savunması tek bir kontrolden çok, saldırı başlamadan önce zaten var olan katmanlı bir konfigürasyona daha çok dayanır.

Savunma katmanlarınızı seçin

L7 DDoS koruması planlarken aşağıdaki modeli kullanın. Her katman, üstündeki katman yakalamadığı trafiği yakalar.

Katman Ne işe yarıyor? Nerede yapılandırılır?
Platform DDoS koruması Azure kenarında ve kaynak genel IP'lerinizde L3/L4 hacimsel saldırıları emer Azure Front Door'ta varsayılan olarak yerleşik olarak kullanılmıştır; Application Gateway genel IP'leri ve köken genel IP'leri için Azure DDoS Network Protection gerektirir
Otomatik L7 azaltma Normal trafiği öğrenir ve acil ayar olmadan rahatsız eden müşterileri hızlıca azaltır HTTP DDoS ruleset (preview) on Azure Front Door Premium and Application Gateway WAF v2
İstemci doğrulaması İnsanları ve meşru istemcileri otomatik saldırı trafiğinden önce engeller Bot Manager ruleset, JavaScript challenge, CAPTCHA
Hız sınırlaması Herhangi bir istemciden, coğrafyadan veya uç noktadan kaç talep gönderebileceğini sınırlar Ön Kapı ve Uygulama Geçidi için Ücret Sınırı Özel Kuralları
Hedefli özel kurallar Bir olay sırasında bilinen bir saldırı imzasını engeller Özel kuralları eşleştirin (geo, IP, ASN, istemci parmak izi, başlık, URI)
Köken koruması Saldırı trafiğinin hesaplamanıza ulaşmasını engeller Önbellekleme, köken kilitleme, otomatik ölçeklendirme

Temel yapılandırma kontrol listesi

Saldırıya uğramadan önce bu adımları tamamla. Başvuru gereksinimlerinize göre ayarlayın.

  1. L7 uygulama katmanı saldırılarına karşı koruma sağlamak için Azure WAF'ı Azure Front Door Premium veya Application Gateway WAF v2 ile deploy edin.
  2. WAF politikasını önleme moduna geçir. Tespit modundaki bir politika sadece trafiği kaydeder ve engellemez. Önce üretim trafiğine karşı politikayı doğrulamak ve ayarlamak için yanlış pozitifleri azaltın, sonra önlemeyi etkinleştirin.
  3. HTTP DDoS kural setini (hem Azure Front Door Premium hem de Application Gateway WAF v2'de mevcut) ata, böylece otomatik azaltma, trafik temelini ihtiyaç duymadan önce öğrenmek anlamına gelir.
  4. Bot Yöneticisi yönetilen kural setinin bilinen kötü botları tespit edip harekete geçmesini etkinleştirin.
  5. En az bir genel tarif sınırı kuralı yapılandırın ( bkz. Hız sınırı).
  6. Kaynak örnek sayınızı yeterince boş kapasite olacak şekilde büyütün ve Application Gateway'i düşük maksimum örnek sayısı zorunlu kılmadan otomatik ölçeklendirmeye ayarlayın.
  7. Azure Front Door'ta önbelleklemeyi etkinleştirin ki ani zirve trafik başlangıç noktanızda değil, kenarda emilsin.
  8. Platforma göre değişen L3/L4 poz alanınızı kapatın. Bkz. Platform DDoS koruması platforma göre farklılık gösterir. Origin bağlantınızı kilitleyin ki trafik sadece Azure Front Door veya Application Gateway'den kabul edilsin.
  9. Log Analytics'e tanı logunu açın ve bir olaydan önce Analyze WAF ile erişim loglarına sorgular oluşturun.

Platform DDoS koruması platforma göre farklılık gösterir

L7 savunmaları, yalnızca altta yatan halka açık IP adresleri hacimsel saldırıdan sağ çıkarsa ve iki Azure WAF platformu aynı yerden başlamazsa önemlidir.

Azure Front Door varsayılan olarak platform DDoS korumasına sahiptir. Azure Front Door, küresel olarak dağıtılmış bir kenar hizmetidir ve kenarı, Azure'ın altyapı DDoS koruması ile ekstra ücret olmadan ve yapılandırma olmadan korunmaktadır. Trafik, sahip olduğunuz IP adresi yerine Ön Kapı kenarında sona erer, bu yüzden saldırganın L3/L4'te hedef alabileceği bir açık IP'niz yoktur. Bu koruma platformun doğasında olduğu için, onu almak için hiçbir şey satın almıyorsunuz veya etkinleştirmiyorsunuz.

Application Gateway'in Azure DDoS Ağ Koruması gereksinimi vardır. Uygulama geçidi, kendi sanal ağınızda genel IP adresi olan bölgesel bir kaynaktır. Azure'ın varsayılan altyapı düzeyindeki koruması Azure platformunun kendisini korur, ancak o IP için kaynak başına ayarlanmış, telmetri veya saldırı raporu sunmaz. Geçidin genel IP'sini L3/L4 hacimsel saldırılara karşı korumak için, onu barındıran sanal ağda Azure DDoS Ağ Koruma'yı etkinleştirin. Bu, ücretli, ayrı satın alınan bir hizmettir.

Bir dağıtım seçerken veya tasarladığınızda pratik sonuçlar:

  • Azure Front Door'ın arkasındaysanız, L7 kontrolleri için bütçe ayırın; L3/L4 kenar koruması zaten var.
  • Eğer Application Gateway kullanıyorsanız ve DDoS Ağ Koruması'nı etkinleştirmediyseniz, WAF kurallarınız mükemmel şekilde ayarlanabilir ve yine de gateway'in genel IP'sine yapılan hacimsel saldırı tarafından aşılabilir. Etkinleştir.
  • Her iki durumda da, açığa çıkardığınız Origin halka açık IP'ler yine de Azure DDoS Ağ Koruması ve sadece WAF servisinin erişebilmesi için kilitleme gerektirir. Korunan, halka açık bir kaynağın önünde korunan bir ön uç koruma değildir.

Daha fazla bilgi için Azure DDoS Protection overview ve Protect your application gateway with Azure DDoS Network Protection bölümlerine bakabilirsiniz.

HTTP DDoS kural seti ile otomatik koruma (önizleme)

IP filtreleri, coğrafi filtreler ve sabit hız sınırları gibi statik kontroller genellikle dağıtık botnetlerle aynı şekilde yetişemez: eşikler tahminlerdir, her zaman açıktır ve trafik kalıpları geliştikçe onları yeniden ayarlamanız gerekir. HTTP DDoS kural seti, Azure WAF'ın minimum kullanıcı yapılandırmasıyla öğrenen, tespit eden ve savunan ilk otomatik katman 7 koruma modelidir. Hem Azure Front Door Premium hem de Application Gateway WAF v2 için önizleme olarak mevcut. Atanan bir kez bu cihaz sürekli olarak normal trafiği temel oluşturur ve sırgalar saldırı işareti verdiğinde, acil durum ayarlaması gerekmeden sorunlu istemcileri seçici olarak engeller.

Tasarım, her iki platformda da en önemli şekilde aynı:

  • İki eşik birlikte değerlendirilir. Kural seti hem küresel eşik (Front Door profiline veya uygulama geçidi başlıcasına) hem de bireysel IP tabanlı eşikleri öğrenir. IP tabanlı eşikler, yalnızca küresel eşik aşıldıktan sonra uygulanır. Bu tasarım, kural setinin birkaç IP adresinden gelen spike'lara etki etmesini engeller, ancak toplam trafiği gerçekten normun ötesine itmedikçe.
  • Kaynak başına kapsamlı. Eşikler küresel kaynak düzeyinde öğrenilir. Bir WAF politikası kural setiyle birden fazla Front Door profiline veya birden fazla geçit atarsanız, hizmet her biri için ayrı ayrı eşikleri hesaplar.
  • Hassasiyet. Her kural üç hassasiyet seviyesi sunar. Daha yüksek hassasiyet daha düşük bir eşik uygular; Daha düşük hassasiyet daha yüksek eşik uygular. Orta standart ve önerilen ayardır.
  • Değerlendirme sırası. WAF, HTTP DDoS kural setini önce, hatta özel kurallardan önce değerlendirir. Özel bir kural, Allow eylemi olan bir kural, diğer tüm WAF denetimlerini atlar, ancak HTTP DDoS kural setini atlamaz.
  • Güvenilir trafik için kural setini atlamak. Özel bir kural ve Allow eylemi burada yardımcı olmaz - diğer tüm kural setlerini atlar ama HTTP DDoS kural setini atlamıyor. Bunun yerine WAF istisnalarını kullanın; bunları belirli bir kural, kural grubu veya HTTP DDoS kural seti dahil tüm yönetilen kural setine genişletebilirsiniz. İstisnalarla muaf güvenilir trafik bölümüne bakınız.
  • Sürekli trafik gerektirir. Kural seti ancak güvenilir temel bilgileri öğrendiğinde etkili olabilir. Bir kaynak öğrenme aşamasında yeterli trafik alamazsa, kural seti algılamaz veya korumaz, ta ki bunu algılayana kadar. Özel gereksinim için platform tablosuna bakınız.

Platform farklılıkları

Characteristic Azure Front Door Premium - Microsoft'un bulut hizmeti için ileri düzey bir ağ yönetim çözümü. Application Gateway WAF v2
Öğrenme aşaması Taban çizgiler yuvarlanan bir pencere boyunca hesaplanır; Son yedi günün en az 50% trafik alan profiller için tespit 24–36 saat içinde başlar Temel bilgiler en az 24 saat öğrenilir; Kural seti 24 saatlik öğrenme aşaması tamamlanana kadar tespit etmez veya engellemez
Yetersiz trafik Bir profil son yedi günün 50%'inden az trafik aldıysa, kural seti güvenilir temel değerler için yeterli trafik bulunana kadar tespit etmez veya engellemez Gateway, 24 saatlik öğrenme aşamasında güvenilir temel oluşturacak kadar trafik alamazsa, kural seti saldırıları tespit etmez veya engellemez
Mitigation Suçlu IP adresleri ceza kutusuna yerleştirilir ve ceza kutusu süresi boyunca engellenir Sorun bozan IP adresleri ceza kutusuna konur ve 15 dakika boyunca engellenir
Kural Kimliği 500100 (istemci isteği oranı), 500110 (şüpheli botlar) 500100 (istemci isteği oranı), 500110 (şüpheli botlar)
Ek ölçümler Web Uygulaması Güvenlik Duvarı HTTPDDoSRuleset Aktiftir Ceza sahası boyutu, Ceza kutusu blokları

Kural kümesi kuralları

Kural seti şu anda iki kural içeriyor. Her kural kendi trafik tabanlarını korur ve kendi duyarlılığı ve eylemiyle yapılandırılabilir:

Kural Description
500100: Yüksek istemci isteği oranında anomali tespit edildi Poliçenin bağlı olduğu Front Door profili veya uygulama geçidi üzerindeki tüm trafiği temel olarak gösterir. Bir istemci öğrenilen eşiği aştığında, yapılandırılmış işlem tetiklenir ve suçlu IP adresi ceza kutusuna yerleştirilir.
500110: Yüksek istek gönderdiği şüpheli botlar Microsoft Threat Intelligence tarafından bot olarak sınıflandırılan trafik için ayrı ve genellikle çok daha katı temeller uygular. Yüksek riskli olarak sınıflandırılan botlar, küresel eşik aşıldıktan sonra hemen engelleniyor.

Ceza kutusu

Her iki platform da ceza sahasıyla azaltma yöntemini artırıyor. Bir istemciden gelen trafik, kural setinin kurallarından birinin eşiğini aştığında, o istemci IP adresi ceza kutusuna yerleştirilir ve WAF tarafından ceza kutusu süresi için engellenir; bu süre Application Gateway'de 15 dakikadır. Süre sona erdiğinde, IP adresi tekrar erişim sağlar, ancak eşik tekrar aşılmazsa ve bu da ceza kutusuna geri döner.

Bu tasarım, telemetri okuma şekliniz için önemlidir: sadece ilk kural isabeti kaydedilir. IP adresi zaten ceza kutusundayken ek bloklanan talepler Front Door'da kaydedilmez, bu yüzden log tabanlı sayımlar engellenen istek sayısını eksik gösterir. Application Gateway'de, gerçek blok sayısı için Penalty box blocks metriğini, şu anda cezalandırılan IP adresi sayısını ise Penalty box boyutu için kullanın.

Önizleme sırasında izleme

Bir IP adresi bir eşiği aştığında, HTTP DDoS kural seti ve WAF Managed Rule Match metrik artışları için bir Block eylemi ile bir log girişi kaydedilir.

  • Front Door: blokları saymak için kural adına göre filtrelenen Web Uygulaması Güvenlik Duvarı Request Count metriğini ve öğrenme tamamlandıktan sonra ve kural seti öğrenilen eşikleri aşan trafiğe karşı harekete geçmeye hazır olduğunda rapor 1veren Web Uygulaması Güvenlik Duvarı HTTPDDoSRuleset Is Active metrikini kullanın.
  • Uygulama Geçidi: cezalandırılan bir IP adresinden gelen her engellenen istek, Yönetilen Kural Eşleşmesi metrikini artırır ve Ceza kutusu boyutu ile Ceza kutusu blokları metrikleri ceza kutusunu doğrudan takip eder.

İstisnalarla muaf güvenilir trafik

Sağlık probları, sentetik izleme, yük testleri, ortak entegrasyonları ve dahili toplu işler hepsi sel gibi görünen ama aslında olmayan trafik üretir. Tarihsel olarak, onları DDoS kural setinden muaf tutmanın bir yolu yoktur, çünkü özel bir İzin Kuralı Varsayılan Kural Seti, Temel Kural Seti ve Bot Koruma kural setini atlar ancak bilerek HTTP DDoS kural setini atlamaz.

WAF istisnaları bu farkı kapatıyor. Bir istisna, tek bir kural, kural grubu veya tüm yönetilen kural seti kapsamında belirli niteliklerle eşleşen talepler için WAF denetimini atlar. İstisnaları HTTP DDoS kural setine ve DRS, CRS ve Bot Koruma'ya uygulayabilirsiniz.

İstisnalar maçı:

  • Uzaktan IP adresi (Equals veya IP Match), bilinen izleme, yük testi veya ortak kaynak aralıklarını DDoS kural setinden muaf tutmak için yaygın tercih olan
  • İstek URI'si
  • Talep başlığı adı ve değeri, Eşit, Başlar, Sona Düşür veya İçeriyor ile eşleştirilmiştir

DDoS kural setiyle istisnaların kullanımı için rehberlik:

  • Kapsamı olabildiğince dar tutun. Kural setinin tamamını muaf tutmaktansa kural başına istisna tercih edin. Geniş bir istisna, saldırgana otomatik azaltma yönteminizin etrafında belgelenmiş bir yol sunar. Bir yük jeneratörü sadece 500100 kuralından muaf tutulması gerekiyorsa, onu 500110 kuralından da muaf tutmayın.
  • Kaynaklar muaf, yollar değil. Bilinen bir test demeti için IP tabanlı bir istisna sınırlıdır. Halka açık bir uç noktada URI tabanlı bir istisna, onu bulan herkes için açık bir kapıdır.
  • Bir programda gözden geçir. Tek seferlik yük testi için eklenen istisnalar, bir yıl sonra hâlâ geçerli olabilir.
  • Sınırlara dikkat et. Her WAF politikası 60'a kadar istisna destekler ve her Front Door tüm ilgili politikalar için toplamda 60 istisna destekler. Tek bir istisna, 600'e kadar IP adresi, 10 URI veya 10 istek başlığı içerebilir.
  • İstisnalar ise yeni nesil WAF motoru ve yönetilen kural seti sürümünü DRS 2.1 veya daha sonrasını gerektirir.

İş için doğru aracı kullanın: istisna etmeler , bir talebin bir unsurunu (gürültülü bir kurabiye veya başlık) incelemeyi atlarken geri kalanını incelemeye devam eder; istisnalar, eşleştirme talepleri için belirli kuralları veya kural setlerini atlar; özel bir İzin Kuralı HTTP DDoS kural seti dışında her şeyi atlar.

Important

WAF istisnaları ve HTTP DDoS kural seti hem Azure Front Door hem de Application Gateway WAF v2'de önizleme aşamasında. Bkz. Microsoft Azure Önizlemeleri için Ek Kullanım Koşulları.

Bloklamadan önce meydan okuma

Engelleme, L7 saldırısı sırasında keskin bir araçtır: saldırı trafiği sık sık gerçek kullanıcıları taşıyan IP adreslerinden ve coğrafyalardan gelir. Zorluklar, otomasyonu insanlardan ayırmanızı sağlıyor, doğrudan bir blok hasarı olmadan ve Azure WAF'nin L7 taşkınlarını yönetme biçimindeki en büyük değişiklik sadece blok oranı sınırı stratejisine kıyasla.

  • JavaScript meydan okuması , insan etkileşimi gerektirmeyen görünmez bir zorluktur. Tarayıcı meydan okumayı başarıyla hesaplarsa, WAF istemciyi bot olmayan olarak doğrular ve kalan kuralları değerlendirmeye devam eder; Başarısız olan talepler engelleniyor. Genel web trafiği için varsayılan zorluk olarak kullanın. Challenge endpoint'e yapılan talepler arka uçunuza iletilmez ve hız sınırlandırması olarak sayılmaz.
  • CAPTCHA , kullanıcı katılımı gerektiren etkileşimli bir meydan okumadır; en iyisi, otomatik kötüye kullanımın pahalı olduğu ve birkaç saniyelik kullanıcı sürprizlerinin kabul edilebilir olduğu giriş girişi, kayıt ve çıkış gibi yüksek değerli akışlar için ayrılır. Meydan okuma çerezi geçerliliği, politika ayarlarında 5 ile 1.440 dakika arasında ayarlanabilir, varsayılan olarak 30 dakikadır. CAPTCHA, ek kullanım bazlı ücretler uygular.

Her iki özelliğin sınırlamalarını dağıtmadan önce planlayın:

  • AJAX ve API çağrıları desteklenmiyor. Zorlukları API rotalarının önüne koymayın. Oran sınırı ve maç kurallarını orada kullanın.
  • Zorluklar, gömülü görseller, CSS veya JavaScript dosyaları için değil, HTML kaynakları için tasarlanmıştır.
  • Zorluk başlatan ilk istekte, POST gövdesi Azure Front Door'ta 64 KB ve Application Gateway'de 128 KB ile sınırlıdır.
  • Her iki özellik de Internet Explorer'ı desteklemiyor; her ikisi de Microsoft Edge, Chrome, Firefox ve Safari'nin güncel sürümlerini desteklemektedir.
  • JavaScript meydan okuması, bir istemcinin IP adresi değiştiğinde ve çapraz köken (CORS) talepleri için yeniden verilir.
  • Application Gateway'de JavaScript Challenge önizleme aşamasında ve hız sınırı özel kuralları için desteklenmiyor. Application Gateway for Containers WAF bunu desteklemiyor.

Hız sınırlaması

En azından, herhangi bir istemciden yüksek talep oranını engelleyen bir hız sınırı kuralı oluşturun. Bu kuralı en düşük öncelikli (en yüksek sayısal değer) oran sınırı kuralı olarak belirleyin, böylece daha spesifik oran sınırı veya eşleşme kuralları önce değerlendirilsin.

Azure Front Door (Azure Ön Kapı hizmeti)

  • Hız sınırları, Azure Front Door'a TCP bağlantısını açan istemcinin adresi olan ve son kullanıcı yerine bir proxy olabilir ve her soket IP adresi için geçerlidir.
  • Eşikler, sabit bir veya beş dakikalık bir zaman aralığında değerlendirilir. Eşik aşıldığında, Azure Front Door kurala uyan tüm trafiği pencerenin geri kalanında engeller. HTTP sel önleme için beş dakikalık pencereyi kullanın: ilk dakikada engellenen saldırgan, kalan dört dakika boyunca engellenmiş kalır.
  • En küçük kabul edilebilir eşik değerine sahip daha büyük pencereler, en etkili anti-DDoS konfigürasyonudur. Daha büyük pencereler ve daha büyük eşik değerleri de yapılandırılmış eşiğe daha yakın bir şekilde uygulanır. Çok düşük eşiklerde (dakikada yaklaşık 200 istekten altında), eşiğin üzerindeki bazı talepler geçilebilir, çünkü bir istemciden gelen talepler, sayaçları henüz yenilenmemiş Front Door sunucularına ulaşabilir.
  • Hız sınırı kuralları yalnızca Log ve Block eylemlerini destekler; İzin verilmiyor.
  • Tüm trafiğe kural uygulayın, uzunluğu 0'dan büyük bir Host başlıkta eşleştirilerek çünkü Azure Front Door'a gönderilen her geçerli istekte bir kural bulunur.

Application Gateway WAF v2

  • Hız sınırlandırma için kaydırma penceresi algoritması kullanılır. Tüm eşleşen trafik, eşik aşıldığı ilk pencerede düşürülür. İkinci pencereden itibaren, eşik seviyesine kadar trafiğe izin verilir; bu da eşleşen müşteriler için tam kesinti yerine bir throttling etkisi yaratır.

  • Kurallar, isteklerin nasıl sayıldığını kontrol eden bir GroupByUserSession gerektirir. Bu özellik, istemci IP'si dışında bir şeyle hız sınırı sağlamaya olanak tanır:

    GroupByVariable Şu durumlarda kullanın:
    ClientAddr (varsayılan) Kaynak IP başına bağımsız sayaçların olduğu normal durum
    ClientAddrXFFHeader Geçitiniz bir CDN veya proxy'nin arkasında yer alıyor ve gerçek istemci IP'si içeride X-Forwarded-For
    GeoLocation Coğrafi olarak yoğunlaşmış bir sel sırasında ülke/bölge başına trafiği sınırlamak istersiniz
    GeoLocationXFFHeader Yukarıdaki gibi, IP adresi X-Forwarded-For
    None Dar eşleşen bir desen için tek bir paylaşılan sayaç, örneğin giriş sayfası veya şüpheli kullanıcı ajanları listesi

  • Hız sınırı kuralları en güncel WAF motorunu gerektirir (varsayılan kural seti için CRS 3.2 veya daha sonrasını seçin) ve hava boşluklu bulutlarda desteklenmez.

  • Application Gateway, politikanın bağlı olduğu her uç nokta için eşikleri bağımsız olarak satar. Beş dinleyiciye yönelik tek bir politika, beş sayaç seti sürdürür.

  • Eşikler tam olarak uygulanmıyor, bu yüzden ince trafik kontrolü için hız sınırlaması kullanmayın. Anormal oranları azaltmak ve erişilebilirliği korumak için kullanın. Geniş eşleştirme kurallarında özellikle Nonedikkatli olun; GeoLocation yanlış seçilmiş bir eşik yasal trafikte sık sık kısa kesintilere yol açabilir.

Coğrafyaya duyarlı eşikler belirleyin

Tek bir küresel eşik en yoğun ülkeniz için yeterince cömert olmalı, bu da onu diğer ülkelerde çok cömert yapar. Çoğu uygulamanın barış zamanında coğrafi profili güçlü şekilde çarpıktır - birkaç ülke veya bölge neredeyse tüm meşru trafiği üretirken, geri kalanlar ise damla. Saldırı trafiği nadiren bu dağılıma saygı gösterir. Coğrafya başına boyut eşikleri bu asimetriyi hem bir tespit sinyali hem de azaltma kontrolüne dönüştürür.

Barış zamanı dağılımınızı en az tam bir hafta boyunca ölçerek başlayın; böylece hafta içi, hafta sonu ve saat dilimi etkileri temsil edilir:

  • Azure Front Door'da, Request count metriğini ClientCountry boyutuna göre böl.

  • Log Analytics'te, erişim günlüğündeki istemci IP adresinden ülkeyi türetin:

    AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(7d)
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize Requests = count(), Clients = dcount(clientIp_s) by Country
| extend ShareOfTraffic = round(100.0 * Requests / toscalar(
      AzureDiagnostics
      | where Category == "FrontdoorAccessLog" and TimeGenerated > ago(7d)
      | count), 2)
| order by Requests desc

Sonra sonuçları katmanlara gruplayın ve her biri için bir eşik belirleyin:

Katman Barış zamanı paylaşımı Önerilen tedavi
Ana pazarlar Trafiğinizin büyük kısmını üreten ülkeler Gerçek kullanıcıların etkilenmemesi için cömert müşteri başına eşik var, o ülkenin kendi p99 sınırından ölçülüdür
İkincil pazarlar Anlamlı ama mütevazı trafik Müşteri başına daha sıkı eşik var, o ülkenin küresel eşikten ziyade p99 ölçüsünden ölçülüdür
Uzun kuyruklu coğrafyalar Meşru trafikin hafif bir damlası Agresif eşik veya blok yerine meydan okuma eylemi
Hizmet vermediğiniz coğrafyalar Etkili olarak sıfır Tamamen engelle ya da statik bir sayfaya yönlendirme

Katmanları nasıl uygulayacağınız platforma bağlıdır:

  • Application Gateway WAF v2 - GroupByVariable: GeoLocation bir coğrafyadan gelen tüm trafik bir sayaç paylaşacak şekilde (veya GeoLocationXFFHeader CDN veya proxy'nin arkasında) kullanılır ve her seviye için kendi eşiği olan bir hız sınırı kuralı oluşturur. Bir ihlal, o coğrafyadaki her istemciye karşı etkili olduğundan, bu eşikleri konservatif şekilde boyutlandırın ve önce Log eyleminde doğrulayın: yanlış yapılandırılmış geniş eşleştirme coğrafi kuralı, meşru trafikte sık sık kısa kesintilere yol açabilir.
  • Azure Front Door - sayaçlar soket IP adresi başına yapılır, bu yüzden seviyeleri coğrafi eşleşme koşullarıyla oluşturun: her seviye için bir oran sınırı kuralı, ilgili ülkelerde eşleştirilmiş ve her birinin kendi eşiği var. Uzun kuyruklu bir coğrafyadaki her müşteri, birincil pazarlarınızdaki müşterilere göre çok daha düşük bir tavan alır, bir müşterinin davranışı diğerlerini etkilemez.

Bunu sürdürülebilir kılan birkaç uygulama:

  • Kuralları en özelden en azına sıralayın: daha yüksek öncelikli birincil piyasa kuralları (daha düşük sayısal değer), sonra ikincil, sonra uzun kuyruklu, en düşük öncelikli oran sınırı kuralı olarak küresel genel kurallar.
  • Uzun kuyruklu coğrafyalar için blok yerine meydan okuma eylemini tercih edin. Az meşru hacmi olan bir ülkeden gelen trafik toplamda şüphelidir ancak yine de gerçek kullanıcıları içerir - yolcular, VPN kullanıcıları ve uzak çalışanlar.
  • Pazarlama lansmanları, bölgesel genişlemeler ve büyük ürün etkinliklerinden sonra yeniden ölçümler yapın. Coğrafyaya duyarlı bir konfigürasyon, ölçüsünün temel ölçü değeri kadar iyidir.
  • Bir olay sırasında ters sinyali izleyin: normalde trafiğin 1% katkısı olan bir ülkenin aniden 40% katkısı organik büyüme yerine saldırı gördüğünüzden daha hızlı doğrulamanın yollarından biridir.

Kendi trafiğinizden bir eşik seçin

Aşağıdaki Log Analytics sorgusunu kullanarak genel kuralı boyutlandırın. Uygulama Geçidi için, FrontdoorAccessLog yerine .ApplicationGatewayAccessLog

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

Daha önce açıklanan coğrafya başına eşikleri ölçmek için, aynı sorguya ülkeyi ekleyin:

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize count() by bin(TimeGenerated, 5m), clientIp_s, Country
| summarize max(count_), percentile(count_, 99), percentile(count_, 95) by Country
| order by percentile_count__99 desc

Barış zamanı trafiğinin %99'unun üzerine eşik koyun, maksimumda değil. Maksimum genellikle tarayıcı veya yanlış yapılandırılmış istemci olur ve buna göre boyutlandırılması kuralı saldırı sırasında yardımcı olamayacak kadar cömert yapar.

Hedefli azaltma için özel kurallar

Belirli bir kullanıcı ajanı, başlık, çerez, sorgu dizisi deseni, URI veya bunların kombinasyonu gibi tanımlanabilir imzaları olan HTTP ve HTTPS saldırılarını engellemek veya hız sınırı oluşturmak için özel WAF kuralları oluşturun. String eşleştirmenin ötesinde, Azure Front Door WAF özel kuralları şu konularda eşleşebilir:

  • Coğrafi konum: Hizmet bölgenizin dışından gelen trafiği engelleyin veya sabit bir sayfaya yönlendirin.
  • Kötü niyetli olarak tanımladığınız adresler ve aralıklar için istemci IP adresi (CIDR) ve IP kısıtlama listeleri.
  • AS Numarası (ASN): Gerçek kullanıcıların gelmediği bir barındırma sağlayıcısı veya taşıma ağından kaynaklanan sel baskınlarını azaltın, IP aralıklarını saymadan yapın.
  • İstemci parmak izi (JA4): Müşterinin TLS el sıkışması ve HTTP özelliklerinden türetilen hash olan JA4 parmak izinde eşleşme. Saldırı araçları ve botnet istemcileri, gönderdikleri IP adresinden bağımsız olarak tutarlı bir parmak izi ürettiği için, JA4 dağıtık saldırı sırasında mevcut olan en dayanıklı imzalardan biridir: binlerce kaynak IP adresi arasında geçiş yapmak parmak izini değiştirmez ve engellemek veya hız sınırlaması tek kuralla tüm botnet'i ortadan kaldırır. Parmak izini barış zamanı kayıtlarınızla doğrulayın, sonra uygulamaya karar verirsiniz. Popüler tarayıcılar ve yaygın SDK'lar, çok sayıda meşru kullanıcı arasında parmak izi paylaşır, bu yüzden doğrulanmamış bir JA4 bloğu son derece geniş olabilir. Önce Log eylemini başlatın, parmak izinin sadece saldırı trafiğinde göründüğünü doğrulayın, sonra Block veya hız sınırı kuralına geçin.
  • Bir olay sırasında cerrahi hafifletme için JA4'ü diğer koşullarla birleştirin. Örneğin, belirli bir JA4 parmak izi ve kullanıcılara hizmet vermediğiniz bir ASN'i engellemek yerine hız sınırı veya JA4 parmak izi ve talep URI.
  • Hizmet etiketi ve talep bileşenlerine yönelik boyut kısıtlamaları .

Bir olay sırasında önemli olan iki uygulama:

  • Bilinen meşru trafik için yanlış pozitifleri azaltmak ve blok ile oran sınırı kurallarından daha yüksek öncelik (daha düşük sayısal değer) vermek için eşleşme kuralları oluşturun. Bir izin kuralı diğer WAF denetimini atlar, ancak HTTP DDoS kural setini atlamaz.
  • Kural değerlendirmesi, Log hariç herhangi bir eylemde durur ve öncelik sayıları benzersiz olmalıdır. Acil durum kuralları için düşük öncelikli numaralardan oluşan bir bloğu ayırın, böylece saldırı sırasında yeniden numaralandırmadan birini ekleyebilirsiniz.

Yönetilen kurallar DDoS savunmasına yönelik değildir, ancak diğer yaygın saldırılara karşı koruma sağlar ve etkin kalmalıdır. Bkz. Yönetilen kurallar (Azure Front Door) veya Yönetilen kurallar (Application Gateway).

Kökeni korumak

  • Origin üzerindeki açık IP'lere erişimi kilitle ve gelen trafiği sadece Azure Front Door veya Application Gateway ulaşabilsin şekilde kısıtla. Azure Front Door kökenlerine trafik güvenliği için verilen rehberliği takip edin.
  • Application Gateway'in sanal ağında kamuya açık IP adreslerinin olmadığından emin olun.
  • Azure Front Door'ta önbelleklemeyi etkinleştirin. Önbelleğe alınan yanıtlar, kenardaki zirve hacmi emer ve kaynak noktanıza ulaşan istek hızını azaltır; bu da genellikle performans kaybı ile kesinti arasındaki farktır.
  • Ölçek kökenleri ve baş boşluğu. Otomatik ve manuel azaltmaların devreye girmesi zaman alır; Yedek kapasite bu boşluğu kapatıyor.

Aktif bir saldırıya yanıt ver

  1. Bunun bir saldırı olduğunu, organik büyüme olmadığını doğrulayın. İstek oranı, istemci IP sayısı, coğrafya karışımı, kullanıcı ajanı dağıtımı ve istenen URI'lerde ani bir değişiklik için WAF ve erişim kayıtlarını kontrol edin.
  2. Zaten neyin hafiflettiğini kontrol et. HTTP DDoS kural setinin aktif olduğunu doğrulayın ve bloklarını kural adıyla inceleyin. Application Gateway'de, Ceza kutusu boyutu ve Ceza kutusu blok metriklerini de işaretleyin, çünkü kayıtlarda sadece IP adresi başına ilk blok görünür. Oran sınırı kural eşleşmelerini inceleyin.
  3. Coğrafya karışımını kendi temel seviyenizle karşılaştırın. Normalde trafikin küçük bir kısmını aniden kontrol altına alan bir ülke, hızlı ve yüksek güvenli bir saldırı sinyalidir. Ayrıca hangi tarif sınırı kurallarını önce sıkılaştırmanız gerektiğini de belirtir.
  4. Yeni kurallar yazmadan önce hassasiyeti artırın. HTTP DDoS kural seti hassasiyetini artırmak veya mevcut bir hız sınırı eşiğini düşürmek, baskı altında yeni bir kural yazmaktan daha hızlı ve güvenlidir.
  5. Trafik karıştığında engellemek yerine meydan okumak olur. Etkilenen HTML yollarına JavaScript meydan okuması, hassas akışlara ise CAPTCHA uygulayın.
  6. Hedefli bir kural yalnızca dayanıklı bir imza belirledikten sonra yazın: ASN, istemci parmak izi, başlık kombinasyonu, coğrafya veya URI desen. Eğer desen gerçek kullanıcılarla da eşleşiyorsa, önce Log eyleminde dağıtın.
  7. Ayarlanırken orijini korumalı tutun: önbelleklemenin açık olduğunu doğrulayın, orijin kilitlenmesini onaylayın ve ölçeklendirin.
  8. Olaydan sonra, hız sınır eşiklerinizi yeni trafik verileriyle yeniden karşılaştırın ve sürekli uygulanmasını istemiyorsanız, acil durum kurallarını Log modunda tutun.

WAF ve erişim günlüklerini analiz et

Anormallikler için Azure WAF logları kullanarak trafiği izleyin ve bunları, olağanüstü sayıda istek, alışılmadık kullanıcı ajanı dizileri veya anormal sorgu dizisi desenleri gönderen şüpheli IP adreslerini belirlemek için kullanın.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Top talkers and top user agents over the attack window (Azure Front Door shown; substitute ApplicationGatewayAccessLog for Application Gateway):

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by clientIp_s
| top 20 by Requests desc

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by userAgent_s, requestUri_s
| top 20 by Requests desc

Daha fazla bilgi için Azure WAF with Azure Front Door ve Azure WAF with Azure Application Gateway sayfalarına bakınız.

İlgili içerik

  • Last updated on