GSP474

Présentation

La mise en miroir du trafic est une fonctionnalité essentielle de sécurité et d'analyse du réseau dans Google Cloud. Son fonctionnement est semblable à celui d'un TAP réseau ou d'une session SPAN sur les réseaux traditionnels. En résumé, la mise en miroir de paquets capture le trafic réseau (entrée et sortie) à partir de "sources en miroir", copie le trafic et transfère la copie aux "collecteurs".

Il est important de noter que la mise en miroir de paquets capture la charge utile complète de chaque paquet et consomme donc une quantité supplémentaire de bande passante. La mise en miroir de paquets n'étant basée sur aucune période d'échantillonnage, elle peut être utilisée pour améliorer le dépannage, les solutions de sécurité et l'analyse basée sur des applications de couche supérieure.

La mise en miroir de paquets est fondée sur une "règle de mise en miroir de paquets", qui contient les attributs suivants :

• Région
• Réseaux VPC
• Sources en miroir
• Collecteur (destination)
• Trafic en miroir (filtre)

Voici quelques points essentiels à prendre en compte :

• Seul le trafic TCP, UDP et ICMP peut être mis en miroir. Toutefois, cela devrait convenir à la plupart des cas d'utilisation.
• Les "sources en miroir" et les "collecteurs" doivent se trouver dans la MÊME région, mais peuvent être dans des zones différentes, voire sur des VPC différents, à condition que ces VPC soient correctement appairés.
• Des frais de bande passante supplémentaires s'appliquent, notamment entre les zones. Vous pouvez utiliser des filtres pour limiter le trafic mis en miroir.

La "mise en miroir de paquets" est notamment utilisée avec les solutions de système de détection des intrusions (IDS). Certaines solutions IDS basées sur le cloud nécessitent l'exécution d'un service spécial sur chaque VM source, ou l'intégration d'un dispositif virtuel IDS entre la source réseau et la destination. Chacun de ces choix a des implications importantes. Par exemple, bien que la solution basée sur les services soit entièrement distribuée, elle nécessite la compatibilité du système d'exploitation invité avec le logiciel. La solution "intégrée" peut créer un goulot d'étranglement sur le réseau, car l'ensemble du trafic doit être acheminé vers le dispositif IDS. La solution intégrée ne pourra pas non plus capturer le trafic "Est-Ouest" au sein des VM d'un même VPC.

La mise en miroir de paquets Google Cloud ne nécessite aucun logiciel supplémentaire sur les VM et est entièrement distribuée sur chacune des machines virtuelles mises en miroir. L'IDS "collecteur" est placé hors du chemin à l'aide d'un équilibreur de charge réseau interne (ILB), et reçoit le trafic "Nord-Sud" et le trafic "Est-Ouest".

Description de l'atelier de mise en miroir de paquets

L'exemple suivant, qui utilise l'IDS Open Source Suricata, présente une utilisation possible de la mise en miroir de paquets à l'aide d'un IDS.

• Un seul VPC avec deux sous-réseaux, un pour les sources mises en miroir et un pour le collecteur
• 2 serveurs Web créés avec une adresse IP publique
• 1 serveur de collecteur (IDS) créé SANS adresse IP publique pour des raisons de sécurité
• CloudNAT activé pour l'accès à Internet en cas de nécessité
• Toutes les VM créées dans la même région et la même zone, pour des raisons de simplicité et de coût

Dans cet atelier, vous allez créer un environnement Google Cloud, configurer l'ILB "collecteur", configurer la règle de mise en miroir de paquets, et installer et configurer [Suricata] (https://suricata-ids.org/) sur une instance virtuelle pour qu'il serve d'IDS. Une fois ces opérations terminées, des tests réseau seront effectués pour valider la configuration et l'utilisation de la mise en miroir de paquets avec l'IDS Open Source. Pour simplifier la démonstration, nous utiliserons une configuration Suricata et un ensemble de règles très réduits.

Objectifs :

