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é de réseau périphérique d'entreprise de Google. Elle offre une protection DDOS, l'application des règles WAF et une 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. Ces ensembles de règles sont basés sur la version 3.0.2 de l'ensemble de règles de base OWASP Modsecurity visant à vous protéger contre certains des risques de sécurité les plus courants pour les applications Web, y compris l'inclusion de fichiers locaux (lfi), l'inclusion de fichiers distants (rfi), l'exécution de code à distance (rce), et bien d'autres encore.
Dans cet atelier de programmation, vous allez apprendre à atténuer certaines des failles courantes à l'aide de règles WAF Google Cloud Armor.
Points abordés
- Configurer un groupe d'instances et un équilibreur de charge global pour la compatibilité d'un service
- Configurer des stratégies de sécurité Cloud Armor avec des règles WAF préconfigurées pour vous protéger contre les attaques LFI, RCE, les analyseurs, les attaques de protocole et la fixation de session
- Comment vérifier 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 la visite guidée de la mise en réseau dans GCP avec Networking in the Google Cloud.
- (Facultatif) Suivez l'atelier Cloudnet20 Cloud Armor pour apprendre à protéger les charges de travail avec l'injection SQL, les règles basées sur les adresses IP et les règles géographiques.
Topologie des ateliers de programmation et cas d'utilisation
Figure 1 : Topologie de l'atelier de programmation avec 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é figurant dans le top 10 de l'OWASP, par nature. Un attaquant peut l’exploiter à des fins de test. Dans cet atelier de programmation, nous l'utiliserons pour illustrer certaines attaques d'applications, puis pour protéger ces dernières à l'aide de règles WAF Cloud Armor. L'application sera exécutée par un équilibreur de charge Google Cloud, auquel la stratégie et les règles de sécurité Cloud Armor seront appliquées. Elles seront diffusées sur l'Internet public, donc accessibles depuis presque n'importe où et protégées à l'aide de règles de pare-feu Cloud Armor et VPC.
2. Préparation
Configuration de l'environnement d'auto-formation
- 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.)
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.
- 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 gratuite. 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
Activer 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, vous allez maintenant configurer quelques règles de pare-feu. La première règle de pare-feu permettra d'autoriser toutes les adresses IP à accéder à l'adresse IP externe du site Web de l'application de test sur le port 3000. La deuxième règle de pare-feu permettra d'autoriser les vérifications de l'é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 micrologiciel pour autoriser les vérifications d'état à partir des plages de vérifications d'état Google.
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 de test
L'étape suivante consiste à créer l'application de test. Dans le cas présent, il s'agit du serveur Web de l'OWASP Juice Shop.
Lors de la création de l'instance de calcul, nous utilisons une image de conteneur pour nous assurer que le serveur dispose des services appropriés. Ce serveur sera déployé dans us-central1-c et comportera un tag réseau qui permettra de vérifier l'état.
Créer l'application OWASP Juice Shop
Utilisez la célèbre application Open Source Juice Shop de l'OWASP en tant qu'application vulnérable. Vous pouvez également utiliser cette application pour tester la sécurité de l'OWASP via son site Web.
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 de l'é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 de 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 d'état, un service de backend, un mappage d'URL, un proxy cible et une règle de transfert.
Configurer le composant Cloud Load Balancing: vérification de l'état
Créez la vérification d'état pour le port du 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 de l'équilibreur de charge Cloud: proxy cible
Créez le proxy cible devant le 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 Cloud Load Balancing: 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 récupérer 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 aussi ouvrir le navigateur pour voir la boutique de jus de fruits !
Nous sommes maintenant prêts à explorer les failles de Juice Shop et à s'en protéger à l'aide d'ensembles de règles WAF Cloud Armor.
5. Démontrer les vulnérabilités connues
Pour gagner du temps, nous allons vous présenter sous forme condensée 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 des fichiers locaux est le processus qui consiste à observer les fichiers présents sur le serveur en exploitant le manque de validation des entrées dans la requête pour potentiellement exposer des données sensibles. L'exemple suivant montre simplement qu'un traversée de répertoire est possible. Dans votre navigateur ou avec curl, observez un chemin existant diffusé par l'application.
Depuis Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp
Sortie
HTTP/1.1 200 OK <...>
Notez également que le 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 comprend divers scénarios d’injection de commandes UNIX et Windows permettant aux attaquants d’exécuter des commandes d’OS généralement limitées à des utilisateurs privilégiés. L'exemple suivant montre une exécution de commande ls simple transmise.
Depuis Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls
Sortie
HTTP/1.1 200 OK <...>
Vous pouvez supprimer les indicateurs curl pour observer le résultat complet.
Observer l'accès d'un analyseur connu
Les applications commerciales et Open Source d'analyse sont utilisées à des fins diverses, y compris pour rechercher des vulnérabilités. Ces outils utilisent un user-agent connu et d'autres en-têtes. Observez le fonctionnement de curl avec un en-tête user-agent bien 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: division du protocole HTTP
Certaines applications Web utilisent les données saisies par 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 empoisonner 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 pourrait alors être interprétée comme deux réponses par tout ce qui se produit pour l'analyser, comme un serveur proxy intermédiaire, susceptible de diffuser un faux contenu dans les requêtes ultérieures. Insérez la séquence %0d%0a dans le paramètre d'entrée, ce qui peut entraîner la diffusion 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 la 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
Répertoriez 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"
Étant donné que la règle par défaut est configurée avec l'action "refuser" (action refus), nous devons autoriser l'accès depuis 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 depuis votre adresse IP (INSÉRER VOTRE 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 le jeu de règles de base OWASP ModSecurity qui empêche le traversée de répertoire pour l'inclusion 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)
Conformément à l'ensemble de règles OWASP ModSecurity Core, appliquez des règles qui recherchent rce, y compris une injection de commandes. Les commandes classiques du système d'exploitation 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 de règles OWASP ModSecurity Core pour bloquer les outils d'analyse de sécurité, les clients HTTP de script et les robots d'exploration 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 règle de sécurité pour bloquer les attaques de protocole
Conformément à l'ensemble de règles OWASP ModSecurity Core, appliquez des règles qui recherchent les caractères de retour chariot (CR) %0d et Linefeed (LF) %0a, ainsi que d'autres types d'attaques de protocole telles que la contrebande 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 de règles de base OWASP ModSecurity, appliquez les 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 (pas plus de 10 minutes). Après avoir vérifié que vous disposez d'un délai suffisant, testez les failles précédemment démontrées pour confirmer l'application des règles WAF Cloud Armor à l'étape suivante.
7. Observer la protection Cloud Armor avec l'ensemble de règles de base OWASP ModSecurity
Confirmer 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 par RCE est atténuée
Depuis Cloud Shell
curl -Ii http://$PUBLIC_SVC_IP/ftp?doc=/bin/ls
Sortie
HTTP/1.1 403 Forbidden <..>
Vérifier que la détection du scanner est bien connue
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
Conformément à l'ensemble de règles OWASP ModSecurity Core 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 <..>
Confirmer que les tentatives de fixation de la 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é, voyons exactement quelles règles ont été configurées.
Les règles sont évaluées par ordre de priorité: les règles dont la priorité est la plus élevée sont évaluées en premier. Une fois déclenchées, le traitement s'interrompt.
- Priorité 9000 - Bloquer LFI (inclusion de fichiers locaux)
- Priorité 9001 - Bloquer RCE (exécution de code à distance/injection de commandes)
- Priorité 9002 - Scanner de blocs détectés
- Priorité 9003 - Attaques de protocole de blocage telles que la séparation de HTTP et le trafic de 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.
*Le bouton "Autoriser votre adresse IP" est configurée avec le numéro de priorité le plus élevé pour autoriser l'accès au site, mais bloque 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 règle de sécurité. Cliquez sur l'onglet Logs, puis sur le lien View policy logs pour accéder à la page Cloud Logging. Il filtrera automatiquement en fonction de la règle 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 règle 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 règles de sécurité appliquées configurées dans cet atelier de programmation.
Journal LFI
Journal RCE
Journal de détection du scanner
Journal d'attaque de protocole
Journal de fixation de la 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
La suppression de la stratégie de sécurité entraînera la suppression automatique des règles associées.
gcloud -q compute security-policies delete block-with-modsec-crs
Supprimer les ressources de l'équilibreur de charge
Les ressources de l'équilibreur de charge à supprimer incluent la règle de transfert, les proxys HTTP cibles, les mappages d'URL, le backend, les vérifications d'é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 de Cloud Armor.
Points abordés
- Configurer un groupe d'instances et un équilibreur de charge cloud global
- Configurer des stratégies de sécurité Cloud Armor avec des règles WAF préconfigurées pour vous protéger contre les attaques LFI, RCE, les analyseurs, les attaques de protocole et la fixation de session
- Comment vérifier 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 le top 10 des failles OWASP grâce aux règles WAF préconfigurées de Cloud Armor.
- Affiner les règles en fonction des niveaux de sensibilité
- Pour une application de sécurité plus spécifique, consultez la documentation de référence sur le langage des règles personnalisées.