DDoS-Schutz für Anwendungen (Schicht 7)

Gilt für: ✔️ Application Gateway V2 ✔️ Front Door Premium

Die Azure Web Application Firewall (WAF) enthält mehrere Verteidigungsmechanismen, die helfen, verteilte Denial-of-Service-(DDoS)-Angriffe zu verhindern. DDoS-Angriffe können sowohl auf die Netzwerkebene (L3/L4) als auch auf die Anwendungsschicht (L7) abzielen. Azure DDoS-Schutz schützt Sie vor volumetrischen Angriffen auf große Netzwerkebene. Azure WAF, das auf Ebene 7 ausgeführt wird, schützt Webanwendungen vor L7 DDoS-Angriffen wie HTTP-Überschwemmungen. Zusammen verhindern diese Verteidigungen, dass Angreifer Ihre Anwendung erreichen und deren Verfügbarkeit sowie Leistung beeinträchtigen.

Angriffe auf Anwendungsebene sind günstig zu starten und schwer von legitimem Datenverkehr zu unterscheiden: Jede Anfrage wirkt für sich genommen gültig, und nur die aggregierte Rate, Verteilung und Client-Mix zeigen den Angriff. Effektive L7-Verteidigung beruht daher weniger auf einer einzelnen Kontrolle und mehr auf einer geschichteten Konfiguration, die bereits vor Beginn eines Angriffs vorhanden ist.

Wähle deine Verteidigungsschichten

Verwenden Sie folgendes Modell, wenn Sie den L7-DDoS-Schutz planen. Jede Ebene fängt den Datenverkehr auf, die darüberliegende Schicht nicht.

Ebene Was es bewirkt Wo sie konfiguriert werden soll
Plattform-DDoS-Schutz Absorbiert L3/L4-volumetrische Angriffe auf dem Azure-Edge und auf deinen öffentlichen Ursprungs-IPs Standard in Azure Front Door eingebaut; benötigt Azure DDoS Network Protection für Application Gateway öffentliche IPs und Origin Public IPs
Automatisierte L7-Minderung Lernt den normalen Verkehr kennen und drosselt belastende Kunden während einer Überspannung, ohne Notabstimmung HTTP DDoS ruleset (preview) on Azure Front Door Premium and Application Gateway WAF v2
Kundenüberprüfung Trennt Menschen und legitime Kunden vom automatisierten Angriffsverkehr, bevor es blockiert wird Bot Manager Regelwerk,JavaScript-Herausforderung, CAPTCHA
Ratenbegrenzung Begrenzt die Anzahl der Anfragen, die ein Client, Geografie oder Endpunkt senden kann Benutzerdefinierte Tarifbegrenzungsregeln auf Front Door und Application Gateway
Gezielte benutzerdefinierte Regeln Blockiert eine bekannte Angriffssignatur während eines Vorfalls Passe benutzerdefinierte Regeln an (Geo, IP, ASN, Client-Fingerabdruck, Header, URI)
Herkunftsschutz Verhindert, dass Angriffsverkehr überhaupt Ihre Rechenleistung erreicht Caching, Origin-Lockdown, Autoskalierung

Baseline-Konfigurationscheckliste

Erledigen Sie diese Schritte, bevor Sie angegriffen werden. Passe sie an deine Bewerbungsanforderungen an.

  1. Deployen Sie Azure WAF mit Azure Front Door Premium oder Application Gateway WAF v2, um sich vor Angriffen auf der L7-Anwendungsebene zu schützen.
  2. Stelle die WAF-Richtlinie auf Präventionsmodus. Eine Richtlinie im Erkennungsmodus protokolliert nur und blockiert keinen Datenverkehr. Verifizieren und optimieren Sie die Richtlinie gegen Produktionsverkehr zuerst, um Fehlalarme zu reduzieren, und schalten Sie dann Prävention ein.
  3. Weisen Sie das HTTP DDoS-Regelsystem zu (verfügbar sowohl bei Azure Front Door Premium als auch in Application Gateway WAF v2), damit automatisierte Mitigation Ihre Verkehrsbasis lernt, bevor Sie sie benötigen.
  4. Aktivieren Sie das vom Bot Manager verwaltete Regelwerk, um bekannte fehlerhafte Bots zu identifizieren und darauf zu reagieren.
  5. Konfigurieren Sie mindestens eine Catch-All-Rate-Limit-Regel (siehe Rate Limiting).
  6. Skaliere deine Ursprungs-Instanzanzahl, sodass genügend freie Kapazität vorhanden ist, und stelle Application Gateway so ein, dass es automatisch skaliert, ohne eine niedrige maximale Instanzanzahl zu erzwingen.
  7. Aktiviere das Caching bei Azure Front Door, sodass plötzlicher Spitzenverkehr am Rand und nicht am Ursprung absorbiert wird.
  8. Decke deine L3/L4-Aufnahme ab, die je nach Plattform unterschiedlich ist. Siehe Platform DDoS Schutz variiert je nach Plattform. Sperre deinen Ursprung so, dass er nur Verkehr von Azure Front Door oder Application Gateway akzeptiert.
  9. Aktivieren Sie das Diagnoselogging in Log Analytics und erstellen Sie die Abfragen in Analyze WAF sowie Zugriffsprotokollevor einem Vorfall.

