Cloud Armor-Sicherheitsrichtlinienregeln erstellen und ansehen

Jede Google Cloud Armor-Sicherheitsrichtlinienregel hat eine Priorität, eine Übereinstimmungsbedingung und eine Aktion. Cloud Armor führt die Aktion der Regel mit der höchsten Priorität aus, die mit einer Anfrage übereinstimmt. Regeln mit einer niedrigeren Priorität als die übereinstimmende Regel mit der höchsten Priorität werden nicht ausgewertet, auch wenn sie dieselben Übereinstimmungsbedingungen haben.

Jede Sicherheitsrichtlinienregel unterstützt zwei Arten von Abgleichsbedingungen:

  • Eine einfache Übereinstimmungsbedingung enthält Listen mit IP-Adressen oder IP-Adressbereichen. Grundlegende Abgleichbedingungen werden mit dem Flag --src-ip-ranges definiert, wenn Sie eine Regel mit der 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 Sie eine Regel mit der Google Cloud CLI erstellen.

Auf dieser Seite wird beschrieben, wie Sie Sicherheitsrichtlinienregeln erstellen und aufrufen. Außerdem finden Sie hier die Referenz für die Sprache für benutzerdefinierte Regeln von Cloud Armor, mit der Sie Ausdrücke in erweiterten Abgleichsbedingungen schreiben. Die Sprache für benutzerdefinierte Cloud Armor-Regeln ist eine Teilmenge der Common Expression Language (CEL).

Ausdrücke, die in der benutzerdefinierten Regelsprache von Cloud Armor geschrieben wurden, erfordern zwei Komponenten:

  • Das Attribut: die zu prüfenden Daten
  • Vorgang: wie die Daten verwendet werden sollen

Der folgende Ausdruck verwendet beispielsweise die Attribute origin.ip und 198.51.100.0/24 im Vorgang inIpRange. In diesem Fall gibt der Ausdruck true zurück, wenn origin.ip im IP-Adressbereich 198.51.100.0/24 liegt.

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

Auch wenn der vorherige Beispielausdruck nur mit der Client-IP-Adresse übereinstimmt, wird die Regel, wenn Sie den Beispielausdruck in einer Cloud Armor-Sicherheitsrichtlinienregel verwenden, aus Kontingentsicht als Regel mit erweiterten Abgleichsbedingungen betrachtet. Weitere Informationen finden Sie unter Kontingente und Limits für Cloud Armor.

Regeln für Sicherheitsrichtlinien erstellen

Folgen Sie der Anleitung in diesem Abschnitt, um Regeln zu einer Cloud Armor-Sicherheitsrichtlinie hinzuzufügen.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Cloud Armor-Richtlinien auf.

    Zu Cloud Armor-Richtlinien

  2. Klicken Sie auf den Namen der Sicherheitsrichtlinie, um die Seite Richtliniendetails zu öffnen, und klicken Sie dann auf den Tab Regeln.

  3. Klicken Sie auf Regel hinzufügen.

  4. Optional: Geben Sie eine Beschreibung der Regel ein.

  5. Wählen Sie den Modus aus:

    • Standardmodus: Zulassen oder Ablehnen von Traffic basierend auf IP-Adressen oder Bereichen.
    • Erweiterter Modus: Zulassen oder Ablehnen von Traffic basierend auf Regelausdrücken.

  6. Geben Sie im Feld Abgleich die Bedingungen an, für die die Regel gilt:

    • Standardmodus: Geben Sie 1 bis 10 IP-Adressbereiche ein, die mit der Regel übereinstimmen sollen. Sie können maximal 10 IP-Adressbereiche hinzufügen. Informationen zu Limits finden Sie unter Kontingente und Limits für Cloud Armor.

    • Erweiterter Modus:

      • Tool zur Bedingungserstellung (Vorschau): Verwenden Sie den visuellen Builder, um Ausdrücke zu erstellen, ohne rohen CEL-Code schreiben zu müssen. Bedingungen kombinieren und gruppieren und Stringtransformationen anwenden. Weitere Informationen finden Sie unter Tool zur Bedingungserstellung für Abgleich verwenden.
      • Bedingungs-Editor für Abgleich: Geben Sie einen Ausdruck ein, der anhand eingehender Anfragen ausgewertet werden soll. Weitere Informationen finden Sie unter Vorgänge und Attribute.

  7. Wählen Sie in der Liste Aktion die Option Zulassen oder Ablehnen aus.

  8. Wenn Sie eine Ablehnungsregel konfigurieren, wählen Sie in der Liste Antwortcode einen Antwortcode aus.

  9. Wenn Sie den Vorschaumodus für die Regel aktivieren möchten, wählen Sie Aktivieren aus.

  10. Geben Sie im Feld Priorität eine Ganzzahl zwischen 0 und 2.147.483.646 ein. Cloud Armor wertet Regeln in der Reihenfolge ihrer Priorität aus, von 0 (höchste) bis 2.147.483.647 (niedrigste). Die Standardregel hat die Priorität 2.147.483.647.

  11. Klicken Sie auf Hinzufügen.

