Schutzregeln optimieren

Verwenden Sie Web Application Firewall für das Tuning von Schutzregeln.

In diesen allgemeinen Informationen zur WAF-Optimierung werden die Grundlagen der Regeloptimierung, der Logprüfung und der Einrichtung von Regelausschlüssen beschrieben. Das Optimieren einer WAF-Policy kann aus folgenden Gründen von Vorteil sein:

Es reduziert die Chance, eine legitime Anforderung zu blockieren.
Es schützt vor standardmäßigen Webanwendungsangriffen.
Es schützt vor spezifischen Webanwendungsangriffen.
Es reduziert die Anzahl der Scans und führt somit zu einer besseren Performance.

Die folgende Tabelle enthält Begriffe und Definitionen für Produktionsregeln.

Definitionen von Schutzregeln
Begriff	Definition
Optimierung	Der Prozess, bei dem ein Techniker oder Analyst Schutzregeln und -aktionen ändert, um den Anwendungsserver zu schützen, ohne seine Funktionsfähigkeit zu beeinträchtigen. Die beiden Ziele, den Anwendungsserver einerseits zu sperren und ihn andererseits seine Aufgaben ausführen zu lassen, halten sich dabei die Waage. Die beste Optimierung erfordert umfassende Kenntnisse über den zu schützenden Anwendungsserver und die Regeln, die zu seinem Schutz verfügbar sind.
Falsch positives Ergebnis	Ein falsch positives Ergebnis tritt auf, wenn eine Schutzregel mit einer HTTP-Transaktion übereinstimmt und die HTTP-Transaktion eine legitime (nicht böswillige) Transaktion ist.
Ausschluss	Eine Änderung einer Schutzregel, mit der der Wert oder Wertname eines Cookies oder HTTP-Arguments ignoriert werden kann.
Oracle Recommendation Engine (ORE)	ORE unterstützt Sie bei der Optimierung Ihres WAF-Sicherheitsprofils, indem Sie alle Regeln aktivieren, die während eines anfänglichen Empfehlungszeitraums nicht ausgelöst werden.

Überblick über WAF-Schutzregeln

WAF schützt Ihre Webanwendungen vor Bedrohungen. WAF ist cloudbasiert und unterstützt über 500 Regelsets sowie Regelsets für das Open Web Application Security Project (OWASP). Verwenden Sie diese Regeln, um Ihre kritischen Webanwendungen vor böswilligen Cyberangriffen zu schützen. Diese Regeln werden mit eingehenden Anforderungen verglichen, um zu bestimmen, ob die Anforderung eine Angriffs-Payload enthält. Wenn festgestellt wird, dass es sich bei einer Anforderung um einen Angriff handelt, blockiert WAF diese Anforderung oder warnt Sie davor. Diese Angriffe sind vielfältig und umfassen Bedrohungen wie SQL-Injection, Cross-Site Scripting und HTML-Injection, die alle mit den WAF-Regelsets erkannt und blockiert werden können.

WAF-Schutz ist ein Toolkit, das für Monitoring, Logging und Zugriffskontrolle von Webanwendungen in Echtzeit konzipiert wurde. Mit dem Toolkit können Sie entscheiden, wie Sie alle verfügbaren Schutzregeln nutzen möchten. Diese Flexibilität ist ein zentrales Element der WAF-Schutzregeln, da wir ständig Updates veröffentlichen, um den Sicherheitsumfang unserer Regeln zu erhöhen.

Hinweis

WAF-Schutzregeln fügen jeder Transaktion zusätzliche CPU-Zyklen hinzu. Daher empfehlen wir, nur die Regeln zu aktivieren, die für Ihre Webanwendungstopologie entworfen wurden.

Um Angriffe zu identifizieren und Webanwendungen davor zu schützen, führen WAF-Schutzregeln Prüfungen bei allen Anforderungen an den Webserver und allen zugehörigen Antworten vom Server unter Verwendung des Regelsets aus. Nachdem die Prüfungen erfolgreich abgeschlossen wurden, wird die HTTP-Anforderung an die Website gesendet, um den relevanten Inhalt abzurufen. Wenn Prüfungen stattdessen nicht erfolgreich sind, werden die entsprechenden vordefinierten Aktionen initiiert.

Kernprinzipien der WAF-Schutzregeln:

