Sprachattribute mit benutzerdefinierte Regeln konfigurieren

Jede Regel der Google Cloud Armor-Sicherheitsrichtlinie hat eine Priorität, eine Abgleichsbedingung und eine Aktion. Google Cloud Armor führt die Aktion der Regel mit der höchsten Priorität aus, die einer Anfrage entspricht. Regeln mit einer niedrigeren Priorität als die Abgleichsregel mit der höchsten Priorität werden nicht ausgewertet, auch wenn sie dieselben Abgleichsbedingungen haben.

Jede Sicherheitsrichtlinienregel unterstützt zwei Arten von Abgleichsbedingungen:

  • Eine einfache Übereinstimmungsbedingung enthält Listen mit IP-Adressen oder IP-Adressbereichen. Grundlegende Übereinstimmungsbedingungen werden mit dem Flag --src-ip-ranges definiert, wenn Sie eine Regel über die Google Cloud CLI erstellen.
  • Eine erweiterte Übereinstimmungsbedingung enthält einen Ausdruck mit bis zu fünf Unterausdrücken, die mit einer Vielzahl von Attributen einer eingehenden Anfrage übereinstimmen können. Erweiterte Abgleichsbedingungen werden mit dem Flag --expression definiert, wenn eine Regel über die Google Cloud CLI erstellt wird.

Auf dieser Seite werden erweiterte Abgleichsbedingungen und die benutzerdefinierte Regelsprache von Google Cloud Armor beschrieben, mit der Sie Ausdrücke in den erweiterten Abgleichsbedingungen von Sicherheitsrichtlinienregeln schreiben. Die benutzerdefinierte Regelsprache von Google Cloud Armor ist eine Teilmenge der Common Expression Language (CEL). Ausdrücke, die in der Sprache für benutzerdefinierte Regeln von Google Cloud Armor geschrieben werden, erfordern zwei Komponenten:

  • Attribut: die zu prüfenden Daten
  • Der Vorgang: Wie werden die Daten verwendet?

Der folgende Ausdruck verwendet beispielsweise die Attribute origin.ip und 9.9.9.0/24 im Vorgang inIpRange(). In diesem Fall gibt der Ausdruck "true" zurück, wenn sich origin.ip im IP-Adressbereich 9.9.9.0/24 befindet.

inIpRange(origin.ip, '9.9.9.0/24')

Obwohl der vorherige Beispielausdruck nur anhand der Quell-IP-Adresse übereinstimmt, wird die Regel bei Verwendung des Beispielausdrucks in einer Google Cloud Armor-Sicherheitsrichtlinie aus Sicht des Kontingents als Regel mit erweiterten Übereinstimmungsbedingungen betrachtet. Weitere Informationen finden Sie unter Kontingente und Limits für Google Cloud Armor.

Attribute

Attribute stellen Informationen aus einer eingehenden Anfrage dar, z. B. die Ursprungs-IP-Adresse oder den angeforderten URL-Pfad.

Feld Typ Feldbeschreibung
origin.ip String Die Quell-IP-Adresse der Anfrage.
origin.user_ip String Die IP-Adresse des ursprünglichen Clients, die von einem Upstream-Proxy in die HTTP-HEADER aufgenommen wird. Bevor Sie dieses Attribut verwenden, müssen Sie die Option userIpRequestHeaders[] im Feld advancedOptionsConfig der Sicherheitsrichtlinie so konfigurieren, dass es einer Quelle wie True-Client-IP, X-Forwarded-For oder X-Real-IP entspricht.

Wenn Sie die Option userIpRequestHeaders[] nicht konfigurieren, wenn der konfigurierte Header ungültige IP-Adresswerte enthält oder der konfigurierte Header nicht vorhanden ist, wird origin.user_ip standardmäßig auf origin.ip gesetzt. Weitere Informationen finden Sie in der Ressourcenreferenz zu securityPolicy.

