1. Einführung
Hallo! Willkommen beim Codelab zu vorkonfigurierten WAF-Regeln für Cloud Armor!
Google Cloud Armor ist die Edge-Netzwerksicherheitslösung von Google für Unternehmen, die DDoS-Schutz, die Durchsetzung von WAF-Regeln und adaptive Verwaltbarkeit im großen Maßstab bietet.
Cloud Armor hat die vorkonfigurierten WAF-Regelsätze erweitert, um die OWASP-Top-10-Sicherheitslücken von Webanwendungen zu mindern. Die Regelsätze basieren auf dem OWASP Modsecurity Core Rule Set Version 3.0.2 und schützen vor einigen der häufigsten Sicherheitsrisiken für Webanwendungen, darunter Local File Inclusion (LFI), Remote File Inclusion (RFI) und Remote Code Execution (RCE).
In diesem Codelab erfahren Sie, wie Sie einige der häufigsten Sicherheitslücken mithilfe von Google Cloud Armor-WAF-Regeln minimieren.
Lerninhalte
- Instanzgruppe und globalen Load Balancer zur Unterstützung eines Dienstes einrichten
- Cloud Armor-Sicherheitsrichtlinien mit vorkonfigurierten WAF-Regeln zum Schutz vor LFI, RCE, Scannern, Protokollangriffen und Session Fixation konfigurieren
- So prüfen Sie anhand von Logs, ob Cloud Armor einen Angriff abgewehrt hat.
Voraussetzungen
- Grundkenntnisse von Google Compute Engine ( Codelab)
- Grundkenntnisse in den Bereichen Netzwerk und TCP/IP
- Grundkenntnisse zu Unix/Linux-Befehlszeilen
- Es ist hilfreich, wenn Sie bereits eine Einführung in die Vernetzung in der GCP mit Netzwerke in Google Cloud durchlaufen haben.
- Optional: Führen Sie das Cloudnet20 Cloud Armor-Lab durch, um zu lernen, wie Sie Arbeitslasten mit SQL-Injection-, IP-basierten und standortbasierten Regeln schützen.
Codelab-Topologie und ‑Anwendungsfall

Abbildung 1: Codelab-Topologie für Cloud Armor-WAF-Regeln
Die OWASP Juice Shop-Anwendung ist nützlich für Sicherheitstraining und -bewusstsein, da sie standardmäßig Instanzen von jeder der OWASP-Top-10-Sicherheitslücken enthält. Ein Angreifer kann sie zu Testzwecken ausnutzen. In diesem Codelab verwenden wir sie, um einige Anwendungsangriffe zu demonstrieren und die Anwendung dann mit Cloud Armor-WAF-Regeln zu schützen. Die Anwendung wird von einem Google Cloud Load Balancer bereitgestellt, auf den die Cloud Armor-Sicherheitsrichtlinie und -Regeln angewendet werden. Sie wird im öffentlichen Internet bereitgestellt und ist daher von fast überall aus erreichbar. Sie ist durch Cloud Armor- und VPC-Firewallregeln geschützt.
2. Einrichtung und Anforderungen
Umgebung zum selbstbestimmten Lernen einrichten
- Melden Sie sich in der Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes Projekt. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.