gcloud

Führen Sie den Befehl gcloud compute security-policies rules create PRIORITY aus. Ersetzen Sie PRIORITY durch die Priorität der Regel in der Richtlinie:

gcloud compute security-policies rules create PRIORITY \
    --security-policy POLICY_NAME \
    --description DESCRIPTION \
    --src-ip-ranges IP_RANGES | --expression EXPRESSION \
    --action=[ allow | deny-403 | deny-404 | deny-502 ] \
    --preview

Der folgende Befehl fügt beispielsweise eine Regel mit der Priorität 1000 hinzu, mit der Traffic von den IP-Adressbereichen 192.0.2.0/24 und 198.51.100.0/24 blockiert wird:

gcloud compute security-policies rules create 1000 \
    --security-policy my-policy \
    --description "block traffic from 192.0.2.0/24 and 198.51.100.0/24" \
    --src-ip-ranges "192.0.2.0/24","198.51.100.0/24" \
    --action "deny-403"

Verwenden Sie das Flag --expression, um eine Bedingung anzugeben. Der folgende Befehl fügt eine Regel hinzu, die Traffic von der IP-Adresse 1.2.3.4 zulässt, und enthält den String example im User-Agent-Header:

gcloud compute security-policies rules create 1000 \
    --security-policy my-policy \
    --expression "inIpRange(origin.ip, '1.2.3.4/32') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('example')" \
    --action allow \
    --description "Block User-Agent 'example'"

Der folgende Befehl fügt eine Regel zum Blockieren von Anfragen hinzu, wenn das Cookie der Anfrage einen bestimmten Wert enthält:

gcloud compute security-policies rules create 1000 \
    --security-policy my-policy \
    --expression "has(request.headers['cookie']) && request.headers['cookie'].contains('80=SomeValue')" \
    --action deny-403 \
    --description "Cookie Block"

Der folgende Befehl fügt eine Regel hinzu, um Anfragen aus der Region AU zu blockieren:

gcloud compute security-policies rules create 1000 \
    --security-policy my-policy \
    --expression "origin.region_code == 'AU'" \
    --action deny-403 \
    --description "AU block"

Der folgende Befehl fügt eine Regel hinzu, um Anfragen aus der Region AU zu blockieren, die nicht im angegebenen IP-Bereich liegen:

gcloud compute security-policies rules create 1000 \
    --security-policy my-policy \
    --expression "origin.region_code == \"AU\" && !inIpRange(origin.ip, '1.2.3.0/24')" \
    --action deny-403 \
    --description "country and IP block"

Der folgende Befehl fügt eine Regel hinzu, um Anfragen mit einem URI zu blockieren, der einem regulären Ausdruck entspricht:

gcloud compute security-policies rules create 1000 \
    --security-policy my-policy \
    --expression "request.path.matches('/example_path/')" \
    --action deny-502 \
    --description "regex block"

Der folgende Befehl fügt eine Regel zum Blockieren von Anfragen hinzu, wenn der Base64-decodierte Wert des user-id-Headers einen bestimmten Wert enthält:

gcloud compute security-policies rules create 1000 \
    --security-policy my-policy \
    --expression "has(request.headers['user-id']) && request.headers['user-id'].base64Decode().contains('myValue')" \
    --action deny-403 \
    --description "country and IP block"

Der folgende Befehl fügt eine Regel hinzu, die einen vorkonfigurierten Ausdruckssatz aus dem OWASP Core Rule Set (CRS) 4.22 verwendet, um SQL-Injection-Angriffe (SQLi) abzuwehren:

gcloud compute security-policies rules create 1000 \
    --security-policy my-policy \
    --expression "evaluatePreconfiguredWaf('sqli-v422-stable')" \
    --action deny-403

Tool zur Bedingungserstellung für Abgleich verwenden

Das Tool zur Bedingungserstellung ist eine visuelle Oberfläche in der Google Cloud -Console, mit der Sie komplexe Cloud Armor-Regelausdrücke erstellen können, ohne CEL-Code (Common Expression Language) schreiben zu müssen. Anstatt Code zu schreiben, können Sie die strukturierte Benutzeroberfläche des Builders verwenden, um Bedingungen und Gruppenlogik zu kombinieren. So können Sie Syntaxfehler vermeiden und Ihre Regelstruktur besser visualisieren. Der Builder unterstützt flache Listen und verschachtelte Logik mit bis zu fünf Ausdrucksebenen. Verwenden Sie dieses Tool, wenn Sie Regeln zum Schutz von Multi-Cloud-Backends oder Hybridbereitstellungen konfigurieren, bei denen Sie möglicherweise bestimmte Anfrageattribute prüfen müssen, bevor Sie Traffic weiterleiten.

