Atelier de programmation sur les règles WAF préconfigurées Cloud Armor

1. Introduction

Bonjour ! Bienvenue dans l'atelier de programmation sur les règles WAF préconfigurées de Cloud Armor.

Google Cloud Armor est la solution de sécurité réseau en périphérie pour les entreprises de Google. Elle offre une protection contre les attaques DDoS, l'application de règles WAF et des capacités de gestion adaptative à grande échelle.

Cloud Armor a étendu les ensembles de règles WAF préconfigurés pour atténuer les failles de sécurité des applications Web figurant dans le Top 10 de l'OWASP. Les ensembles de règles sont basés sur l'ensemble des règles de base OWASP Modsecurity version 3.0.2 pour protéger contre certains des risques de sécurité les plus courants concernant les applications Web : les inclusions de fichiers locaux (LFI), les inclusions de fichiers distants (RFI), les exécutions de code à distance (RCE) et bien d'autres.

Dans cet atelier de programmation, vous allez apprendre à atténuer certaines des failles courantes à l'aide des règles WAF Google Cloud Armor.

Points abordés

• Configurer un groupe d'instances et un équilibreur de charge mondial pour prendre en charge un service
• Configurer des stratégies de sécurité Cloud Armor avec des règles WAF préconfigurées pour protéger contre les attaques LFI, les exécutions RCE, les analyseurs, les attaques de protocole et la fixation de session
• Comment valider que Cloud Armor a atténué une attaque en observant les journaux.

Prérequis

• Connaissances de base sur Google Compute Engine ( atelier de programmation)
• Connaissances de base sur la gestion de réseaux et les protocoles TCP/IP
• Connaissances de base de la ligne de commande Unix/Linux
• Il est utile d'avoir suivi une visite guidée de la mise en réseau dans GCP avec Mise en réseau dans Google Cloud.
• (Facultatif) Suivez l'atelier Cloudnet20 Cloud Armor pour apprendre à protéger les charges de travail avec des règles basées sur l'injection SQL, l'adresse IP et la géolocalisation.

Topologie et cas d'utilisation de l'atelier de programmation

Figure 1 : Topologie de l'atelier de programmation sur les règles WAF Cloud Armor

L'application OWASP Juice Shop est utile pour la sensibilisation et la formation à la sécurité, car elle contient des instances de chacune des failles de sécurité du Top 10 de l'OWASP, de par sa conception. Elle peut donc être exploitée pour simuler des attaques. Dans cet atelier de programmation, nous allons l'utiliser pour montrer l'existence de certaines attaques, puis protéger l'application à l'aide de règles WAF Cloud Armor. L'application se trouve derrière un équilibreur de charge Google Cloud, auquel les règles et la stratégie de sécurité Cloud Armor sont appliquées. Elle sera mise en service sur l'Internet public, et sera donc accessible depuis presque n'importe où. Elle sera protégée à l'aide de Cloud Armor et de règles de pare-feu VPC.

2. Préparation

Configuration de l'environnement d'auto-formation

1. Connectez-vous à la console Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

Remarque : Vous pouvez facilement accéder à la console Cloud en mémorisant son URL, à savoir console.cloud.google.com.

Mémorisez l'ID du projet. Il s'agit d'un nom unique permettant de différencier chaque projet Google Cloud (le nom ci-dessus est déjà pris ; vous devez en trouver un autre). Il sera désigné par le nom PROJECT_ID tout au long de cet atelier de programmation.

Remarque : Si vous utilisez un compte Gmail, vous pouvez conserver l'emplacement par défaut défini sur Aucune organisation. Si vous utilisez un compte Google Workspace, choisissez un emplacement pertinent pour votre organisation.

2. Vous devez ensuite activer la facturation dans Cloud Console pour pouvoir utiliser les ressources Google Cloud.

L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Veillez à suivre les instructions de la section "Nettoyer" qui indique comment désactiver les ressources afin d'éviter les frais une fois ce tutoriel terminé. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300$.

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Depuis la console GCP, cliquez sur l'icône Cloud Shell de la barre d'outils située dans l'angle supérieur droit :

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez réaliser toutes les activités de cet atelier dans un simple navigateur.