Notieren Sie sich die Projekt-ID, also den projektübergreifend nur einmal vorkommenden Namen eines Google Cloud-Projekts. Der oben angegebene Name ist bereits vergeben und kann leider nicht mehr verwendet werden. Sie wird später in diesem Codelab als PROJECT_ID bezeichnet.
- Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Google Cloud-Ressourcen verwenden zu können.
Die Durchführung dieses Codelabs sollte keine oder nur geringe Kosten verursachen. Folgen Sie bitte der Anleitung im Abschnitt „Bereinigen“, in der Sie erfahren, wie Sie Ressourcen herunterfahren können, damit nach Abschluss dieser Anleitung keine Gebühren anfallen. Neue Nutzer von Google Cloud kommen für das Programm für kostenlose Testversionen mit einem Guthaben von 300$ infrage.
Cloud Shell starten
Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.
Klicken Sie in der GCP Console oben rechts in der Symbolleiste auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Für dieses Lab benötigen Sie lediglich einen Browser.
Hinweis
Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist.
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] PROJECT_ID=[YOUR-PROJECT-NAME] echo $PROJECT_ID
APIs aktivieren
Alle erforderlichen Dienste aktivieren
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. VPC‑Netzwerk erstellen
VPC-Netzwerk erstellen
Über Cloud Shell
gcloud compute networks create ca-lab-vpc --subnet-mode custom
Ausgabe
Created NAME SUBNET_MODE BGP_ROUTING_MODE IPV4_RANGE GATEWAY_IPV4 ca-lab-vpc CUSTOM REGIONAL
Subnetz erstellen
Über Cloud Shell
gcloud compute networks subnets create ca-lab-subnet \
--network ca-lab-vpc --range 10.0.0.0/24 --region us-central1
Ausgabe
Created NAME REGION NETWORK RANGE ca-lab-subnet us-central1 ca-lab-vpc 10.0.0.0/24
VPC-Firewallregeln erstellen
Nachdem Sie das VPC-Netzwerk und das Subnetz erstellt haben, richten Sie nun einige Firewallregeln ein. Mit der ersten Firewallregel wird allen IP-Adressen der Zugriff auf die externe IP-Adresse der Website der Testanwendung auf Port 3000 erlaubt. Die zweite Firewallregel wird verwendet, um Systemdiagnosen von der Quell-IP-Adresse der Load-Balancer zuzulassen.
Über Cloud Shell
gcloud compute firewall-rules create allow-js-site --allow tcp:3000 --network ca-lab-vpc
Ausgabe
Creating firewall...done. NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED allow-js-site ca-lab-vpc INGRESS 1000 tcp:3000 False
Erstellen Sie Firewallregeln, um Systemdiagnosen aus den Google-Systemdiagnosebereichen zuzulassen.
Über Cloud Shell
gcloud compute firewall-rules create allow-health-check \
--network=ca-lab-vpc \
--action=allow \
--direction=ingress \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--target-tags=allow-healthcheck \
--rules=tcp
Ausgabe
Creating firewall...done. NAME NETWORK DIRECTION PRIORITY ALLOW DENY DISABLED allow-health-check ca-lab-vpc INGRESS 1000 tcp False
4. Testanwendung einrichten
Im nächsten Schritt erstellen Sie die Testanwendung, in diesem Fall den OWASP Juice Shop-Webserver.
Beim Erstellen der Compute-Instanz verwenden wir ein Container-Image, um sicherzustellen, dass der Server die entsprechenden Dienste hat. Dieser Server wird in us-central1-c bereitgestellt und hat ein Netzwerk-Tag, das Systemdiagnosen zulässt.
OWASP Juice Shop-Anwendung erstellen
Verwenden Sie die bekannte Open-Source-Anwendung OWASP Juice Shop als anfällige Anwendung. Sie können diese Anwendung auch verwenden, um OWASP-Sicherheitsherausforderungen über die Website zu absolvieren.
Über Cloud Shell
gcloud compute instances create-with-container owasp-juice-shop-app --container-image bkimminich/juice-shop \
--network ca-lab-vpc \
--subnet ca-lab-subnet \
--private-network-ip=10.0.0.3 \
--machine-type n1-standard-2 \
--zone us-central1-c \
--tags allow-healthcheck
Ausgabe
NAME ZONE MACHINE_TYPE PREEMPTIBLE owasp-juice-shop-app us-central1-c n1-standard-2 INTERNAL_IP EXTERNAL_IP STATUS 10.0.0.3 <public IP> RUNNING
Cloud Load Balancer-Komponente einrichten: Instanzgruppe
Erstellen Sie die nicht verwaltete Instanzgruppe.
Über Cloud Shell
gcloud compute instance-groups unmanaged create juice-shop-group \
--zone=us-central1-c
Ausgabe
NAME LOCATION SCOPE NETWORK MANAGED INSTANCES juice-shop-group us-central1-c zone 0
Fügen Sie die Juice Shop-GCE-Instanz der nicht verwalteten Instanzgruppe hinzu.
Über Cloud Shell
gcloud compute instance-groups unmanaged add-instances juice-shop-group \
--zone=us-central1-c \
--instances=owasp-juice-shop-app
Ausgabe
Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].
Legen Sie den benannten Port auf den der Juice Shop-Anwendung fest.
Über Cloud Shell
gcloud compute instance-groups unmanaged set-named-ports \ juice-shop-group \ --named-ports=http:3000 \ --zone=us-central1-c
Ausgabe
Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].
Nachdem Sie die nicht verwaltete Instanzgruppe erstellt haben, müssen Sie als Nächstes eine Systemdiagnose, einen Back-End-Dienst, eine URL-Zuordnung, einen Ziel-Proxy und eine Weiterleitungsregel erstellen.
Cloud Load Balancer-Komponente einrichten: Systemdiagnose
Erstellen Sie die Systemdiagnose für den Juice Shop-Dienstport.
Über Cloud Shell
gcloud compute health-checks create tcp tcp-port-3000 \
--port 3000
Ausgabe
Created NAME PROTOCOL tcp-port-3000 TCP
Cloud-Load-Balancer-Komponente einrichten: Backend-Dienst
Erstellen Sie die Parameter für den Back-End-Dienst.
Über Cloud Shell
gcloud compute backend-services create juice-shop-backend \
--protocol HTTP \
--port-name http \
--health-checks tcp-port-3000 \
--enable-logging \
--global
Ausgabe
NAME BACKENDS PROTOCOL juice-shop-backend HTTP
Fügen Sie dem Backend-Dienst die Juice Shop-Instanzgruppe hinzu.
Über Cloud Shell
gcloud compute backend-services add-backend juice-shop-backend \
--instance-group=juice-shop-group \
--instance-group-zone=us-central1-c \
--global
Ausgabe
Updated [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/backendServices/juice-shop-backend].
Cloud Load Balancer-Komponente: URL-Zuordnung einrichten
Erstellen Sie die URL-Zuordnung, die an das Backend gesendet werden soll.
Über Cloud Shell
gcloud compute url-maps create juice-shop-loadbalancer \
--default-service juice-shop-backend
Ausgabe
NAME DEFAULT_SERVICE juice-shop-loadbalancer backendServices/juice-shop-backend
Cloud Load Balancer-Komponente: Zielproxy einrichten
Erstellen Sie den Zielproxy für die URL-Zuordnung.
Über Cloud Shell
gcloud compute target-http-proxies create juice-shop-proxy \
--url-map juice-shop-loadbalancer
Ausgabe
NAME URL_MAP juice-shop-proxy juice-shop-loadbalancer
Cloud Load Balancer-Komponente einrichten: Weiterleitungsregel
Erstellen Sie die Weiterleitungsregel für den Load Balancer.
Über Cloud Shell
gcloud compute forwarding-rules create juice-shop-rule \
--global \
--target-http-proxy=juice-shop-proxy \
--ports=80
Ausgabe
Created [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/forwardingRules/juice-shop-rule].
Prüfen, ob der Juice Shop-Dienst online ist
Über Cloud Shell
PUBLIC_SVC_IP="$(gcloud compute forwarding-rules describe juice-shop-rule --global --format="value(IPAddress)")"
Über Cloud Shell
echo $PUBLIC_SVC_IP
Ausgabe
<public VIP of service>
Warten Sie einige Minuten, bevor Sie fortfahren, da Sie sonst möglicherweise die HTTP/1.1-Antwort „404 Not Found“ erhalten.
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP
Ausgabe
HTTP/1.1 200 OK <...>
Sie können den Juice Shop auch im Browser aufrufen.

