Vorkonfigurierte WAF-Regeln von Google Cloud Armor optimieren

Google Cloud Armor bietet vorkonfigurierte WAF-Regeln, die jeweils aus mehreren Signaturen aus dem ModSecurity Core Rule Set (CRS) bestehen. Jede Signatur entspricht einer Angriffserkennungsregel im Regelsatz. Eingehende Anfragen werden anhand der vorkonfigurierten WAF-Regeln bewertet. Eine Anfrage entspricht einer vorkonfigurierten WAF-Regel, wenn die Anfrage mit einer der Signaturen übereinstimmt, die mit der vorkonfigurierten WAF-Regel verknüpft sind. Eine Übereinstimmung wird hergestellt, wenn der Ausdruck evaluatePreconfiguredWaf() oder evaluatePreconfiguredExpr() den Wert true zurückgibt.

Empfindlichkeitsstufe auswählen

Jede Signatur hat eine Empfindlichkeitsstufe, die einer ModSecurity-Paranoia-Stufe entspricht. Sie können eine Empfindlichkeit zwischen 0 und 4 auswählen, obwohl die Empfindlichkeitsstufe 0 bedeutet, dass standardmäßig keine Regeln aktiviert sind.

Eine niedrigere Empfindlichkeitsstufe weist auf Signaturen mit höherer Konfidenz hin, die mit geringerer Wahrscheinlichkeit ein falsch-positives Ergebnis generieren. Eine höhere Empfindlichkeitsstufe erhöht die Sicherheit, erhöht aber auch das Risiko, ein falsch-positives Ergebnis zu erzeugen. Wenn Sie eine Empfindlichkeitsstufe für die WAF-Regel auswählen, aktivieren Sie Signaturen auf Empfindlichkeitsstufen, die kleiner oder gleich der ausgewählten Empfindlichkeitsstufe sind. Im folgenden Beispiel optimieren Sie eine vorkonfigurierte WAF-Regel, indem Sie die Empfindlichkeitsstufe von 1 auswählen:

evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 1})

Regelsignaturen deaktivieren

Wenn Sie entscheiden, dass eine vorkonfigurierte WAF-Regel mehr Anfragen entspricht als erforderlich, oder wenn die Regel den zulässigen Traffic blockiert, kann die Regel so eingestellt werden, dass fehlerhafte oder anderweitig unnötige Signaturen deaktiviert werden. Um Signaturen in einer bestimmten vorkonfigurierten WAF-Regel zu deaktivieren, stellen Sie dem Ausdruck evaluatePreconfiguredWaf() eine Liste der IDs der unerwünschten Signaturen zur Verfügung.

Im folgenden Beispiel werden zwei CRS-Regel-IDs aus der vorkonfigurierten WAF-Regel sqli-v33-stable (CRS 3.3) ausgeschlossen:

evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 4, 'opt_out_rule_ids': ['owasp-crs-v030301-id942350-sqli', 'owasp-crs-v030301-id942360-sqli']})

Wenn Sie Signatur-IDs aus vorkonfigurierten CRS-Regelsätzen deaktivieren, müssen Sie die Signatur-ID-Version mit der Regelsatzversion (CRS 3.0 oder 3.3) abgleichen, um Konfigurationsfehler zu vermeiden.

Sie können Signatur-IDs auch mit dem Legacy-Ausdruck evaluatePreconfigureExpr() deaktivieren. Weitere Informationen zu vorkonfigurierten WAF-Regelausdrücken finden Sie in der Referenz zur Sprache für benutzerdefinierte Regeln.

Regelsignaturen aktivieren

Anstatt Regelsignaturen zu deaktivieren, können Sie Regelsignaturen in ansonsten deaktivierten Empfindlichkeitsstufen aktivieren. Wir empfehlen, Regelsignaturen zu aktivieren, wenn es weniger Signaturen gibt, die Sie auf einer bestimmten Empfindlichkeitsstufe verwenden möchten, als es Regeln gibt, die Sie deaktivieren möchten. Um die Signaturen zu aktivieren, muss die Empfindlichkeitsstufe 0 sein. Im folgenden Beispiel werden alle cve-canary-Signaturen aller Empfindlichkeitsstufen deaktiviert und dann explizit owasp-crs-v030001-id044228-cve und owasp-crs-v030001-id144228-cve aktiviert:

evaluatePreconfiguredWaf('cve-canary', {'sensitivity': 0, 'opt_in_rule_ids': ['owasp-crs-v030001-id044228-cve', 'owasp-crs-v030001-id144228-cve']})

Anfragefelder von der Prüfung ausschließen

Ihre benutzerdefinierte Anwendung enthält möglicherweise Inhalte in Anfragefeldern (Header, Cookies, Abfrageparameter oder URIs), die mit Signaturen in vorkonfigurierten WAF-Regeln übereinstimmen, von denen Sie aber wissen, dass sie zulässig sind. In diesem Fall können Sie die falsch-positiven Ergebnisse reduzieren, indem Sie diese Anfragefelder von der Prüfung ausschließen. Dazu verknüpfen Sie eine Liste von Ausschlüssen für Anfragefelder mit der Sicherheitsrichtlinienregel.

Wenn Sie einen Anfragefeldausschluss konfigurieren, verknüpfen Sie ihn mit einem Ziel. Dies kann eine gesamte vorkonfigurierte WAF-Regel oder eine Liste von Signaturen unter einer vorkonfigurierten WAF-Regel sein. Mit einem Feldoperator und einem Feldwert können Sie eine genaue oder eine teilweise Übereinstimmung angeben. Folgende Feldoperatoren sind verfügbar:

  • EQUALS: Der Operator stimmt überein, wenn der Feldwert mit dem angegebenen Wert übereinstimmt.
  • STARTS_WITH: Der Operator stimmt überein, wenn der Feldwert mit dem angegebenen Wert beginnt.
  • ENDS_WITH: Der Operator stimmt überein, wenn der Feldwert mit dem angegebenen Wert endet.
  • CONTAINS: Der Operator stimmt überein, wenn der Feldwert den angegebenen Wert enthält.
  • EQUALS_ANY: Der Operator stimmt überein, wenn der Feldwert ein beliebiger Wert ist.

In den folgenden Abschnitten finden Sie weitere Informationen zu den Anfragefeldern, die Sie von der Prüfung ausschließen können, gefolgt von Beispielen.

Anfrageheader

Eine Liste der Namen von Anfrageheadern, deren Wert bei der Auswertung vorkonfigurierter WAF-Regeln von der Prüfung ausgeschlossen ist.

Der Ausschluss gilt nur für Signaturen im Ziel, die den Wert des Anfrageheaders ursprünglich prüfen würden. Dazu gehören Signaturen, die mit dem folgenden Anfrage-Flag im ModSecurity Core Rule Set verknüpft sind:

  • REQUEST_HEADERS

Nur der Wert der angegebenen Anfrageheader wird von der Prüfung ausgeschlossen. Der Name wird aber geprüft.

Anfrage-Cookies

Eine Liste der Namen von Anfragecookienamen, deren Wert bei der Auswertung vorkonfigurierter WAF-Regeln von der Prüfung ausgeschlossen wird.

Der Ausschluss gilt nur für Signaturen im Ziel, die den Wert des Anfrage-Cookies ursprünglich prüfen würden. Dazu gehören Signaturen, die mit dem folgenden Anfrage-Flag im ModSecurity Core Rule Set verknüpft sind:

  • REQUEST_COOKIES

Nur der Wert der angegebenen Anfrage-Cookies wird von der Prüfung ausgeschlossen. Der Name wird aber geprüft.

Anfrage-Abfrageparameter

Eine Liste der Namen von Anfrageparametern, deren Wert bei der Auswertung vorkonfigurierter WAF-Regeln von der Prüfung ausgeschlossen wird.

Der Ausschluss gilt nur für Signaturen im Ziel, die den Wert der Anfrageparameter ursprünglich prüfen würden. Dazu gehören Signaturen, die mit den folgenden Anfrage-Flags im ModSecurity Core Rule Set verknüpft sind:

  • ARGS
  • ARGS_GET
  • REQUEST_URI
  • REQUEST_URI_RAW
  • REQUEST_LINE

