Schutz für Web Application Firewall

Erfahren Sie, wie Sie Schutzmaßnahmen für Firewallrichtlinien für Webanwendungen hinzufügen und verwalten.

Web Application Firewall schützt Ihre Webanwendungen vor Bedrohungen. Web Application Firewall ist ein regionaler Service, der an einen Durchsetzungspunkt angehängt ist. Verwenden Sie Web Application Firewall-Schutzfunktionen, um Ihre kritischen Webanwendungen vor böswilligen Cyberangriffen zu schützen. Mit den Schutzfunktionen können Sie Regeln einrichten, die mit eingehenden Anforderungen verglichen werden, 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 Web Application Firewall 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 Web Application Firewall-Schutzfunktionen erkannt und blockiert werden können.

Der Web Application Firewall-Schutz ist ein Toolkit, das für Monitoring, Logging und Zugriffskontrolle von Webanwendungen konzipiert wurde. Mit dem Toolkit können Sie entscheiden, wie Sie alle verfügbaren Schutzfunktionen nutzen möchten. Diese Flexibilität ist ein zentrales Element des Web Application Firewall-Schutzes, da OCI ständig Updates veröffentlicht, um den Sicherheitsumfang der Schutzfunktionen zu erhöhen.

Die wichtigsten Grundsätze der Web Application Firewall-Schutzfunktionen sind:

Passivität: Sie entscheiden, welche Funktionen erforderlich sind. Daher haben Sie die vollständige Kontrolle.
Flexibilität: Das Oracle Web Application Firewall-Sicherheitsteam hat eine Liste der Schutzfunktionen kuratiert, die sich sowohl auf die 10 wichtigsten Lebensläufe des Open Web Application Security Project (OWASASP) als auch auf kritische Lebensläufe für beliebte Webanwendungen beziehen.
Qualität, nicht Anzahl: Web Application Firewall-Schutzregeln sind ein dediziertes Modul für die Prüfung von HTTP-Traffic, das mit den anderen WAF-Features (z.B. Zugriffskontrolle) kompatibel ist.
Vorhersagebarkeit: Sie haben vollständige Kontrolle über die Web Application Firewall-Schutzfunktionen 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.

Schutzregeln gleichen Webtraffic mit Regelbedingungen ab und ermitteln so die Aktion, die bei Erfüllung der Bedingungen ausgeführt werden soll.

Die Web Application Firewall-Policy enthält ungefähr 490 Regeln und enthält nur die neuesten Versionen der Regeln. Die WAF-Policy enthält nur Regeln, die auf CRS 3.0 und höher basieren.

Hinweis

Neben dem Erstellen neuer Regeln aktualisieren und optimieren wir vorhandene Regeln kontinuierlich. Aufgrund von Sicherheitslücken können wir das Risikominderungsmuster für Regeln nicht angeben.

Für die Web Application Firewall-Policy sind keine benutzerdefinierten Schutzregeln verfügbar.

Sie können folgende Schutzaufgaben ausführen:

Weitere Informationen finden Sie unter:

Ausschlüsse

Gelegentlich kann eine Schutzregel einen falsch positiven Treffer auslösen. Sie können eine Ausnahme konfigurieren, wenn die Anforderungen, die diese falsch positiven Treffer generieren, ein bestimmtes Argument oder ein bestimmtes Cookie haben, anhand dessen sie sich identifizieren lassen, um sie aus der Aktion auszuschließen, die normalerweise für die Regel ausgeführt wird. Sie können Ausschlüsse mit der OCI-Konsole oder über die API erstellen. Verwenden Sie die folgenden Ausschlussparameter:


Name	Wert
REQUEST_COOKIES	Cookiewert
ARGS	Argument (Abfrageparameter oder POST/PUT-Daten)

Leistungsoptimierung

In diesen allgemeinen Informationen zur WAF-Optimierung werden die Grundlagen der Regeloptimierung, der Logprüfung und der Einrichtung von Funktionsausschlüssen beschrieben. Tuning 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.

In der folgenden Tabelle sind Begriffe und Definitionen für Schutzfunktionen aufgeführt.

Definitionen von Schutzfunktionen
Begriff	Definition
Optimierung	Der Prozess, bei dem der Techniker oder Analyst des Kunden Schutzfunktionen 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 Funktionen, die zu seinem Schutz verfügbar sind.
Falsch positives Ergebnis	Ein falsch positives Ergebnis tritt auf, wenn eine Schutzfunktion mit einer HTTP-Transaktion übereinstimmt und die HTTP-Transaktion eine legitime (nicht böswillige) Transaktion ist.
Ausschluss	Eine Änderung einer Schutzfunktion, mit der der Wert oder Wertname eines Cookies oder HTTP-Arguments ignoriert werden kann.