Wir sind jetzt bereit, die Sicherheitslücken im Juice Shop zu untersuchen und zu sehen, wie wir uns mit Cloud Armor-WAF-Regelsätzen davor schützen können.
5. Bekannte Sicherheitslücken demonstrieren
Um Zeit zu sparen, zeigen wir die Status vor und nach der Übertragung der Cloud Armor-WAF-Regeln in verkürzten Schritten.
LFI-Sicherheitslücke beobachten: Pfaddurchlauf
Bei der Aufnahme lokaler Dateien werden Dateien auf dem Server beobachtet, indem die fehlende Eingabevalidierung in der Anfrage ausgenutzt wird, um möglicherweise vertrauliche Daten preiszugeben. Das Folgende zeigt lediglich, dass ein Path Traversal möglich ist. Sehen Sie sich in Ihrem Browser oder mit curl einen vorhandenen Pfad an, der von der Anwendung bereitgestellt wird.
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp
Ausgabe
HTTP/1.1 200 OK <...>
Außerdem funktioniert auch Path Traversal:
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp/../
Ausgabe
HTTP/1.1 200 OK <...>
RCE-Sicherheitslücke beobachten
Die Remotecodeausführung umfasst verschiedene UNIX- und Windows-Befehlseinschleusungsszenarien, die es Angreifern ermöglichen, Betriebssystembefehle auszuführen, die normalerweise privilegierten Nutzern vorbehalten sind. Im Folgenden sehen Sie ein einfaches Beispiel für die Ausführung des Befehls „ls“.
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls
Ausgabe
HTTP/1.1 200 OK <...>
Sie können die curl-Flags entfernen, um die vollständige Ausgabe zu sehen.
Zugriff eines bekannten Scanners beobachten
Sowohl kommerzielle als auch Open-Source-Scan-Anwendungen werden für verschiedene Zwecke eingesetzt, unter anderem zum Scannen auf Sicherheitslücken. Diese Tools verwenden bekannte User-Agent- und andere Header. Beobachten Sie, dass „curl“ mit einem bekannten User-Agent-Header funktioniert:
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"
Ausgabe
HTTP/1.1 200 OK <...>
Protokollangriff beobachten: HTTP-Splitting
Einige Webanwendungen verwenden Eingaben des Nutzers, um die Header in den Antworten zu generieren. Wenn die Anwendung die Eingabe nicht richtig filtert, kann ein Angreifer den Eingabeparameter möglicherweise mit der Sequenz %0d%0a (der CRLF-Sequenz, die zum Trennen verschiedener Zeilen verwendet wird) manipulieren. Die Antwort könnte dann von allen, die sie parsen, z. B. von einem zwischengeschalteten Proxyserver, als zwei Antworten interpretiert werden, was dazu führen könnte, dass bei nachfolgenden Anfragen falsche Inhalte bereitgestellt werden. Fügen Sie die Sequenz %0d%0a in den Eingabeparameter ein. Dadurch kann eine irreführende Seite ausgeliefert werden.
Über Cloud Shell
curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"
Ausgabe
HTTP/1.1 200 OK <...>
Sitzungsfixierung beobachten
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP -H session_id=X
Ausgabe
HTTP/1.1 200 OK <...>
6. Cloud Armor WAF-Regeln definieren
Vorkonfigurierte WAF-Regeln auflisten:
Über Cloud Shell
gcloud compute security-policies list-preconfigured-expression-sets
Ausgabe
EXPRESSION_SET
Sqli-canary
RULE_ID
owasp-crs-v030001-id942110-sqli
owasp-crs-v030001-id942120-sqli
<...>
Cloud Armor-Sicherheitsrichtlinie erstellen
Über Cloud Shell:
gcloud compute security-policies create block-with-modsec-crs \
--description "Block with OWASP ModSecurity CRS"
Standardregel der Sicherheitsrichtlinie aktualisieren
Die Priorität der Standardregel hat den numerischen Wert 2147483647.
Über Cloud Shell:
gcloud compute security-policies rules update 2147483647 \
--security-policy block-with-modsec-crs \
--action "deny-403"
Da die Standardregel mit der Aktion „Ablehnen“ konfiguriert ist, müssen wir den Zugriff von Ihrer IP-Adresse zulassen. Ermitteln Sie Ihre öffentliche IP-Adresse (z. B. mit curl, ipmonkey oder whatismyip).
Über Cloud Shell:
MY_IP=$(curl ifconfig.me)
Fügen Sie die erste Regel hinzu, um den Zugriff von Ihrer IP-Adresse (IP-ADRESSE HIER EINFÜGEN) zuzulassen.
Über Cloud Shell:
gcloud compute security-policies rules create 10000 \
--security-policy block-with-modsec-crs \
--description "allow traffic from my IP" \
--src-ip-ranges "$MY_IP/32" \
--action "allow"
Sicherheitsrichtlinie aktualisieren, um LFI-Angriffe zu blockieren
Wenden Sie das OWASP ModSecurity Core Rule Set an, das Pfaddurchläufe für lokale Dateieinbindungen verhindert.
Über Cloud Shell:
gcloud compute security-policies rules create 9000 \
--security-policy block-with-modsec-crs \
--description "block local file inclusion" \
--expression "evaluatePreconfiguredExpr('lfi-stable')" \
--action deny-403
Sicherheitsrichtlinie aktualisieren, um die Ausführung von Code per Fernzugriff (Remote Code Execution, RCE) zu blockieren
Gemäß dem OWASP ModSecurity Core Rule Set werden Regeln angewendet, die nach RCE suchen, einschließlich Command Injection. Typische Betriebssystembefehle werden erkannt und blockiert.
Über Cloud Shell:
gcloud compute security-policies rules create 9001 \
--security-policy block-with-modsec-crs \
--description "block rce attacks" \
--expression "evaluatePreconfiguredExpr('rce-stable')" \
--action deny-403
Sicherheitsrichtlinie aktualisieren, um Sicherheitsscanner zu blockieren
Wenden Sie das OWASP ModSecurity Core Rule Set an, um bekannte Sicherheitsscanner, Scripting-HTTP-Clients und Webcrawler zu blockieren.
Über Cloud Shell:
gcloud compute security-policies rules create 9002 \
--security-policy block-with-modsec-crs \
--description "block scanners" \
--expression "evaluatePreconfiguredExpr('scannerdetection-stable')" \
--action deny-403
Sicherheitsrichtlinie aktualisieren, um Protokollangriffe zu blockieren
Gemäß dem OWASP ModSecurity Core Rule Set werden Regeln angewendet, die nach Carriage Return (CR) %0d- und Linefeed (LF) %0a-Zeichen und anderen Arten von Protokollangriffen wie HTTP Request Smuggling suchen.
Über Cloud Shell:
gcloud compute security-policies rules create 9003 \
--security-policy block-with-modsec-crs \
--description "block protocol attacks" \
--expression "evaluatePreconfiguredExpr('protocolattack-stable')" \
--action deny-403
Sicherheitsrichtlinie aktualisieren, um Session-Fixing zu blockieren
Gemäß dem OWASP ModSecurity Core Rule Set gelten Regeln, die…
Über Cloud Shell:
gcloud compute security-policies rules create 9004 \
--security-policy block-with-modsec-crs \
--description "block session fixation attacks" \
--expression "evaluatePreconfiguredExpr('sessionfixation-stable')" \
--action deny-403
Sicherheitsrichtlinie an den Back-End-Dienst anhängen
Über Cloud Shell:
gcloud compute backend-services update juice-shop-backend \
--security-policy block-with-modsec-crs \
--global
Es kann einige Zeit dauern, bis Regeln übernommen werden (maximal 10 Minuten). Wenn Sie sicher sind, dass genügend Zeit vergangen ist, testen Sie die zuvor demonstrierten Sicherheitslücken, um die Durchsetzung der Cloud Armor-WAF-Regeln im nächsten Schritt zu bestätigen.
7. Cloud Armor-Schutz mit OWASP ModSecurity Core Rule Set beobachten
Bestätigen, dass die LFI-Sicherheitslücke behoben wurde
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/?a=../
Ausgabe
HTTP/1.1 403 Forbidden <...>
Bestätigen, dass der RCE-Angriff abgewehrt wurde
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls
Ausgabe
HTTP/1.1 403 Forbidden <..>
Erkennung bekannter Scanner bestätigen
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"
Ausgabe
HTTP/1.1 403 Forbidden <..>
Bestätigen, dass ein Protokollangriff abgewehrt wurde
Gemäß dem OWASP ModSecurity Core Rule Set Version 3.0.2 wird der Protokollangriff durch Folgendes abgemildert:
Über Cloud Shell
curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"
Ausgabe
HTTP/1.1 403 Forbidden <..>
Bestätigen, dass Versuche zur Sitzungsfixierung blockiert werden
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/?session_id=a
Ausgabe
HTTP/1.1 403 Forbidden <..>
8. Cloud Armor-Sicherheitsregeln prüfen
Nachdem wir die Sicherheitsrichtlinie erstellt haben, sehen wir uns an, welche Regeln konfiguriert wurden.