Plattform-DDoS-Schutz variiert je nach Plattform

L7-Verteidigungen sind nur dann relevant, wenn die zugrunde liegenden öffentlichen IP-Adressen einen volumetrischen Angriff überleben und die beiden Azure-WAF-Plattformen nicht am selben Ort starten.

Azure Front Door hat standardmäßig den Platform DDoS-Schutz. Azure Front Door ist ein global verteilter Edge-Service, dessen Edge durch Azure-Infrastruktur-DDoS-Schutz ohne zusätzliche Kosten und ohne Konfiguration geschützt ist. Der Datenverkehr endet am Rand der Front Door und nicht an einer IP-Adresse, die du besitzt, daher gibt es keine öffentliche IP von dir, die ein Angreifer auf L3/L4 anvisieren könnte. Dieser Schutz ist der Plattform inhärent, also kaufen oder aktivieren Sie nichts, um ihn zu bekommen.

Application Gateway benötigt Azure DDoS Network Protection. Ein Application Gateway ist eine regionale Ressource mit einer öffentlichen IP-Adresse in Ihrem eigenen virtuellen Netzwerk. Azure's Standard-Infrastrukturschutz schützt die Azure-Plattform selbst, bietet aber keine abgestimmten, ressourcenbezogenen Minderungs-, Telemetrie- oder Angriffsberichte für diese IP. Um die öffentliche IP des Gateways vor L3/L4-volumetrischen Angriffen zu schützen, aktivieren Sie Azure DDoS Network Protection im virtuellen Netzwerk, das es enthält. Dies ist ein kostenpflichtiger, separat erworbener Service.

Praktische Konsequenzen bei der Wahl oder Gestaltung einer Deployment:

  • Wenn du hinter Azure Front Door stehst, budgetiere für L7-Kontrollen; der L3/L4-Kantenschutz ist bereits vorhanden.
  • Wenn Sie Application Gateway verwenden und den DDoS-Netzwerkschutz nicht aktiviert haben, können Ihre WAF-Regeln perfekt abgestimmt werden und dennoch durch einen volumetrischen Angriff auf die öffentliche IP des Gateways umgangen werden. Aktivieren Sie es.
  • In beiden Fällen benötigen die von dir bereitgestellten Ursprungs-IP-Adressen weiterhin Azure DDoS Network Protection sowie eine Sperrung, sodass nur der WAF-Dienst sie erreichen kann. Ein geschütztes Frontend vor einem ungeschützten, öffentlich zugänglichen Ursprung ist nicht geschützt.

Weitere Informationen finden Sie unter Azure DDoS Protection Überblick und Protect your application gateway with Azure DDoS Network Protection.

Automatisierter Schutz mit dem HTTP-DDoS-Regelwerk (Vorschau)

Statische Kontrollen wie IP-Filter, Geofilter und feste Ratenbegrenzungen können oft nicht mit verteilten Botnets Schritt halten: Die Schwellenwerte sind Vermutungen, sie sind immer aktiviert, und man muss sie anpassen, wenn sich die Verkehrsmuster entwickeln. Das HTTP DDoS-Regelwerk ist Azure WAFs erstes automatisiertes Layer-7-Schutzmodell, das mit minimaler Benutzerkonfiguration lernt, erkennt und verteidigt. Es ist in der Vorschauversion sowohl auf Azure Front Door Premium als auch auf Application Gateway WAF v2 verfügbar. Sobald sie zugewiesen ist, wird der normale Verkehr kontinuierlich als Basis gewertet und, wenn Überspannungen auf einen Angriff hinweisen, selektiv störende Clients blockiert, ohne dass Notfallabstimmung erforderlich ist.