origin.tls_ja3_fingerprint String JA3 TLS/SSL-Fingerabdruck, wenn der Client eine Verbindung mithilfe von HTTPS, HTTP/2 oder HTTP/3 herstellt. Falls nicht verfügbar, wird ein leerer String zurückgegeben.
request.headers Karte Eine String-zu-String-Zuordnung der HTTP-Anfrageheader. Wenn ein Header mehrere Werte enthält, ist der Wert in dieser Zuordnung ein kommagetrennter String aller Werte des Headers. Die Schlüssel in dieser Zuordnung sind alle kleingeschrieben. Alle Header, die von externen Application Load Balancern akzeptiert werden, werden geprüft, und es gelten die gleichen Einschränkungen für Header.
request.method String Die HTTP-Anfragemethode, z. B. GET oder POST.
request.path String Der angeforderte HTTP-URL-Pfad.
request.scheme String Das HTTP-URL-Schema, z. B. http oder https. Die Werte für dieses Attribut sind alle kleingeschrieben.
request.query String Die HTTP-URL-Abfrage im Format name1=value&name2=value2, wie sie in der ersten Zeile der HTTP-Anfrage angezeigt wird. Es wird keine Decodierung durchgeführt.
origin.region_code String Der Unicode-Ländercode, der der Ursprungs-IP zugeordnet ist, z. B. US. Wenn Sie eine Regel oder einen Ausdruck erstellen, der die Länder- oder Regionscodes im Format ISO 3166-1 alpha 2 verwendet, behandelt Google Cloud Armor jeden Code unabhängig. Die Regeln und Ausdrücke von Google Cloud Armor verwenden diese Regionscodes explizit, um Anfragen zuzulassen oder abzulehnen.

Weitere Informationen finden Sie im Unicode Technical Standard unter unicode_region_subtag.

origin.asn integer Die Nummer des autonomen Systems (Autonomous System Number, ASN), das der Ursprungs-IP-Adresse zugeordnet ist. Die global eindeutige ASN wird anhand des Netzwerkoperators ermittelt, der die IP-Adresspräfixe unterstützt, die die IP-Adresse des Ursprungsorts enthalten.

reCAPTCHA Enterprise-Attribute

In diesem Abschnitt werden Attribute aufgeführt, die nur für reCAPTCHA Enterprise-Tokens oder Ausnahme-Cookies gelten. Ein Unterausdruck basierend auf diesen Attributen gibt false zurück, wenn das auszuwertende reCAPTCHA Enterprise-Token oder Ausnahmecookie nicht verfügbar oder aus einem der folgenden Gründe ungültig ist:

  • Das Token ist fehlerhaft und kann nicht decodiert werden.
  • Das Token enthält ungültige Attribute. Das Token wurde beispielsweise mit einem reCAPTCHA-Schlüssel generiert, der nicht mit den verknüpften reCAPTCHA-Schlüsseln der Regel übereinstimmt.
  • Das Token ist abgelaufen.
Feld Typ Feldbeschreibung
token.recaptcha_exemption.valid bool Das Vorhandensein eines gültigen reCAPTCHA-Ausnahme-Cookies.

Aktionstoken-Attribute

Feld Typ Feldbeschreibung
token.recaptcha_action.score float Der Score eines reCAPTCHA Enterprise-Tokens. Eine gültiger Score reicht von 0.0 bis 1.0, wobei 0.0 ein illegitimer Nutzer und 1.0 ein legitimer Nutzer ist.
token.recaptcha_action.captcha_status string Der CAPTCHA-Status von einem reCAPTCHA-Aktionstoken. Ein gültiger Status ist NONE, PASS oder FAIL, wobei sich NONE darauf bezieht, wann bei der reCAPTCHA-Bewertung keine Herausforderungen auftreten, z. B. das Captcha-Feld im Aktionstoken fehlt.
token.recaptcha_action.action string Der Aktionsname (bis zu 100 Zeichen) aus einem reCAPTCHA Enterprise-Aktionstoken. Weitere Informationen finden Sie unter Aktionsnamen.
token.recaptcha_action.valid bool Das Vorhandensein eines gültigen reCAPTCHA-Aktionstokens.

