Cloud Armor pour l'équilibrage de charge réseau/VM avec des règles définies par l'utilisateur

1. Introduction

Les stratégies de sécurité Cloud Armor permettent de configurer des règles définies par l'utilisateur afin de filtrer le trafic à la périphérie du réseau de Google, en amont de votre infrastructure. Les règles de sécurité de réseau périphérique peuvent servir à protéger, autoriser ou bloquer le trafic ciblant les types de points de terminaison suivants: équilibreur de charge réseau, transfert de protocole et VM avec des adresses IP publiques.

Dans cet atelier de programmation, nous allons voir comment configurer des stratégies de sécurité Cloud Armor avec des règles définies par l'utilisateur pour empêcher les attaques DDoS.

Figure 1. Cloud Armor pour les VM avec protection des adresses IP publiques

Points abordés

• Stratégies de sécurité Cloud Armor avec configuration de règles définies par l'utilisateur
• Configurations et tests de décalage UDP

Prérequis

• Connaissance du protocole TCP/IP
• Connaissance de la ligne de commande Unix/Linux

2. Avant de commencer

L'atelier de programmation propose des étapes de configuration et de validation basées sur une topologie illustrée. Les autorisations IAM ne sont pas prises en compte dans cet atelier de programmation. Les projets doivent être enregistrés dans Managed Protection Plus pour que vous puissiez créer une règle de sécurité réseau périphérique avec des règles déjà configurées.

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

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

3. Créer un réseau VPC cible

Dans la section suivante, nous allons configurer des réseaux VPC et les configurations réseau associées. La stratégie de sécurité de Cloud Armor à la périphérie du réseau est basée sur une région. Nous configurons toutes les ressources associées dans la région asia-southeast1.

Réseau VPC

Depuis Cloud Shell

gcloud compute networks create ca4nlb --project=$prodproject --subnet-mode=custom

Créer un sous-réseau

Depuis Cloud Shell

gcloud compute networks subnets create ca4nlb-asia-southeast1 --project=$prodproject --range=10.0.0.0/24 --network=ca4nlb --region=asia-southeast1

Créez des règles de pare-feu.

Dans cette section, nous allons ajouter une règle de pare-feu pour autoriser le trafic UDP attendu sur le port 10000.

Dans Cloud Shell, créez une règle de pare-feu afin d'ouvrir le port UDP 10000 pour les tests suivants.

gcloud compute firewall-rules create ca4nlb-udp10000 --allow udp:10000 --network ca4nlb --source-ranges 0.0.0.0/0 --enable-logging

Dans Cloud Shell, créez une règle de pare-feu pour autoriser IAP à se connecter à vos instances de VM.

gcloud compute firewall-rules create ca4nlb-iap-prod --network ca4nlb --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging

Les stratégies de pare-feu n'ont pas la même fonction que les stratégies Cloud Armor. Les règles de pare-feu sont efficaces pour configurer les LCA réseau et appliquer des règles de segmentation réseau au sein de votre VPC.

L'objectif des stratégies de sécurité en périphérie du réseau Cloud Armor est de bloquer les attaques DDoS volumétriques sans consommer aucune de vos ressources. Les règles de sécurité en périphérie du réseau sont évaluées et appliquées à la périphérie du réseau Google, avant l'application des règles de pare-feu. Elles peuvent atténuer efficacement le volume important de trafic indésirable avant qu'il n'ait un impact sur la charge de travail ciblée.

4. Créer des instances de VM cibles

Créer une VM cible pour tester les règles de sécurité Cette VM doit avoir une adresse IP publique et ouvrir le port UDP 10000.

À partir de Cloud Shell, créer l'instance targetvm

gcloud compute instances create targetvm \
--zone=asia-southeast1-b \
--image-family=debian-11 \
--image-project=debian-cloud \
--network-interface=network-tier=PREMIUM,nic-type=GVNIC,stack-type=IPV4_ONLY,subnet=ca4nlb-asia-southeast1 \
--shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring

5. Configurer la protection DDoS avancée du réseau

