Vorkonfigurierte WAF-Regeln von Google Cloud Armor optimieren

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 xss-v33-stable (CRS 3.3) ausgeschlossen:

evaluatePreconfiguredWaf('xss-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 Anfrageheadernamen (ohne Berücksichtigung der Groß- und Kleinschreibung, nach deren Transformation), deren Wert während der Auswertung der vorkonfigurierten WAF-Regel von der Prüfung ausgeschlossen wird.

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 Anfrage-Cookienamen (ohne Berücksichtigung der Groß- und Kleinschreibung, nach deren Transformation), deren Wert während der Auswertung der vorkonfigurierten WAF-Regel 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 Anfrage-Abfrageparameter (ohne Berücksichtigung der Groß- und Kleinschreibung, nach deren Transformation), deren Wert während der Auswertung der vorkonfigurierten WAF-Regel 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 von URIs aus der Anfragezeile ohne die Abfragestringdaten (ohne Berücksichtigung der Groß- und Kleinschreibung, nach deren Transformation), die während der Auswertung der vorkonfigurierten WAF-Regel 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.

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 beta 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 beta 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 beta 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"

JSON-Parsing auf benutzerdefinierte Content-Type-Headerwerte anwenden

Bei der Auswertung des POST-Texts anhand vorkonfigurierter WAF-Regeln gibt der Header Content-Type das Format der Daten im Anfragetext an. Das JSON-Parsing wird standardmäßig nur angewendet, wenn es aktiviert und der Header Content-Type auf application/json gesetzt ist. Sie können jedoch eine Liste benutzerdefinierter Content-Type-Headerwerte konfigurieren, für die das JSON-Parsing angewendet werden soll. Im folgenden Beispiel wird die Sicherheitsrichtlinie POLICY_NAME aktualisiert, um das JSON-Parsing zu aktivieren, und es werden die Inhaltstypen application/json, application/vnd.api+json, application/vnd.collection+json und application/vnd.hyper+json 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"

Die Prüfung des POST-Texts ist weiterhin 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, sodass der JSON-Parser eine unvollständige Liste von Name/Wert-Parametern zurückgibt, werden die bisher geparsten Ergebnisse für die Parameterprüfung verwendet.

  • 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