Das Design ist auf beiden Plattformen in den wichtigsten Bereichen gleich:

  • Zwei Schwellenwerte, gemeinsam bewertet. Das Regelset lernt sowohl einen globalen Schwellenwert (pro Front Door Profil oder pro Anwendungsgateway) als auch einzelne IP-basierte Schwellenwerte. IP-basierte Schwellenwerte werden erst durchgesetzt, nachdem die globale Schwelle überschritten wurde. Dieses Design verhindert, dass das Regelwerk auf Spitzen von wenigen IP-Adressen wirkt, es sei denn, sie bringen tatsächlich den Gesamtverkehr über das Normalwert hinaus.
  • Scoped pro Ressource. Schwellenwerte werden auf globaler Ressourcenebene gelernt. Wenn du eine WAF-Policy mit dem Regelset mehreren Front-Door-Profilen oder mehreren Gateways zuweist, berechnet der Dienst für jedes einzelne die Schwellenwerte separat.
  • Sensibilität. Jede Regel bietet drei Empfindlichkeitsstufen. Eine höhere Empfindlichkeit führt zu einer niedrigeren Schwelle; Eine niedrigere Empfindlichkeit führt zu einer höheren Schwelle. Mittel ist die Standardeinstellung und empfohlen.
  • Bewertungsbestellung. Die WAF bewertet zuerst das HTTP DDoS-Regelwerk, noch bevor benutzerdefinierte Regeln eingeführt werden. Eine benutzerdefinierte Regel mit einer Erlaubt-Aktion umgeht alle anderen WAF-Inspektionen, umgeht aber nicht das HTTP-DDoS-Regelwerk.
  • Umgehung des Regelwerks für vertrauenswürdigen Datenverkehr. Eine benutzerdefinierte Regel mit einer Erlaubt-Aktion hilft hier nicht – sie umgeht alle anderen Regelsätze, aber nicht das HTTP-DDoS-Regelwerk. Verwenden Sie stattdessen WAF-Ausnahmen , die Sie auf eine bestimmte Regel, Regelgruppe oder ein ganzes verwaltetes Regelwerk, einschließlich des HTTP DDoS-Regelsystems, scopen können. Siehe Exempt Trusted Traffic with exception.
  • Erfordert anhaltenden Verkehr. Das Regelwerk kann erst handeln, wenn es verlässliche Basislinien gelernt hat. Wenn eine Ressource während der Lernphase nicht genug Traffic erhält, erkennt oder schützt das Regelwerk erst, wenn es soweit ist. Siehe die Plattformtabelle für die spezifische Anforderung.

Plattformunterschiede

Merkmal Azure Front Door Premium Anwendungsgateway WAF v2
Lernphase Die Basislinien werden über ein Rollfenster berechnet; Die Erkennung beginnt innerhalb von 24–36 Stunden für Profile, die mindestens 50% der letzten sieben Tage Traffic erhalten haben Basislinien werden mindestens 24 Stunden lang gelernt; Das Regelwerk erkennt oder blockiert erst, wenn die 24-Stunden-Lernphase abgeschlossen ist
Unzureichender Verkehr Wenn ein Profil weniger als 50% der letzten sieben Tage Verkehr empfangen hat, erkennt oder blockiert das Regelwerk erst, wenn genügend Verkehr für verlässliche Basislinien vorhanden ist Wenn das Gateway während der 24-Stunden-Lernphase nicht genug Datenverkehr erhält, um zuverlässige Baselines zu etablieren, erkennt oder blockiert das Regelsystem Angriffe erst, wenn es dies tut
Mitigation Betroffene IP-Adressen werden in eine Strafbox gelegt und für die Dauer der Strafbox gesperrt Störende IP-Adressen werden in eine Strafbank gelegt und für 15 Minuten blockiert
Regel-IDs 500100 (Client-Anfragerate), 500110 (vermutete Bots) 500100 (Client-Anfragerate), 500110 (vermutete Bots)
Zusätzliche Metriken Web Application Firewall HTTPDDoSRuleset ist aktiv Größe der Strafbox, Blockade der Strafbox

Regelsatzregeln

Das Regelwerk enthält derzeit zwei Regeln. Jede Regel pflegt ihre eigenen Verkehrsbasislinien und ist mit eigener Empfindlichkeit und Aktion konfigurierbar:

Regel Beschreibung
500100: Anomalie bei hoher Rate von Client-Anfragen erkannt Der gesamte Datenverkehr basiert auf dem Front Door-Profil oder dem Anwendungsgateway, an das die Policy angeschlossen ist. Wenn ein Client die gelernte Schwelle überschreitet, wird die konfigurierte Aktion ausgelöst und die beeinträchtigte IP-Adresse wird in die Strafbox gelegt.
500110: Mutmaßliche Bots senden hohe Anfrageraten Führt separate, in der Regel deutlich strengere Basislinien für den Datenverkehr, der von Microsoft Threat Intelligence als Bots klassifiziert wird. Als Hochrisiko-Bots werden sofort geblockt, sobald die globale Schwelle überschritten wird.

Das Straffeld

Beide Plattformen mildern durch eine Strafbox. Wenn der Datenverkehr von einem Client die Schwelle einer der Regeln des Regelwerks überschreitet, wird diese Client-IP-Adresse in die Strafbox gelegt und vom WAF für die Dauer der Strafbox, die auf Application Gateway 15 Minuten beträgt, blockiert. Wenn der Zeitraum endet, erhält die IP-Adresse wieder den Zugriff, es sei denn, sie überschreitet erneut die Schwelle, was sie in die Strafbox zurückführt.

Dieses Design ist entscheidend dafür, wie du deine Telemetrie auslesest: Nur der erste Regeltreffer wird protokolliert. Zusätzliche blockierte Anfragen, während die IP-Adresse bereits in der Strafbox ist, werden in Front Door nicht protokolliert, daher unterschätzen logbasierte Zählungen die Anzahl der blockierten Anfragen. Im Application Gateway verwenden Sie die Strafbox-Block-Metrik für die tatsächliche Blockanzahl und die Strafbox-Größe für die aktuell bestrafte Anzahl der IP-Adressen.