Funktionen des Tools zur Bedingungserstellung für Abgleich

Das Tool zur Bedingungserstellung für den Abgleich bietet die folgenden Funktionen:

  • Logik und Verschachtelung: Kombinieren Sie mehrere Bedingungen mit den Operatoren AND und OR. Der Builder unterstützt das Gruppieren und Verschachteln von bis zu fünf Ausdrücken.
  • Stringtransformationen: Für stringbasierte Attribute (z. B. request.path oder request.headers) werden Transformationen angewendet, um Daten vor der Auswertung zu normalisieren. Zu den unterstützten Transformationen gehören:
    • Klein- und Großbuchstaben
    • Base64-Decodierung
    • URL decodieren und URL decodieren (Unicode)
    • UTF-8 in Unicode umwandeln
  • Bidirektionales Parsen: Wechseln Sie zwischen dem visuellen Tool zur Bedingungserstellung und dem Editor für Übereinstimmungsbedingungen im Nur-Text-Format. Die Benutzeroberfläche parst CEL-Rohcode automatisch in visuelle Blöcke.
  • Funktionsunterstützung: Der Builder bietet UI-Steuerelemente für funktionsbasierte Ausdrücke wie vorkonfigurierte WAF-Regeln, Adressgruppen und Threat Intelligence.

Beschränkungen

Das Tool zur Bedingungserstellung für den Abgleich ist die Standardoberfläche für die Erstellung erweiterter Regeln. Wenn ein Ausdruck nicht unterstützte Logik enthält (z. B. unbekannte Makros), ist der Builder deaktiviert. Verwenden Sie in diesen Fällen den Rohtext im Editor für Übereinstimmungsbedingungen, um die Regel zu bearbeiten.

Außerdem hängt die Verfügbarkeit bestimmter Ausdrücke im Builder von der Google Cloud Armor Enterprise-Stufe Ihres Projekts und dem Typ der Sicherheitsrichtlinie ab.

Beispielausdrücke

Im Folgenden finden Sie Beispielausdrücke. Weitere Informationen zu unterstützten Vorgängen und Attributen finden Sie unter Vorgänge und Attribute.

Wenn Ihre Regel oder Ihr Ausdruck Länder- oder Regionscodes im Format ISO 3166-1 alpha-2 verwendet, behandelt Cloud Armor jeden Code unabhängig. Die Regeln und Ausdrücke von Cloud Armor verwenden diese Codes, um Anfragen zuzulassen oder abzulehnen.

  • Der folgende Ausdruck stimmt mit Anfragen von der IP-Adresse 1.2.3.4 überein, die den String example im User-Agent-Header enthalten:

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

    Alternativ können Sie den IP-Adressbereich eines benutzerdefinierten Client-IP-Adressheaders mit dem Attribut origin.user_ip abgleichen:

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

  • Der folgende Ausdruck stimmt mit Anfragen überein, die ein Cookie mit einem bestimmten Wert enthalten:

    has(request.headers['cookie']) && request.headers['cookie'].contains('cookie_name=cookie_value')

  • Der folgende Ausdruck stimmt mit Anfragen aus der Region AU überein:

    origin.region_code == 'AU'

  • Der folgende Ausdruck stimmt mit Anfragen aus der Region AU überein, die nicht im angegebenen IP-Bereich liegen:

    origin.region_code == "AU" && !inIpRange(origin.ip, '1.2.3.0/24')

  • Der folgende Ausdruck stimmt mit Anfragen mit einem nummerierten Variablenpfad zu einer bestimmten Datei überein, falls der URI mit einem regulären Ausdruck übereinstimmt:

    request.path.matches('/path/[0-9]+/target_file.html')

  • Der folgende Ausdruck stimmt mit Anfragen überein, wenn der Base64-decodierte Wert des user-id-Headers einen bestimmten Wert enthält:

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

  • Der folgende Ausdruck verwendet einen vorkonfigurierten Ausdruckssatz aus dem OWASP CRS 4.22-Regelsatz, um SQLi-Angriffe abzuwehren:

    evaluatePreconfiguredWaf('sqli-v422-stable')

Path Traversal und Normalisierung

Normalisieren Sie Inhalte in Ihren pfadbasierten Regeln, um Regeln für die Pfaddurchquerung und Codierung zu verwalten und allgemeine Regeln zu erstellen, die Groß- und Kleinschreibung oder inhaltsspezifische Codierung vermeiden.