• Créer un environnement de mise en réseau Google Cloud, comme illustré dans le schéma ci-dessus
• Créer deux machines virtuelles avec des commandes gcloud intervenant en tant que SERVEURS WEB
• Créer une machine virtuelle unique avec des commandes gcloud qui interviendra en tant qu'IDS
• Créer un équilibreur de charge interne (ILB) qui interviendra en tant que "collecteur" pour la mise en miroir de paquets
• Installer et configurer un IDS Open Source (Suricata) sur la VM IDS
• Passer en revue les règles de base de l'alerte IDS
• Créer une règle de mise en miroir de paquets
• Tester la mise en miroir de paquets en générant du trafic réseau vers le sous-réseau "mis en miroir"
• Tester l'IDS Suricata en générant du trafic réseau pour simuler un événement IDS et examiner la journalisation IDS

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome) ;

Remarque : Ouvrez une fenêtre de navigateur en mode incognito/navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le temporaire étudiant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• vous disposez d'un temps limité ; une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :

   • Le bouton Ouvrir la console Google Cloud
   • Le temps restant
   • Les identifiants temporaires que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier

2. Cliquez sur Ouvrir la console Google Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans la fenêtre de navigation privée si vous utilisez le navigateur Chrome).

   L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur ci-dessous et collez-le dans la boîte de dialogue Se connecter.

   {{{user_0.username | "Username"}}}

   Vous trouverez également le nom d'utilisateur dans le panneau Détails concernant l'atelier.

4. Cliquez sur Suivant.

5. Copiez le mot de passe ci-dessous et collez-le dans la boîte de dialogue Bienvenue.

   {{{user_0.password | "Password"}}}

   Vous trouverez également le mot de passe dans le panneau Détails concernant l'atelier.

6. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis pour l'atelier. Ne saisissez pas ceux de votre compte Google Cloud. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

7. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas à des essais gratuits.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Pour afficher un menu contenant la liste des produits et services Google Cloud, cliquez sur le menu de navigation en haut à gauche.

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Le résultat contient une ligne qui déclare YOUR_PROJECT_ID (VOTRE_ID_PROJET) pour cette session :

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

2. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

3. Cliquez sur Autoriser.

4. Vous devez à présent obtenir le résultat suivant :

Résultat :

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = <ID_Projet>

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Tâche 1 : Créer une empreinte réseau

Dans cette section, vous allez créer un VPC et deux sous-réseaux au sein de ce VPC. Tout cela sera effectué à l'aide des commandes gcloud CLI dans Google Cloud Shell.

1. Exécutez la commande suivante pour créer un réseau privé virtuel :

gcloud compute networks create dm-stamford \ --subnet-mode=custom

2. Ajoutez un sous-réseau au VPC pour le trafic mis en miroir dans la région "" :

gcloud compute networks subnets create dm-stamford-{{{project_0.default_region | REGION}}} \ --range=172.21.0.0/24 \ --network=dm-stamford \ --region={{{project_0.default_region | REGION}}}

3. Ajoutez un sous-réseau au VPC pour le collecteur dans la région "" :

gcloud compute networks subnets create dm-stamford-{{{project_0.default_region | REGION}}}-ids \ --range=172.21.1.0/24 \ --network=dm-stamford \ --region={{{project_0.default_region | REGION}}}

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer une empreinte réseau

Tâche 2 : Créer des règles de pare-feu et une instance Cloud NAT

Pour réaliser cet atelier, vous devrez créer trois règles de pare-feu.

• La règle 1 autorise le port HTTP standard (TCP 80) et le protocole ICMP sur toutes les VM de toutes les sources.
• La règle 2 permet à l'IDS de recevoir TOUT le trafic provenant de TOUTES les sources. Veillez à NE PAS attribuer une adresse IP publique à la VM IDS dans les sections suivantes.
• La règle 3 autorise le port TCP 22 de la plage d'adresses IP du "proxy IAP Google Cloud" sur TOUTES les VM, ce qui vous permet de vous connecter en SSH aux VM via la console Cloud.

Exécutez les commandes suivantes pour créer les règles de pare-feu :

gcloud compute firewall-rules create fw-dm-stamford-allow-any-web \ --direction=INGRESS \ --priority=1000 \ --network=dm-stamford \ --action=ALLOW \ --rules=tcp:80,icmp \ --source-ranges=0.0.0.0/0 gcloud compute firewall-rules create fw-dm-stamford-ids-any-any \ --direction=INGRESS \ --priority=1000 \ --network=dm-stamford \ --action=ALLOW \ --rules=all \ --source-ranges=0.0.0.0/0 \ --target-tags=ids gcloud compute firewall-rules create fw-dm-stamford-iapproxy \ --direction=INGRESS \ --priority=1000 \ --network=dm-stamford \ --action=ALLOW \ --rules=tcp:22,icmp \ --source-ranges=35.235.240.0/20

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer des règles de pare-feu Cloud et une instance Cloud NAT