Pour pouvoir créer une règle de sécurité en périphérie de réseau avec des règles configurées, vous devez d'abord activer la protection DDoS avancée du réseau pour la région souhaitée. La protection DDoS avancée du réseau de Cloud Armor permet aux clients de détecter et d'atténuer les attaques en continu pour les charges de travail situées derrière un équilibreur de charge réseau externe, un transfert de protocole ou des VM dotées d'adresses IP publiques. Une fois activés, tous les points de terminaison régionaux de la région activée bénéficient d'une protection DDoS avancée du réseau, toujours activée.

Depuis Cloud Shell

 gcloud compute security-policies create ca_advanced_ddos \
     --type CLOUD_ARMOR_NETWORK \
     --region asia-southeast1

 gcloud compute security-policies update ca_advanced_ddos \
     --network-ddos-protection ADVANCED \
     --region asia-southeast1

 gcloud compute network-edge-security-services create caedgepolicy \
     --security-policy ca_advanced_ddos \
     --region asia-southeast1

6. Créer une règle de sécurité en périphérie du réseau avec des règles par défaut

Vous ne pouvez pas combiner la stratégie de sécurité de la protection DDoS avancée du réseau avec la stratégie de sécurité des règles définies par l'utilisateur.

Créer une règle de sécurité en périphérie du réseau

Depuis Cloud Shell

gcloud alpha compute security-policies create customnetworkedge --type=CLOUD_ARMOR_NETWORK --region=asia-southeast1

Remplacez la règle par défaut de la stratégie par une règle de refus. La règle par défaut régit le trafic qui ne correspond à aucune des règles précédentes. Il s'agit de la dernière règle de stratégie. Si vous modifiez la règle en passant d'une règle d'autorisation à une règle de refus, tout le trafic ne provenant pas de la plage figurant sur la liste d'autorisation est bloqué.

Modifier la règle par défaut

Depuis Cloud Shell

gcloud alpha compute security-policies rules update 2147483647 --security-policy=customnetworkedge --action=deny --region=asia-southeast1

7. Créer une règle de sécurité en périphérie du réseau avec des règles configurées utilisées

Décalage UDP prédéfini par l'utilisateur et configuré dans la règle Cloud Armor. Paquet avec ces "valeurs de décalage" passe la vérification des règles et l'envoie à la VM de backend. Dans l'exemple suivant, nous définirons deux "décalages" avec des valeurs différentes.

La première valeur se trouve juste après l'en-tête UDP, et correspond exactement à 2 octets 0x1700

La deuxième valeur est un décalage de 8 octets de l'en-tête UDP, correspond exactement à 4 octets 0x12345678

Une valeur prédéfinie supérieure est convertie en une vue de bits de paquets UDP.

Le mot clé offset définit le point de départ de la valeur de correspondance, y compris l'en-tête UDP 8 octets. Toutes les valeurs prédéfinies par l'utilisateur commenceront à partir du décalage de 8. La taille maximale d'emplacement correspondant pris en charge par Cloud Armor est de 8. La longueur maximale de séquence continue de chaque emplacement est de 4 octets.

Depuis Cloud Shell

gcloud alpha compute security-policies add-user-defined-field customnetworkedge \
--user-defined-field-name=SIG1_AT_0 \
--base=udp --offset=8 --size=2 --mask=0xFF00 \
--region=asia-southeast1

gcloud alpha compute security-policies add-user-defined-field customnetworkedge \
--user-defined-field-name=SIG2_AT_8 \
--base=udp --offset=16 --size=4 --mask=0xFFFFFFFF \
--region=asia-southeast1

gcloud alpha compute security-policies rules create 1000 \
--security-policy=customnetworkedge \
--network-user-defined-fields="SIG1_AT_0;0x1700,SIG2_AT_8;0x12345678" \
--action=allow --region=asia-southeast1

8. Associer une règle de sécurité à la VM cible

Contrairement à Cloud Armor Advance, la protection DDoS du réseau couvre la protection de toutes les ressources dans les régions activées, la stratégie de sécurité en périphérie du réseau Cloud Armor doit associer une stratégie de sécurité aux ressources protégées.