Passivität: Sie entscheiden, welche Regeln erforderlich sind. Daher haben Sie die volle Kontrolle.
Flexibilität: WAF-Schutzregeln wurden von einem Sicherheitsexperten erstellt, der über 250 Regeln und die Möglichkeit zur Einführung benutzerdefinierter Schutzregeln bereitgestellt hat.
Qualität, nicht Quantität: WAF-Schutzregeln sind ein dediziertes Modul für die Prüfung von HTTP-Traffic, das mit den anderen WAF-Features (z.B. Zugriffskontrolle und Botverwaltung) zusammenarbeitet.
Vorhersagbarkeit: Sie haben vollständige Kontrolle über die WAF-Schutzregeln und können so die erwarteten Ergebnisse kontrollieren. Sie können Ihre Schutzregeln definieren und optimieren und das Setup unbeaufsichtigt ablaufen lassen, da Sie wissen, dass weiter wie konfiguriert funktioniert.

Onboarding und anfängliche Optimierung

Zunächst benötigen Sie Kenntnisse zur Webanwendung für den Optimierungsprozess. Andernfalls könnten Sie Linux-spezifische Regeln für Ihren Windows-Server oder -Ursprung aktivieren und Regeln einrichten, die unnötig Ihren Traffic scannen, was zu einer Performancebeeinträchtigung führt. ORE unterstützt Sie durch die Bereitstellung eines soliden und sicheren Sets aus Schutzregeln. Der Empfehlungszeitraum ist eine konfigurierbare Einstellung mit einem Standardwert von 10 Tagen. Es wird empfohlen, diesen Wert auf 15 Tage zu erhöhen, um ein großes Sample von Logs für normalen Traffic in der Webanwendung abzurufen. Etwa 24 Stunden nach dem Erstellen der WAF-Policy werden Empfehlungen für Schutzregeln auf der Registerkarte "Empfehlungen" angezeigt. Die Empfehlungen sind Regeln, die von WAF-Experten für die OWASP Top Ten ausgewählt werden. Diese empfohlenen Regeln wurden ausgewählt, weil sie in der Regel die geringste Anzahl an falsch positiven Ergebnissen erzeugen und dennoch einen guten Schutz bieten.

Empfehlungszeitraum ändern und Empfehlungen akzeptieren

Mit den folgenden Schritten aktivieren Sie die empfohlenen Regeln im Ermittlungsmodus. Wenn sich die Regeln im Ermittlungsmodus befinden, empfehlen wir, 15 Tage zu warten, bevor Sie sie in den Blockiermodus versetzen.

Hinweis

Während des Bewertungszeitraums befinden sich alle Regeln im Ermittlungsmodus. Im Ermittlungsmodus erfolgt keine Blockierung durch Schutzregeln. Wir empfehlen, Benutzerakzeptanztests durchzuführen und die Anwendung normal zu verwenden, um den Optimierungsprozess durch Generieren von Logs zu unterstützen. Prüfen Sie die Logs, und suchen Sie nach falsch positiven Werten, während sich die Regeln im Ermittlungsmodus befinden. Indem Sie Logs prüfen, die für Schutzregeln ausgelöst werden, können Sie erkennen, welcher Traffic eine Blockierung verursachen würde, wenn die Regeln in den Blockiermodus versetzt werden. Während des Bewertungszeitraums sollte die Anwendung soweit wie möglich mit normalem oder produktionsähnlichem Traffic ausgeführt werden. Im normalen Traffic wird über Logs angezeigt, welche Regeln ausgelöst werden. Falsch positive Ergebnisse können somit herausgefiltert werden.

So ändern Sie den Empfehlungszeitraum:

Öffnen sie das Navigationsmenü , und wählen Sie Identität und Sicherheit aus. Wählen Sie unter Web Application Firewall die Option Edge Policy-Ressourcen aus.
Die Liste Policys wird geöffnet. Alle Edge Policys werden in einer Tabelle aufgeführt.
Wählen Sie die Edge Policy aus, für die Sie Regeleinstellungen konfigurieren möchten.
Die Detailseite der Edge Policy wird geöffnet.
Wählen Sie Schutzregeln aus.
Der Bereich Schutzregeln wird geöffnet.
Klicken Sie auf das Register Einstellungen.
Wählen Sie Regeleinstellungen bearbeiten.
Der Bereich "Regeleinstellungen bearbeiten" wird geöffnet.
Erhöhen Sie den Empfehlungszeitraum von 10 auf 15 Tage.
Wählen Sie Änderungen speichern aus.

So akzeptieren Sie die Empfehlungen