Sitzungstoken-Attribute

Feld Typ Feldbeschreibung
token.recaptcha_session.score float Der Score eines reCAPTCHA Sitzungstokens. Eine gültiger Score reicht von 0.0 bis 1.0, wobei 0.0 ein illegitimer Nutzer und 1.0 ein legitimer Nutzer ist.
token.recaptcha_session.valid bool Das Vorhandensein eines gültigen reCAPTCHA-Sitzungstokens.

Operations

In der folgenden Referenz werden die Operatoren beschrieben, die Sie mit Attributen (dargestellt durch x, y und k) verwenden können, um Regelausdrücke zu definieren.

Ausdrücke Beschreibung
x == "foo" Gibt "true" zurück, wenn x dem angegebenen konstanten String-Literal entspricht.
x == R"fo'o" Gibt "true" zurück, wenn x dem angegebenen Raw-String-Literal entspricht, das keine Escape-Sequenzen interpretiert. Raw-String-Literale eignen sich gut für die Darstellung von Strings, die ihrerseits Escape-Sequenz-Zeichen verwenden müssen.
x == y Gibt TRUE zurück, wenn x gleich x ist.
x != y Gibt TRUE zurück, wenn x ungleich x ist.
x + y Gibt den verketteten String xy zurück.
x && y Gibt "true" zurück, wenn sowohl x als auch y "true" sind.
x || y Gibt "true" zurück, wenn x, y oder beide "true" sind.
!x Gibt "true" zurück, wenn der boolesche Wert x "false" ist, oder "false", wenn der boolesche Wert x "true" ist.
x.contains(y) Gibt "true" zurück, wenn der String x den Teilstring y enthält.
x.startsWith(y) Gibt "true" zurück, wenn der String x mit dem Teilstring y beginnt.
x.endsWith(y) Gibt "true" zurück, wenn der String x mit dem Teilstring y endet.
x.matches(y) Gibt „true“ zurück, wenn der String x teilweise mit dem angegebenen RE2-Muster y übereinstimmt. Das RE2-Muster wird mithilfe der Option "RE2::Latin1" kompiliert, die Unicode-Funktionen deaktiviert.
inIpRange(x, y) Gibt "true" zurück, wenn die IP-Adresse x im IP-Bereich y enthalten ist. Subnetzmasken für IPv6-Adressen dürfen nicht größer als /64 sein.
x.lower() Gibt den Kleinbuchstabenwert des Strings x zurück
x.upper() Gibt den Großbuchstabenwert des Strings x zurück
x.base64Decode() Gibt den decodierten base64-Wert von x zurück. Die Zeichen _ - werden zuerst durch das entsprechende Zeichen aus / + ersetzt. Gibt "" (leerer String) zurück, wenn x kein gültiger base64-Wert ist.
has(m['k']) Gibt "true" zurück, wenn der Schlüssel k in der Zuordnung m verfügbar ist.
m['k'] Gibt den Wert bei Schlüssel k in der String-zu-String-Zuordnung m zurück, wenn k verfügbar ist, andernfalls wird ein Fehler zurückgegeben. Es wird empfohlen, zuerst die Verfügbarkeit mithilfe von "has(m['k'])==true" zu prüfen.
int(x) Wandelt das Stringergebnis von x in einen int-Typ um. Anschließend kann mithilfe der standardmäßigen arithmetischen Operatoren wie > und <= ein ganzzahliger Vergleich durchgeführt werden. Dies funktioniert nur bei Werten, die ganze Zahlen sein sollten.
size(x) Gibt die Länge des Strings x zurück.
x.urlDecode() Gibt den URL-decodierten Wert von x zurück; Zeichensequenzen im Format %## werden durch die Nicht-ASCII-Entsprechungen ersetzt und + wird durch ein Leerzeichen ersetzt. Ungültige Codierungen werden unverändert zurückgegeben.
x.urlDecodeUni() Gibt den URL-decodierten Wert von x zurück; neben urlDecode() werden auch Unicode-Zeichensequenzen im Format %u### verarbeitet. Ungültige Codierungen werden unverändert zurückgegeben.
x.utf8ToUnicode() Gibt die Kleinbuchstaben-Unicode-Darstellung einer UTF-8-codierten Verschlüsselungx zurück.