Créer un routeur Cloud Router

• Pour créer une instance Cloud NAT, vous devez d'abord configurer un routeur Cloud Router dans la région correspondante :

gcloud compute routers create router-stamford-nat-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}} \ --network=dm-stamford

Configurer une instance Cloud NAT

• Pour fournir un accès Internet aux VM sans adresse IP publique, une instance Cloud NAT doit être créée dans la région correspondante :

gcloud compute routers nats create nat-gw-dm-stamford-{{{project_0.default_region | REGION}}} \ --router=router-stamford-nat-{{{project_0.default_region | REGION}}} \ --router-region={{{project_0.default_region | REGION}}} \ --auto-allocate-nat-external-ips \ --nat-all-subnet-ip-ranges

La VM IDS sera créée sans adresse IP publique pour qu'elle soit inaccessible depuis Internet. Cependant, l'accès à Internet sera nécessaire pour télécharger les mises à jour et installer les packages Suricata.

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer un routeur Cloud Router et configurer une instance Cloud NAT

Tâche 3 : Créer des machines virtuelles

Créer un modèle d'instance pour un serveur Web

• Ce modèle prépare un serveur Ubuntu dans la région "" et installe un service Web simple :

gcloud compute instance-templates create template-dm-stamford-web-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}} \ --network=dm-stamford \ --subnet=dm-stamford-{{{project_0.default_region | REGION}}} \ --machine-type=e2-small \ --image=ubuntu-1604-xenial-v20200807 \ --image-project=ubuntu-os-cloud \ --tags=webserver \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'

Créer un groupe d'instances géré pour les serveurs Web

• Cette commande utilise le modèle d'instance de l'étape précédente pour créer deux serveurs Web :

gcloud compute instance-groups managed create mig-dm-stamford-web-{{{project_0.default_region | REGION}}} \ --template=template-dm-stamford-web-{{{project_0.default_region | REGION}}} \ --size=2 \ --zone={{{project_0.default_zone | "ZONE"}}}

Créer un modèle d'instance pour la VM IDS

• Ce modèle prépare un serveur Ubuntu dans la région "" sans adresse IP publique :

gcloud compute instance-templates create template-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}} \ --network=dm-stamford \ --no-address \ --subnet=dm-stamford-{{{project_0.default_region | REGION}}}-ids \ --image=ubuntu-1604-xenial-v20200807 \ --image-project=ubuntu-os-cloud \ --tags=ids,webserver \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'

Créer un groupe d'instances géré pour la VM IDS

• Cette commande utilise le modèle d'instance de l'étape précédente pour créer une VM qui sera configurée pour être votre IDS. L'installation de Suricata sera traitée dans une section ultérieure.

gcloud compute instance-groups managed create mig-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --template=template-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --size=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer des machines virtuelles

Tâche 4 : Créer un équilibreur de charge interne

La mise en miroir de paquets utilise un équilibreur de charge interne (ILB) pour transférer le trafic mis en miroir vers un groupe de collecteurs. Dans ce cas, le groupe de collecteurs contient une seule VM.

1. Créez une vérification d'état de base pour les services de backend :

gcloud compute health-checks create tcp hc-tcp-80 --port 80

2. Créez un groupe de services de backend à utiliser pour un ILB :

gcloud compute backend-services create be-dm-stamford-suricata-{{{project_0.default_region | REGION}}} \ --load-balancing-scheme=INTERNAL \ --health-checks=hc-tcp-80 \ --network=dm-stamford \ --protocol=TCP \ --region={{{project_0.default_region | REGION}}}

3. Ajoutez le groupe d'instances géré IDS qui a été créé au groupe de services de backend créé à l'étape précédente :

gcloud compute backend-services add-backend be-dm-stamford-suricata-{{{project_0.default_region | REGION}}} \ --instance-group=mig-dm-stamford-ids-{{{project_0.default_region | REGION}}} \ --instance-group-zone={{{project_0.default_zone | "ZONE"}}} \ --region={{{project_0.default_region | REGION}}}