Überwachung während der Vorschau

Wenn eine IP-Adresse eine Schwelle überschreitet, wird ein Protokolleintrag mit einer Block-Aktion für das HTTP DDoS-Regelwerk und die WAF Managed Rule Match-Metrik erhöht sich.

  • Front Door: Verwenden Sie die Web Application Firewall Request Count-Metrik, gefiltert nach Regelnamen, um Blöcke zu zählen, sowie die Web Application Firewall HTTPDDoSRuleset Is Active Metrik, die meldet1, sobald das Lernen abgeschlossen ist und das Regelsystem bereit ist, auf Verkehr zu reagieren, der die gelernten Schwellenwerte überschreitet.
  • Application Gateway: Jede nachfolgende blockierte Anfrage von einer bestraften IP-Adresse erhöht die Managed Rule Match-Metrik, und die Penaltybox-Größen- und Penaltybox-Blocks-Metriken verfolgen die Strafbox direkt.

Vertrauenswürdigen Datenverkehr mit Ausnahmen ausnehmen

Gesundheitsproben, synthetisches Monitoring, Lasttests, Partnerintegrationen und interne Batch-Jobs erzeugen alle Datenverkehr, der wie eine Flut aussieht, es aber nicht ist. Historisch gesehen gibt es keine Möglichkeit, sie vom DDoS-Regelset auszuschließen, da eine benutzerdefinierte Erlaubt-Regel das Standard-Regelwerk, das Core Rule Set und das Bot Protection-Regelset umgeht, aber absichtlich das HTTP-DDoS-Regelset nicht umgeht.

WAF-Ausnahmen schließen diese Lücke. Eine Ausnahme umgeht die WAF-Inspektion für Anfragen, die mit bestimmten Attributen übereinstimmen, die auf eine einzelne Regel, eine Regelgruppe oder ein ganzes verwaltetes Regelwerk beschränkt sind. Sie können Ausnahmen sowohl auf das HTTP DDoS-Regelwerk als auch auf DRS, CRS und Bot Protection anwenden.

Ausnahmen stimmen auf:

  • Entfernte IP-Adresse (Equals oder IP Match), die übliche Wahl ist, um bekannte Überwachungs-, Lasttest- oder Partnerquellenbereiche vom DDoS-Regelwerk auszuschließen
  • Anforderungs-URI
  • Header-Name und -Wert anfordern, abgeglichen mit Equals, Starts with, Ends with oder Contains

Hinweise zur Verwendung von Ausnahmen im DDoS-Regelwerk:

  • Fokussiere so eng wie möglich. Bevorzuge eine Ausnahme pro Regel gegenüber der Ausnahme des gesamten Regelwerks. Eine breite Ausnahme gibt einem Angreifer einen dokumentierten Weg um Ihre automatisierte Minderung herum. Wenn ein Lastgenerator nur eine Ausnahme von Regel 500100 benötigt, befreie ihn nicht auch von 500110.
  • Befreite Quellen, keine Wege. Eine IP-basierte Ausnahme für ein bekanntes Test-Harness ist begrenzt. Eine URI-basierte Ausnahme auf einem öffentlichen Endpunkt ist eine offene Tür für jeden, der sie findet.
  • Überprüfen Sie sie nach einem Zeitplan. Ausnahmen für einen einmaligen Lasttest könnten auch ein Jahr später noch bestehen.
  • Achte auf die Grenzen. Jede WAF-Richtlinie unterstützt bis zu 60 Ausnahmen, und jede Front Door unterstützt insgesamt 60 über alle zugehörigen Richtlinien hinweg. Eine einzelne Ausnahme kann bis zu 600 IP-Adressen, 10 URIs oder 10 Anfrage-Header enthalten.
  • Ausnahmen erfordern die nächste Generation der WAF-Engine und die verwaltete Regelsatzversion DRS 2.1 oder neuer.

Verwenden Sie das richtige Tool für die Aufgabe: Ausschlüsse überspringen die Inspektion eines Elements einer Anfrage (ein verrauschtes Cookie oder einen Header), während der Rest weiterhin überprüft wird; Ausnahmen überspringen bestimmte Regeln oder Regelwerke für Matching-Anfragen; eine benutzerdefinierte Erlaubt-Regel umgeht alles außer dem HTTP-DDoS-Regelwerk.

Von Bedeutung

WAF-Ausnahmen und das HTTP DDoS-Regelwerk sind sowohl auf Azure Front Door als auch auf Application Gateway WAF v2 in der Vorschau verfügbar. Lesen Sie die ergänzenden Nutzungsbedingungen für Microsoft Azure Previews.

Herausforderung vor dem Blocken