Avant de commencer

Dans Cloud Shell, assurez-vous que l'ID de votre projet est configuré.

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
PROJECT_ID=[YOUR-PROJECT-NAME]
echo $PROJECT_ID

Activer les API

Activez tous les services nécessaires.

gcloud services enable compute.googleapis.com
gcloud services enable logging.googleapis.com        
gcloud services enable monitoring.googleapis.com 

3. Créer le réseau VPC

Créer un réseau VPC

Depuis Cloud Shell

gcloud compute networks create ca-lab-vpc --subnet-mode custom

Sortie

Created
NAME        SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
ca-lab-vpc  CUSTOM       REGIONAL

Créer un sous-réseau

Depuis Cloud Shell

gcloud compute networks subnets create ca-lab-subnet \
        --network ca-lab-vpc --range 10.0.0.0/24 --region us-central1

Sortie

Created 
NAME           REGION       NETWORK       RANGE
ca-lab-subnet  us-central1  ca-lab-vpc    10.0.0.0/24

Créer des règles de pare-feu VPC

Après avoir créé le VPC et le sous-réseau, configurez quelques règles de pare-feu. La première règle de pare-feu sera utilisée pour autoriser toutes les adresses IP à accéder à l'adresse IP externe du site Web de l'application test sur le port 3000. La deuxième règle de pare-feu sera utilisée pour autoriser les vérifications d'état à partir de l'adresse IP source des équilibreurs de charge.

Depuis Cloud Shell

gcloud compute firewall-rules create allow-js-site --allow tcp:3000 --network ca-lab-vpc

Sortie

Creating firewall...done.
NAME           NETWORK     DIRECTION  PRIORITY  ALLOW     DENY  DISABLED
allow-js-site  ca-lab-vpc  INGRESS    1000      tcp:3000        False

Créez des règles de pare-feu pour autoriser les vérifications d'état à partir des plages utilisées par Google pour ces vérifications.

Depuis Cloud Shell

gcloud compute firewall-rules create allow-health-check \
    --network=ca-lab-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=allow-healthcheck \
    --rules=tcp

Sortie

Creating firewall...done.
NAME                NETWORK     DIRECTION  PRIORITY  ALLOW  DENY  DISABLED
allow-health-check  ca-lab-vpc  INGRESS    1000      tcp          False

4. Configurer l'application test

L'étape suivante consiste à créer l'application test, en l'occurrence le serveur Web OWASP Juice Shop.

Lorsque vous créez l'instance de calcul, vous utilisez une image de conteneur pour vous assurer que le serveur dispose des services appropriés. Ce serveur sera déployé dans us-central1-c et disposera d'un tag réseau qui autorisera les vérifications de l'état.

Créer l'application OWASP Juice Shop

Utilisez OWASP Juice Shop, une application Open Source bien connue qui servira d'application vulnérable. Vous pouvez également l'utiliser pour réaliser les "challenges" de sécurité sur le site Web de l'OWASP.

Depuis Cloud Shell

gcloud compute instances create-with-container owasp-juice-shop-app --container-image bkimminich/juice-shop \
     --network ca-lab-vpc \
     --subnet ca-lab-subnet \
     --private-network-ip=10.0.0.3 \
     --machine-type n1-standard-2 \
     --zone us-central1-c \
     --tags allow-healthcheck

Sortie

NAME                  ZONE           MACHINE_TYPE   PREEMPTIBLE  
owasp-juice-shop-app  us-central1-c  n1-standard-2               

INTERNAL_IP  EXTERNAL_IP     STATUS
10.0.0.3     <public IP>     RUNNING

Configurer le composant d'équilibreur de charge Cloud : groupe d'instances

Créez le groupe d'instances non géré.

Depuis Cloud Shell

gcloud compute instance-groups unmanaged create juice-shop-group \
    --zone=us-central1-c

Sortie

NAME              LOCATION       SCOPE  NETWORK  MANAGED  INSTANCES
juice-shop-group  us-central1-c  zone                     0

Ajoutez l'instance GCE Juice Shop au groupe d'instances non géré.

Depuis Cloud Shell

gcloud compute instance-groups unmanaged add-instances juice-shop-group \
    --zone=us-central1-c \
    --instances=owasp-juice-shop-app