4. Créez une règle de transfert frontale pour qu'elle serve de point de terminaison de la collecte :

gcloud compute forwarding-rules create ilb-dm-stamford-suricata-ilb-{{{project_0.default_region | REGION}}} \ --load-balancing-scheme=INTERNAL \ --backend-service be-dm-stamford-suricata-{{{project_0.default_region | REGION}}} \ --is-mirroring-collector \ --network=dm-stamford \ --region={{{project_0.default_region | REGION}}} \ --subnet=dm-stamford-{{{project_0.default_region | REGION}}}-ids \ --ip-protocol=TCP \ --ports=all Remarque : Bien que le TCP soit listé comme protocole, le type de trafic mis en miroir sera configuré dans la règle de mise en miroir de paquets dans une prochaine section. Notez également que l'option --is-mirroring-collector, est définie.

Cliquez sur Vérifier ma progression pour valider l'objectif.

Créer un équilibreur de charge interne

Tâche 5 : Installer l'IDS Open Source – Suricata

Remarque : Pour les deux sections suivantes, vous devrez vous connecter en SSH à la VM IDS et exécuter les commandes dans son shell. Veillez à ne pas exécuter les commandes dans Cloud Shell.

Se connecter en SSH à la VM IDS

1. Dans le menu de navigation de la console Cloud, accédez à Compute Engine > Instances de VM.

2. Cliquez sur le bouton SSH de votre VM IDS.

Une nouvelle fenêtre s'ouvre, vous permettant d'exécuter des commandes dans la VM IDS.

3. Mettez à jour la VM IDS :

sudo apt-get update -y

4. Installez les dépendances Suricata :

sudo apt-get install libpcre3-dbg libpcre3-dev autoconf automake libtool libpcap-dev libnet1-dev libyaml-dev zlib1g-dev libcap-ng-dev libmagic-dev libjansson-dev libjansson4 -y sudo apt-get install libnspr4-dev -y sudo apt-get install libnss3-dev -y sudo apt-get install liblz4-dev -y sudo apt install rustc cargo -y

5. Installez Suricata :

sudo add-apt-repository ppa:oisf/suricata-stable -y sudo apt-get update -y sudo apt-get install suricata -y Remarque : Si un message d'erreur s'affiche pendant l'installation, réalisez l'étape de vérification suivante.

Vérifier l'installation

• Vérifiez l'installation et la version installée de Suricata à l'aide la commande suivante :

suricata -V

Le résultat doit être semblable à ceci :

This is Suricata version 5.0.3 RELEASE

Tâche 6 : Configurer et examiner Suricata

Les commandes et les étapes de la section suivante doivent également être exécutées dans le SSH de la VM IDS/Suricata.

• Arrêtez le service Suricata et sauvegardez le fichier de configuration par défaut :

sudo systemctl stop suricata sudo cp /etc/suricata/suricata.yaml /etc/suricata/suricata.backup

Télécharger et remplacer le nouveau fichier de configuration Suricata et le fichier de règles abrégées

Le nouveau fichier de configuration met à jour l'interface du collecteur et n'émet des alertes que sur une petite partie du trafic, tel que configuré dans les fichiers my.rules et suricata.yaml. Les configurations par défaut des ensembles de règles et des alertes de Suricata sont assez complètes et superflues pour cet atelier.

• Exécutez les commandes suivantes pour copier les fichiers :

wget https://storage.googleapis.com/tech-academy-enablement/GCP-Packet-Mirroring-with-OpenSource-IDS/suricata.yaml wget https://storage.googleapis.com/tech-academy-enablement/GCP-Packet-Mirroring-with-OpenSource-IDS/my.rules sudo mkdir /etc/suricata/poc-rules sudo cp my.rules /etc/suricata/poc-rules/my.rules sudo cp suricata.yaml /etc/suricata/suricata.yaml

Démarrer le service Suricata

Le service doit parfois redémarrer. La commande restart est incluse à cette étape pour tenir compte de cette possibilité :

sudo systemctl start suricata sudo systemctl restart suricata

Examiner des règles Suricata simples afin de réaliser des tests

Pour cet atelier, l'ensemble de règles pour Suricata a été réduit à 4. L'installation par défaut de Suricata dispose cependant d'un vaste ensemble de règles.