Blockierung ist ein stumpfes Instrument während eines L7-Angriffs: Angriffsverkehr kommt häufig von IP-Adressen und Regionen, die auch echte Nutzer tragen. Challenges ermöglichen es, Automatisierung von Menschen zu trennen, ohne den Kollateralschaden einer kompletten Blockierung zu verursachen, und sie sind die größte Veränderung darin, wie Azure WAF L7-Überschwemmungen im Vergleich zu einer reinen Block-Rate-Limit-Strategie handhabt.

  • Die JavaScript-Herausforderung ist eine unsichtbare Herausforderung, die keine menschliche Interaktion erfordert. Wenn der Browser die Herausforderung erfolgreich berechnet, validiert WAF den Client als Nicht-Bot und bewertet weiterhin die verbleibenden Regeln; Fehlgeschlagene Anfragen werden blockiert. Nutze es als Standard-Herausforderung für den allgemeinen Webverkehr. Anfragen an den Challenge-Endpunkt werden nicht an dein Backend weitergeleitet und zählen nicht zur Rate Limiting.
  • CAPTCHA ist eine interaktive Herausforderung, die Nutzerbeteiligung erfordert und am besten für hochwertige Flows wie Anmelde, Anmeldung und Checkout reserviert, wo automatisierter Missbrauch teuer ist und ein paar Sekunden Benutzerreibung akzeptabel sind. Die Gültigkeit des Challenge-Cookies ist in Richtlinieneinstellungen zwischen 5 und 1.440 Minuten konfigurierbar, mit einer Standarddauer von 30 Minuten. CAPTCHA verursacht zusätzliche nutzungsbasierte Gebühren.

Plane die Einschränkungen beider Funktionen vor der Einführung in Planung:

  • AJAX- und API-Aufrufe werden nicht unterstützt. Stellen Sie keine Herausforderungen vor API-Routen. Verwende dort stattdessen Rate-Limiting- und Match-Regeln.
  • Challenges sind für HTML-Ressourcen konzipiert, nicht für eingebettete Bilder, CSS oder JavaScript-Dateien.
  • Bei der ersten Anfrage, die eine Herausforderung auslöst, ist der POST-Body auf 64 KB bei Azure Front Door und 128 KB auf Application Gateway begrenzt.
  • Keine der beiden Funktionen unterstützt den Internet Explorer; beide unterstützen aktuelle Versionen von Microsoft Edge, Chrome, Firefox und Safari.
  • Die JavaScript-Herausforderung wird erneut ausgestellt, wenn sich die IP-Adresse eines Kunden ändert und bei Cross-Origin-(CORS)-Anfragen.
  • Auf Application Gateway ist JavaScript Challenge in der Vorschau und wird für benutzerdefinierte Rate-Limit-Regeln nicht unterstützt. Application Gateway for Containers WAF unterstützt das nicht.

Ratenbegrenzung

Erstelle mindestens eine Rate Limit-Regel, die eine hohe Anzahl von Anfragen von jedem einzelnen Client blockiert. Setze diese Regel als deine niedrigste Priorität (höchster numerischer Wert) Rate-Limit-Regel, damit zuerst spezifischere Rate-Limit- oder Match-Regeln ausgewertet werden.

Azure Front Door – der Dienst für Web-Traffic-Management

  • Für die IP-Adresse des Sockets gelten Ratenbegrenzungen, also die Adresse des Kunden, der die TCP-Verbindung zu Azure Front Door öffnet und möglicherweise ein Proxy statt des Endnutzers ist.
  • Schwellenwerte werden über ein festes Zeitfenster von ein oder fünf Minuten bewertet. Sobald die Schwelle überschritten wird, blockiert Azure Front Door für den Rest des Fensters jeglichen Datenverkehr, der der Regel entspricht. Nutzen Sie das fünfminütige Zeitfenster zur HTTP-Überschwemmungsminderung: Ein Angreifer, der in der ersten Minute blockiert wird, bleibt für die verbleibenden vier Minuten blockiert.
  • Größere Fenster mit der niedrigsten akzeptablen Schwelle sind die effektivste Anti-DDoS-Konfiguration. Größere Fenster und höhere Schwellenwerte setzen ebenfalls näher an die konfigurierte Schwelle heran. Bei sehr niedrigen Schwellenwerten (unter etwa 200 Anfragen pro Minute) können einige Anfragen über dem Schwellenwert durchkommen, weil Anfragen von einem Client auf Front-Door-Servern landen können, deren Zähler noch nicht aktualisiert sind.
  • Ratenbegrenzungsregeln unterstützen nur Log- und Block-Aktionen;Allow wird nicht unterstützt.
  • Wenden Sie eine Regel auf allen Datenverkehr an, indem Sie auf einen Host Header mit einer Länge größer als 0 matchen, denn jede gültige Anfrage an Azure Front Door hat eine Regel.