Sortie

Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].

Définissez le port nommé sur celui de l'application Juice Shop.

Depuis Cloud Shell

gcloud compute instance-groups unmanaged set-named-ports \
juice-shop-group \
   --named-ports=http:3000 \
   --zone=us-central1-c

Sortie

Updated [https://www.googleapis.com/compute/v1/projects/<project name>/zones/us-central1-c/instanceGroups/juice-shop-group].

Maintenant que vous avez créé le groupe d'instances non géré, l'étape suivante consiste à créer une vérification de l'état, un service de backend, un mappage d'URL, un proxy cible et une règle de transfert.

Configurer le composant d'équilibreur de charge Cloud : vérification de l'état

Créez la vérification de l'état du port de service Juice Shop.

Depuis Cloud Shell

gcloud compute health-checks create tcp tcp-port-3000 \
        --port 3000

Sortie

Created 
NAME           PROTOCOL
tcp-port-3000  TCP

Configurer le composant d'équilibreur de charge Cloud : service de backend

Créez les paramètres du service de backend.

Depuis Cloud Shell

gcloud compute backend-services create juice-shop-backend \
        --protocol HTTP \
        --port-name http \
        --health-checks tcp-port-3000 \
        --enable-logging \
        --global 

Sortie

NAME                BACKENDS  PROTOCOL
juice-shop-backend            HTTP

Ajoutez le groupe d'instances Juice Shop au service de backend.

Depuis Cloud Shell

 gcloud compute backend-services add-backend juice-shop-backend \
        --instance-group=juice-shop-group \
        --instance-group-zone=us-central1-c \
        --global

Sortie

Updated [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/backendServices/juice-shop-backend].

Configurer le composant d'équilibreur de charge Cloud : mappage d'URL

Créez le mappage d'URL à envoyer au backend.

Depuis Cloud Shell

gcloud compute url-maps create juice-shop-loadbalancer \
        --default-service juice-shop-backend

Sortie

NAME                     DEFAULT_SERVICE
juice-shop-loadbalancer  backendServices/juice-shop-backend

Configurer le composant d'équilibreur de charge Cloud : proxy cible

Créez le proxy cible pour faire face au mappage d'URL.

Depuis Cloud Shell

gcloud compute target-http-proxies create juice-shop-proxy \
        --url-map juice-shop-loadbalancer

Sortie

NAME              URL_MAP
juice-shop-proxy  juice-shop-loadbalancer

Configurer le composant d'équilibreur de charge Cloud : règle de transfert

Créez la règle de transfert pour l'équilibreur de charge.

Depuis Cloud Shell

gcloud compute forwarding-rules create juice-shop-rule \
        --global \
        --target-http-proxy=juice-shop-proxy \
        --ports=80

Sortie

Created [https://www.googleapis.com/compute/v1/projects/cythom-host1/global/forwardingRules/juice-shop-rule].

Vérifier que le service Juice Shop est en ligne

Depuis Cloud Shell

PUBLIC_SVC_IP="$(gcloud compute forwarding-rules describe juice-shop-rule  --global --format="value(IPAddress)")"

Depuis Cloud Shell

echo $PUBLIC_SVC_IP

Sortie

<public VIP of service>

Patientez quelques minutes avant de continuer, sinon vous risquez de recevoir une réponse "HTTP/1.1 404 Not Found".

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP

Sortie

HTTP/1.1 200 OK
<...>

Vous pouvez également accéder au navigateur pour afficher Juice Shop.

Nous sommes maintenant prêts à explorer les failles de Juice Shop et à découvrir comment s'en protéger à l'aide des ensembles de règles WAF Cloud Armor.

5. Montrer l'existence de failles connues

Pour gagner du temps, nous allons suivre des étapes condensées pour montrer les états avant et après la propagation des règles WAF Cloud Armor.

Observer une faille LFI : traversée de répertoire

L'inclusion de fichiers locaux consiste à observer les fichiers présents sur le serveur en exploitant l'absence de validation des entrées dans la requête afin d'exposer potentiellement des données sensibles. La requête suivante montre simplement qu'une traversée de répertoire est possible. Dans votre navigateur ou avec curl, observez un chemin d'accès existant traité par l'application.

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/ftp

Sortie

HTTP/1.1 200 OK
<...>

Notez également que la traversée de répertoire fonctionne également :

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/ftp/../

Sortie

HTTP/1.1 200 OK
<...>

Observer une faille RCE

L'exécution de code à distance inclut divers scénarios d'injection de commandes UNIX et Windows permettant aux pirates informatiques d'exécuter des commandes OS généralement réservées aux utilisateurs disposant de privilèges. Voici un exemple d'exécution de la commande ls transmise.

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls

Sortie

HTTP/1.1 200 OK
<...>

Vous pouvez supprimer les options curl pour observer le résultat complet.

Observer l'accès d'un analyseur connu

Les applications d'analyse, qu'elles soient commerciales ou Open Source, servent entre autres à détecter des failles. Ces outils utilisent des en-têtes user-agent et d'autres en-têtes connus. Observez le fonctionnement de curl avec un en-tête user-agent connu :

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"

Sortie

HTTP/1.1 200 OK
<...>

Observer une attaque de protocole : séparation de réponse HTTP

Certaines applications Web utilisent les entrées de l'utilisateur pour générer les en-têtes des réponses. Si l'application ne filtre pas correctement l'entrée, un pirate informatique peut potentiellement corrompre le paramètre d'entrée avec la séquence %0d%0a (la séquence CRLF utilisée pour séparer différentes lignes). La réponse peut alors être interprétée comme deux réponses par toute entité qui l'analyse, comme un serveur proxy intermédiaire, et potentiellement renvoyer du contenu erroné dans les requêtes suivantes. Insérez la séquence %0d%0a dans le paramètre d'entrée, ce qui peut entraîner l'affichage d'une page trompeuse.

Depuis Cloud Shell

curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"

Sortie

HTTP/1.1 200 OK
<...>

Observer la fixation de session

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP -H session_id=X

Sortie

HTTP/1.1 200 OK
<...>

6. Définir des règles WAF Cloud Armor

Listez les règles WAF préconfigurées :

Depuis Cloud Shell

gcloud compute security-policies list-preconfigured-expression-sets

Sortie

EXPRESSION_SET
Sqli-canary
RULE_ID
    owasp-crs-v030001-id942110-sqli
    owasp-crs-v030001-id942120-sqli
<...>

Créer la stratégie de sécurité Cloud Armor

Depuis Cloud Shell :

gcloud compute security-policies create block-with-modsec-crs \
    --description "Block with OWASP ModSecurity CRS"

Mettre à jour la règle par défaut de la stratégie de sécurité

Notez que la priorité de la règle par défaut a une valeur numérique de 2147483647.

Depuis Cloud Shell :

gcloud compute security-policies rules update 2147483647 \
    --security-policy block-with-modsec-crs \
    --action "deny-403"

Comme la règle par défaut est configurée avec l'action "deny" (Refuser), nous devons autoriser l'accès à partir de votre adresse IP. Veuillez trouver votre adresse IP publique (curl, ipmonkey, whatismyip, etc.).

Depuis Cloud Shell :

MY_IP=$(curl ifconfig.me)

Ajoutez la première règle pour autoriser l'accès à partir de votre adresse IP (INSÉREZ VOTRE ADRESSE IP CI-DESSOUS)

Depuis Cloud Shell :

gcloud compute security-policies rules create 10000 \
    --security-policy  block-with-modsec-crs  \
    --description "allow traffic from my IP" \
    --src-ip-ranges "$MY_IP/32" \
    --action "allow"

Mettre à jour la stratégie de sécurité pour bloquer les attaques LFI

Appliquez l'ensemble des règles de base OWASP Modsecurity qui empêche la traversée de répertoire pour les inclusions de fichiers locaux.

Depuis Cloud Shell :

gcloud compute security-policies rules create 9000 \
    --security-policy block-with-modsec-crs  \
    --description "block local file inclusion" \
     --expression "evaluatePreconfiguredExpr('lfi-stable')" \
    --action deny-403

Mettre à jour la stratégie de sécurité pour bloquer l'exécution de code à distance (RCE, Remote Code Execution)

Conformément à l'ensemble des règles de base OWASP Modsecurity, appliquez des règles qui recherchent les exécutions de code à distance, y compris les injections de commandes. Les commandes OS classiques sont détectées et bloquées.

Depuis Cloud Shell :

gcloud compute security-policies rules create 9001 \
    --security-policy block-with-modsec-crs  \
    --description "block rce attacks" \
     --expression "evaluatePreconfiguredExpr('rce-stable')" \
    --action deny-403

Mettre à jour la stratégie de sécurité pour bloquer les analyseurs de sécurité

Appliquez l'ensemble des règles de base OWASP Modsecurity pour bloquer les analyseurs de sécurité, les clients HTTP de script et les robots d'exploration Web connus.

Depuis Cloud Shell :

gcloud compute security-policies rules create 9002 \
    --security-policy block-with-modsec-crs  \
    --description "block scanners" \
     --expression "evaluatePreconfiguredExpr('scannerdetection-stable')" \
    --action deny-403

Mettre à jour la stratégie de sécurité pour bloquer les attaques de protocole

Conformément à l'ensemble des règles de base OWASP Modsecurity, appliquez des règles qui recherchent les caractères de retour chariot (CR) %0d et de saut de ligne (LF) %0a, ainsi que d'autres types d'attaques de protocole comme le trafic de requêtes HTTP.

Depuis Cloud Shell :

gcloud compute security-policies rules create 9003 \
    --security-policy block-with-modsec-crs  \
    --description "block protocol attacks" \
     --expression "evaluatePreconfiguredExpr('protocolattack-stable')" \
    --action deny-403

Mettre à jour la stratégie de sécurité pour bloquer la fixation de session

Conformément à l'ensemble des règles de base OWASP Modsecurity, appliquez des règles qui…

Depuis Cloud Shell :

gcloud compute security-policies rules create 9004 \
    --security-policy block-with-modsec-crs  \
    --description "block session fixation attacks" \
     --expression "evaluatePreconfiguredExpr('sessionfixation-stable')" \
    --action deny-403

Associer la stratégie de sécurité au service de backend

Depuis Cloud Shell :

gcloud compute backend-services update juice-shop-backend \
    --security-policy block-with-modsec-crs \
    --global

L'application des règles peut prendre un certain temps (mais pas plus de 10 minutes). Une fois que vous êtes sûr d'avoir attendu suffisamment longtemps, testez les failles dont vous avez précédemment montré l'existence pour confirmer l'application des règles WAF Cloud Armor à l'étape suivante.

7. Observer la protection Cloud Armor avec l'ensemble des règles de base OWASP Modsecurity

Vérifiez que la faille LFI est atténuée.

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/?a=../

Sortie

HTTP/1.1 403 Forbidden
<...>

Vérifier que l'attaque RCE est atténuée

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls

Sortie

HTTP/1.1 403 Forbidden
<..>

Confirmer la détection d'un analyseur connu

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP -H "User-Agent: blackwidow"

Sortie

HTTP/1.1 403 Forbidden
<..>

Confirmer qu'une attaque de protocole est atténuée

Selon l'ensemble des règles de base OWASP Modsecurity version 3.0.2, l'attaque de protocole est atténuée par

Depuis Cloud Shell

curl -Ii "http://$PUBLIC_SVC_IP/index.html?foo=advanced%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>"

Sortie

HTTP/1.1 403 Forbidden
<..>

Vérifier que les tentatives de fixation de session sont bloquées

Depuis Cloud Shell

curl -Ii http://$PUBLIC_SVC_IP/?session_id=a

Sortie

HTTP/1.1 403 Forbidden
<..>

8. Examiner les règles de sécurité Cloud Armor

Maintenant que nous avons créé la stratégie de sécurité, examinons les règles qui ont été configurées.

Les règles sont évaluées selon leur priorité : les nombres inférieurs sont évalués en premier et, une fois qu'une règle est déclenchée, le traitement ne se poursuit pas pour les règles dont la valeur de priorité est supérieure.

• Priorité 9000 : bloquer les inclusions de fichiers locaux (LFI)
• Priorité 9001 : bloquer l'exécution de code à distance/l'injection de commandes (RCE, remote code execution)
• Priorité 9002 : bloquer la détection d'analyseurs
• Priorité 9003 : bloquer les attaques de protocole telles que la séparation de réponse HTTP et le trafic de requêtes HTTP
• Priorité 9004 : bloquer les attaques de fixation de session
• Priorité 10000 : autoriser votre adresse IP à accéder au site Web
• Priorité par défaut : refuser

*Notez que la règle "autoriser votre adresse IP" est configurée avec le numéro de priorité le plus élevé pour autoriser l'accès au site, tout en bloquant toute attaque.

9. Observer les journaux de la stratégie de sécurité Cloud Armor

Sur la page de la console Cloud Armor, vous pouvez afficher les détails de la stratégie de sécurité, puis cliquer sur l'onglet Logs et sur le lien View policy logs pour accéder à la page Cloud Logging. Elle filtrera automatiquement les journaux en fonction de la stratégie de sécurité qui vous intéresse, par exemple resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:(block-with-modsec-crs). Observez les codes de réponse d'erreur 403 et développez les détails du journal pour observer le nom de la stratégie de sécurité appliquée, la valeur du champ correspondant et, plus bas, les ID d'expression préconfigurés (ou l'ID de signature). Les captures d'écran suivantes montrent des exemples de journaux pour les stratégies de sécurité appliquées qui ont été configurées dans cet atelier de programmation.

Journal LFI

Journal RCE

Journal de détection d'analyseurs

Journal des attaques de protocole

Journal de fixation de session

10. Nettoyage de l'atelier

Nettoyez les ressources maintenant que vous avez terminé l'atelier.

Exécutez ces commandes pour supprimer la stratégie de sécurité Cloud Armor, l'équilibreur de charge, les instances, les règles de pare-feu et le réseau VPC.

Supprimer la stratégie de sécurité Cloud Armor du service de backend

gcloud -q compute backend-services update juice-shop-backend --security-policy "" --global

Supprimer la stratégie de sécurité Cloud Armor

Si vous supprimez la stratégie de sécurité, les règles associées seront automatiquement supprimées.

gcloud -q compute security-policies delete block-with-modsec-crs

Supprimer les ressources de l'équilibreur de charge

Les ressources d'équilibreur de charge à supprimer incluent la règle de transfert, les proxys HTTP cibles, les mappages d'URL, le backend, les vérifications de l'état et le groupe d'instances.

gcloud -q compute forwarding-rules delete juice-shop-rule --global

gcloud -q compute target-http-proxies delete juice-shop-proxy

gcloud -q compute url-maps delete juice-shop-loadbalancer

gcloud -q compute backend-services delete juice-shop-backend \
    --global

gcloud -q compute health-checks delete tcp-port-3000

gcloud -q compute instance-groups unmanaged delete juice-shop-group --zone=us-central1-c

Supprimer l'instance

gcloud -q compute instances delete owasp-juice-shop-app --zone us-central1-c

Supprimer les règles de pare-feu, le sous-réseau et le VPC

gcloud -q compute firewall-rules delete allow-health-check
gcloud -q compute firewall-rules delete allow-js-site
gcloud -q compute networks subnets delete ca-lab-subnet --region us-central1
gcloud -q compute networks delete ca-lab-vpc

11. Félicitations !

Félicitations ! Vous avez terminé l'atelier de programmation sur les règles WAF préconfigurées Cloud Armor.

Points abordés

• Configurer un groupe d'instances et un équilibreur de charge Cloud mondial
• Configurer des stratégies de sécurité Cloud Armor avec des règles WAF préconfigurées pour protéger contre les attaques LFI, les exécutions RCE, les analyseurs, les attaques de protocole et la fixation de session
• Valider que Cloud Armor a atténué certaines des 10 principales attaques de l'OWASP à l'aide des journaux

Étapes suivantes

• Protégez votre application contre les 10 principales failles de sécurité de l'OWASP grâce aux règles WAF préconfigurées de Cloud Armor.
• Ajuster les règles en fonction des niveaux de sensibilité
• Utilisez la documentation de référence sur le langage des règles personnalisées pour appliquer des mesures de sécurité plus spécifiques.