Wenn Sie Regeln schreiben, die startsWith, endsWith oder contains verwenden, um Übereinstimmungen mit request.path zu finden, verwenden Sie lower und urlDecode, um den Pfad vor dem Abgleich zu normalisieren. So wird verhindert, dass die Filterung durch URL-Codierung oder Groß-/Kleinschreibung umgangen wird.

Wenn Sie beispielsweise den Zugriff auf das Verzeichnis /admin blockieren möchten, verwenden Sie den folgenden Ausdruck:

request.path.lower().urlDecode().startsWith('/admin')

Diese Regel blockiert Anfragen für /admin, /Admin, /a%64min und andere Varianten.

Wenn Sie Regeln schreiben, die matches verwenden, um Übereinstimmungen mit request.path zu finden, müssen Sie den umgekehrten Schrägstrich (\) in Ihrem regulären Ausdruck berücksichtigen.

Wenn Sie beispielsweise den Zugriff auf das Verzeichnis /admin blockieren möchten, verwenden Sie den folgenden Ausdruck, um Umgehungen zu blockieren, die den Backslash (\) verwenden:

request.path.matches(r'^/\\*admin')

Kombinieren Sie dies mit urlDecode, um sowohl die URL-Codierung als auch die Umgehung des Backslash-Zeichens (\) zu verarbeiten:

request.path.urlDecode().matches(r'^/\\*admin')

Regeln für Sicherheitsrichtlinien ansehen

In den folgenden Abschnitten wird beschrieben, wie Sie die in einer Sicherheitsrichtlinie konfigurierten Regeln auflisten und verfügbare vorkonfigurierte WAF-Regeln aufrufen können.

Regeln in einer Sicherheitsrichtlinie auflisten

Folgen Sie der Anleitung in diesem Abschnitt, um die Regeln in einer Cloud Armor-Sicherheitsrichtlinie aufzulisten.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Cloud Armor-Richtlinien auf.

    Zu Cloud Armor-Richtlinien

  2. Klicken Sie auf den Namen der jeweiligen Sicherheitsrichtlinie. Auf der Seite Richtliniendetails werden die Richtlinienregeln auf dem Tab Regeln angezeigt.

gcloud

Verwenden Sie den folgenden gcloud-Befehl, um alle Regeln in einer Sicherheitsrichtlinie aufzulisten:

gcloud compute security-policies describe NAME

Verwenden Sie den folgenden gcloud-Befehl, um alle Regeln in einer einzelnen Sicherheitsrichtlinie in einer bestimmten Region zusammen mit einer Beschreibung der Richtlinie aufzulisten:

gcloud compute security-policies describe NAME \
  --region REGION

Verwenden Sie den folgenden gcloud-Befehl, um eine Regel zu beschreiben:

gcloud compute security-policies rules describe PRIORITY \
    --security-policy POLICY_NAME

Der folgende Befehl beschreibt zum Beispiel die Regel mit der Priorität 1.000 in der Sicherheitsrichtlinie my-policy:

gcloud compute security-policies rules describe 1000 \
    --security-policy my-policy

Ausgabe: 

action: deny(403)
description: block traffic from 192.0.2.0/24 and 198.51.100.0/24
kind: compute#securityPolicyRule
match:
  srcIpRanges:
  - '192.0.2.0/24'
  - '198.51.100.0/24'
preview: false
priority: 1000

Weitere Informationen finden Sie unter gcloud compute security-policies describe.

Verfügbare vorkonfigurierte Regeln auflisten

Zusätzlich zu den Regeln, die Sie selbst konfigurieren, bietet Cloud Armor vorkonfigurierte Regeln, die Sie in Ihren Sicherheitsrichtlinien verwenden können. Sie können vorkonfigurierte Regeln auflisten, um die vordefinierten Anwendungsschutzregeln und -signaturen wie das von Cloud Armor bereitgestellte OWASP Core Rule Set (CRS) anzeigen zu lassen. Diese Regeln enthalten integrierte Signaturen, die Cloud Armor anhand eingehender Anfragen auswertet. Sie können diese vorkonfigurierten Regeln mithilfe der Sprache für benutzerdefinierte Regeln neuen oder vorhandenen Regeln hinzufügen. Wir empfehlen, nach Möglichkeit die neueste CRS-Regelversion zu verwenden.

gcloud

  1. Führen Sie den Befehl gcloud compute security-policies list-preconfigured-expression-sets aus:

    gcloud compute security-policies list-preconfigured-expression-sets

    Das folgende Beispiel zeigt die Form der Befehlsausgabe:

    EXPRESSION_SET
expression-set-1
   RULE_ID                SENSITIVITY
   expression-set-1-id-1  sensitivity-value-1
   expression-set-1-id-2  sensitivity-value-2