• Pour cet atelier, il est préférable de limiter les alertes à cette liste succincte afin de pouvoir tester facilement chacune d'elles.

cat /etc/suricata/poc-rules/my.rules

Le résultat doit afficher en tout quatre règles et une description pour chacune d'elles.

####RULES##### #UDP ALERTS alert udp $HOME_NET any -> 8.8.8.8 53 (msg:"BAD UDP DNS REQUEST"; sid:99996; rev:1;) #HTTP ALERTS alert http any any -> $HOME_NET 80 (msg:"BAD HTTP PHP REQUEST"; http.uri; content:"index.php"; sid:99997; rev:1;) #ICMP ALERTS alert icmp any any -> $HOME_NET any (msg:"BAD ICMP"; sid:99998; rev:1;) #TCP ALERTS alert tcp $HOME_NET any -> any 6667 (msg:"BAD TCP 6667 REQUEST"; sid:99999; rev:1;) Remarque : Les fichiers de règles standards se trouvent généralement dans /etc/suricata/rules/ ou /var/lib/suricata/rules. Ils ont été reconfigurés pour un autre emplacement lors de l'étape 2 de cet atelier.

Tâche 7 : Configurer la règle de mise en miroir de paquets

Pour cette section de l'atelier, revenez dans Cloud Shell.