Öffnen sie das Navigationsmenü , und wählen Sie Identität und Sicherheit aus. Wählen Sie unter Web Application Firewall die Option Edge Policy-Ressourcen aus.
Die Liste Policys wird geöffnet. Alle Edge Policys werden in einer Tabelle aufgeführt.
Wählen Sie die Edge Policy aus, für die Sie Regeleinstellungen konfigurieren möchten.
Die Detailseite der Edge Policy wird geöffnet.
Wählen Sie Schutzregeln aus.
Der Bereich Schutzregeln wird geöffnet.
Wählen Sie die Registerkarte Empfehlungen.
Der Bereich Empfehlungen wird geöffnet.
Wählen Sie Empfehlungen akzeptieren aus.
Wählen Sie Nicht veröffentlichte Änderungen aus.
Wählen Sie Alle veröffentlichen aus.
Wählen Sie im Bereich Änderungen veröffentlichen die Option Alle veröffentlichen aus.

Mit der API bestimmte Logs abfragen

Die API bietet die meisten Optionen zum Filtern von Regeln. Im Folgenden finden Sie Beispiele für die Verwendung der CLI zum Filtern von Logs.

So filtern Sie Logs nach Schutzregel-ID:

oci waas waf-log list --waas-policy-id <WASS Policy OCID> --protection-rule-key <protection rule id number>

So filtern Sie Logs nach Regeltyp (z.B. Schutz- oder Zugriffsregeltyp):

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type PROTECTION_RULES
oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --log-type ACCESS

So filtern Sie Logs nach Anforderungs-URL:

oci waas waf-log list --waas-policy-id <WAAS Policy OCID> --request-url <request url>

Log Analytics einrichten

Mit Log Analytics können Sie die Schutzregeln eingrenzen, die bearbeitet werden müssen. Verwenden Sie die folgenden Informationen, um den Log Analytics-Service mit WAF einzurichten. Weitere Informationen finden Sie unter Security Insights für Ihre Webanwendungen mit OMC Log Analytics.

Ausschlüsse in Schutzregeln erstellen

Die Prüfung von Logs ist ein wichtiger Bestandteil des Optimierungsprozesses. Logs zeigen an, welche Regel abgeglichen wurde und mit welchem Teil der HTTP-Transaktion sie abgeglichen wurde. In der folgenden Tabelle finden Sie Beispiele für Logs und deren Verwendung zum Erstellen eines Ausschlusses.

Das Objekt protectionRuleDetections in WafLog bietet eine Zuordnung von Schutzregelschlüsseln zu Details von Ermittlungsmeldungen. Die folgende Tabelle enthält vier mögliche Ausschlüsse, die für eine Schutzregel eingerichtet werden können.


Logwert	Ausschlusswert	Beschreibung
ARGS	Anforderungsparameter	Wird für Werte eines bestimmten Arguments verwendet.
ARGS_NAMES	Namen von Anforderungsparametern	Wird für den Namen des Arguments verwendet.
REQUEST_COOKIES	Werte von Anforderungscookies	Wird für Werte eines bestimmten Cookies verwendet.
REQUEST_COOKIES_NAMES	Namen von Anforderungscookies	Wird für den Namen des Cookies verwendet.

Beispielausschlüsse mit Logs

Der folgende Abschnitt enthält Raw-Logbeispiele sowie Beispiele dafür, welcher Ausschlusswert für jede Regel gelten sollte.