expression-set-2
   alias-1
   RULE_ID                SENSITIVITY
   expression-set-2-id-1  sensitivity-value-1
   expression-set-2-id-2  sensitivity-value-2

    Das folgende Beispiel enthält ein Beispiel der tatsächlichen Befehlsausgabe. Beachten Sie, dass die tatsächliche Ausgabe alle Regeln enthält, die unter Cloud Armor-WAF-Regeln abstimmen aufgeführt sind.

    gcloud compute security-policies list-preconfigured-expression-sets

    EXPRESSION_SET
sqli-canary
    RULE_ID                          SENSITIVITY
    owasp-crs-v042200-id942120-sqli  2
    …
xss-canary
    RULE_ID                         SENSITIVITY
    owasp-crs-v042200-id941110-xss  1
    owasp-crs-v042200-id941120-xss  2
…
sourceiplist-fastly
sourceiplist-cloudflare
sourceiplist-imperva

Vorgänge

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.

Vorgänge Ausdrücke Beschreibung
Gleichberechtigung x == y Gibt true zurück, wenn x gleich y ist.
Gleichheit, Stringliteral x == "foo" Gibt true zurück, wenn x mit dem angegebenen konstanten Stringliteral übereinstimmt.
Gleichheit, Rohstringliteral x == R"fo'o" Gibt true zurück, wenn x mit dem angegebenen Rohstringliteral übereinstimmt, das keine Escapesequenzen interpretiert. Raw-String-Literale eignen sich gut für die Darstellung von Strings, die ihrerseits Escape-Sequenz-Zeichen verwenden müssen.
Logisches NOT !x Gibt true zurück, wenn der boolesche Wert x false ist, oder false, wenn der boolesche Wert x true ist.
Ungleichheit x != y Gibt true zurück, wenn x ungleich y ist.
Verkettung x + y Gibt den verketteten String xy zurück.
Logisches AND x && y Gibt true zurück, wenn sowohl x als auch y true sind.
Logisches OR x || y Gibt true zurück, wenn x, y oder beide true sind.
Enthält Teilstring x.contains(y) Gibt true zurück, wenn der String x den Teilstring y enthält.
Beginnt mit Teilstring x.startsWith(y) Gibt true zurück, wenn der String x mit dem Teilstring y beginnt.
Endet mit Teilstring x.endsWith(y) Gibt true zurück, wenn der String x mit dem Teilstring y endet.
Übereinstimmung mit regulärem Ausdruck. 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.
IP-Adresse im Bereich inIpRange(x, y) Gibt true zurück, wenn die IP-Adresse x im IP-Bereich y enthalten ist.
Kleinschreibung x.lower() Gibt den Kleinbuchstabenwert des Strings x zurück
Großbuchstabe x.upper() Gibt den Großbuchstabenwert des Strings x zurück
Base64-decodierter Wert x.base64Decode() Gibt den base64-decodierten Wert von x zurück. Der Unterstrich (_) und der Bindestrich (-) werden zuerst durch einen Schrägstrich (/) bzw. ein Pluszeichen (+) ersetzt. Gibt "" (leeren String) zurück, wenn x kein gültiger base64-Wert ist.
Schlüsselzuordnungswert m['k'] Gibt den Wert am 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 mit "has(m['k'])==true" zu prüfen.
Verfügbarkeit von Schlüsseln in einer Karte prüfen has(m['k']) Gibt true zurück, wenn der Schlüssel k in der Map m verfügbar ist.
In Ganzzahl konvertieren 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.
Länge size(x) Gibt die Länge des Strings x zurück.
URL decodieren 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.
URL decodieren (Unicode) 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.
UTF-8 in Unicode umwandeln x.utf8ToUnicode() Gibt die Kleinbuchstaben-Unicode-Darstellung einer UTF-8-codierten Verschlüsselungx zurück.
Vorhanden m.exists(k, expr) Gibt true zurück, wenn mindestens ein Eintrag in der Zuordnung m die Bedingung expr erfüllt, wobei k den Schlüssel jedes Zuordnungseintrags darstellt.
Eine vorhanden m.exists_one(k, expr) Gibt true zurück, wenn genau ein Eintrag in der Zuordnung m die Bedingung expr erfüllt, wobei k den Schlüssel jedes Zuordnungseintrags darstellt.
Alle m.all(k, expr) Gibt true zurück, wenn alle Einträge in der Map m die Bedingung expr erfüllen, wobei k den Schlüssel jedes Map-Eintrags darstellt.
Filter m.filter(k, expr) Gibt eine Zuordnung zurück, die nur die Einträge aus der Zuordnung m enthält, die expr erfüllen, wobei k den Schlüssel jedes Zuordnungseintrags darstellt.
Karte m.map(k, expr) Gibt eine Liste mit dem Ergebnis der Auswertung von expr für jeden Schlüssel in der Zuordnung m zurück, wobei k den Schlüssel jedes Zuordnungseintrags darstellt.