Depuis Cloud Shell, associez une stratégie de sécurité à la VM protégée.

gcloud alpha compute instances network-interfaces update targetvm \
--security-policy=customnetworkedge \
--security-policy-region=asia-southeast1 \
--network-interface=nic0 \
--zone=asia-southeast1-b

Dans la section "Décrivez la VM cible" de Cloud Shell, vous constatez que la stratégie "securityPolicy" est associée. Enregistrez l'adresse IP publique pour les tests suivants.

gcloud alpha compute instances describe targetvm --zone=asia-southeast1-b

networkInterfaces:
- accessConfigs:
  - kind: compute#accessConfig
    name: External NAT
    natIP: 35.240.148.100
    networkTier: PREMIUM
    securityPolicy: https://www.googleapis.com/compute/alpha/projects/<project>/regions/asia-southeast1/securityPolicies/customnetworkedge

Une fois la règle de sécurité appliquée à la VM cible, tout autre trafic sans correspondance provenant d'Internet sera supprimé. Par exemple, vous ne pouvez pas exécuter sudo apt update, car le protocole TCP n'est pas autorisé.

Dans Cloud Shell, dissociez la stratégie de sécurité de la VM protégée.

gcloud alpha compute instances network-interfaces update targetvm \
--network-interface=nic0 \
--zone=asia-southeast1-b \
--security-policy= 

9. Préparer les ressources de test

Créer un réseau VPC test

Depuis Cloud Shell

gcloud compute networks create test --project=$prodproject --subnet-mode=custom

Créer un sous-réseau de test

Depuis Cloud Shell

gcloud compute networks subnets create test-asia-southeast1 --project=$prodproject --range=10.0.1.0/24 --network=test --region=asia-southeast1

Créer un pare-feu

Dans Cloud Shell, créez une règle de pare-feu pour autoriser IAP à se connecter à vos instances de VM.

gcloud compute firewall-rules create test-iap-prod --network test --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging

Créer une VM de test

Depuis Cloud Shell

gcloud compute instances create test01 \
    --zone=asia-southeast1-b \
    --image-family=debian-11 \
    --image-project=debian-cloud \
    --network-interface=network-tier=PREMIUM,nic-type=GVNIC,stack-type=IPV4_ONLY,subnet=test-asia-southeast1 \
    --shielded-secure-boot \
    --shielded-vtpm \
    --shielded-integrity-monitoring

10. Validation

Connectez-vous à la console de la VM de test et installez le générateur de paquets packit.

sudo apt install packit

Conformément à la conception de décalage UDP, utilisez packit pour générer des paquets UDP. Nous simulons un paquet (-t udp) entre l'adresse IP source de l'interface (-s ens4) (-s 10.0.1.2) avec les ports sources (-S 10000) et l'adresse IP de destination de la VM cible (-d 35.240.148.100) avec les ports de destination (-D 10000). Le contenu des paquets correspond aux valeurs (-p ‘0x 17 00 00 00 00 00 00 00 12 34 56 78'). Nous enverrons les paquets (-c 4).

sudo packit -m inject -t UDP -i ens4 -s 10.0.1.2 -d 35.240.148.100 -S 10000 -D 10000 -p '0x 17 00 00 00 00 00 00 00 12 34 56 78' -c 4

Dans la VM cible, exécutez tcpdump pour capturer le paquet UDP.

sudo tcpdump port 10000 -v -n 

tcpdump: listening on ens4, link-type EN10MB (Ethernet), snapshot length 262144 bytes
06:36:18.434106 IP (tos 0x0, ttl 128, id 17173, offset 0, flags [none], proto UDP (17), length 40)
    35.197.157.140.10000 > 10.0.0.2.10000: UDP, length 12
06:36:19.433656 IP (tos 0x0, ttl 128, id 55641, offset 0, flags [none], proto UDP (17), length 40)
    35.197.157.140.10000 > 10.0.0.2.10000: UDP, length 12