Nur der Wert der angegebenen Abfrageparameter (die sich im Abfragestring oder im POST-Text befinden können) wird von der Prüfung ausgeschlossen. Der Name wird aber geprüft.

Da Abfrageparameter Teil des URI und der Anfragezeile sind, werden diese Felder nach dem Ausschließen der angegebenen Abfrageparameter für die Prüfung wieder zusammengesetzt. Bei Signaturen, die den gesamten Anfragetext prüfen (z. B. Signaturen, die dem Anfrage-Flag REQUEST_BODY zugeordnet sind), wird der Ausschluss für Abfrageparameter jedoch nicht angewendet.

Wenn Sie beispielsweise einen Abfrageparameter mit dem Namen "args" ausschließen, wird möglicherweise weiterhin eine Übereinstimmung für eine Signatur angezeigt, die den gesamten Anfragetext prüft, wenn die Anfrage einen "args"-Parameter im POST-Text und Wert von "args"-Übereinstimmungen entspricht.

Anfrage-URI

Eine Liste der URIs aus der Anfragezeile mit Ausnahme der Abfragestringdaten, die bei der Auswertung der vorkonfigurierten WAF-Regeln von der Prüfung ausgeschlossen werden sollen.

Der Ausschluss gilt nur für Signaturen im Ziel, die den Wert des Anfrage-URIs ursprünglich prüfen würden. Dazu gehören Signaturen, die mit den folgenden Anfrage-Flags im ModSecurity Core Rule Set verknüpft sind:

  • REQUEST_URI
  • REQUEST_URI_RAW
  • REQUEST_LINE
  • REQUEST_FILENAME
  • REQUEST_BASENAME

Wenn Sie eines der vorherigen Felder ausschließen, wird das Feld vollständig von der Prüfung ausgeschlossen und es wird keine neue Zusammensetzung durchgeführt.

Feldwerte

Sie müssen einen Feldwert angeben, wenn Sie einen anderen Feldoperator als EQUALS_ANY verwenden.

Bei Anfrageheadern, Anfragecookies und Anfrageparametern sind die folgenden Zeichen für Feldwerte zulässig:

  • !, #, $, %, &, *, +, -, ., ^, _, `, |, ~
  • Alphazeichen A bis Z (Groß- und Kleinschreibung)
  • Ziffern 0 bis 9

Beim Anwenden von Ausschlüssen auf diese Anfragefelder werden die konfigurierten Feldwerte unverändert mit den Werten aus der Anfrage (Groß-/Kleinschreibung wird nach der Transformation nicht berücksichtigt) verglichen. Wenn Sie ein bestimmtes Zeichen ausschließen möchten, das nicht im zulässigen Zeichensatz enthalten ist, sollten Sie keine zusätzliche Codierung vornehmen.

Für Anfrage-URIs muss der Feldwert im folgenden URI-Format angegeben werden:

  • Ein Schema ist zulässig, ist aber auf HTTP oder HTTPS beschränkt.
  • Ein Host ist zulässig und kann eine IP-Adresse sein.
  • Ein Port ist zulässig.
  • Ein Pfad ist zulässig.
  • Eine Abfrage ist nicht zulässig.
  • Ein Fragment ist nicht zulässig.

Beim Anwenden von Ausschlüssen auf Anfrage-URIs werden die konfigurierten Feldwerte mit den URIs aus der Anfragezeile verglichen (Groß-/Kleinschreibung wird nicht berücksichtigt, nach der Transformation). Der Abfragestring wird dabei nicht berücksichtigt. Die URIs aus der Anfragezeile können relativ oder absolut sein. Berücksichtigen Sie dies beim Konfigurieren von Ausschlüssen für Anfrage-URIs.

Beispiele

Das erste Beispiel aktualisiert die Regel in der Sicherheitsrichtlinie POLICY_1 für PRIORITY, um eine Ausschlusskonfiguration für alle Signaturen unter der WAF-Regel sqli-v33-stable hinzuzufügen, damit alle Anfrage-Cookies von der Prüfung ausgeschlossen werden:

gcloud compute security-policies rules add-preconfig-waf-exclusion PRIORITY \
    --security-policy POLICY_1 \
    --target-rule-set "sqli-v33-stable" \
    --request-cookie-to-exclude "op=EQUALS_ANY"

