Uygulama (katman 7) DDoS koruması

Şunun için 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ını başlatmak ucuzdur ve bunları meşru trafikten ayırt etmek zordur: her bir istek tek başına geçerli görünür; saldırıyı ortaya çıkaran yalnızca toplam istek hızı, dağılım ve istemci bileşimidir. 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 uç ağında ve kaynak sunucularınızın genel IP adreslerinde L3/L4 hacimsel saldırıları sönümler 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 Olağan trafiğinizi öğrenir ve ani bir trafik artışı sırasında sorunlu istemcilerin hızını, acil durum ayarı gerektirmeden sınırlar. Azure Front Door Premium ve Application Gateway WAF v2 üzerindeki HTTP DDoS kural kümesi (önizleme)
İstemci doğrulaması Engellemeden önce insanları ve meşru istemcileri otomatik saldırı trafiğinden ayırt eder 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 hız sınırlama kuralı yapılandırın (bkz. Hız sınırlama).
  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. Tanılama günlüklerini etkinleştirin ve bir olay öncesinde, Log Analytics için WAF ve erişim günlüklerini analiz etme bölümünde sorguları oluşturun.

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

L7 savunmaları, ancak temelindeki genel IP adresleri volümetrik bir saldırıya dayanabilirse önem taşır; ayrıca iki Azure WAF platformu aynı başlangıç noktasına sahip değildir.

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’un varsayılan altyapı düzeyindeki koruması Azure platformunun kendisini korur, ancak size söz konusu IP için kaynak başına ayarlanmış azaltma, telemetri veya saldırı raporlaması sağlamaz. 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, dışarıya açtığınız kaynak genel IP'leri yine de Azure DDoS Ağ Koruması ile korunmalı ve yalnızca WAF hizmetinin bunlara erişebilmesi için erişim kısıtlaması uygulanmalıdır. Korunmayan, genel erişime açık bir kaynak sunucunun önündeki korumalı bir ön uç, korunmuş sayılmaz.

Daha fazla bilgi için Azure DDoS Protection’a genel bakış ve Uygulama ağ geçidinizi Azure DDoS Network Protection ile koruma bölümlerine bakın.

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'de önizleme sürümünde kullanılabilir. Atandıktan sonra, normal trafiğin temel seviyesini sürekli olarak belirler ve trafik artışları bir saldırıya işaret ettiğinde, ek bir acil ayar gerektirmeden sorunlu istemcileri seçici olarak engeller.

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

  • İki eşik birlikte değerlendirilir. Kural kümesi, hem genel bir eşiği (Front Door profili veya uygulama ağ geçidi başına) hem de IP tabanlı ayrı eşikleri öğrenir. IP tabanlı eşikler, yalnızca küresel eşik aşıldıktan sonra uygulanır. Bu tasarım, toplam trafik gerçekten normal düzeyin üzerine çıkmadıkça, kural kümesinin birkaç IP adresinden kaynaklanan ani artışlara tepki vermesini engeller.
  • Kaynak başına kapsamlandırılmış. Eşikler küresel kaynak düzeyinde öğrenilir. Kural kümesine sahip bir WAF ilkesini birden fazla Front Door profiline veya birden fazla ağ geçidine atadığınızda, hizmet eşikleri her biri için ayrı ayrı 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. Allow eylemine sahip özel bir kural, diğer tüm WAF denetimlerini atlar, ancak HTTP DDoS kural kümesini 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. Bkz. Güvenilir trafiği istisnalarla muaf tutma.
  • Sürekli trafik gerektirir. Kural seti ancak güvenilir temel bilgileri öğrendiğinde etkili olabilir. Bir kaynak, öğrenme aşamasında yeterli trafik almazsa, kural seti yeterli trafik alana kadar onu tespit etmez veya koruma sağlamaz. Ö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ı Temel değerler kayan bir zaman aralığı üzerinden hesaplanır; son yedi günün en az %50’sinde trafik alan profiller için tespit işlemi 24–36 saat içinde başlar Temel değerler en az 24 saat boyunca oluşturulur; kural kümesi, 24 saatlik öğrenme aşaması tamamlanana kadar tespit veya engelleme yapmaz
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 Ağ geçidi, 24 saatlik öğrenme aşaması sırasında güvenilir temel ölçütler oluşturmak için yeterli trafik almazsa, kural kümesi yeterli trafik alana kadar 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 Kimlikleri 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 kutusu 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 oranda istek gönderen şü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 bunu ceza kutusu aracılığıyla hafifletir. 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 yeniden erişim kazanır; ancak eşiği tekrar aşarsa yeniden ceza kutusuna alınır.