Attribute

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

Feld Typ Feldbeschreibung
origin.ip String Die IP-Adresse des Clients, der die Anfrage initiiert hat.
origin.user_ip String Die IP-Adresse des ursprünglichen Clients, die von einem Upstream-Proxy in den HTTP-HEADER eingefügt wird. Bevor Sie dieses Attribut verwenden, müssen Sie die Option userIpRequestHeaders[] im Feld advancedOptionsConfig der Sicherheitsrichtlinie so konfigurieren, dass sie mit einer Quelle wie True-Client-IP, X-Forwarded-For oder X-Real-IP übereinstimmt. Weitere Informationen finden Sie unter Übersicht über Nutzer-IP-Adressen.

Wenn Sie die Option userIpRequestHeaders[] nicht konfigurieren, 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_ja4_fingerprint String JA4-TLS/SSL-Fingerabdruck, wenn der Client eine Verbindung über HTTPS, HTTP/2 oder HTTP/3 herstellt. Wenn nicht verfügbar, wird ein leerer String zurückgegeben.
origin.tls_ja3_fingerprint String JA3-TLS/SSL-Fingerabdruck, wenn der Client eine Verbindung über HTTPS, HTTP/2 oder HTTP/3 herstellt. Wenn 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 hat, ist der entsprechende Wert in dieser Zuordnung ein einzelner String, der alle Werte durch Kommas getrennt enthält. Die Schlüssel in dieser Zuordnung sind alle kleingeschrieben. Die externen Application Load Balancer prüfen alle akzeptierten Header und es gelten die gleichen Header-Einschränkungen.

Verwenden Sie has(), um die Verfügbarkeit zu prüfen, z. B. has(request.headers['header-key']) && request.headers['header-key'] != 'header-value'.

Sie können die Map iterieren, um sowohl Schlüssel als auch Werte zu prüfen. Sie können jedoch nur Map-Iterationsoperatoren (exists(), exists_one(), all(), filter() und map()) für request.headers in Kombination mit request.body oder request.params im selben Ausdruck verwenden, z. B. request.body && request.headers.exists(k, k.lower().startsWith('header-prefix')).
request.body String Stellt den Anfragetext als Rohstring dar. Es kann Daten eines beliebigen Content-Type darstellen. Der Inhalt wird als String ohne automatisches Parsen gespeichert.
request.params Karte Eine Zuordnung von Schlüssel/Wert-Paaren, die an die URL angehängt oder in den Text von Anfragen aufgenommen werden.
URI-Anfrage: name1=value1&name2=value2
JSON-Anfragetext mit Content-Type: application/json:
{ "username": "johndoe", "email": "johndoe@example.com" }
GraphQL-POST-Anfragetext mit Content-Type: application/graphql:
{ Username: "exampleUser", query: "/* other fields */" }
Formular-POST-Anfragetext mit Content-Type: application/x-www-form-urlencoded:
"username=exampleUser&email=johndoe%40example.com"
request.method String Die HTTP-Anfragemethode.
request.path String Der angeforderte HTTP-URL-Pfad. Wenn Sie Regeln schreiben, die mit request.path übereinstimmen, empfehlen wir, den Pfad zu normalisieren, um die Syntax im Falle von URL-Codierung, Groß-/Kleinschreibung oder Backslashes zu vereinfachen. Weitere Informationen und Beispiele finden Sie unter Pfaddurchlauf und Normalisierung.
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 Client-IP-Adresse zugeordnet ist, z. B. US. Wenn Sie eine Regel oder einen Ausdruck erstellen, die bzw. der die Länder- oder Regionscodes im Format ISO 3166-1 alpha 2 verwendet, behandelt Cloud Armor jeden Code unabhängig. Die Regeln und Ausdrücke von Cloud Armor verwenden diese Regionscodes explizit, um Anfragen zuzulassen oder abzulehnen.
origin.asn integer Die ASN (Autonomous System Number), die der Client-IP-Adresse zugeordnet ist. Die global eindeutige ASN wird anhand des Netzbetreibers bestimmt, der die IP-Adresspräfixe unterstützt, die die Client-IP-Adresse enthalten.

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 basierend auf einem benutzerdefinierten Client-IP-Adressbereich 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-Header zulassen oder ablehnen

