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 Ausschluss von Anfragefeldern mit einer WAF-Regel verknüpft haben, können Sie die Aktion allow nicht verwenden.

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 von Anfrageheadernamen, deren Wert während der Prüfung von der Prüfung ausgeschlossen wird vorkonfigurierte WAF-Regelauswertung.

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 mit Namen von Anfragecookies, deren Wert während der Prüfung von der Prüfung ausgeschlossen wird vorkonfigurierte WAF-Regelauswertung.

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-Abfrageparametern, 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, 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.

Feldwerte

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

Für Anfrage-Header, Anfrage-Cookies und Anfrage-Suchparameter Der zulässige Zeichensatz für Feldwerte enthält die folgenden Zeichen:

  • !, #, $, %, &, *, +, -, ., ^, _, `, |, ~
  • Alphabetische Zeichen A bis Z (sowohl Klein- als auch Großbuchstaben)
  • Ziffern 0 bis 9

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

Bei Anfrage-URIs muss der Feldwert im folgenden URI-Format angegeben werden:

  • Ein Schema ist zulässig, aber nur 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 für Anfrage-URIs sind die konfigurierten Feldwerte verglichen mit den URIs (Groß-/Kleinschreibung nicht berücksichtigend, nach der Transformation) aus der Anfragezeile ohne den Abfragestring aus. Die URIs in der Anfragezeile können relativ oder absolut sein. Berücksichtigen Sie dies bei der Konfiguration 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, Der Content-Type-Header gibt das Format der Daten im Anfragetext an. Von behandelt Google Cloud Armor den Inhalt des POST-Textkörpers die alle für die Prüfung und den Abgleich in Ihrem vorkonfigurierten WAF-Regeln. Sie können jedoch ein genaueres Parsing konfigurieren, wenn Ihre haben eingehende Anfragen eine andere Codierung. Google Cloud Armor unterstützt die folgenden Codierungstypen:

  • JSON
  • GraphQL

Weitere Informationen findest du unter Parsing des POST-Textinhalts.

Nächste Schritte