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 ab, den die darüberliegende Ebene nicht abfängt.

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 in den Präventionsmodus um. 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 den HTTP-DDoS-Regelsatz zu (verfügbar sowohl in Azure Front Door Premium als auch in Application Gateway WAF v2), damit die automatisierte Abwehr Ihr normales Datenverkehrsmuster erlernt, 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. Decken Sie Ihre L3/L4-Abdeckung 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, wenn Sie eine Bereitstellung wählen oder entwerfen:

• 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 Ihnen offengelegten öffentlichen Ursprungs-IP-Adressen weiterhin Azure DDoS Network Protection sowie eine strikte Zugriffsbeschränkung, 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 Übersicht über Azure DDoS Protection und Schützen Sie Ihr Application Gateway mit 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, erstellt sie fortlaufend ein Basisprofil des normalen Datenverkehrs und blockiert, wenn Verkehrsspitzen auf einen Angriff hindeuten, selektiv auffällige Clients, ohne dass eine Notfallanpassung 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.
• Auf die jeweilige Ressource beschränkt. 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 Standard- und empfohlene Einstellung.
• Reihenfolge der Auswertung 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 Vertrauenswürdigen Datenverkehr mit Ausnahmen ausnehmen.
• Erfordert anhaltenden Verkehr. Das Regelwerk kann erst handeln, wenn es verlässliche Basislinien gelernt hat. Wenn eine Ressource während der Lernphase nicht genügend Datenverkehr erhält, erkennt oder schützt das Regelwerk sie nicht, bis sie genügend Datenverkehr erhält. Siehe die Plattformtabelle für die spezifische Anforderung.

Plattformunterschiede

Regelsatzregeln

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

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 wichtig dafür, wie du deine Telemetriedaten auswertest: nur die erste Regelübereinstimmung 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 einen Schwellenwert überschreitet, wird für das HTTP-DDoS-Regelwerk ein Protokolleintrag mit der Aktion Block aufgezeichnet, und die WAF-Metrik Managed Rule Match wird erhöht.

• 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 weitere blockierte Anforderung von einer mit einer Strafe belegten IP-Adresse erhöht die Metrik „Managed Rule Match“, und die Metriken Penalty box size und Penalty box blocks erfassen den Strafbereich direkt.

Vertrauenswürdigen Datenverkehr durch 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 entsprechen:

• Entfernte IP-Adresse (Equals oder IP Match), die übliche Wahl ist, um bekannte Überwachungs-, Lasttest- oder Partnerquellenbereiche vom DDoS-Regelwerk auszuschließen
• Anforderungs-URI
• Name und Wert des Request-Headers, abgeglichen mit „Gleich“, „Beginnt mit“, „Endet mit“ oder „Enthält“

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 weit gefasste Ausnahme bietet einem Angreifer einen dokumentierten Weg zur Umgehung Ihrer automatisierten Gegenmaßnahme. Wenn ein Lastgenerator nur eine Ausnahme von Regel 500100 benötigt, befreie ihn nicht auch von 500110.
• Quellen ausnehmen, nicht Pfade. 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 planmäßig. 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.

Anfechten, bevor Sie blockieren

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 die Mitwirkung der Nutzer erfordert und am besten kritischen Abläufen wie Anmeldung, Registrierung und Checkout vorbehalten ist, bei denen automatisierter Missbrauch teuer ist und ein paar Sekunden zusätzlicher Aufwand für Nutzer 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.

Berücksichtige bei der Planung die Einschränkungen beider Funktionen, bevor du sie bereitstellst:

• AJAX- und API-Aufrufe werden nicht unterstützt. Stellen Sie keine Herausforderungen vor API-Routen. Verwende dort stattdessen Regeln zur Ratenbegrenzung und Abgleichsregeln.
• 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 bewirken ebenfalls eine stärkere Annäherung an den konfigurierten Schwellenwert. 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.
• Regeln zur Ratenbegrenzung unterstützen nur die Aktionen Log und Block; Allow wird nicht unterstützt.
• Wenden Sie eine Regel auf den gesamten Datenverkehr an, indem Sie einen Host-Header mit einer Länge von mehr als 0 abgleichen, da jede gültige Anforderung an Azure Front Door einen solchen Header aufweist.

Anwendungsgateway WAF v2

• Die Ratenbegrenzung verwendet einen Algorithmus für das Sliding-Window . Der gesamte entsprechende Datenverkehr wird im ersten Fenster verworfen, in dem der Schwellenwert überschritten wird. Ab dem zweiten Zeitfenster ist Datenverkehr bis zum Schwellenwert zulässig, was für entsprechende Clients zu einer Drosselung anstelle eines vollständigen Ausfalls führt.

• 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 beschrieben, unter Verwendung 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

• Regeln zur Ratenbegrenzung setzen die neueste WAF-Engine voraus (für den Standardregelsatz muss CRS 3.2 oder höher ausgewählt werden) und werden in isolierten Clouds nicht unterstützt.

• Application Gateway zählt die Schwellenwerte unabhängig für jeden Endpunkt , an den die Policy angeschlossen ist. Eine einzelne Richtlinie mit fünf Listenern verwaltet fünf Sätze von Zählern.

• 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 Regeln mit breiter Übereinstimmung, die GeoLocation oder None verwenden; ein schlecht gewählter Schwellenwert kann zu häufigen kurzen Ausfällen für legitimen Datenverkehr 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:

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

• Application Gateway WAF v2 - verwenden Sie GroupByVariable: GeoLocation (oder GeoLocationXFFHeader hinter einem CDN oder Proxy), damit der gesamte Datenverkehr aus einer geografischen Region denselben Zähler verwendet, und erstellen Sie pro Stufe eine Rate-Limit-Regel mit eigenem Schwellenwert. Da ein Verstoß jeden Client in dieser Region betrifft, sollten diese Schwellenwerte konservativ festgelegt und zunächst mit der Aktion „Log“ validiert werden: Eine falsch konfigurierte, weit gefasste Geo-Regel kann häufige kurze Ausfälle für legitimen Datenverkehr verursachen.
• Azure Front Door – die Zählung erfolgt pro Socket-IP-Adresse. Konfigurieren Sie die Tiers daher stattdessen mit Geo-Match-Bedingungen: eine Rate-Limit-Regel pro Tier, die mit den jeweiligen Ländern abgeglichen wird, jeweils 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:

• Ordnen Sie die Regeln von der spezifischsten zur allgemeinsten: Regeln für den Primärmarkt haben die höchste Priorität (niedrigerer Zahlenwert), gefolgt von Regeln für den Sekundärmarkt und den „Long-Tail“-Bereich; die globale Auffangregel bildet die Rate-Limit-Regel mit der niedrigsten Priorität.
• 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 während eines Vorfalls auf das gegenteilige Signal: Wenn ein Land, das normalerweise 1 % des Traffics ausmacht, plötzlich 40 % ausmacht, ist das eine der schnellsten Möglichkeiten, um zu bestätigen, dass Sie einen Angriff und nicht organisches Wachstum beobachten.

Wählen Sie einen Schwellenwert auf Grundlage Ihres eigenen Datenverkehrs

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 geografiespezifischen Schwellenwerte zu dimensionieren, fügen Sie der gleichen Abfrage das Land 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. Der Höchstwert stammt meist von einem Crawler oder einem falsch konfigurierten Client, und wenn man die Regel danach bemisst, ist sie zu großzügig, um während eines Angriffs hilfreich zu sein.

Benutzerdefinierte Regeln für gezielte Risikominderung

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 den Abgleich von Zeichenfolgen hinaus können benutzerdefinierte WAF-Regeln in Azure Front Door Folgendes abgleichen:

• 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, von der sie senden, einen konsistenten Fingerabdruck erzeugen, ist JA4 bei einem verteilten Angriff eine der beständigsten verfügbaren Signaturen: Selbst der Wechsel zwischen Tausenden von Quell-IP-Adressen verändert den Fingerabdruck nicht, und durch Blockieren oder Ratenbegrenzung auf dieser Grundlage lässt sich das gesamte Botnet mit einer einzigen Regel außer Gefecht setzen. Gleiche den Fingerabdruck mit deinen Protokollen aus Friedenszeiten ab, 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 Log-Aktion bereitstellen, sicherstellen, dass der Fingerabdruck nur im Angriffsverkehr erscheint, und dann zu „Block“ oder zu einer Rate-Limit-Regel wechseln.
• Kombinieren Sie JA4 mit anderen Bedingungen für chirurgische Maßnahmen zur Schadensbegrenzung während eines Vorfalls. Zum Beispiel sollten Sie lieber eine Ratenbegrenzung für einen bestimmten JA4-Fingerabdruck und ein ASN anwenden, aus dem Sie keine Nutzer bedienen, oder für einen JA4-Fingerabdruck und eine Anfrage-URI, anstatt diese zu blockieren.
• Service-Tag und Größenbeschränkungen für Anfragekomponenten.

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

• Erstellen Sie Zulassen-Abgleichsregeln für bekanntermaßen legitimen Datenverkehr, um Fehlalarme zu reduzieren, und geben Sie ihnen eine höhere Priorität (einen niedrigeren numerischen Wert) als Ihren Sperr- und Regeln zur Ratenbegrenzung. Beachten Sie, dass eine Zulassungsregel andere WAF-Prüfungen umgeht, jedoch nicht das HTTP-DDoS-Regelwerk außer Kraft setzt.
• Die Regelbewertung wird bei jeder Aktion außer Log beendet, 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 fangen Lastspitzen am Netzwerkrand ab und verringern die Anfragerate, die Ihren Ursprungsserver erreicht, was oft den Unterschied zwischen beeinträchtigter Leistung und einem Ausfall ausmacht.
• Skalieren Sie Ursprünge mit Reserve. 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üfen Sie, was bereits zur Minderung beiträgt. Bestätigen Sie, dass das HTTP DDoS-Regelwerk aktiv ist, und überprüfen Sie seine Blöcke nach Regelnamen. Im Application Gateway prüfen Sie auch die Metriken Größe des Strafbereichs und Sperren im Strafbereich, da nur die erste Sperre pro IP-Adresse in den Protokollen angezeigt wird. Überprüfen Sie die Übereinstimmungen 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. Hinterfragen statt blockieren bei gemischtem Verkehr. 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. Stelle es zuerst für die Protokollaktion bereit, wenn das Muster auch auf echte Nutzer zutrifft.
7. Schützen Sie den Ursprungsserver, während Sie Optimierungen vornehmen: Vergewissern Sie sich, dass das Caching aktiviert ist, bestätigen Sie, dass der Zugriff auf den Ursprungsserver eingeschränkt ist, und skalieren Sie horizontal.
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"

Hauptverursacher und häufigste User-Agents während des Angriffszeitfensters (Azure Front Door hier dargestellt; ersetzen Sie ApplicationGatewayAccessLog durch 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

• HTTP-DDoS-Regelsatz: Azure Front Door WAF | Application Gateway WAF
• Liste der WAF-Ausnahmen: Azure Front Door WAF | Application Gateway WAF
• Ratenbegrenzung: Azure Front Door WAF | Application Gateway WAF
• WAF setup: Azure Front Door | Application Gateway
• Azure WAF JavaScript-Herausforderung
• Azure Front Door WAF CAPTCHA
• DDoS-Schutz für Azure Front Door
• Referenzarchitekturen für Azure DDoS Protection
• Azure DDoS Protection: Übersicht