Regeln werden nach Priorität ausgewertet: Niedrigere Zahlen werden zuerst ausgewertet. Wenn eine Regel ausgelöst wird, wird die Verarbeitung für Regeln mit höheren Prioritätswerten nicht fortgesetzt.
- Priorität 9000 – LFI (Local File Inclusion) blockieren
- Priorität 9001 – RCE-Angriffe (Remote Code Execution/Command Injection) blockieren
- Priorität 9002 – Block Scanners Detected (Block-Scanner erkannt)
- Priorität 9003 – Protokollangriffe wie HTTP-Splitting und HTTP-Smuggling blockieren
- Priorität 9004 – Angriffe über Sitzungsfixierung blockieren
- Priorität 10.000 – Ihrer IP-Adresse den Zugriff auf die Website erlauben
- Standardpriorität – Ablehnen.
*Beachten Sie, dass die Regel „IP-Adresse zulassen“ mit der höchsten Prioritätsnummer konfiguriert ist, um den Zugriff auf die Website zu ermöglichen, aber alle Angriffe zu blockieren.
9. Cloud Armor-Sicherheitsrichtlinien-Logs ansehen
Auf der Cloud Armor Console-Seite können Sie Details der Sicherheitsrichtlinie aufrufen und auf den Tab Logs und dann auf den Link View policy logs klicken, um zur Cloud Logging-Seite weitergeleitet zu werden. Die Filterung erfolgt automatisch anhand der gewünschten Sicherheitsrichtlinie, z.B. resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:(block-with-modsec-crs). Sehen Sie sich die 403-Fehlerantwortcodes an und maximieren Sie die Logdetails, um den Namen der erzwungenen Sicherheitsrichtlinie, den übereinstimmenden Feldwert und weiter unten die vorkonfigurierten Ausdrucks-IDs (oder die Signatur-ID) zu sehen. Die folgenden Screenshots zeigen Beispiele für die Logs der erzwungenen Sicherheitsrichtlinien, die in diesem Codelab konfiguriert wurden.
LFI-Log

