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 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 mit Namen von Anfragesuchparametern, deren Wert von der Prüfung ausgeschlossen ist bei der Auswertung vorkonfigurierter WAF-Regeln.
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 verwendet werden sollen während der Auswertung vorkonfigurierter WAF-Regeln von der Prüfung ausgeschlossen.
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
Für Anfrage-Header, Anfrage-Cookies und Anfrage-Suchparameter Der zulässige Zeichensatz für Feldwerte enthält die folgenden Zeichen:
!
,#
,$
,%
,&
,*
,+
,-
,.
,^
,_
,`
,|
,~
- Alphazeichen
A
bisZ
(Groß- und Kleinschreibung) - Ziffern
0
bis9
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. Es wird nicht erwartet, dass Sie weitere Codierung, wenn Sie ein bestimmtes Zeichen ausschließen möchten, das nicht im zulässigen Zeichensatz.
Für Anfrage-URIs muss der Feldwert im folgenden URI-Format angegeben werden:
- Ein Schema ist zulässig, ist jedoch 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 aus der Anfragezeile kann relativ oder absolut sein. Beachten Sie das bei der Konfiguration Ausschlüsse 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"
Parsen 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
- Sicherheitsrichtlinien konfigurieren
- Verfügbare Regelsignaturen für vorkonfigurierte WAF-Regeln
- Weitere Informationen zu vorkonfigurierten WAF-Regeln finden Sie in der Referenz zur Sprache für benutzerdefinierte Regeln.