La configuration de la règle de mise en miroir de paquets peut être réalisée en une seule commande (ou en passant par un "assistant" dans l'IUG). Dans cette commande, spécifiez les cinq attributs mentionnés dans la section "Mise en miroir de paquets".

• Région
• Réseaux VPC
• Sources en miroir
• Collecteur (destination)
• Trafic en miroir (filtre)

Notez qu'il n'est pas fait mention de "trafic en miroir". En effet, cette règle sera configurée pour mettre en miroir TOUT le trafic et aucun filtre n'est nécessaire. La règle met en miroir le trafic d'entrée et de sortie, puis le transfère vers l'appareil IDS Suricata qui fait partie de l'ILB du collecteur.

• Exécutez la commande suivante dans Cloud Shell pour configurer la règle de mise en miroir de paquets :

gcloud compute packet-mirrorings create mirror-dm-stamford-web \ --collector-ilb=ilb-dm-stamford-suricata-ilb-{{{project_0.default_region | REGION}}} \ --network=dm-stamford \ --mirrored-subnets=dm-stamford-{{{project_0.default_region | REGION}}} \ --region={{{project_0.default_region | REGION}}}

À ce stade, la mise en miroir de paquets et la configuration de Suricata doivent être terminées. Les sections suivantes testeront ces deux opérations.

Cliquez sur Vérifier ma progression pour valider l'objectif.

Configurer la règle de mise en miroir de paquets

Tâche 8 : Tester la mise en miroir de paquets

Dans cette section, vous devrez accéder au shell de la VM IDS. Si la fenêtre de l'interface système est toujours ouverte, utilisez-la. Si la fenêtre de l'interface système a été fermée, reconnectez-vous.

Vous utiliserez également Cloud Shell en tant que "client Internet".

Prenez quelques instants pour chercher l'adresse IP externe des deux VM WEB.

Dans le menu de navigation de la console Cloud, cliquez sur Compute Engine > Instances de VM et notez les adresses IP externes des deux VM WEB. Nous les désignerons respectivement par les appellations [PUBLIC_IP_WEB1] et [PUBLIC_IP_WEB2].

Vous pouvez aussi obtenir les mêmes informations via les commandes gcloud de Cloud Shell :

gcloud compute instances list

Revenir à l'interface système de la VM IDS

Tester la mise en miroir de paquets

• Exécutez une capture de paquets (tcpdump) sur la VM IDS/Suricata avec les filtres suivants :

sudo tcpdump -i ens4 -nn -n "(icmp or port 80) and net 172.21.0.0/24" Remarque : Le réseau 172.21.0.0/24 est le sous-réseau MIS EN MIROIR, et la VM IDS ne fait pas partie de ce sous-réseau. Si la mise en miroir de paquets est correctement configurée, la VM IDS doit recevoir le trafic mis en miroir pour ce sous-réseau.

Générer du trafic vers le sous-réseau "mis en miroir"

1. À l'aide du terminal Cloud Shell, pinguez l'adresse publique attribuée à WEB1, en remplaçant [PUBLIC_IP_WEB1] par l'adresse IP publique de "WEB1" visible dans la console Cloud :

sudo apt install iputils-ping ping -c 4 [PUBLIC_IP_WEB1]

La mise en miroir de paquets doit dupliquer et transmettre ce trafic à la VM IDS. Vous devez le voir dans la capture de paquets de l'étape 1. Le résultat sur la VM IDS doit être semblable à l'exemple ci-dessous, où X.X.X.X est l'adresse IP source des requêtes ICMP. Dans le résultat tcpdump, vous devez voir l'adresse IP privée du Serveur Web. Google Cloud effectue la translation de réseau à la périphérie du réseau.

00:55:32.980666 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 0, length 64 00:55:32.980801 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 0, length 64 00:55:33.968920 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 1, length 64 00:55:33.968965 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 1, length 64 00:55:34.980472 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 2, length 64 00:55:34.980521 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 2, length 64 00:55:35.986354 IP X.X.X.X > 172.21.0.2: ICMP echo request, id 3399, seq 3, length 64 00:55:35.986445 IP 172.21.0.2 > X.X.X.X: ICMP echo reply, id 3399, seq 3, length 64

---

En principe, il en va de même si vous pinguez l'adresse publique de WEB2.

2. Pinguez l'adresse publique attribuée à WEB2, en remplaçant [PUBLIC_IP_WEB2] par l'adresse IP publique de "WEB2".

ping -c 4 [PUBLIC_IP_WEB2]

La mise en miroir des paquets doit transférer ce trafic vers la VM IDS, et vous pouvez le voir dans la capture de paquets de l'étape 1. Le résultat de la VM IDS doit être semblable à l'exemple ci-dessous. Veuillez noter que, dans le résultat tcpdump, vous devez voir l'adresse IP privée du Serveur Web. Google Cloud effectue la translation de réseau à la périphérie du réseau.

00:00:45.309407 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 0, length 64 00:00:45.309736 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 0, length 64 00:00:46.309406 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 1, length 64 00:00:46.309602 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 1, length 64 00:00:47.306278 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 2, length 64 00:00:47.306406 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 2, length 64 00:00:48.314506 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 3, length 64 00:00:48.314698 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 3, length 64

Pour mieux démontrer que la mise en miroir de paquets affiche plus que les en-têtes de couche 3, le test suivant concerne une requête HTTP GET standard sur l'un des serveurs WEB, y compris le handshake TCP à trois voies.

1. Ouvrez un nouvel onglet dans votre navigateur et ouvrez l'adresse publique attribuée à WEB1 avec le protocole HTTP. Si vous préférez, vous pouvez utiliser l'utilitaire "curl" de la console Cloud.

2. Remplacez [PUBLIC_IP_WEB1] par l'adresse IP publique de "WEB1".

http://[PUBLIC_IP_WEB1]/

La mise en miroir des paquets doit transférer ce trafic vers la VM IDS, et vous pouvez le voir dans la capture de paquets de l'étape 1.

Le résultat de la VM IDS doit être semblable à ceci :

00:00:46.761748 IP X.X.X.60835 > 172.21.0.2.80: Flags [S]... 00:00:46.763037 IP 172.21.0.2.80 > X.X.X.60835: Flags [S.], ... ack ... 00:00:46.816407 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ... 00:00:46.823624 IP X.X.X.60835 > 172.21.0.2.80: Flags [P.], ... HTTP: GET / HTTP/1.1 00:00:46.823832 IP 172.21.0.2.80 > X.X.X.60835: Flags [.], ack ... 00:00:46.824549 IP 172.21.0.2.80 > X.X.X.60835: Flags [P.], ... HTTP: HTTP/1.1 200 OK 00:00:46.879214 IP IP XXX608835 > 172.21.0.2.80: Flags [.], ack ... 00:00:46.888477 IP IP XXX60835 > 172.21.0.2.80: indicateurs [F.], ... 00:00:46.888662 IP 172.21.0.2.80 > X.X.X.60835: Flags [F.], ... ack... 00:00:46.943915 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ...

---

3. Il doit en aller de même si vous ouvrez l'adresse publique de WEB2. Remplacez [PUBLIC_IP_WEB2] par l'adresse IP publique de "WEB2".

http://[PUBLIC_IP_WEB2]/

La mise en miroir des paquets doit transférer ce trafic vers la VM IDS, et vous pouvez le voir dans la capture de paquets de l'étape 1.

Le résultat de la VM IDS doit être semblable à l'exemple ci-dessous.

00:00:58.819740 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [S]... 00:00:58.820027 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [S.], ... ack ... 00:00:58.875301 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [.], ack ... 00:00:58.875329 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [P.], ... HTTP: GET / HTTP/1.1 00:00:58.875448 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [.], ack ... 00:00:58.876204 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [P.], ... HTTP: HTTP/1.1 200 OK 00:00:58.929015 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [.], ack ... 00:00:58.929047 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [F.], ... 00:00:58.929244 IP 172.21.0.3.80 > X.X.X.X.62335: Flags [F.], ... ack... 00:00:58.993844 IP X.X.X.X.62335 > 172.21.0.3.80: Flags [.], ack ...

Appuyez sur les touches CTRL+C dans la VM IDS pour quitter tcpdump.

Tâche 9 : Tester l'inspection et les alertes de l'IDS Suricata

La dernière section de cet atelier consiste à tester l'intégration de la mise en miroir de paquets dans le cadre de l'IDS Open Source Suricata. Prenez quelques instants pour passer en revue les quatre règles d'alerte de Suricata définies dans l'étape 4 de la section "Configurer et examiner Suricata" :

####RULES##### #UDP ALERTS alert udp $HOME_NET any -> 8.8.8.8 53 (msg:"BAD UDP DNS REQUEST"; sid:99996; rev:1;) #HTTP ALERTS alert http any any -> $HOME_NET 80 (msg:"BAD HTTP PHP REQUEST"; http.uri; content:"index.php"; sid:99997; rev:1;) #ICMP ALERTS alert icmp any any -> $HOME_NET any (msg:"BAD ICMP"; sid:99998; rev:1;) #TCP ALERTS alert tcp $HOME_NET any -> any 6667 (msg:"BAD TCP 6667 REQUEST"; sid:99999; rev:1;)

Lors des quatre étapes suivantes, vous allez générer le trafic réseau qui déclenche chacune de ces règles. Les alertes correspondantes devront s'afficher dans le fichier journal des événements Suricata.

Remarque : Assurez-vous d'avoir ouvert des fenêtres SSH pour la VM IDS et une VM du serveur WEB. Vous devrez les visualiser TOUTES LES DEUX simultanément pour terminer cette section.

Les tests TEST 1 et TEST 2 seront lancés à partir du serveur Web. Ils testeront le trafic de sortie.

Les tests TEST 3 et TEST 4 seront lancés à partir de Cloud Shell et testeront le trafic d'entrée.

TEST 1 : Tester la règle et l'alerte UDP de sortie

1. Exécutez la commande suivante à partir d'un des serveurs WEB pour générer du trafic DNS de sortie :

dig @8.8.8.8 example.com

2. Puis, visualisez l'alerte dans le fichier journal des événements Suricata de la VM IDS.

Passer à la fenêtre SSH pour la VM IDS

3. Exécutez la commande suivante dans la fenêtre SSH de la VM IDS :

egrep "BAD UDP DNS" /var/log/suricata/eve.json

L'entrée de journal doit être semblable à ceci :

@GCP: {"timestamp":"2020-08-14T01:23:14.903210+0000","flow_id":412864167987242,"in_iface":"ens4","event_type":"alert","src_ip":"172.21.0.2","src_port":47020,"dest_ip":"8.8.8.8","dest_port":53,"proto":"UDP","alert":{"action":"allowed","gid":1,"signature_id":99996,"rev":1,"signature":"BAD UDP DNS REQUEST","category":"","severity":3},"dns":{"query":[{"type":"query","id":17268,"rrname":"EXAMPLE.COM","rrtype":"A","tx_id":0}]},"app_proto":"dns","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":82,"bytes_toclient":0,"start":"2020-08-19T18:23:14.903210+0000"}}