Bu tasarım, telemetri verilerinizi nasıl yorumladığınız açısından önemlidir: yalnızca ilk kural eşleşmesi günlüğe 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şik değerini aştığında, HTTP DDoS kural seti için Engelleme eylemiyle bir günlük kaydı oluşturulur ve WAF Yönetilen Kural Eşleşmesi metriği artar.

  • 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 güvenilir trafiği muaf tutun

Sağlık kontrolleri, sentetik izleme, yük testleri, iş ortağı entegrasyonları ve dahili toplu işlem görevleri, taşkın gibi görünen ama gerçekte öyle 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 şuna göre eşleştirilir:

  • 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. Çok geniş kapsamlı bir istisna, saldırgana otomatik önleminizi aşmak için belgelenmiş bir yol sağlar. Bir yük jeneratörü sadece 500100 kuralından muaf tutulması gerekiyorsa, onu 500110 kuralından da muaf tutmayın.
  • Yol adlarını değil, kaynakları muaf tutun. Bilinen bir test düzeneği için IP tabanlı bir istisna sınırlandırılmıştır. Halka açık bir uç noktada URI tabanlı bir istisna, onu bulan herkes için açık bir kapıdır.
  • Bunları düzenli olarak gözden geçirin. 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, yeni nesil WAF motorunu ve yönetilen kural kümesinin DRS 2.1 veya üzeri sürümü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. Sorgulamalar, doğrudan engellemenin yol açtığı istenmeyen yan etkiler olmadan otomatik trafiği insan kullanıcılardan ayırmanıza olanak tanır ve Azure WAF’nin L7 flood saldırılarını ele alma biçiminde, yalnızca engellemeye dayalı bir hız sınırlama stratejisine kıyasla yapılan en büyük değişikliktir.

  • 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 doğrulama yöntemidir; en uygun kullanım alanı, otomatik kötüye kullanımın maliyetli olduğu ve kullanıcıdan birkaç saniyelik ek çaba istenmesinin kabul edilebilir olduğu oturum açma, kayıt olma ve ödeme gibi yüksek değerli işlemlerdir. Meydan okuma çerezinin geçerlilik süresi, politika ayarlarında 5 ila 1.440 dakika arasında yapılandırılabilir; varsayılan süre 30 dakikadır. CAPTCHA, ek kullanım bazlı ücretler uygular.

Her iki özelliği dağıtıma almadan önce, sınırlamalarını göz önünde bulundurarak plan yapın:

  • AJAX ve API çağrıları desteklenmiyor. Zorlukları API rotalarının önüne koymayın. Bunun yerine, orada hız sınırlaması ve eşleştirme kurallarını 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 sınaması önizlemededir ve hız sınırlaması özel kuralları için desteklenmez. 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ıdan ziyade bir proxy olabilen soket IP adresi başına uygulanır.
  • 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, yapılandırılan eşiğe daha yakın bir uygulamayı da sağlar. Çok düşük eşiklerde (kabaca dakikada 200 isteğin altında), eşiği aşan bazı istekler yine de geçebilir; çünkü tek bir istemciden gelen istekler, sayaçları henüz güncellenmemiş Front Door sunucularına denk gelebilir.
  • Hız sınırı kuralları yalnızca Log ve Block eylemlerini destekler; İzin verilmiyor.
  • Azure Front Door'a yönelik her geçerli istekte uzunluğu 0'dan büyük bir Host başlığı bulunduğundan, bu başlıkla eşleşen bir kuralı tüm trafiğe uygulayın.

Application Gateway WAF v2

  • Hız sınırlandırma için kayan pencere algoritması kullanılır. Tüm eşleşen trafik, eşiğin aşıldığı ilk pencerede engellenir. İkinci pencereden itibaren, eşik değerine kadar trafiğe izin verilir; bu da eşleşen istemciler için tam kesinti yerine bir hız sınırlama 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 Ağ geçidiniz bir CDN veya proxy’nin arkasında bulunuyor ve gerçek istemci IP’si X-Forwarded-For içindedir
    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ıdakiyle aynı, X-Forwarded-For içindeki IP adresi kullanılarak
    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 uygulandığı her uç nokta için eşikleri bağımsız olarak sayar. 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. None veya GeoLocation kullanan geniş eşleştirme kurallarında özellikle dikkatli olun; kötü belirlenmiş bir eşik, geçerli trafikte sık sık kısa kesintilere neden olabilir.

Coğrafyaya duyarlı eşikler belirleyin