Das zweite Beispiel aktualisiert die Regel in der Sicherheitsrichtlinie POLICY_2 für PRIORITY, um eine Ausschlusskonfiguration für die Signaturen owasp-crs-v030301-id941140-xss und owasp-crs-v030301-id941270-xss unter der WAF-Regel xss-v33-stable hinzuzufügen, damit Anfrageheader ausgeschlossen werden, die entweder mit abc beginnen oder mit xyz enden:

gcloud compute security-policies rules add-preconfig-waf-exclusion PRIORITY \
    --security-policy POLICY_2 \
    --target-rule-set "xss-v33-stable" \
    --target-rule-ids "owasp-crs-v030301-id941140-xss" "owasp-crs-v030301-id941270-xss" \
    --request-header-to-exclude "op=STARTS_WITH,val=abc" \
    --request-header-to-exclude "op=ENDS_WITH,val=xyz"

Im dritten Beispiel wird die Regel in der Sicherheitsrichtlinie POLICY_3 für PRIORITY aktualisiert, um alle Anfragefeldausschlüsse für die Regel-IDs owasp-crs-v030301-id942110-sqli und owasp-crs-v030301-id942120-sqli unter sqli-v33-stable zu entfernen.

gcloud compute security-policies rules remove-preconfig-waf-exclusion PRIORITY \
    --security-policy POLICY_3 \
    --target-rule-set "sqli-v33-stable" \
    --target-rule-ids "owasp-crs-v030301-id942110-sqli,owasp-crs-v030301-id942120-sqli"

Parsing auf benutzerdefinierte Content-Type-Headerwerte anwenden

Wenn Google Cloud Armor den POST-Text anhand vorkonfigurierter WAF-Regeln auswertet, gibt der Header Content-Type das Format der Daten im Anfragetext an. Standardmäßig behandelt Google Cloud Armor den Inhalt des POST-Texts als einen String, der alle für die Prüfung und den Abgleich mit Ihren vorkonfigurierten WAF-Regeln geeignet ist. Sie können jedoch ein genaueres Parsen konfigurieren, wenn Ihre eingehenden Anfragen eine andere Codierung haben. Google Cloud Armor unterstützt die folgenden Codierungstypen:

  • JSON
  • GraphQL

Im folgenden Beispiel wird die Liste der benutzerdefinierten Content-Type-Headerwerte konfiguriert, auf die alternatives Parsing angewendet wird. Im Beispiel wird die Sicherheitsrichtlinie POLICY_NAME aktualisiert, um das JSON-Parsing zu aktivieren, und die Inhaltstypen application/json, application/vnd.api+json, application/vnd.collection+json und application/vnd.hyper+json werden angegeben:

gcloud compute security-policies update POLICY_NAME \
    --json-parsing STANDARD \
    --json-custom-content-types "application/json,application/vnd.api+json,application/vnd.collection+json,application/vnd.hyper+json"

Wenn Ihre Sicherheitsrichtlinie eine Anwendung schützt, die GraphQL verwendet oder GraphQL-codierten Inhalt empfängt, können Sie alternativ das Argument STANDARD_WITH_GRAPHQL verwenden, um den POST-Hauptinhalt wie GraphQL-Inhalte zu parsen:

gcloud compute security-policies update POLICY_NAME \
    --json-parsing STANDARD_WITH_GRAPHQL

Die Überprüfung des POST-Texts ist auf die ersten 8 KB beschränkt. Weitere Informationen finden Sie unter Einschränkungen für Sicherheitsrichtlinien.

  • Wenn der JSON-Inhalt größer als 8 KB ist, wendet Google Cloud Armor das JSON-Parsing auf die ersten 8 KB des verwendeten Inhalts an, der durch vorkonfigurierte WAF-Regeln geprüft wird.

  • Wenn der JSON-Parser kein Ergebnis zurückgibt, wird möglicherweise ein URI-Parsing versucht. Wenn der URI-Parser keine oder nur unvollständige Name/Wert-Parameter zurückgibt, wird der gesamte String oder ein Teil davon möglicherweise für die Prüfung als Parametername behandelt.

Nächste Schritte