Möglichkeiten des kollaborativen Schutzes

Sie können spezielle Schutzfunktionen verwenden, die als "Kollaborativ" gekennzeichnet sind, um falsch positive Ergebnisse zu begrenzen. Die kollaborativen Funktionen funktionieren anders als die anderen Schutzfunktionen.

Kollaborative Schutzfunktionen verwenden ein Bewertungs- und Schwellenwertsystem, um den Traffic zu bewerten. Einzelne Funktionen gleichen Elemente der HTTP-Transaktion und die Funktionssignatur gegeneinander ab. Wenn eine Übereinstimmung gefunden wird, führt die Regel ihre Aktion aus (z.B. Ermitteln oder Blockieren).

Jede der kollaborativen Funktionen verwendet eine Gruppe individueller Funktionen. Die kollaborativen Schutzfunktionen führen ihre Aktionen nur aus, wenn mehrere Übereinstimmungen von Elementen der HTTP-Transaktion mit einzelnen Regeln vorliegen.

Damit kollaborative Funktionen ihre Aktionen ausführen können, müssen Elemente der HTTP-Transaktion mit den einzelnen Funktionen in der kollaborativen Gruppe übereinstimmen. Dabei werden die festgelegten Gewichtungen und Schwellenwerte der kollaborativen Funktionen wie folgt berücksichtigt:

Gewichtung: Eine Zahl, die angibt, wie viel eine einzelne Funktion zum Schwellenwert der kollaborativen Funktion beiträgt.
Schwellenwert: Die Mindestsumme der Gewichtungen aus einzelnen Funktionen, mit denen die kollaborative Funktion übereinstimmt.

Hinweis

Sie können die Gewichtungen und die Schwellenwerte nach Bedarf ändern.

Wenn der kollaborativen Schutzfunktion ein Ausschluss hinzugefügt wird, gilt der Ausschluss für alle individuellen Funktionen innerhalb der kollaborativen Funktion.

Beispiel:

Ein kollaborativer Funktionsschlüssel mit der ID 9420000 - SQL-Injection (SQLi) Collaborative Group - SQLi Filters Categories prüft die eingehende HTTP-Anforderung für bestimmte Typen von SLQ-Injections. Diese kollaborative Funktion besteht aus mehreren Funktionen, wie z.B. 9421000, 9421400, 9421600, jeweils mit einer Standardgewichtung von 4.

Wenn diese kollaborative Funktion aktiviert ist (9420000), führt WAF für jede eingehende HTTP-Anforderung jede einzelne Funktion (9421000, 9421400, 9421600), aus der die kollaborative Funktion besteht, separat aus, um übereinstimmende Funktionen zu finden.

Nachdem die Regeln verarbeitet wurden, werden die Gewichtungen der übereinstimmenden Funktionen aufaddiert (hier: 4+4+4 = 12), und die Summe wird mit dem Schwellenwert (10) abgeglichen. Da die HTTP-Anforderung mit den einzelnen Funktionen der kollaborativen Funktion (9420000) übereinstimmt, wird die kollaborative Funktion als ausgelöst markiert. Wenn Logging konfiguriert ist, wird die übereinstimmende Funktion protokolliert. Je nach Konfiguration der Funktion wird eine HTTP-Antwort zurückgegeben.

Weitere Informationen finden Sie in der Referenz zu Schutzfunktionen.

Schlüssel für kollaborative Schutzfunktionen

Die folgende Liste enthält Schlüssel für kollaborative Schutzfunktionen:

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

Weitere Schutzfunktionen

Die folgende Liste enthält Schutzfunktionen, die möglicherweise unerwünscht ("noisy"). Sie enthält Beschreibungen und Empfehlungen, mit denen Sie nachvollziehen können, womit die Funktionen übereinstimmen sollen. Auf einige dieser Schlüssel können keine Ausschlüsse angewendet werden.


Funktionsschlüssel	Funktionsname	Hinweise
920310 920311	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.
920280	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.
920320 920330	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 Minderung 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.
920170 920171	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.
920180	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.
911100	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.
920380	Maximale Anzahl Argumente	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.
920370	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.
920390	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.
920350	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.

Schutzregeln

Schutzregeln gleichen Webtraffic mit Regelbedingungen ab und ermitteln so die Aktion, die bei Erfüllung der Bedingungen ausgeführt werden soll.

Die WAF-Policy enthält ca. 490 Regeln und enthält nur die neuesten Versionen der Regeln. Die WAF-Policy enthält nur Regeln, die auf CRS 3.0 und höher basieren.

Benutzerdefinierte Schutzregeln sind für die WAF-Policy nicht verfügbar.