TEST 2 : Tester la règle et l'alerte TCP de sortie

1. Exécutez la commande suivante à partir d'un des serveurs WEB pour générer du trafic TCP de sortie, en remplaçant [PUBLIC_IP_WEB2] par l'adresse IP publique de "WEB2" :

telnet [PUBLIC_IP_WEB2] 6667

2. Appuyez sur les touches CTRL+C pour quitter.

3. Puis, visualisez l'alerte dans le fichier journal des événements Suricata de la VM IDS.

Passer à la fenêtre SSH pour la VM IDS

4. Exécutez la commande suivante à partir de la fenêtre SSH de la VM IDS :

egrep "BAD TCP" /var/log/suricata/eve.json

L'entrée de journal doit être semblable à ceci :

@GCP: {"timestamp":"2020-08-14T01:27:45.058526+0000","flow_id":479376049300638,"in_iface":"ens4","event_type":"alert","src_ip":"172.21.0.2","src_port":36168,"dest_ip":"100.64.1.1","dest_port":6667,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":99999,"rev":1,"signature":"BAD TCP 6667 REQUEST","category":"","severity":3},"flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":74,"bytes_toclient":0,"start":"2020-08-19T18:27:45.058526+0000"}}

TEST 3 : Tester la règle et l'alerte ICMP d'entrée

1. Exécutez la commande suivante dans Cloud Shell pour générer du trafic ICMP d'ENTRÉE.

2. Remplacez [PUBLIC_IP_WEB1] par l'adresse IP publique de "WEB1".

ping -c 3 [PUBLIC_IP_WEB1]

3. Puis, visualisez l'alerte dans le fichier journal des événements Suricata de la VM IDS :

egrep "BAD ICMP" /var/log/suricata/eve.json

L'entrée de journal doit être semblable à ceci :

@GCP: {"timestamp":"2020-08-14T01:24:46.065250+0000","flow_id":1114966772874978,"in_iface":"ens4","event_type":"alert","src_ip":"X.X.X.X","dest_ip":"172.21.0.2","proto":"ICMP","icmp_type":8,"icmp_code":0,"alert":{"action":"allowed","gid":1,"signature_id":99998,"rev":1,"signature":"BAD ICMP","category":"","severity":3},"flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":98,"bytes_toclient":0,"start":"2020-08-19T18:24:46.065250+0000"}}

