Codelab zu vorkonfigurierten WAF-Regeln in Cloud Armor

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

119e13312f3cec25.jpeg

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

  1. 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.

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

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.

  1. 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:

bce75f34b2c53987.png

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

f6ef2b5f13479f3a.png

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.

428c18eee6708c28.png

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.

d00e4102fc89e44f.png

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

983a6cab0cff940d.png

RCE-Log

988a3a571f9d9d45.png

Scanner-Erkennungsprotokoll

7ed661863ba27555.png

Protokollangriffslog

17ee3cbe0bd98939.png

Sitzungsfixierungsprotokoll

80d1ddfd0fe982e1.png

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