Sie können Traffic basierend auf dem Wert des Headers Host in der Anfrage zulassen oder ablehnen.

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

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

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

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

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

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

  • Der folgende Ausdruck stimmt mit Anfragen an mehrere Domains mit contains überein:

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

  • Der folgende Ausdruck stimmt mit Anfragen für eine Domain und ihre Subdomains mit matches überein:

    request.headers['host'].matches('(?i:(?:sub\.)?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 ISO 3166-1 alpha-2-Codes. 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 Netzwerkbetreibern ü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 /example_path/ im URI enthalten:

    request.path.matches('/example_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, der einen Stringwert einer bestimmten Länge enthält, 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 entspricht Anfragen, die einen Header x-data mit einer Länge von mindestens 1.024 Zeichen haben:

    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 Cookiewert %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 Cookiewert 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 JA4-Fingerabdruck zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen überein, die einen JA4-Fingerabdruck gleich t13d1516h2_8daaf6152771_b186095e22b6 haben:

    origin.tls_ja4_fingerprint == 't13d1516h2_8daaf6152771_b186095e22b6'

Traffic basierend auf einer Liste von JA4-Fingerabdrücken zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen überein, deren JA4-Fingerabdruck mit einem der folgenden JA4-Fingerabdrücke übereinstimmt:

    • t00d0000h0_000000000000_000000000000
    • t13d1516h2_8daaf6152771_b186095e22b6
    origin.tls_ja4_fingerprint == 't00d0000h0_000000000000_000000000000' || origin.tls_ja4_fingerprint == 't13d1516h2_8daaf6152771_b186095e22b6'

Traffic basierend auf dem Inhalt des Anfragetexts zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit POST-Anfragen überein, die malicious-value im Anfragetext enthalten:

    request.method == 'POST' && request.body.contains('malicious-value')

  • Der folgende Ausdruck stimmt mit Anfragen überein, die mit <!DOCTYPE html> beginnen:

    request.body.startsWith('<!DOCTYPE html>')

  • Der folgende Ausdruck entspricht Anfragen, bei denen der Text mit dem regulären Ausdruck \w+@\w+.com übereinstimmt:

    request.body.matches('\w+@\w+.com')

Traffic basierend auf Anfrageparametern zulassen oder ablehnen

  • Der folgende Ausdruck stimmt mit Anfragen überein, die keinen Parameter namens category enthalten:

    !has(request.params.category)

  • Der folgende Ausdruck stimmt mit Anfragen überein, bei denen der Parameter category den Wert electronics hat:

    request.params.category == 'electronics'

  • Der folgende Ausdruck stimmt mit Anfragen überein, bei denen alle Parameterwerte nicht leer sind:

    request.params.all(k, request.params[k] != '')

  • Der folgende Ausdruck stimmt mit Anfragen überein, bei denen ein Parameter den String admin enthält:

    request.params.exists(k, request.params[k].contains('admin'))

  • Der folgende Ausdruck stimmt mit Anfragen überein, bei denen genau ein Parametername admin enthält:

    request.params.exists_one(k, k.contains('admin'))

  • Der folgende Ausdruck entspricht Anfragen, bei denen mindestens ein Parametername id enthält:

    size(request.params.filter(k, k.contains('id'))) > 0

  • Der folgende Ausdruck stimmt mit Anfragen überein, bei denen die Parameterwerte den String admin enthalten:

    request.params.map(k, request.params[k]).contains('admin')

Traffic basierend auf strukturierten Daten im Anfragetext zulassen oder ablehnen

  • Der folgende Ausdruck entspricht Anfragen, bei denen das Feld password in einem JSON-Anfragetext 123 enthält:

    has(request.params.password) && request.params.password.contains('123')

  • Der folgende Ausdruck entspricht Anfragen, bei denen das Feld city in den Formulardaten NewYork ist:

    has(request.params.city) && request.params.city == 'NewYork'

  • Der folgende Ausdruck entspricht Anfragen, bei denen das verschachtelte Feld newsletter den Wert true hat:

    has(request.params.preferences) && has(request.params.preferences.newsletter) && request.params.preferences.newsletter == true

  • Der folgende Ausdruck entspricht Anfragen, bei denen das Feld name des ersten Elements im Array friends den Wert johndoe hat:

    request.params['friends'][0]['name'] == 'johndoe'

Vorkonfigurierte WAF-Regeln

Vorkonfigurierte WAF-Regeln verwenden vorkonfigurierte statische Signaturen, reguläre Ausdrücke oder beides für den Abgleich mit dem HTTP-Anfragetext, den HTTP-Anfrageheadern und den Abfrageparametern. Die verfügbaren vorkonfigurierten WAF-Regeln basieren auf dem OWASP Core Rule Set 4.22. 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 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>-<OWASP 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-Injection).

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-v422-stable enthält beispielsweise den Ausdruck owasp-crs-v042200-id941100-xss, der der Regel-ID id941100 für Version 4.22 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 Core Rule Set und zur Feinabstimmung bei unterschiedlichen Empfindlichkeitsstufen finden Sie unter 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-v422-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 OWASP 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 ein sensitivity 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.
evaluatePreconfiguredWaf(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 kommagetrennte Stringliste mit IDs, die von der Auswertung ausgeschlossen werden müssen. 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-v422-stable, um XSS-Angriffe abzuwenden:

    evaluatePreconfiguredWaf('xss-v422-stable')

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

    evaluatePreconfiguredWaf('xss-v422-stable', {'opt_out_rule_ids': ['owasp-crs-v042200-id941100-xss',
'owasp-crs-v042200-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') && evaluatePreconfiguredWaf('sqli-v422-stable')

  • Der folgende Ausdruck verwendet die vorkonfigurierte WAF-Regel xss-v422-stable, um XSS-Angriffe für Anfragen an example.com abzuwenden, mit Ausnahme von Pfaden, die mit /login/api/ beginnen:

    request.headers['host'].lower() == 'example.com' && !request.path.startswith('/login/api/') && evaluatePreconfiguredWaf('xss-v422-stable')

Andere Operatoren

Ausdrücke Beschreibung
evaluateThreatIntelligence(string)
evaluateThreatIntelligence(string, LIST)
evaluateThreatIntelligence(string, string, LIST)

Gibt true zurück, wenn die Client-IP-Adresse mit einem der IP-Bereiche in der angegebenen IP-Liste übereinstimmt, sofern sie nicht explizit mit der Ausschlussliste ausgeschlossen wurde.

Das erste Argument ist der Name des Google Threat Intelligence-Feeds, z. B. iplist-known-malicious-ips. Wenn das zweite Argument ein String ist (optional), wird damit festgelegt, woher die IP-Adresse extrahiert wird. Es kann entweder origin.ip, origin.user_ip oder ein bestimmter Headername sein. Wenn das zweite oder dritte Argument (optional) eine durch Kommas getrennte Liste von Strings ist, wobei jeder String eine IP-Adresse oder ein CIDR-Bereich ist, wird dieser von der Auswertung ausgeschlossen. Die Ausschlussliste ist nützlich, wenn ein Feed eine IP-Adresse enthält, die ein falsch-positives Ergebnis auslöst.
evaluateAddressGroup(string, string)
evaluateAddressGroup(string, string, LIST)

evaluateOrganizationAddressGroup(string, string)
evaluateOrganizationAddressGroup(string, string, LIST)

Gibt true zurück, wenn die Client-IP-Adresse mit einem der IP-Bereiche in der angegebenen Adressgruppe übereinstimmt, es sei denn, sie wurde explizit mit der Ausschlussliste ausgeschlossen.

Das erste Argument ist der Name der Adressgruppe. Das zweite Argument bestimmt, woher die IP-Adresse extrahiert wird. Es kann entweder origin.ip, origin.user_ip oder ein bestimmter Headername sein. Das dritte Argument (optional) ist eine durch Kommas getrennte Liste von Strings, wobei jeder String eine IP-Adresse oder ein CIDR-Bereich ist, die von der Auswertung ausgeschlossen werden. Die Ausschlussliste ist nützlich, wenn eine Adressgruppe eine IP-Adresse enthält, die ein falsch-positives Ergebnis auslöst.
evaluateAdaptiveProtection(string)

Gibt true zurück, wenn die Anfrage mit der Angriffssignatur übereinstimmt, die von Google Cloud Armor Adaptive Protection generiert wurde.

Das Argument ist die ID einer bestimmten Benachrichtigung, die von Adaptive Protection generiert wird, wenn ein Angriff erkannt wird.
evaluateAdaptiveProtectionAutoDeploy()

Gibt true zurück, wenn die Anfrage von einer Heavy-Hitter-IP-Adresse stammt, die der Angriffssignatur eines laufenden Angriffs entspricht, der von Adaptive Protection erkannt wurde.

Beispiele

  • Der folgende Ausdruck gleicht die eingehende Anfrage mit dem Google Threat Intelligence-Feed iplist-known-malicious-ips ab, um Schutz vor der bekannten Liste schädlicher IP-Adressen zu bieten:

    evaluateThreatIntelligence('iplist-known-malicious-ips')

  • Der folgende Ausdruck gleicht die eingehende Anfrage mit dem Google Threat Intelligence-Feed iplist-known-malicious-ips ab, um Schutz vor der bekannten Liste schädlicher IP-Adressen zu bieten, mit Ausnahme von IP-Adressen in 203.0.113.0/24:

    evaluateThreatIntelligence('iplist-known-malicious-ips', ['203.0.113.0/24'])

  • Der folgende Ausdruck gleicht den benutzerdefinierten Anfrageheader für die Nutzer-IP mit der Adressgruppe my-own-list-of-bad-ips ab:

    evaluateAddressGroup('my-own-list-of-bad-ips', origin.user_ip)

Nächste Schritte