TEST 4 : Tester la règle et l'alerte HTTP d'entrée

À l'aide du navigateur Web de votre poste de travail local ou de curl dans Cloud Shell, ouvrez l'adresse publique attribuée à WEB1 pour la page index.php avec le protocole HTTP.

1. Remplacez [PUBLIC_IP_WEB1] par l'adresse IP publique de "WEB1".

http://[PUBLIC_IP_WEB1]/index.php

2. Puis, visualisez l'alerte dans le fichier journal des événements Suricata de la VM IDS :

egrep "BAD HTTP" /var/log/suricata/eve.json

L'entrée de journal doit être semblable à ceci :

@GCP: {"timestamp":"2020-08-14T01:26:36.794124+0000","flow_id":1901424684045611,"in_iface":"ens4","event_type":"alert","src_ip":"X.X.X.X","src_port":61132,"dest_ip":"172.21.0.3","dest_port":80,"proto":"TCP","tx_id":0,"alert":{"action":"allowed","gid":1,"signature_id":99997,"rev":1,"signature":"BAD HTTP PHP REQUEST","category":"","severity":3},"http":{"hostname":"PUBLIC_IP_WEB1","url":"\/index.php","http_user_agent":"curl\/7.64.1","http_content_type":"text\/html","http_method":"GET","protocol":"HTTP\/1.1","status":404,"length":275},"app_proto":"http","flow":{"pkts_toserver":7,"pkts_toclient":6,"bytes_toserver":658,"bytes_toclient":1284,"start":"2020-08-19T18:26:36.660779+0000"}}

Félicitations !

Notre atelier de mise en miroir de paquets Google Cloud avec l'IDS Open Source Suricata est terminé.

Étapes suivantes et informations supplémentaires

Pour en savoir plus sur la mise en miroir de paquets, consultez les articles suivants :

• Présentation de la mise en miroir de paquets

• Utiliser la mise en miroir de paquets

Pour plus d'informations sur Suricata, rendez-vous sur https://suricata-ids.org/.

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 18 novembre 2024

Dernier test de l'atelier : 6 septembre 2023

Copyright 2024 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.