Anwendungsgateway WAF v2

  • Die Ratenbegrenzung verwendet einen Algorithmus für das Sliding-Window . Der gesamte übereinstimmende Verkehr wird im ersten Fenster, in dem die Schwelle überschritten wird, abgebrochen. Ab dem zweiten Fenster ist der Verkehr bis zur Schwelle erlaubt, was einen Drosselungseffekt erzeugt, statt eines vollständigen Ausfalls für das Abgleichen der Kunden.

  • Regeln erfordern eine GroupByUserSession, die steuert, wie Anfragen gezählt werden. Mit dieser Funktion kann man die Rate um etwas anderes als die Client-IP begrenzen:

    GroupByVariable (GruppeNach Variable) Verwenden Sie ihn, wenn
    ClientAddr (Standardwert) Normalfall mit unabhängigen Zählern pro Quell-IP
    ClientAddrXFFHeader Dein Gateway sitzt hinter einem CDN oder Proxy und die echte Client-IP ist in X-Forwarded-For
    GeoLocation Du solltest den Verkehr pro Land/Region während einer geografisch konzentrierten Überschwemmung begrenzen.
    GeoLocationXFFHeader Wie oben, mit der IP-Adresse in X-Forwarded-For
    None Ein einzelner gemeinsamer Zähler für ein eng übereinstimmtes Muster, wie eine Anmeldeseite oder eine Liste verdächtiger Benutzeragenten

  • Ratenbegrenzungsregeln erfordern die neueste WAF-Engine (wähle CRS 3.2 oder höher als Standardregelsatz) und werden in Air-Gapped Clouds nicht unterstützt.

  • Application Gateway zählt die Schwellenwerte unabhängig für jeden Endpunkt , an den die Policy angeschlossen ist. Eine einzige Richtlinie mit fünf Zuhörern hält fünf Zähler aufrecht.

  • Schwellenwerte werden nicht exakt durchgesetzt, daher sollten Sie keine Ratenbegrenzung für eine feine Verkehrssteuerung verwenden. Nutzen Sie es, um anomale Raten zu mindern und die Verfügbarkeit aufrechtzuerhalten. Seien Sie besonders vorsichtig bei weitgehenden Matching-Regeln, die oder Noneverwenden; GeoLocation ein schlecht gewählter Schwellenwert kann häufig zu kurzen Ausfällen für legitimen Verkehr führen.

Setze geografiebewusste Schwellenwerte

Eine einzige globale Schwelle muss großzügig genug für Ihr belebbarstes Land sein, was sie überall sonst viel zu großzügig macht. Die meisten Anwendungen haben in Friedenszeiten ein stark verzerrtes geografisches Profil – einige wenige Länder oder Regionen produzieren fast ausschließlich legitimen Datenverkehr, der Rest liefert nur einen Rinnsal. Angriffsverkehr respektiert diese Verteilung selten. Die Größenschwellen pro Geografie verwandeln diese Asymmetrie sowohl in ein Erkennungssignal als auch in eine Minderungskontrolle.

Beginnen Sie damit, Ihre Friedenszeitverteilung über mindestens eine ganze Woche zu messen, sodass Effekte an Wochentagen, Wochenenden und Zeitzonen dargestellt sind:

  • Auf Azure Front Door teilt man die Request Count-Metrik nach der ClientCountry-Dimension auf.

  • In Log Analytics leiten Sie das Land aus der Client-IP-Adresse im Zugriffsprotokoll ab:

    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

Gruppieren Sie die Ergebnisse dann in Stufen und legen für jede eine Schwelle fest:

Tarif Friedenszeit-Anteil Empfohlene Behandlung
Primärmärkte Die Länder, die den Großteil deines Traffics ausmachen Großzügige Pro-Client-Schwelle, ausgebaut von der eigenen P99 des Landes, sodass echte Nutzer nie betroffen sind.
Sekundärmärkte Bedeutender, aber bescheidener Verkehr Strengere Pro-Client-Schwelle, die von der P99 des Landes statt der globalen basiert
Langschwanzgeographien Ein Rinnsal legitimer Verkehrsteilnehmer Aggressive Schwellenwerte oder eine Herausforderungsaktion statt eines Blocks
Geografien, die du nicht bedienst, bedient du nicht Effektiv null Blockieren Sie komplett oder leiten Sie auf eine statische Seite um

Wie man die Tiers implementiert, hängt von der Plattform ab:

  • Application Gateway WAF v2 – verwenden GroupByVariable: GeoLocation Sie (oder GeoLocationXFFHeader hinter einem CDN oder Proxy), sodass der gesamte Datenverkehr aus einer Region einen Zähler teilt, und pro Stufe eine Rate-Limit-Regel mit eigenem Schwellenwert erstellt wird. Da eine Verletzung gegen jeden Client in dieser Region wirkt, sollten diese Schwellenwerte vorsichtig dimensioniert und in der Log-Aktion zuerst validiert werden: Eine falsch konfigurierte breit angepasste Geo-Regel kann häufige Kurzzeitausfälle für legitimen Datenverkehr verursachen.
  • Azure Front Door – Zähler sind pro Socket-IP-Adresse, also bauen Sie die Tiers stattdessen mit Geo-Match-Bedingungen auf: eine Rate Limit-Regel pro Tier, die auf die jeweiligen Länder abgestimmt wird, jedes mit eigenem Schwellenwert. Jeder Kunde in einer Long-Tail-Region hat dann eine viel niedrigere Obergrenze als Kunden in Ihren Hauptmärkten, ohne dass das Verhalten eines Kunden die anderen beeinflusst.