Tek bir küresel eşik, trafiğin en yoğun olduğu ülkeniz için yeterince yüksek olmak zorundadır; bu da diğer her yerde gereğinden fazla yüksek kalmasına neden olur. Çoğu uygulamanın barış dönemindeki coğrafi profili belirgin biçimde dengesizdir; birkaç ülke veya bölge meşru trafiğin neredeyse tamamını üretirken, geri kalanı ise çok az trafik üretir. 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ış dönemi paylaşımı Önerilen tedavi
Ana pazarlar Trafiğinizin büyük kısmını üreten ülkeler Gerçek kullanıcıların asla etkilenmemesi için, her ülkenin kendi p99 değerine göre belirlenen geniş bir istemci başına eşik vardır.
İkincil pazarlar Anlamlı ama mütevazı trafik Küresel eşik yerine o ülkenin p99 değerine göre belirlenen, istemci başına daha sıkı eşik
Uzun kuyruklu coğrafyalar Az miktarda meşru trafik Agresif eşik veya blok yerine meydan okuma eylemi
Hizmet vermediğiniz coğrafyalar Neredeyse 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 - aynı coğrafi bölgeden gelen tüm trafiğin tek bir sayaç paylaşmasını sağlamak için GroupByVariable: GeoLocation kullanın (veya CDN ya da proxy arkasındaysa GeoLocationXFFHeader kullanın) ve her katman için kendi eşiğine sahip bir hız sınırlama kuralı oluşturun. 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 spesifik olana doğru sıralayın: birincil pazar kuralları daha yüksek öncelikte (daha düşük sayısal değer) olacak şekilde, ardından ikincil kurallar, sonra uzun kuyruk kuralları gelsin; genel kapsayıcı global kural ise en düşük öncelikli oran sınırlama kuralınız olsun.
  • 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 yapılandırma, yalnızca temel aldığı referans değer kadar iyidir.
  • Bir olay sırasında tersine sinyali izleyin: normalde trafiğin %1’ini oluşturan bir ülkenin aniden %40’ını oluşturmaya başlaması, gördüğünüz şeyin organik büyüme değil bir saldırı olduğunu doğrulamanın en hızlı 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 yazın.

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. En yüksek değer genellikle bir crawler botundan veya hatalı yapılandırılmış bir istemciden kaynaklanır; sınırın buna göre belirlenmesi, kuralı saldırı sırasında işe yaramayacak kadar gevşek bırakır.

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. Dize eşleştirmenin ötesinde, Azure Front Door WAF özel kuralları şunlarla eşleşebilir:

  • Coğrafi konum: Hizmet bölgenizin dışından gelen trafiği engelleyin veya sabit bir sayfaya yönlendirin.
  • Kötü amaçlı olarak belirlediğiniz adresler ve aralıklar için istemci IP adresi (CIDR) ve IP kısıtlama listeleri.
  • AS Numarası (ASN): Meşru kullanıcılarınızın kaynaklanmadığı bir barındırma sağlayıcısından veya transit ağından kaynaklanan flood saldırılarını, IP aralıklarını tek tek belirtmeden azaltı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ılarına hizmet sunmadığınız bir ASN’yi ya da bir JA4 parmak izi ve bir istek URI’sini engellemek yerine bunlara hız sınırlaması uygulayın.
  • 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 amacıyla İzin ver eşleşme kuralları oluşturun ve bu kurallara engelleme ile oran sınırlama kurallarınızdan daha yüksek öncelik (daha düşük sayısal değer) verin. 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 kaynaklarına giden trafiğin güvenliğini sağlama konusundaki yönergeleri izleyin.
  • 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ınmış yanıtlar, uçta en yoğun trafiği karşılar ve origin sunucunuza ulaşan istek oranını azaltır; bu da çoğu zaman düşen performans ile hizmet kesintisi arasındaki farkı belirler.
  • Ö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. Halihazırda nelerin etkisini azalttığını kontrol edin. 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. Hız sınırı kural eşleşmelerini inceleyin.
  3. Coğrafya karışımını kendi temel seviyenizle karşılaştırın. Normalde trafikte küçük bir paya sahip olan bir ülkenin aniden trafiğe hâkim duruma gelmesi, hızlı ve yüksek güvenilirlikli 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. Trafiğin karışık olduğu durumlarda engellemek yerine doğrulama isteyin. 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. Desen gerçek kullanıcılarla da eşleşiyorsa, önce bunu Log eyleminde kullanıma alı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ırlama eşiklerinizi yeni trafik verilerine göre yeniden temel alın ve sürekli olarak uygulanmalarını istemiyorsanız, Log modunda doğru sonuç verdiği kanıtlanan acil durum kurallarını koruyun.

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"

Saldırı süresi boyunca en çok trafik oluşturanlar ve en yaygın kullanıcı aracıları (Azure Front Door gösterilmiştir; Application Gateway için ApplicationGatewayAccessLog yerine kullanın):

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