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 pour filtrer le trafic à la périphérie du réseau Google, en amont de votre infrastructure. Les stratégies de sécurité Network Edge peuvent être utilisées pour protéger et autoriser ou bloquer le trafic ciblant les types de points de terminaison suivants : équilibreur de charge réseau, transfert de protocole et VM avec adresses IP publiques.

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

Figure 1. Cloud Armor pour la protection des VM avec adresse IP publique.

Points abordés

• Configuration des règles de sécurité Cloud Armor avec des règles définies par l'utilisateur
• Configurations et tests de décalage UDP.

Prérequis

• Connaissances de 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 abordées dans cet atelier de programmation. Pour créer une stratégie de sécurité de périphérie de réseau avec des règles configurées par l'utilisateur, les projets doivent être enregistrés dans Managed Protection Plus.

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 les réseaux VPC et les configurations réseau associées. La stratégie de sécurité de périphérie réseau Cloud Armor est basée sur les régions. 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 vers le port 10000.

Dans Cloud Shell, créez une règle de pare-feu pour 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 ont un objectif différent de celui des stratégies Cloud Armor. Les stratégies de pare-feu sont efficaces pour configurer les ACL réseau et appliquer les stratégies de segmentation réseau dans votre VPC.

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

4. Créer des instances de VM cibles

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

Depuis Cloud Shell, créez 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é de réseau périphérique avec des règles configurées par l'utilisateur, 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 offre aux clients une détection et une atténuation permanentes des attaques pour les charges de travail situées derrière un équilibreur de charge réseau externe, un transfert de protocole ou des VM avec adresses IP publiques. Une fois la fonctionnalité activée, tous les points de terminaison régionaux de la région activée bénéficient d'une protection DDoS avancée 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 stratégie de sécurité de périphérie réseau avec des règles par défaut

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

Créer une règle de sécurité Network Edge

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, qui est une règle d'autorisation, par une règle de blocage. 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 la stratégie. Le fait de remplacer la valeur de la règle "Autoriser" par "Refuser" bloque tout le trafic qui ne provient pas de la plage de la liste d'autorisation.

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 stratégie de sécurité de périphérie réseau avec des règles configurées par l'utilisateur

Décalage UDP prédéfini par l'utilisateur et configuré dans la règle Cloud Armor. Les paquets avec ces "valeurs de décalage" passeront le contrôle des règles et seront envoyés à la VM de backend. Dans l'exemple suivant, nous allons définir deux "décalages" avec des valeurs différentes.

La première valeur se trouve juste après l'en-tête UDP. Elle doit correspondre exactement à 2 octets 0x1700.

La deuxième valeur correspond au décalage de 8 octets de l'en-tête UDP et correspond exactement aux 4 octets 0x12345678.

La valeur prédéfinie ci-dessus se traduit par une vue des bits du paquet UDP.

Le mot clé offset définit le point de départ de la valeur de correspondance, y compris l'en-tête UDP de 8 octets. Toutes les valeurs prédéfinies par l'utilisateur commenceront à l'offset 8. Le nombre maximal d'emplacements correspondants acceptés par Cloud Armor est de huit. La longueur maximale de la séquence continue correspondante de chaque emplacement de paquet 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 stratégie de sécurité à une VM cible

Contrairement à la protection DDoS avancée du réseau Cloud Armor, qui 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.

Dans Cloud Shell, associez la 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

À partir de Cloud Shell, décrivez la VM cible. Vous verrez que la stratégie de sécurité 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 stratégie de sécurité appliquée à la VM cible, tout autre trafic non correspondant provenant d'Internet sera abandonné. Par exemple, vous ne pouvez pas exécuter sudo apt update, car nous n'avons pas autorisé le protocole TCP.

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éparez les ressources de test.

Créer un réseau VPC de 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

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

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 schémas de trafic dans la VM de test, nous ne pouvons 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 stratégie de sécurité Cloud Armor est déployée à la périphérie d'Internet. Si vous configurez une VM dans le VPC ca4nlb et que vous effectuez un test avec l'adresse IP interne de la VM cible, cette règle n'aura aucun effet.

11. Telemetry

Pour pouvoir afficher la télémétrie, l'API Network Security (networksecurity.googleapis.com) doit être activée.

Ouvrez Cloud Metrics et utilisez le MQL ci-dessous pour interroger les données de télémétrie NetworkSecurityPolicy.

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érez un trafic à volume élevé avec la commande d'offset de correspondance.

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érez un trafic à volume élevé avec une commande de décalage non correspondante.

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

La télémétrie est filtrée par policy_name et regroupée par blocage. La ligne bleue indique le trafic autorisé par les règles de stratégie. La ligne verte indique le trafic bloqué par les règles de stratégie.

12. Étapes de nettoyage

Supprimer les composants de l'atelier à partir d'un seul terminal Cloud Shell

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

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