Beispielausdrücke

Für jeden dieser Ausdrücke hängt die durchgeführte Aktion davon ab, ob der Ausdruck in einer "deny"- oder "allow"-Regel enthalten ist.

Zugriff basierend auf einem IP-Adressbereich in IPv4 oder IPv6 zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen aus dem IP-Adressbereich 198.51.100.0/24 überein:

    inIpRange(origin.ip, '198.51.100.0/24')
    
  • Der folgende Ausdruck stimmt mit Anfragen aus dem IP-Adressbereich 2001:db8::/32 überein:

    inIpRange(origin.ip, '2001:db8::/32')
    

Zugriff anhand eines benutzerdefinierten Client-IP-Adressbereichs hinter einem Upstream-Proxy zulassen oder ablehnen

Wenn Sie den Operator origin.user_ip konfiguriert haben, können Sie einen Abgleich anhand der Headerwerte vornehmen, die Sie im Feld advancedOptionsConfig.userIpRequestHeaders[] angegeben haben.

  • Der folgende Ausdruck stimmt mit Anfragen überein, die aus dem IP-Adressbereich 192.0.2.0/24 stammen:

    inIpRange(origin.user_ip, '192.0.2.0/24')
    
  • Der folgende Ausdruck stimmt mit Anfragen überein, die aus dem IP-Adressbereich 2001:db8::/32 stammen:

    inIpRange(origin.user_ip, '2001:db8::/32')
    
  • Der folgende Ausdruck stimmt mit Anfragen überein, deren Cookie 80=BLAH enthält.

    has(request.headers['cookie']) && request.headers['cookie'].contains('80=BLAH')
    

Traffic mit einem nicht leeren referer-Header zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen überein, die einen nicht leeren referer-Header haben.

    has(request.headers['referer']) && request.headers['referer'] != ""
    

Traffic basierend auf Host-URL im Header zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen an eine bestimmte URL überein:

    request.headers['host'].lower().contains('test.example.com')
    

Traffic aus einer bestimmten Region zulassen oder ablehnen

Wenn Ihre Webanwendung in der Region AU nicht verfügbar ist, müssen alle Anfragen aus dieser Region blockiert werden.

  • Verwenden Sie in einer Ablehnungsregel den folgenden Ausdruck, der Anfragen aus der Region AU entspricht:

    origin.region_code == 'AU'
    

Wenn Ihre Webanwendung nur in der Region AU verfügbar ist, müssen Anfragen von allen anderen Regionen blockiert werden.

  • Verwenden Sie in einer Ablehnungsregel den folgenden Ausdruck, der Anfragen aus allen Regionen außer der Region AU entspricht:

    origin.region_code != 'AU'
    

Die Regionscodes basieren auf den Codes gemäß ISO 3166-1 alpha-2. In einigen Fällen entspricht eine Region einem Land. Dies ist jedoch nicht immer der Fall. Beispielsweise enthält der Code US alle Bundesstaaten der USA, einen District und sechs Außengebiete.

Traffic aus einer bestimmten ASN zulassen oder ablehnen