06:36:20.433935 IP (tos 0x0, ttl 128, id 27161, offset 0, flags [none], proto UDP (17), length 40)
    35.197.157.140.10000 > 10.0.0.2.10000: UDP, length 12
06:36:21.434150 IP (tos 0x0, ttl 128, id 46782, offset 0, flags [none], proto UDP (17), length 40)
    35.197.157.140.10000 > 10.0.0.2.10000: UDP, length 12

Si nous modifions les modèles de trafic dans la VM de test, nous ne pouvons pas capturer aucun paquet dans la VM cible.

sudo packit -m inject -t UDP -i ens4 -s 10.148.0.6 -d 34.87.79.31 -S 10000 -D 10000 -p '0x 33 33 00 00 00 00 00 00 12 34 56 78' -c 4

La règle de sécurité Cloud Armor est déployée à la périphérie d'Internet. Si vous configurez une VM dans un VPC ca4nlb et que vous la testez avec une adresse IP interne de VM cible, cette règle ne s'appliquera pas.

11. Télémétrie

L'API Network Security (networksecurity.googleapis.com) doit être activée pour que vous puissiez afficher la télémétrie.

Ouvrez Cloud Metric. Utilisez le MQL ci-dessous pour interroger les données de télémétrie de NetworkSercurityPolicy.

fetch networksecurity.googleapis.com/RegionalNetworkSecurityPolicy
| metric 'networksecurity.googleapis.com/l3/external/packet_count'
| filter (resource.policy_name == 'customnetworkedge')
| align rate(1m)
| every 1m
| group_by [metric.blocked], [value_packet_count_mean: mean(value.packet_count)]
| group_by 1m, [value_packet_count_mean_mean: mean(value_packet_count_mean)]
| every 1m

Générer un volume de trafic important à l'aide de la commande "match offset"

sudo packit -m inject -t UDP -i ens4 -s 10.148.0.6 -d 34.87.79.31 -S 10000 -D 10000 -p '0x 17 00 00 00 00 00 00 00 12 34 56 78' -c 1000000 -w 0.001

[result]
Injected: 1000000  Packets/Sec: 10309.27  Bytes/Sec: 412371.13  Errors: 0

Générer un volume de trafic important à l'aide d'une commande d'annulation de correspondance (unmatch offset)

sudo packit -m inject -t UDP -i ens4 -s 10.148.0.6 -d 34.87.79.31 -S 10000 -D 10000 -p '0x 11 00 00 00 00 00 00 00 12 34 56 78' -c 1000000 -w 0.001

[result]
Injected: 1000000  Packets/Sec: 10309.27  Bytes/Sec: 412371.13  Errors: 0

Les données de télémétrie sont filtrées par "policy_name" et regroupées par "bloqué". La ligne bleue indique le trafic autorisé par les règles de stratégie. La ligne verte indiquait le trafic bloqué par les règles de stratégie.

12. Étapes de nettoyage

Supprimer les composants de l'atelier depuis une seule interface Cloud Shell dans le terminal

gcloud compute instances delete targetvm --zone=asia-southeast1-b

gcloud compute firewall-rules delete ca4nlb-udp10000

gcloud compute firewall-rules delete ca4nlb-iap-prod

gcloud compute networks subnets delete ca4nlb-asia-southeast1 --region=asia-southeast1

gcloud compute networks delete ca4nlb

gcloud alpha compute security-policies delete customnetworkedge --region=asia-southeast1

gcloud alpha compute network-edge-security-services delete caedgepolicy --region=asia-southeast1

gcloud alpha compute security-policies delete ca_advanced_ddos --region=asia-southeast1

gcloud compute instances delete test01 --zone=asia-southeast1-b

gcloud compute firewall-rules delete test-iap-prod

gcloud compute networks subnets delete test-asia-southeast1 --region=asia-southeast1

gcloud compute networks delete test

13. Félicitations !

Bravo ! Vous avez terminé cet atelier de programmation.

Points abordés

• Stratégies de sécurité Cloud Armor avec des règles définies par le client