Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: ✔️ Front Door Premium
HTTP-Layer-Überschwemmungen bleiben der häufigste Treiber für Anwendungsverfügbarkeitsvorfälle, und statische Kontrollen wie IP- und Geofilter oder feste Ratenlimits können oft nicht mit verteilten Botnets Schritt halten. Das HTTP-DDoS-Regelwerk ist das automatisierte Layer-7-Schutzmodell der Azure Web Application Firewall (WAF), das mit minimaler Benutzerkonfiguration lernt, erkennt und schützt. Nach der Zuweisung erstellt das Regelwerk kontinuierlich eine Basislinie für den normalen Datenverkehr für jedes Azure Front Door-Profil und wehrt, wenn Anstiege auf einen Angriff hinweisen, selektiv schädlichen Datenverkehr ab, ohne dass eine Notfallanpassung erforderlich ist.
Funktionsweise des HTTP-DDoS-Regelets
Sobald das HTTP-DDoS-Regelwerk auf eine Policy angewendet wird, die an ein Azure Front Door Premium-Profil angehängt ist, werden die Verkehrsbaselines mittels eines rollenden Fensters berechnet. Für Profile, die an mindestens 50 % der vergangenen sieben Tage Traffic erhalten haben, berechnet das Regelwerk die Basiswerte und beginnt, innerhalb von 24 bis 36 Stunden Spitzen zu erkennen. Wenn das Front Door-Profil nicht genügend Verkehr erhalten hat (weniger als 50 % des Verkehrsaufkommens der letzten sieben Tage), erkennt oder mindert das Regelwerk Angriffe erst, wenn genügend Verkehr vorhanden ist, um verlässliche Basislinien zu etablieren.
Anforderungsschwellenwerte werden auf globaler Profilebene gelernt. Wenn eine einzelne WAF-Richtlinie, die mit dem HTTP-DDoS-Regelsatz konfiguriert ist, mehreren Azure Front Door-Profilen zugewiesen ist, werden Datenverkehrsschwellenwerte für jedes Profil, an das die Richtlinie angefügt ist, separat berechnet.
Das Regelwerk verwendet ein zweistufiges Design. Es lernt eine globale Profilschwelle sowie engere Schwellenwerte für einzelne Client-IP-Adressen und mit den Geo-Regeln für jedes Land/jede Region. Solange die Profilschwelle für Anfragen nicht überschritten wird, werden die engeren Schwellenwerte nicht durchgesetzt. Dieser Ansatz verhindert, dass das Regelwerk auf Lastspitzen einiger Clients wirkt, es sei denn, sie führen dazu, dass die gesamte Anfragerate im Profil die Schwelle überschreitet.
Jede Regel im HTTP-DDoS-Regelet bietet drei Vertraulichkeitsstufen, die jeweils einem anderen Schwellenwert entsprechen. Eine höhere Vertraulichkeitseinstellung wendet einen niedrigeren Schwellenwert für diese Regel an, während eine niedrigere Vertraulichkeitseinstellung einen höheren Schwellenwert anwendet. Die Standardeinstellung und die empfohlene Einstellung ist mittlere Empfindlichkeit.
Wenn du das Regelwerk zuweist, werden seine Regeln standardmäßig mit der Log-Aktion und der mittleren Empfindlichkeit aktiviert. Überprüfen Sie die Protokolle und passen Sie dann die Aktion jeder Regel an Ihre Anwendung an.
Das HTTP-DDoS-Regelet ist das erste von Azure WAF ausgewertete Regelet, auch vor den benutzerdefinierten Regeln.
Von Bedeutung
Alle benutzerdefinierten Regeln, die mit der Aktion „Erlauben“ konfiguriert sind, umgehen das HTTP-DDoS-Regelwerk nicht, umgehen aber alle anderen WAF-Inspektionen. Um vertrauenswürdigen Datenverkehr vom HTTP DDoS-Regelwerk auszuschließen, verwenden Sie exceptions.
Das Straffeld
Sobald die Profil-Schwelle überschritten wird, wird jede Client-IP-Adresse, die ihre Schwelle für Regel 500100 oder 500110 überschreitet, in eine Sperrliste gesetzt. Während sich die IP-Adresse im Sperrbereich befindet, wendet das WAF die von der Regel konfigurierte Aktion auf seine Anfragen an. Wenn die Sperrfrist endet, wird die IP-Adresse wieder normal bewertet und kehrt in die Sperrfrist zurück, wenn sie erneut ihren Schwellenwert überschreitet.
Regelsetregeln
Das HTTP DDoS-Regelset erscheint als Microsoft_HTTPDDoSRuleSet_1.0 in den verwalteten Regeln Ihrer WAF-Richtlinie und besteht aus vier Regeln. Jede Regel führt separate Traffic-Baselines für den Datenverkehr, der ihren Kriterien entspricht, und jede ist mit eigener Empfindlichkeit und Maßnahme konfigurierbar.
| Regel-ID | Regel | Was es als Basis festlegt | Status |
|---|---|---|---|
| 500100 | Anomalie bei hoher Anzahl von Client-Anfragen erkannt | Anfragen von jeder einzelnen Client-IP-Adresse | Allgemein verfügbar |
| 500110 | Mutmaßliche Bots senden eine hohe Anfragerate | Anfragen von IP-Adressen, die von Microsoft Threat Intelligence als Bots eingestuft werden | Allgemein verfügbar |
| 500310 | Anomalie bei hoher Anfragerate aus Herkunftsregionen mit hohem Volumen erkannt | Anfragen aus allen Ländern/Regionen mit hohem Anfragevolumen | Preview |
| 500320 | Anomalie aufgrund einer hohen Anfragerate von Quellgeos mit geringem Volumen erkannt | Kombinierte Anfragen aus jedem anderen Land/jeder anderen Region | Preview |
Regel 500100: Anomalie aufgrund einer hohen Rate von Client-Anfragen erkannt: Diese Regel verfolgt den gesamten Verkehr auf dem Profil, an das eine Richtlinie angehängt ist, und legt dafür eine Baseline fest. Wenn ein Client den festgelegten Schwellenwert überschreitet, wird die entsprechende konfigurierte Aktion ausgelöst.
Regel 500110: Mutmaßliche Bots, die eine hohe Anfragerate senden: Diese Regel erlaubt es, verschiedene Empfindlichkeitsstufen basierend auf Datenverkehr festzulegen, der von Microsoft Threat Intelligence als Bots klassifiziert wird. Bei verdächtigen Bots ist der Standardschwellenwert strenger als der Standardschwellenwert für alle anderen IP-Adressen. Bots, die als hohes Risiko klassifiziert sind, werden sofort durch diese Regel blockiert, wenn der globale Profilschwellenwert verletzt wird.
Die Regeln 500310 und 500320 sind die Geo-Regeln, die im nächsten Abschnitt beschrieben werden.
Geo-Regeln (Vorschau)
Von Bedeutung
Die Geo-Regeln im HTTP DDoS-Regelwerk, Regeln 500310 und 500320, befinden sich derzeit in der Vorschau. Der Rest des HTTP DDoS-Regelwerks ist allgemein verfügbar. Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.
Per-IP Schwellenwerte funktionieren gut gegen Angriffe, bei denen jeder Client eine große Anzahl von Anfragen sendet. Sie sind weniger effektiv gegen stark verteilte Angriffe, bei denen ein Botnet seinen Datenverkehr über so viele IP-Adressen verteilt, dass jede unter ihrem eigenen Schwellenwert bleibt. Die Geo-Regeln fügen eine zweite Verteidigungsschicht hinzu, die den Datenverkehr nach Land/Region statt nach Client als Basis einordnet.
Wie die Geo-Regeln funktionieren
Die meisten Anwendungen erhalten den Großteil ihres legitimen Datenverkehrs aus wenigen Ländern oder Regionen mit hohem Datenverkehrsaufkommen. Die Geo-Regeln verwenden dieses Muster:
- Regel 500310 lernt für jedes Land oder jede Region mit hohem Volumen einen eigenen Schwellenwert.
- Regel 500320 ermittelt für jedes andere Land oder jede Region einen gemeinsamen Schwellenwert. Anfragen von all diesen Quellen mit geringem Volumen werden gemeinsam auf diesen einen Schwellenwert angerechnet.
Angenommen, der Großteil des Traffics eines Profils kommt aus den Vereinigten Staaten, Australien und Frankreich. Regel 500310 lernt für jeden dieser drei einen Schwellenwert, und Regel 500320 lernt einen Schwellenwert für den kombinierten Datenverkehr von überall sonst. Während eines Angriffs wird ein Anstieg des Datenverkehrs aus den USA am US-Schwellenwert gemessen, während ein Angriff, der dünn auf viele andere Standorte verteilt ist, gegen die kombinierte Schwelle gemessen wird.
Die Geo-Regeln folgen demselben zweistufigen Design wie der Rest des Regelwerks: Sie wirken erst, nachdem die Gesamtanforderungsrate des Profils die gelernte Schwelle überschritten hat. Wenn dies geschieht und die Anfragerate aus einem Land oder einer Region mit hohem Aufkommen die Schwelle überschreitet, wendet Regel 500310 ihre Maßnahme auf Anfragen aus diesem Land oder dieser Region an. Wenn die kombinierte Anfragerate aus allen anderen Ländern oder Regionen ihren Schwellenwert überschreitet, wendet Regel 500320 ihre Maßnahme auf Anfragen von all diesen Quellen mit geringem Volumen an.
Behalte folgende Verhaltensweisen im Hinterkopf:
- Die Geo-Regeln lernen ihre Ausgangswerte aus ungefähr den letzten sieben Tagen Datenverkehr und berechnen sie regelmäßig neu, sodass sie Veränderungen im Datenverkehr im Laufe der Zeit verfolgen.
- Die Schwellenwerte spiegeln Ihren Spitzenverkehr wider und nicht den Durchschnitt, sodass die normalen täglichen Spitzen darunter bleiben.
- Anfragen von IP-Adressen, die nicht einem Land oder einer Region zugeordnet sind, werden als unbekanntes Land oder Region (ZZ) gruppiert und wie jedes andere Land oder jede andere Region als Baseline behandelt.
- Wenn ein Profil nicht genug Verkehrshistorie hat, um verlässliche Baselines zu lernen, ergreifen die Geo-Regeln keine Maßnahmen für dieses Profil.
- Die Geo-Regeln werden nach Regel 500100 bewertet. Clients, die ihre eigenen Pro-IP-Schwellenwerte überschreiten, werden zuerst von der Pro-IP-Regel behandelt, und die Geo-Regeln wirken dann auf verteilten Datenverkehr, der unter den Pro-IP-Schwellenwerten bleibt.
Wähle Aktionen und Empfindlichkeitseinstellung für die Geo-Regeln
Eine Geo-Regel gilt für den Datenverkehr aus einem Land oder einer Region insgesamt, nicht für einzelne Kunden. Wenn eine Geo-Regel übereinstimmt, gilt ihre Maßnahme sowohl für legitime Nutzer in diesem Land oder dieser Region als auch für bösartigen Datenverkehr. Plane das vor, bevor du die Standardaktion änderst:
- Beginnen Sie mit der Aktion „Log“. Die Geo-Regeln werden standardmäßig mit der Log-Aktion aktiviert. Überprüfen Sie die Protokolle für den normalen Datenverkehr und etwaige Spitzen, bevor Sie sie anwenden.
- Bevorzuge eine Herausforderung gegenüber einer Blockierung. Eine JavaScript-Prüfung lässt legitime Browser durch, während die meisten geskripteten Clients gestoppt werden, was die Auswirkungen auf echte Nutzer im betroffenen Land oder in der betroffenen Region einschränkt.
- Senken Sie die Empfindlichkeit für erwartete regionale Spitzen. Wenn Sie einen legitimen Anstieg aus einem bestimmten Land oder einer Region erwarten, zum Beispiel während einer regionalen Kampagne oder Produkteinführung, reduzieren Sie die Empfindlichkeit der betroffenen Regel vor dem Ereignis.
Vertrauenswürdigen Verkehr vom Regelwerk ausnehmen
Eine benutzerdefinierte Regel mit einer Zulassen-Aktion umgeht das HTTP-DDoS-Regelwerk nicht. Um bekannten Datenverkehr wie Health-Probes, synthetisches Monitoring, Lasttests oder Partnerintegrationen das Regelwerk umgehen zu lassen, verwenden Sie WAF-Ausnahmen. Man kann eine Ausnahme für eine bestimmte Regel im HTTP DDoS-Regelwerk oder für das gesamte Regelwerk festlegen und anhand der Remote-IP-Adresse, der Request-URI oder eines Request-Headers abgleichen.
Fassen Sie Ausnahmen so eng wie möglich. Wenn ein Lasttest-Tool zum Beispiel nur eine Ausnahme von Regel 500100 benötigt, sollte man es nicht von den anderen Regeln im Regelwerk ausnehmen.
Überwachen des HTTP DDoS-Regelsatzes
Für das HTTP DDoS-Regelwerk stehen folgende Überwachungsoptionen zur Verfügung:
- Wenn eine IP-Adresse erstmals eine Schwelle für Regel 500100 oder 500110 überschreitet, wird für diese IP-Adresse mit der Aktion der Regel ein Logeintrag erfasst, und die WAF-verwaltete Regel-Match-Metrik wird erhöht.
- Sie können Regelübereinstimmungen überwachen, indem Sie die Web Application Firewall Request Count Metrik verwenden und nach Regelnamen filtern. Geo-Regel-Matches werden unter den Regel-IDs 500310 und 500320 erfasst.
- Die Metrik Web Application Firewall HTTPDDoSRuleset Is Active hat den Wert
1, sobald das Regelsystem das Lernen abgeschlossen hat und bereit ist, auf Verkehr zu reagieren, der die gelernten Schwellenwerte überschreitet.