Wenn Ihre Webanwendung für Kunden blockiert werden muss, die von einem bestimmten Netzwerkbetreiber bedient werden, können Sie die ASN-Nummer des Netzwerkoperators zum Blockieren verwenden.

  • Verwenden Sie in einer Ablehnungsregel den folgenden Ausdruck, der Anfragen von einer bestimmten ASN entspricht:

    origin.asn == 123
    

Wenn Ihre Webanwendung hingegen nur für Kunden verfügbar sein soll, die sich hinter einem bestimmten Netzwerkbetreiber befinden, müssen Anfragen von allen anderen Netzwerkanbietern blockiert werden.

  • Verwenden Sie in einer Ablehnungsregel den folgenden Ausdruck, der mit allen anderen Netzwerkoperatoren übereinstimmt, mit Ausnahme desjenigen, den Sie zulassen möchten:

    origin.asn != 123
    

Mehrere Ausdrücke

Wenn Sie mehrere Bedingungen in eine einzige Regel einbeziehen möchten, kombinieren Sie mehrere Unterausdrücke.

  • Im folgenden Beispiel stimmen Anfragen von 1.2.3.0/24 (z. B. Ihren Alpha-Testern) in der Region AU mit dem folgenden Ausdruck überein:

    origin.region_code == "AU" && inIpRange(origin.ip, '1.2.3.0/24')
    
  • Der folgende Ausdruck entspricht Anfragen von 1.2.3.4, bei denen ein User-Agent den String WordPress enthält:

    inIpRange(origin.ip, '1.2.3.4/32') &&
    has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')
    

Traffic für einen Anfrage-URI, der einem regulären Ausdruck entspricht, zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen überein, die den String bad_path im URI enthalten:

    request.path.matches('/bad_path/')
    
  • Der folgende Ausdruck stimmt mit Anfragen überein, bei denen Chrome im Headerfeld User-Agent enthalten ist:

    request.headers['user-agent'].matches('Chrome')
    
  • Der folgende Ausdruck zeigt den Abgleich der Groß-/Kleinschreibung für den User-Agent-Header, der wordpress enthält. Er stimmt mit User-Agent:WordPress/605.1.15, User-Agent:wordPress und anderen Varianten von wordpress überein:

    request.headers['user-agent'].matches('(?i:wordpress)')
    

Traffic, der einen bestimmten base64-decodierten Wert enthält, zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen überein, die einen base64-decodierten Wert von myValue für den user-id-Header haben:

    has(request.headers['user-id']) && request.headers['user-id'].base64Decode().contains('myValue')
    

Traffic mit einem Stringwert mit einer bestimmten Länge zulassen oder ablehnen

  • Der folgende Ausdruck entspricht Anfragen mit einer URL-Länge von mehr als 10 Zeichen:

    size(request.path) < 10
    
  • Der folgende Ausdruck stimmt mit Anfragen überein, deren x-data-Header länger als oder gleich 1.024 Zeichen ist:

    size(request.headers['x-data']) >= 1024
    

Traffic mit einer content-length von Null im HTTP-Body zulassen oder ablehnen

  • Der folgende Ausdruck entspricht Anfragen mit einer content-length von Null im HTTP-Body.

    int(request.headers["content-length"]) == 0
    

Traffic, der einen bestimmten URL-codierten Wert enthält, zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen überein, deren Cookie-Wert %3c enthält:

    has(request.headers['cookie']) && request.headers['cookie'].urlDecode().contains('<')
    

Traffic, der einen bestimmten URL-codierten Wert eines Unicode-Strings enthält, zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen überein, deren Cookie-Wert gleich Match%2BValue oder Match%u002BValue ist:

    has(request.headers['cookie']) && request.headers['cookie'].urlDecodeUni() == 'Match+Value'
    

Traffic, der einen bestimmten Unicode-String eines UTF-8-Texts enthält, zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen überein, deren Cookiewert gleich ¬ ist:

    has(request.headers['cookie']) && request.headers['cookie'].utf8ToUnicode() == '%u00ac'
    