Regel-ID 9411000 - ARGS
In diesem Beispiel wurden die übereinstimmenden Daten (Matched Data) im Argument ARGS:foo gefunden. Der Ausschluss gilt für die Regel-ID 9411000. Der zu erstellende Ausschluss gilt für Anforderungsparameter mit dem Wert foo.
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS:foo: <script>xss"
},
```

Regel-ID 9411000 - ARGS_NAMES
In diesem Beispiel wurden die übereinstimmenden Daten (Matched Data) im Argument ARGS_NAMES gefunden. Der Ausschluss gilt für die Regel-ID 9411000. Der zu erstellende Ausschluss gilt für Anforderungsparameternamen mit dem Wert <script>xss.
```
"protection-rule-detections": {
 "9411000": {
  "Message": "detected XSS using libinjection.",
  "Message details": "Matched Data: found within ARGS_NAMES:<script>xss: <script>xss"
},
```

Regel-ID 9411100

In diesem Beispiel wurden die übereinstimmenden Daten (Matched Data) im Argument REQUEST_COOKIES:a gefunden. Der Ausschluss gilt für die Regel-ID 9411100. Der zu erstellende Ausschluss gilt für Anforderungscookiewerte mit dem Wert a.

"protection-rule-detections": {
 "9411100": {
  "Message": "Pattern match \"(?i)([<\\xef\\xbc\\x9c]script[^>\\xef\\xbc\\x9e]*[>\\xef\\xbc\\x9e][\\\\s\\\\S]*?)\" at REQUEST_COOKIES:a.",
  "Message details": "Matched Data: <script> found within REQUEST_COOKIES:a: <script>xss"
},

So erstellen Sie Ausschlüsse

Öffnen sie das Navigationsmenü , und wählen Sie Identität und Sicherheit aus. Wählen Sie unter Web Application Firewall die Option Edge Policy-Ressourcen aus.
Die Liste Policys wird geöffnet. Alle Edge Policys werden in einer Tabelle aufgeführt.
Wählen Sie die Edge Policy aus, für die Sie Regeleinstellungen konfigurieren möchten.
Die Detailseite der Edge Policy wird geöffnet.
Wählen Sie Schutzregeln aus.
Der Bereich Schutzregeln wird geöffnet.
Wählen Sie das Register Regeln.
Suchen Sie die Schutzregel, auf die Sie eine Aktion anwenden möchten.
Wählen Sie das Menü Aktionen (drei Punkte), und wählen Sie Ausschlüsse. Schließen Sie die Ausschlüsse mit den Informationen aus dem vorherigen Abschnitt "Beispielausschlüsse mit Logs" ein.
Wählen Sie Änderungen speichern aus.
Wählen Sie Nicht veröffentlichte Änderungen aus.
Wählen Sie Alle veröffentlichen aus.
Wählen Sie im Dialogfeld "Änderungen veröffentlichen" die Option Alle veröffentlichen aus.

Weitere Informationen zu Schutzregeln

Individuelle Schutzregeln und kollaborative Schutzregeln - Vergleich

Um falsch positive Ergebnisse zu begrenzen, gibt es spezielle Schutzregeln, die als "kollaborativ" gekennzeichnet sind. Diese Regelgruppen funktionieren anders als die übrigen Schutzregeln, da sie zur Auswertung des Traffics ein Scoring- und Schwellenwertsystem verwenden. Einzelne Regeln vergleichen Elemente der HTTP-Transaktion mit der Regelsignatur. Wenn eine Übereinstimmung gefunden wird, führt die Regel ihre Aktion aus (z.B. Ermitteln oder Blockieren). Jede der kollaborativen Schutzregeln verwendet eine Gruppe individueller Regeln. Die kollaborativen Schutzregeln erfordern mehrere Übereinstimmungen von Elementen der HTTP-Transaktion mit einzelnen Regeln, um ihre Aktion auszuführen (z.B. Ermitteln oder Blockieren). Damit eine kollaborative Regel ihre Aktion ausführen kann, müssen mindestens drei Elemente der HTTP-Transaktion mit den einzelnen Regeln in der kollaborativen Gruppe übereinstimmen. Nachdem der Ausschluss in der kollaborativen Schutzregelgruppe hinzugefügt wurde, gilt er für alle darin enthaltenen Regeln. Im Folgenden finden Sie eine Liste der IDs von kollaborativen Schutzregeln.

IDs von kollaborativen Schutzregeln

9300000 - Local File Inclusion (LFI) Collaborative Group - LFI Filter Categories
9320000 - Remote Code Execution (RCE) Collaborative Group - UNIX RCE Filter Categories
9320001 - Remote Code Execution (RCE) Collaborative Group - Windows RCE Filter Categories
9330000 - PHP Injection Attacks Collaborative Group - PHP Filters Categories
9410000 - Cross-Site Scripting (XSS) Collaborative Group - XSS Filters Categories
9420000 - SQL Injection (SQLi) Collaborative Group - SQLi Filters Categories

IDs von Prüfungsregeln für Anforderungsbodys

Für die folgenden Regeln müssen Sie die Prüfung von Antwortbodys aktivieren. Beachten Sie, dass die Prüfung des Antwortbodys die Transaktion verzögert, da alle darin enthaltenen Informationen gescannt werden. Aktivieren Sie nur die erforderlichen Regeln.

970014, 90005, 120133, 970008, 970016, 981080, 920020, 920006, 920008, 920010, 920012, 920014, 920016, 920018, 90017, 90018, 90020, 90019, 90014, 90021, 90015, 90016, 920021, 920022, 920023, 90024, 90022, 90023, 970013, 970011, 981177, 981000, 981001, 981003, 970018, 970004, 970904, 970010, 970118, 2100090, 970012, 970903, 970009, 970015, 970902, 981005, 981004, 981007, 981006, 970003, 970002, 950110, 950921, 950922, 90002, 90025, 970021, 970007

Keine Ausnahmeregeln

Die folgenden Regeln erstellen andere Raw-Logwerte als ARGS, ARGS_NAMES, REQUEST_COOKIE und REQUEST_COOKIE_VALUE. Für diese Regeln sind keine Ausschlüsse vorhanden, da die Regeln darauf basieren, ob das Element vorhanden ist oder nicht. Beispiel: Wenn der Content-Type-Header vorhanden ist, besteht die einzige Option zum Ausschließen dieser Regel darin, eine Serviceanfrage bei My Oracle Support zu öffnen, um eine benutzerdefinierte WAF-Regel anzufordern, die eine der folgenden Regeln ausschließt.

960020, 960015, 960009, 950103

Diese Regeln sind leicht zu erkennen, da die Logwerte REQUEST_URI, REQUEST_PROTOCOL und REQUEST_HEADERS lauten.

Weitere Schutzregeln

Die folgende Liste enthält Schutzregeln, die möglicherweise unerwünscht ("noisy") sind. Sie enthält Beschreibungen und Empfehlungen, mit denen Sie nachvollziehen können, womit die Regeln übereinstimmen sollen. Ausschlüsse können nicht auf einige dieser Regeln angewendet werden.


Regel-ID	Regelname	Hinweise
981318	String Termination/Statement Ending	Diese Regel ist wichtig, da sie Alerts für alle Escapezeichen sendet, die in einem Eingabefeld und queryString [ARGS] oder einem Cookie ermittelt wurden. Prüfen Sie die anwendungsseitigen Validierungen, und stellen Sie sicher, dass nur die richtigen Eingabezeichen zulässig sind, z.B. Buchstaben und Zahlen. Wenn ein anderer Eingabewert erforderlich ist, kann ein Ausschluss der Regel in WAF angewendet werden, um den Wert zuzulassen.
960015 960021	Missing Accept Header	Selbst wenn Anforderungen ohne Accept-Header keine Verletzung des HTTP-Protokolls bedeuten, sind Anforderungen ohne Accept-Header meist keine echten Anforderungen. Die Regel kann Alerts für API- oder benutzerdefinierte Anwendungsanforderungen senden. Um den Scan von API- oder benutzerdefinierten Anwendungsanforderungen zu vermeiden, erfassen Sie eine Liste der bekannten Anwendungen, die Traffic senden, und fordern Sie benutzerdefinierte Regeln an. Weitere Informationen finden Sie in RFC 7231, Abschnitt 5.3.2.
960007 960008	Missing Host Header	Wie in RFC 7230, Abschnitt 5.4 beschrieben, muss ein Server mit einem 400-Statuscode (Ungültige Anforderung) auf eine HTTP/1.1-Anforderungsnachricht antworten, die kein Hostheaderfeld enthält, sowie auf jede Anforderungsnachricht, die mehrere Hostheaderfelder oder ein Hostheaderfeld mit einem ungültigen Feldwert enthält. Das ist eine wesentliche Schutzmethode und stellt gleichzeitig sicher, dass WAF-Server richtig identifizieren, für welche WAF-Policy die Anforderung gedacht ist. Da WAF einen Hostheader benötigt, um Traffic an den richtigen Ursprung zu übergeben, kann diese Regel eine hohe Rate an falsch positiven Ergebnissen verursachen.
960009 960006	Missing User-Agent Header	Diese Regel verhindert, dass nicht identifizierte Benutzer auf Ihre Webanwendung zugreifen. User-Agent ist einer der Anforderungsheader, die in verschiedenen RFCs definiert sind, und stellt Benutzerinformationen bereit. Selbst wenn eine Anforderung einen User-Agent enthält, bedeutet das nicht, dass sie von einem echten Benutzer stammt. Diese Regel dient als erste Stufe der Mitigation von "Dummy"-Angriffen, die von möglichen Bots oder "nicht-RFC-konformen" Anwendungen stammen. Hinweis: Einige APIs enthalten möglicherweise nicht den User-Agent-Header. Wenn API-Anforderungen erwartet werden, stellen Sie sicher, dass Sie die API-IP-Adresse der Ausnahmeliste hinzufügen oder eine benutzerdefinierte WAF-Regel einrichten, damit dieser Traffic nicht geprüft wird. Weitere Informationen finden Sie in RFC 7231, Abschnitt 5.5.3. Diese Regel ist ein Indikator für fehlerhaften oder böswilligen Traffic. Es ist jedoch möglich, dass legitime Anwendungen keinen User-Agent haben. Bitten Sie Anwendungseigentümer gegebenenfalls, User-Agents zu verwenden.
960011	GET/HEAD Requests Validation	Wie in RFC 7231, Abschnitt 4.3.1 und Abschnitt 4.3.2 beschrieben, sind HEAD und GET HTTP-Methoden, die Informationen vom Ursprungsserver abrufen. Auch wenn es nicht vom RFC verboten ist, ist das Senden von Bodys oder Payloads über diese Methoden nicht üblich. Normalerweise wird das durch falsch definierte Anwendungen verursacht, die nicht den Best Practices des RFC folgen. Es kann von böswilligen Benutzern als Umgehungstechnik verwendet werden. Außerdem wird in RFC 2616, Abschnitt 4.3 Folgendes definiert: Wenn die Anforderungsmethode keine definierte Semantik für einen Entitybody enthält, muss der Nachrichtenbody bei der Verarbeitung der Anforderung ignoriert werden.
960904	Missing Content-Type Header	Wie unter RFC 2616, Abschnitt 7.2.1 definiert, sollte jede HTTP/1.1-Nachricht, die einen Entitybody enthält, ein Content-Type-Headerfeld enthalten, das den Medientyp dieses Bodys definiert. Wenn diese Best Practice nicht befolgt wird, könnte das zu MIME-Typ-Sniffing-Angriffen führen.
960032	Allowed HTTP methods	Die standardmäßig zulässigen HTTP-Methoden sind GET, HEAD, POST und OPTIONS. OPTIONS wird als unsichere Methode betrachtet, da sie von Angreifern häufig zum Sammeln von Informationen vom Ursprungsserver verwendet wird. Diese Methode wird auch von einigen Anwendungen benötigt, um ordnungsgemäß zu funktionieren. Wenn diese Methode nicht erforderlich ist, erstellen Sie eine Serviceanfrage bei My Oracle Support, um sie zu deaktivieren. Andere Methoden können ebenfalls nach Bedarf mit einer Serviceanfrage hinzugefügt werden.
960335	Max amount of arguments	RFC setzt keine bestimmte Anzahl an Argumenten durch, die eine Anforderung haben muss. Die Verwendung vieler Argumente könnte jedoch eine Methode sein, die von böswilligen Benutzern verwendet wird, um eine Webanwendung zu überlasten. Zum Schutz vor derartigen Angriffen wird empfohlen, die maximal zulässige Anzahl an ARGs pro Anforderung zu begrenzen. Der Standardwert ist 255.
960208	Max length of an argument	RFC setzt keine bestimmte Länge pro Argument durch, die eine Anforderung haben muss. Die Verwendung langer Argumente könnte jedoch eine Methode sein, die von böswilligen Benutzern verwendet wird, um eine Webanwendung zu überlasten. Zum Schutz vor derartigen Angriffen wird empfohlen, die maximal zulässige Länge von ARGs pro Anforderung zu begrenzen. Der Standardwert ist 400.
960341	Max total argument length	RFC setzt keine bestimmte Gesamtgroße (kombiniert) von Argumenten durch, die eine Anforderung haben muss. Die Verwendung vieler kombinierter Argumentwerte könnte jedoch eine Methode sein, die von böswilligen Benutzern verwendet wird, um eine Webanwendung zu überlasten. Zum Schutz vor derartigen Angriffen wird empfohlen, den maximal zulässigen kombinierten Argumentwert pro Anforderung zu begrenzen. Der Standardwert ist 64000.
92035032	Host Header Is IP Address	Diese Regel wird in der Regel nicht ausgelöst, da WAF einen Hostheader benötigt, um Traffic an den Ursprung zu senden.
941120	Cross-Site Scripting (XSS) Attempt: XSS Filters - Category 2	Die Verarbeitung dieser Regel dauert sehr lange, wenn die Payload groß ist. Beispiel: Die Verarbeitung einer Payload mit 64.005 Byte dauert etwa 32 Sekunden.

Oracle Cloud Infrastructure - Dokumentation