RCE-Log

Scanner-Erkennungsprotokoll

Protokollangriffslog

Sitzungsfixierungsprotokoll

10. Lab bereinigen
Bereinigen Sie die Ressourcen, nachdem Sie das Lab abgeschlossen haben.
Führen Sie diese Befehle aus, um die Cloud Armor-Sicherheitsrichtlinie, den Load Balancer, die Instanzen, die Firewallregeln und das VPC-Netzwerk zu löschen.
Cloud Armor-Sicherheitsrichtlinie aus dem Backend-Dienst entfernen
gcloud -q compute backend-services update juice-shop-backend --security-policy "" --global
Cloud Armor-Sicherheitsrichtlinie löschen
Wenn Sie die Sicherheitsrichtlinie löschen, werden die zugehörigen Regeln automatisch gelöscht.
gcloud -q compute security-policies delete block-with-modsec-crs
Load-Balancer-Ressourcen löschen
Zu den Load-Balancer-Ressourcen, die gelöscht werden müssen, gehören die Weiterleitungsregel, die Ziel-HTTP-Proxys, die URL-Zuordnungen, das Back-End, die Systemdiagnosen und die Instanzgruppe.
gcloud -q compute forwarding-rules delete juice-shop-rule --global
gcloud -q compute target-http-proxies delete juice-shop-proxy
gcloud -q compute url-maps delete juice-shop-loadbalancer
gcloud -q compute backend-services delete juice-shop-backend \
--global
gcloud -q compute health-checks delete tcp-port-3000
gcloud -q compute instance-groups unmanaged delete juice-shop-group --zone=us-central1-c
Instanz löschen
gcloud -q compute instances delete owasp-juice-shop-app --zone us-central1-c
Firewallregeln, Subnetz und VPC löschen
gcloud -q compute firewall-rules delete allow-health-check gcloud -q compute firewall-rules delete allow-js-site gcloud -q compute networks subnets delete ca-lab-subnet --region us-central1 gcloud -q compute networks delete ca-lab-vpc
11. Glückwunsch!
Herzlichen Glückwunsch zum Abschluss des Codelabs zu vorkonfigurierten WAF-Regeln für Cloud Armor!
Behandelte Themen
- Instanzgruppe und globalen Cloud Load Balancer einrichten
- Cloud Armor-Sicherheitsrichtlinien mit vorkonfigurierten WAF-Regeln zum Schutz vor LFI, RCE, Scannern, Protokollangriffen und Session Fixation konfigurieren
- Über Logs prüfen, ob Cloud Armor einige der OWASP-Top-10-Angriffe abgewehrt hat
Weiteres Vorgehen
- Anwendung mit vorkonfigurierten WAF-Regeln für Cloud Armor vor den OWASP Top 10-Sicherheitslücken schützen
- Regeln basierend auf Empfindlichkeitsstufen optimieren
- Verwenden Sie die Referenz zur Sprache für benutzerdefinierte Regeln, um die Sicherheitsdurchsetzung genauer zu definieren.