Traffic basierend auf einem bekannten JA3-Fingerabdruck zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen mit einem JA3-Fingerabdruck gleich e7d705a3286e19ea42f587b344ee6865 überein:

    origin.tls_ja3_fingerprint == 'e7d705a3286e19ea42f587b344ee6865'
    

Traffic anhand einer Liste von JA3-Fingerabdrücken zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen mit einem JA3-Fingerabdruck überein, der einem der folgenden JA3-Fingerabdrücke entspricht:

    • e7d705a3286e19ea42f587b344ee6865
    • f8a5929f8949e846267b582072e35f84
    • 8f8b62163873a62234c14f15e7b88340
    origin.tls_ja3_fingerprint == 'e7d705a3286e19ea42f587b344ee6865' || origin.tls_ja3_fingerprint == 'f8a5929f8949e846267b582072e35f84' || origin.tls_ja3_fingerprint == '8f8b62163873a62234c14f15e7b88340'
    

Vorkonfigurierte WAF-Regeln

Vorkonfigurierte WAF-Regeln verwenden vorkonfigurierte statische Signaturen, reguläre Ausdrücke oder beides für den Abgleich mit dem HTTP-POST-Text, den HTTP-Anfrageheadern und den Abfrageparametern. Die verfügbaren vorkonfigurierten WAF-Regeln basieren auf dem OWASP-Modsecurity Core Rule Set Version 3.3. Google Cloud Armor bietet mehrere vordefinierte vorkonfigurierte WAF-Regeln. Eine vollständige Liste der vorkonfigurierten WAF-Regeln finden Sie in der Übersicht über die vorkonfigurierten WAF-Regeln für Google Cloud Armor.

Eine Liste aller verfügbaren vorkonfigurierten WAF-Regeln finden Sie unter Verfügbare vorkonfigurierte WAF-Regeln auflisten.

Weitere Informationen zu vorkonfigurierten WAF-Regeln finden Sie im Anwendungsfall Angriffe auf Anwendungsebene mithilfe vorkonfigurierter WAF-Regeln abwehren.

Vorkonfigurierte WAF-Regelnamen

Vorkonfigurierte WAF-Regelnamen haben das Format <attack category>-<ModSecurity CRS version>-<version field>. Die Angriffskategorie gibt die Art der Angriffe an, die Sie verhindern möchten, z. B. xss (Cross-Site-Scripting) oder sqli (SQL-Einschleusung).

Die unterstützten Versionsfelder sind stable und canary. Hinzufügungen und Änderungen an den Regeln werden zuerst in der canary-Version veröffentlicht. Wenn Add-ons und Änderungen als sicher und stabil angesehen werden, werden sie in die Version stable umgewandelt.

Vorkonfigurierte Mitglieds-IDs der WAF-Regel

Eine vorkonfigurierte WAF-Regel enthält mehrere Ausdrücke, jeder mit seiner Signatur. Die vorkonfigurierte WAF-Regel xss-v33-stable enthält beispielsweise den Ausdruck owasp-crs-v030301-id941100-xss, der der Regel-ID id941100 für Version 3.3 entspricht. Sie können die Signaturen verwenden, um bestimmte Ausdrücke von der Verwendung auszuschließen. Dies ist nützlich, wenn ein bestimmter Ausdruck regelmäßig ein falsch-positives Ergebnis auslöst. Weitere Informationen finden Sie unter falsch-positive Informationen zur Fehlerbehebung.

Informationen zum Hauptregelsatz und zur Feinabstimmung bei unterschiedlichen Schweregraden finden Sie unter Google Cloud Armor WAF-Regeln abstimmen.

Operator für vorkonfigurierte WAF-Regeln

