1. Einführung
Hallo! Willkommen zum Codelab zu vorkonfigurierten WAF-Regeln in Cloud Armor!
Google Cloud Armor ist die Netzwerksicherheitslösung von Google für Unternehmen, die Schutz vor DDoS-Angriffen, die Durchsetzung von WAF-Regeln und eine umfassende adaptive Verwaltbarkeit bietet.
Cloud Armor hat die vorkonfigurierten WAF-Regelsätze erweitert, um besseren Schutz vor den OWASP-Top-10-Sicherheitslücken in Webanwendungen zu bieten. 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), Remote Code-Ausführung (RCE) und viele mehr.
In diesem Codelab erfahren Sie, wie Sie sich mithilfe der WAF-Regeln von Google Cloud Armor vor einigen der häufigsten Sicherheitslücken schützen.
Lerninhalte
- Instanzgruppe und globalen Load Balancer zur Unterstützung eines Dienstes einrichten
- Cloud Armor-Sicherheitsrichtlinien mit vorkonfigurierten WAF-Regeln konfigurieren, um sich vor LFI, RCE, Scannern, Protokollangriffen und Session Fixation zu schützen
- Anhand von Logs prüfen, 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: Topologie des Codelabs zu WAF-Regeln in Cloud Armor
Die OWASP Juice Shop-Anwendung hilft beim Sicherheitstraining und schärft das Bewusstsein, da sie standardmäßig Beispiele für jede der OWASP-Top-10-Sicherheitslücken enthält. Angreifende können sie zu Testzwecken ausnutzen. In diesem Codelab wird sie verwendet, um einige Anwendungsangriffe zu demonstrieren und die Anwendung anschließend mit Cloud Armor-WAF-Regeln zu schützen. Der Anwendung wird ein Google Cloud-Load Balancer vorgeschaltet, auf den die Cloud Armor-Sicherheitsrichtlinie und ‑regeln angewendet werden. Sie wird im öffentlichen Internet bereitgestellt und ist daher von fast überall aus erreichbar. Außerdem wird sie mit 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 kostenlose Testprogramm 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 alle Aufgaben in diesem 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 die VPC und das Subnetz erstellt haben, richten Sie einige Firewallregeln ein. Die erste Firewallregel wird verwendet, um allen IP-Adressen den Zugriff auf die externe IP-Adresse der Website der Testanwendung über Port 3000 zu ermöglichen. 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. So wird sichergestellt, 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. Mithilfe dieser Anwendung können Sie auch OWASP-Sicherheitsherausforderungen über die OWASP-Website bewältigen.
Ü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].
Geben Sie für den benannten Port den Port der Juice Shop-Anwendung an.
Ü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, erstellen Sie als Nächstes eine Systemdiagnose, einen Backend-Dienst, eine URL-Zuordnung, einen Ziel-Proxy und eine Weiterleitungsregel.
Cloud Load Balancer-Komponente einrichten: Systemdiagnose
Erstellen Sie die Systemdiagnose für den Dienstport von Juice Shop.
Ü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 einrichten: URL-Zuordnung
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 einrichten: Ziel-Proxy
Erstellen Sie den Zielproxy, der der URL-Zuordnung vorangestellt wird.
Ü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 den Fehler „HTTP/1.1 404 Nicht gefunden“ erhalten.
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP
Ausgabe
HTTP/1.1 200 OK <...>
Sie können Juice Shop auch im Browser aufrufen.
Wir können uns jetzt die Sicherheitslücken von Juice Shop ansehen und uns mit Cloud Armor-WAF-Regelsätzen vor ihnen schützen.
5. Bekannte Sicherheitslücken demonstrieren
Um Zeit zu sparen, demonstrieren wir die Zustände vor und nach der Weitergabe der Cloud Armor-WAF-Regeln in grundlegenden Schritten.
LFI-Sicherheitslücke beobachten: Path Traversal
Bei der Local File Inclusion werden Dateien auf dem Server aufgerufen, indem die fehlende Eingabevalidierung in der Anfrage ausgenutzt wird. Dadurch werden möglicherweise sensible Daten offengelegt. Das folgende Beispiel 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 <...>
Sie werden feststellen, dass auch Path Traversal funktioniert:
Über Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp/../
Ausgabe
HTTP/1.1 200 OK <...>
RCE-Sicherheitslücke beobachten
Die Remote-Codeausführung umfasst verschiedene UNIX- und Windows-Befehlseinschleusungsszenarien, mit denen Angreifende Betriebssystembefehle ausführen können, die normalerweise privilegierten Nutzerinnen und Nutzern vorbehalten sind. Das folgende Beispiel zeigt die Ausführung eines einfachen ls-Befehls, der übergeben wurde.
Ü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
Es gibt sowohl kommerzielle als auch Open-Source-Scan-Anwendungen, die für verschiedene Zwecke genutzt werden, zum Beispiel, um Sicherheitslücken zu finden. Diese Tools verwenden bekannte User-Agent- und andere Header. Sie werden feststellen, 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 generieren Header in den Antworten anhand von Nutzereingaben. Wenn die Anwendung die Eingabe nicht richtig filtert, können Angreifende den Eingabeparameter mit der Sequenz %0d%0a manipulieren (die CRLF-Sequenz, mit der unterschiedliche Zeilen getrennt werden). Die Antwort könnte dann von allem, was sie parst, wie einem zwischengeschalteten Proxyserver, als zwei Antworten interpretiert werden. Dadurch werden bei nachfolgenden Anfragen möglicherweise falsche Inhalte bereitgestellt. Fügen Sie die Sequenz %0d%0a in den Eingabeparameter ein. Dadurch wird unter Umständen eine irreführende Seite bereitgestellt.
Ü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 <...>
Session Fixation 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
In der 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.
In der 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 aus zulassen. Suchen Sie Ihre öffentliche IP-Adresse, beispielsweise mit curl, ipmonkey oder whatismyip.
In der Cloud Shell:
MY_IP=$(curl ifconfig.me)
Fügen Sie die erste Regel hinzu, um den Zugriff von Ihrer IP-Adresse aus zuzulassen (FÜGEN SIE IHRE IP-ADRESSE UNTEN EIN)
In der 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 Path Traversal für Local File Inclusions verhindert.
In der 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 Remote-Codeausführung (RCE) zu blockieren
Wenden Sie gemäß dem OWASP ModSecurity Core Rule Set Regeln an, die nach RCE suchen, einschließlich Befehlsinjektion. Typische Betriebssystembefehle werden erkannt und blockiert.
In der 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, HTTP-Scripting-Clients und Web-Crawler zu blockieren.
In der 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
Wenden Sie gemäß dem OWASP ModSecurity Core Rule Set Regeln an, die nach Zeilenumbruchzeichen (%0d) und Zeilenvorschubzeichen (%0a) sowie anderen Arten von Protokollangriffen wie HTTP Request Smuggling suchen.
In der 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 Fixation zu verhindern
Wenden Sie gemäß dem OWASP ModSecurity Core Rule Set Regeln an, die…
In der 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
In der Cloud Shell:
gcloud compute backend-services update juice-shop-backend \
--security-policy block-with-modsec-crs \
--global
Es kann etwas dauern, bis die Regeln wirksam werden (maximal aber zehn Minuten). Wenn Sie sicher sind, dass genügend Zeit vergangen ist, testen Sie im nächsten Schritt die zuvor demonstrierten Sicherheitslücken, um zu bestätigen, dass die Cloud Armor-WAF-Regel erzwungen wurde.
7. Cloud Armor-Schutz mit OWASP ModSecurity Core Rule Set prüfen
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äß OWASP ModSecurity Core Rule Set Version 3.0.2 wird der Protokollangriff durch Folgendes abgewehrt:
Ü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 <..>
Prüfen, ob Versuche zur Session Fixation 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.
Die Auswertung von Regeln erfolgt nach Priorität: Solche mit niedrigeren Zahlen werden zuerst ausgewertet. Sobald eine Regel ausgelöst wurde, wird die Verarbeitung von Regeln mit höheren Prioritätswerten nicht fortgesetzt.
- Priorität 9000: LFI blockieren (Local File Inclusion)
- Priorität 9001: RCE-Angriffe blockieren (Remote-Codeausführung/Befehlsinjektion)
- Priorität 9002: Erkannte Scanner blockieren
- Priorität 9003: Protokollangriffe wie HTTP-Splitting und HTTP-Smuggling blockieren
- Priorität 9004: Session-Fixation-Angriffe blockieren
- Priorität 10000: Ihrer IP-Adresse den Zugriff auf die Website gewähren
- Priorität „Default“: ablehnen
*Die Regel „Ihrer IP-Adresse den Zugriff auf die Website gewähren“ hat die höchste Prioritätsnummer, damit der Zugriff auf die Website ermöglicht wird, aber alle Angriffe blockiert werden.
9. Logs von Cloud Armor-Sicherheitsrichtlinien beobachten
Auf der Cloud Armor-Konsolenseite können Sie die Details der Sicherheitsrichtlinie aufrufen. Klicken Sie auf den Tab Logs und dann auf den Link View policy logs, um zur Cloud Logging-Seite zu gelangen. Es wird automatisch nach der relevanten Sicherheitsrichtlinie gefiltert, z.B. resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:(block-with-modsec-crs). Sehen Sie sich die Antwortcodes des Fehlers 403 an und erweitern 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
Scannererkennungslog
Protokollangriffslog
Session-Fixation-Log
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 zu löschenden Load-Balancer-Ressourcen 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 in Cloud Armor!
Behandelte Themen
- Instanzgruppe und globalen Cloud Load Balancer einrichten
- Cloud Armor-Sicherheitsrichtlinien mit vorkonfigurierten WAF-Regeln konfigurieren, um sich vor LFI, RCE, Scannern, Protokollangriffen und Session Fixation zu schützen
- Anhand von Logs prüfen, ob Cloud Armor einige der OWASP-Top-10-Angriffe abgewehrt hat
Weiteres Vorgehen
- Schützen Sie Ihre Anwendung mit vorkonfigurierten WAF-Regeln für Cloud Armor vor den OWASP-Top-10-Sicherheitslücken.
- Regeln basierend auf Empfindlichkeitsstufen optimieren
- Verwenden Sie die Referenz zur Sprache für benutzerdefinierte Regeln, um die Sicherheitsdurchsetzung genauer zu definieren.