Einige Praktiken, die dies aufrechterhalten:

  • Ordne die Regeln von der spezifischsten bis zur niedrigsten Regel: Primärmarktregeln mit höherer Priorität (niedrigerer numerischer Wert), dann sekundär, dann Long-Tail, wobei der globale Sammelpunkt als niedrigste Prioritätsrate Limit ist.
  • Bevorzuge eine Herausforderungsaktion gegenüber einem Block für Long-Tail-Geographien. Der Datenverkehr aus einem Land mit geringem legitimem Volumen ist insgesamt verdächtig, enthält aber dennoch echte Nutzer – Reisende, VPN-Nutzer und Remote-Mitarbeiter.
  • Messen Sie nach Markteinführungen, regionalen Expansionen und großen Produktveranstaltungen neu. Eine geografiebewusste Konfiguration ist nur so gut wie die Basislinie, von der aus sie dimensioniert wurde.
  • Achten Sie auf das umgekehrte Signal während eines Vorfalls: Ein Land, das normalerweise 1% Verkehr leistet und plötzlich 40% steuert, ist eine der schnellsten Methoden, um zu bestätigen, dass Sie einen Angriff statt eines organischen Wachstums sehen.

Wählen Sie eine Schwelle aus Ihrem eigenen Datenverkehr

Verwenden Sie die folgende Log Analytics-Abfrage, um die Catch-All-Regel zu dimensionieren. Für Application Gateway ersetzen FrontdoorAccessLog Sie durch ApplicationGatewayAccessLog.

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

Um die zuvor beschriebenen geographischen Schwellenwerte zu berechnen, fügen Sie das Land derselben Abfrage hinzu:

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

Setzen Sie die Schwelle über dem 99. Perzentil des Verkehrs in Friedenszeiten, nicht auf das Maximum. Das Maximum ist meist ein Crawler oder ein falsch konfigurierter Client, und die entsprechende Größe macht die Regel zu großzügig, um bei einem Angriff zu helfen.

Benutzerdefinierte Regeln für gezielte Minderung

Erstellen Sie benutzerdefinierte WAF-Regeln, um HTTP- und HTTPS-Angriffe mit identifizierbaren Signaturen zu blockieren oder zu begrenzen, wie z. B. einen bestimmten User Agent, Header, Cookie, Abfragezeichenmuster, URI oder eine Kombination davon. Über das Stringmatching hinaus können benutzerdefinierte WAF-Regeln in Azure Front Door auf:

  • Geo-Ortung: Blockieren Sie den Datenverkehr außerhalb Ihrer Dienstregion oder leiten Sie ihn auf eine statische Seite um.
  • Client-IP-Adresse (CIDR) und IP-Einschränkungen listen Adressen und Bereiche auf, die du als bösartig identifiziert hast.
  • AS-Nummer (ASN): Mindern Sie Überschwemmungen, die von einem Hosting-Anbieter oder Transitnetz stammen, von dem Ihre legitimen Nutzer nicht stammen, ohne IP-Bereiche zu nennen.
  • Client-Fingerabdruck (JA4): Übereinstimmung auf dem JA4-Fingerabdruck, einem Hash, der aus den TLS-Handshake- und HTTP-Eigenschaften des Clients abgeleitet ist. Da Angriffswerkzeuge und Botnet-Clients unabhängig von der IP-Adresse einen konsistenten Fingerabdruck erzeugen, ist JA4 eine der langlebigsten Signaturen während eines verteilten Angriffs: Das Durchlaufen von Tausenden von Quell-IP-Adressen ändert den Fingerabdruck nicht, und das Blockieren oder Rate-Limiting beseitigt das gesamte Botnetz mit einer Regel. Vergleiche den Fingerabdruck mit deinen Friedenszeitprotokollen, bevor du ihn durchsetzt. Beliebte Browser und gängige SDKs teilen Fingerabdrücke mit enormen Zahlen legitimer Nutzer, sodass ein nicht validierter JA4-Block extrem breit sein kann. Zuerst in der Log-Aktion deployen, bestätigen, dass der Fingerabdruck nur im Angriffsverkehr erscheint, und dann auf Block oder eine Rate Limit-Regel wechseln.
  • Kombinieren Sie JA4 mit anderen Zuständen zur chirurgischen Minderung während eines Vorfalls. Zum Beispiel: Rate Limit, anstatt einen bestimmten JA4-Fingerabdruck und ein ASN zu blockieren, von dem Nutzer nicht ausgeliefert werden, oder einen JA4-Fingerabdruck und eine Anfrage-URI.
  • Service-Tag und Größenbeschränkungen für Anfragekomponenten.