Ausdrücke Beschreibung
evaluatePreconfiguredWaf(string, MAP<string, dyn>) Gibt „true“ zurück, wenn eine der WAF-Signaturen im angegebenen WAF-Regelsatz „true“ zurückgibt. Das erste Argument ist der Name des WAF-Regelsatzes, z. B. xss-v33-stable. Das zweite Argument (optional) ist eine Zuordnung, bei der der Schlüssel ein String ist und der Wert abhängig vom Schlüssel dynamisch eingegeben wird. Der Zweck dieses Arguments besteht darin, die WAF-Signaturen auszuwerten. Folgende Schlüssel werden akzeptiert:
  • „sensitivity“: Dies entspricht der Paranoia-Ebene des ModSecurity Core Rule Set, die 4 Stufen von 1 bis 4 umfasst. Der Wert ist eine Ganzzahl mit einem gültigen Bereich zwischen 0 und 4. Beachten Sie, dass 0 als gültiger Wert reserviert ist, wenn er in Kombination mit „opt_in_rule_ids“ (später beschrieben) verwendet wird. Wenn Sie eine Empfindlichkeit von x (x >= 1) angeben, werden alle zugehörigen WAF-Signaturen mit einem Empfindlichkeitswert von 1 bis x ausgewertet. Wenn nichts angegeben ist, wird 4 als Empfindlichkeitswert verwendet.
  • „opt_out_rule_ids“: WAF-Signaturen (dargestellt durch Regel-IDs), die von der Auswertung deaktiviert werden sollen. Dabei wird der Basissatz durch den Empfindlichkeitswert bestimmt. Der Wert ist eine Liste von Strings. Die maximale Anzahl an zulässigen Regel-IDs beträgt 128.
  • „opt_in_rule_ids“: WAF-Signaturen (dargestellt durch Regel-IDs), die für die Auswertung aktiviert werden sollen, wenn der Basissatz leer ist. Der Wert ist eine Liste von Strings. Die maximale Anzahl an zulässigen Regel-IDs ist 128. Wenn Sie dies verwenden, muss eine „Empfindlichkeit“ von 0 angegeben werden.

Die Schlüssel „opt_out_rule_ids“ und „opt_in_rule_ids“ schließen sich gegenseitig aus. Sie können „opt_in_rule_ids“ verwenden, wenn Sie neue WAF-Signaturen, die später zu einem bestehenden Regelsatz hinzugefügt werden, überprüfen und manuell aktivieren möchten.

evaluatePreconfiguredExpr(string, LIST)

Gibt „true“ zurück, wenn einer der Ausdrücke in der angegebenen vorkonfigurierten WAF-Regel „true“ zurückgibt.

Das erste Argument ist der Name der vorkonfigurierten WAF-Regel, z. B. xss-stable. Das zweite Argument (optional) ist eine durch Kommas getrennte Stringliste mit IDs, die von der Auswertung ausgeschlossen werden sollen. Die Ausschlussliste ist nützlich, wenn ein bestimmtes Mitglied der vorkonfigurierten WAF-Regel ein falsch-positives Ergebnis auslöst.

Beispiele für vorkonfigurierte WAF-Regeln

  • Der folgende Ausdruck verwendet die vorkonfigurierte WAF-Regel xss-v33-stable, um XSS-Angriffe abzuwenden:

    evaluatePreconfiguredExpr('xss-v33-stable')
    
  • Der folgende Ausdruck verwendet alle Ausdrücke aus der vorkonfigurierten WAF-Regel xss-v33-stable mit Ausnahme der Mitglieds-IDs 941100 und 941110:

    evaluatePreconfiguredExpr('xss-v33-stable', ['owasp-crs-v030301-id941100-xss',
    'owasp-crs-v030301-id941110-xss'])
    
  • Der folgende Ausdruck verwendet eine vorkonfigurierte WAF-Regel, um SQLi-Angriffe über den IP-Adressbereich 198.51.100.0/24 zu reduzieren:

    inIpRange(origin.ip, '198.51.100.0/24') && evaluatePreconfiguredExpr('sqli-v33-stable')
    

Nächste Schritte