Zwei Praktiken, die während eines Vorfalls von Bedeutung sind:

  • Erstellen Sie Allow Match-Regeln für bekannten legitimen Datenverkehr, um Fehlalarme zu reduzieren, und geben ihnen eine höhere Priorität (niedrigeren numerischen Wert) als Ihre Block- und Rate-Limit-Regeln. Beachten Sie, dass eine Erlaubt-Regel andere WAF-Inspektionen umgeht, aber nicht das HTTP-DDoS-Regelwerk.
  • Die Regelbewertung stoppt bei jeder Aktion außer Log, und Prioritätszahlen müssen eindeutig sein. Reserviere einen Block mit niedriger Prioritätsnummern für Notfallregeln, damit du während eines Angriffs eine einfügen kannst, ohne umnummeriert zu werden.

Managed Rules sind nicht auf DDoS-Verteidigung ausgerichtet, aber sie schützen gegen andere häufige Angriffe und sollten aktiviert bleiben. Siehe Managed rules (Azure Front Door) oder Managed rules (Application Gateway).

Schützen Sie den Ursprung

  • Sperren Sie den Zugriff auf öffentliche IPs auf dem Ursprung und beschränken Sie eingehenden Datenverkehr, sodass nur Azure Front Door oder Application Gateway darauf zugreifen können. Folgen Sie den Anweisungen zur Sicherung von Datenverkehr zu Azure Front Door Origins.
  • Stellen Sie sicher, dass im virtuellen Netzwerk des Application Gateway keine öffentlich offengelegten IP-Adressen vorhanden sind.
  • Caching auf Azure Front Door aktivieren. Zwischengespeicherte Antworten absorbieren das Spitzenvolumen am Rand und verringern die Anfragerate, die Ihren Ursprung erreicht, was oft der Unterschied zwischen verschlechterter Leistung und einem Ausfall ist.
  • Scale Origins mit Headroom. Automatisierte und manuelle Minderungen brauchen Zeit, um umgesetzt zu werden; Freie Kapazität füllt diese Lücke.

Reagieren Sie auf einen aktiven Angriff

  1. Bestätigen Sie, dass es ein Angriff ist, kein organisches Wachstum. Überprüfen Sie die WAF- und Zugriffsprotokolle auf eine plötzliche Änderung der Anforderungsrate, der Anzahl der Client-IPs, der geografischen Mischung, der User-Agent-Verteilung und der angeforderten URIs.
  2. Überprüfe, was bereits abmildert. Bestätigen Sie, dass das HTTP DDoS-Regelwerk aktiv ist, und überprüfen Sie seine Blöcke nach Regelnamen. Auf Application Gateway prüfen Sie auch die Strafboxgröße und die Strafbox-Blocks-Metriken , da nur der erste Block pro IP-Adresse in den Protokollen erscheint. Überprüfen Sie die Übereinstimmung der Rate-Limit-Regeln.
  3. Vergleiche die geografische Mischung mit deinem Ausgangswert. Ein Land, das normalerweise nur einen kleinen Anteil des Verkehrs beiträgt und plötzlich dominiert, ist ein schnelles, hochkonfidenziertes Angriffssignal. Es sagt auch, welche Stufe der Zinsbegrenzungsregeln zuerst verschärft werden sollte.
  4. Erhöhe die Sensibilität, bevor du neue Regeln schreibst. Die Erhöhung der HTTP-DDoS-Regelsatzsensitivität oder das Senken einer bestehenden Ratenbegrenzungsgrenze ist schneller und sicherer, als unter Druck eine neue Regel zu verfassen.
  5. Fordern Sie heraus, anstatt zu blockieren , wo der Verkehr gemischt ist. Wende JavaScript-Herausforderungen auf betroffene HTML-Routen an und CAPTCHA auf sensible Flows.
  6. Schreiben Sie eine gezielte Regel erst, wenn Sie eine dauerhafte Signatur identifiziert haben: ASN, Kundenfingerabdruck, Header-Kombination, Geografie oder URI-Muster. Deploye es zuerst in der Log-Aktion, falls das Muster auch mit echten Nutzern übereinstimmt.
  7. Halte den Ursprung geschützt , während du abstimmst: Überprüfen Sie, ob Caching aktiviert ist, bestätigen Sie Ursprungssperrung und Skalieren Sie aus.
  8. Nach dem Vorfall sollten Sie Ihre Tarifgrenzwerte anhand der neuen Verkehrsdaten neu ausgleichen und im Log-Modus die Notfallregeln, die sich als korrekt erwiesen haben, beibehalten, falls Sie nicht wollen, dass sie kontinuierlich durchgesetzt werden.

WAF- und Zugriffsprotokolle analysieren

Überwachen Sie den Datenverkehr mit Azure WAF-Protokollen auf Anomalien und nutzen Sie diese, um verdächtige IP-Adressen zu identifizieren, die ungewöhnlich viele Anfragen, ungewöhnliche User-Agent-Strings oder anomale Abfragestring-Muster senden.

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure Application Gateway

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

Top-Talker und Top-User Agents über das Angriffsfenster (Azure Front Door gezeigt; Ersatz ApplicationGatewayAccessLog für 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

Weitere Informationen finden Sie unter Azure WAF mit Azure Front Door und Azure WAF mit Azure Application Gateway.

Verwandte Inhalte

  • Last updated on