Premiers pas avec la détection avancée des menaces de DNS Armor

1. Introduction et présentation générale

DNS Armor, optimisé par Infoblox, est un service entièrement géré qui assure la sécurité de la couche DNS pour vos charges de travail Google Cloud. Son détecteur de menaces avancé est conçu pour détecter les activités malveillantes le plus tôt possible dans la chaîne d'attaque (au niveau de la requête DNS), sans ajouter de complexité opérationnelle ni de surcharge de performances.

Cet atelier de programmation fournit des instructions détaillées pour configurer et tester le service DNS Armor. Vous allez configurer l'infrastructure réseau nécessaire, créer le détecteur de menaces, tester le service en simulant des menaces DNS et, enfin, analyser les journaux de menaces à l'aide de l'explorateur de journaux.

Objectifs de l'atelier

Dans cet atelier de programmation, vous allez provisionner les ressources suivantes :

  • Deux réseaux VPC : network-a et network-b
  • network-a inclura les sous-réseaux et les machines virtuelles dans les régions us-east4 et us-central1.
  • network-b inclura un sous-réseau et une machine virtuelle uniquement dans us-east4.
  • Un détecteur de menaces avancées DNS Armor configuré pour inspecter les requêtes DNS.

75d6eeb807735645.png

Points abordés

  • Comment provisionner les ressources réseau nécessaires, y compris les VPC et les machines virtuelles.
  • Découvrez comment déployer un détecteur de menaces avancées et exclure des réseaux spécifiques.
  • Comment valider la configuration de la détection des menaces à l'aide d'un script de simulation des menaces.
  • Découvrez comment analyser les journaux de menaces dans l'explorateur de journaux.

Prérequis

  • Un projet Google Cloud.
  • Accès à l'outil de ligne de commande gcloud

2. Prérequis

Dans cette section, vous allez effectuer les tâches suivantes :

  • Vérifiez que votre projet Google Cloud respecte les contraintes nécessaires des règles d'administration.
  • Vérifiez que votre compte utilisateur dispose des rôles et autorisations IAM requis.
  • Activez les API Google Cloud essentielles pour cet atelier de programmation.
  • Attribuez le rôle IAM roles/logging.viewer au compte de service Compute Engine.

Contraintes liées aux règles d'administration

Pour mener à bien cet atelier de programmation, veuillez vérifier les contraintes de règle d'administration appliquées à votre projet. Certaines règles peuvent entraver le provisionnement des ressources nécessaires. Les contraintes suivantes peuvent avoir un impact sur la configuration de cet atelier de programmation :

  • constraints/gcp.resourceLocations : limite les régions dans lesquelles vous pouvez créer des ressources. Cet atelier de programmation nécessite us-east4 et us-central1.
  • constraints/compute.vmExternalIpAccess : empêche la création de machines virtuelles avec des adresses IP publiques, ce qui pourrait interférer avec la configuration si vous ne suivez pas l'utilisation de l'indicateur --no-address dans l'atelier de programmation .
  • constraints/compute.shieldedVm : force la création de VM protégées, que les commandes de création de VM du tutoriel ne spécifient pas, ce qui peut entraîner une erreur.
  • constraints/gcp.restrictServiceUsage : limite les API Google Cloud qui peuvent être activées et peut bloquer l'atelier de programmation s'il n'autorise pas compute.googleapis.com, networksecurity.googleapis.com, logging.googleapis.com et monitoring.googleapis.com.

Rôles et autorisations IAM

Pour réussir cet atelier de programmation, veuillez vérifier les rôles et autorisations IAM accordés à votre utilisateur. Les rôles et autorisations IAM suivants sont nécessaires pour effectuer cet atelier de programmation.

  • Administrateur de l'utilisation des services (roles/serviceusage.serviceUsageAdmin) : pour activer les API Google Cloud requises pour l'atelier de programmation.
  • Administrateur de réseau Compute (roles/compute.networkAdmin) : permet de créer et de gérer des réseaux VPC, des sous-réseaux et Cloud NAT.
  • Administrateur de sécurité Compute (roles/compute.securityAdmin) : pour configurer les règles de pare-feu pour l'accès SSH aux machines virtuelles.
  • Administrateur d'instances Compute (v1) (roles/compute.instanceAdmin.v1) : pour créer et gérer les machines virtuelles requises pour l'atelier.
  • Utilisateur de tunnels sécurisés par IAP (roles/iap.tunnelResourceAccessor) : pour se connecter aux machines virtuelles à l'aide de SSH via Identity-Aware Proxy (IAP).
  • Administrateur de la sécurité du réseau (roles/networksecurity.admin) : pour créer et gérer le détecteur de menaces DNS Armor.
  • Lecteur de journaux (roles/logging.viewer) : pour afficher et analyser les journaux des menaces dans l'explorateur de journaux.

API Google Cloud

Veuillez vous assurer que les API Google Cloud requises sont activées dans votre projet.

1. Activez les API nécessaires en exécutant les commandes gcloud suivantes dans Cloud Shell.

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

2. Vérifiez que les API sont activées en exécutant les commandes gcloud suivantes dans Cloud Shell.

gcloud services list --enabled

Compte de service Compute Engine

Le script de test nécessite des autorisations pour lire les journaux des menaces dans Cloud Logging. Étant donné que le script sera exécuté à partir d'une VM utilisant le compte de service Compute Engine par défaut, le rôle IAM roles/logging.viewer doit être attribué à ce compte de service.

1. Définissez les variables d'environnement en exécutant les commandes suivantes dans Cloud Shell.

export PROJECT_ID=$(gcloud config get-value project)

export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

2. Attribuez le rôle Lecteur de journaux au compte de service Compute Engine. Exécutez les commandes gcloud suivantes dans Cloud Shell.

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \
--role="roles/logging.viewer"

3. Configuration de base de l'environnement

Dans cette section, vous allez effectuer les tâches suivantes :

  • Créez des réseaux VPC (network-a et network-b) avec des sous-réseaux personnalisés.
  • Configurez des routeurs Cloud Router et Cloud NAT pour la sortie Internet dans network-a et network-b.
  • Créez des règles de pare-feu pour autoriser l'accès SSH aux VM à partir de la plage d'adresses IP d'IAP pour network-a et network-b.
  • Provisionnez des machines virtuelles Linux dans network-a et network-b sans adresses IP publiques.

Créer des VPC et des sous-réseaux

1. Créez network-a et ses sous-réseaux dans les régions us-east4 et us-central1. Exécutez les commandes gcloud suivantes dans Cloud Shell.

gcloud compute networks create network-a --subnet-mode=custom

gcloud compute networks subnets create subnet-a-use4 \
--network=network-a \
--range=10.10.0.0/24 \
--region=us-east4

gcloud compute networks subnets create subnet-a-usc1 \
--network=network-a \
--range=10.10.1.0/24 \
--region=us-central1

2. Créez network-b et son sous-réseau dans la région us-east4. Exécutez les commandes gcloud suivantes dans Cloud Shell.

gcloud compute networks create network-b --subnet-mode=custom

gcloud compute networks subnets create subnet-b-use4 \
--network=network-b \
--range=10.20.0.0/24 \
--region=us-east4

Configurer la sortie Internet

1. Créez Cloud Router et Cloud NAT pour network-a afin d'autoriser le trafic Internet sortant pour les VM sans adresse IP publique.

gcloud compute routers create router-a-use4 \
--network=network-a \
--region=us-east4

gcloud compute routers nats create nat-a-use4 \
--router=router-a-use4 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--region=us-east4

gcloud compute routers create router-a-usc1 \
--network=network-a \
--region=us-central1

gcloud compute routers nats create nat-a-usc1 \
--router=router-a-usc1 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--region=us-central1

2. Créez Cloud Router et Cloud NAT pour network-b afin d'autoriser le trafic Internet sortant pour les VM sans adresse IP publique.

gcloud compute routers create router-b-use4 \
--network=network-b \
--region=us-east4

gcloud compute routers nats create nat-b-use4 \
--router=router-b-use4 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges \
--region=us-east4

Configurer les règles de pare-feu

1. Créez des règles de pare-feu pour network-a afin d'autoriser l'accès SSH depuis la plage d'adresses IP d'IAP. Exécutez les commandes gcloud suivantes dans Cloud Shell.

gcloud compute firewall-rules create allow-ssh-iap-a \
--network=network-a \
--allow=tcp:22 \
--source-ranges=35.235.240.0/20

2. Créez des règles de pare-feu pour network-b afin d'autoriser l'accès SSH depuis la plage d'adresses IP d'IAP. Exécutez les commandes gcloud suivantes dans Cloud Shell.

gcloud compute firewall-rules create allow-ssh-iap-b \
--network=network-b \
--allow=tcp:22 \
--source-ranges=35.235.240.0/20

Créer des machines virtuelles

1. Créer des VM Linux dans network-a

gcloud compute instances create vm-a-use4 \
--zone=us-east4-c \
--network=network-a \
--subnet=subnet-a-use4 \
--no-address \
--scopes=cloud-platform

gcloud compute instances create vm-a-usc1 \
--zone=us-central1-a \
--network=network-a \
--subnet=subnet-a-usc1 \
--no-address \
--scopes=cloud-platform

2. Créer une VM Linux dans network-b

gcloud compute instances create vm-b-use4 \
--zone=us-east4-c \
--network=network-b \
--subnet=subnet-b-use4 \
--no-address \
--scopes=cloud-platform

4. Créer le détecteur de menaces DNS

Dans cette section, vous allez effectuer les tâches suivantes :

  • Créez le détecteur de menaces.
  • Lister le détecteur de menaces.
  • Décrivez la ressource.

Maintenant que les VPC, les sous-réseaux et les machines virtuelles sont provisionnés, l'étape suivante consiste à créer le détecteur de menaces DNS.

1. Créez le détecteur de menaces à l'aide de la commande gcloud beta network-security dns-threat-detectors create. Utilisez l'option --excluded-networks pour exclure network-b.

gcloud beta network-security dns-threat-detectors create my-dns-threat-detector \
--location=global \
--provider=infoblox \
--excluded-networks=projects/$PROJECT_ID/global/networks/network-b

2. Répertoriez le détecteur de menaces pour confirmer sa création.

gcloud beta network-security dns-threat-detectors list --location=global

3. Décrivez la ressource pour vérifier que network-b est correctement listé sous excludedNetworks.

gcloud beta network-security dns-threat-detectors describe my-dns-threat-detector --location=global

Exemple de résultat :

createTime: '2025-08-06T17:06:30.297586089Z'
excludedNetworks:
- projects/dns-armor-demo-project/global/networks/network-b
name: projects/dns-armor-demo-project/locations/global/dnsThreatDetectors/my-dns-threat-detector
provider: INFOBLOX
updateTime: '2025-08-27T01:14:09.666357239Z'

5. Tester la configuration

Dans cette section, vous allez effectuer les tâches suivantes :

  • Connectez-vous en SSH aux VM.
  • Installez Git sur les VM.
  • Clonez le dépôt du simulateur de détection des menaces Infoblox.
  • Exécutez le script et analysez le résultat généré.

Validez la configuration en générant des requêtes DNS malveillantes émulées à partir de vos VM. Vous devriez observer des entrées de journal pour les requêtes provenant de network-a, tandis qu'aucun journal ne sera généré à partir de network-b..

1. Connectez-vous en SSH à vm-a-use4. Exécutez les commandes gcloud suivantes dans Cloud Shell.

gcloud compute ssh vm-a-use4 --zone=us-east4-c

2. Installez Git sur la VM.

sudo apt-get install git -y

3. Clonez le dépôt du simulateur de détection des menaces Infoblox.

git clone https://github.com/infobloxopen/ib-threat-detection-simulator

4. Remplacez le répertoire par celui du simulateur.

cd ib-threat-detection-simulator/threat_detection_simulator/

5. Exécutez le script et analysez le résultat généré.

Rendez le script exécutable.

chmod +x run.sh

Exécutez le script.

./run.sh info basic

6. Exemple de résultat

La capture d'écran ci-dessous montre une partie de la sortie du script d'une VM du réseau A. Le résultat indique que 100 % des menaces ont été détectées.

a66c1757f8c74da6.png

La capture d'écran ci-dessous montre une partie de la sortie du script d'une VM du réseau B. Le résultat indique que 0 % des menaces ont été détectées. C'est normal, car le réseau B a été exclu lors de la création du détecteur de menaces.

c12d130c95c04e84.png

7. Revenez à Cloud Shell en quittant la session SSH.

exit

6. Afficher les journaux de menaces dans l'explorateur de journaux

Les journaux de menaces générés peuvent être consultés dans l'explorateur de journaux après l'exécution du script de test, car ils sont écrits dans Cloud Logging.

Exemple d'entrée de journal

Cette section fournit un exemple d'entrée de journal pour une menace DNS détectée. Elle illustre les informations détaillées capturées par DNS Armor, y compris l'adresse IP source, le domaine interrogé et la catégorie de menace. Il vous servira de référence pour comprendre la structure et le contenu des journaux que vous analyserez.

{
  "insertId": "1izjkneb44",
  "jsonPayload": {
    "partnerId": "Infoblox",
    "detectionTime": "2025-08-08T01:49:54.092250101Z",
    "dnsQuery": {
      "authAnswer": false,
      "rdata": "random.malicious-domain.com.\t300\tIN\ta\t196.251.118.39",
      "protocol": "UDP",
      "projectNumber": "1234567890",
      "responseCode": "NOERROR",
      "queryType": "A",
      "location": "us-east4",
      "sourceIp": "10.10.0.2",
      "queryName": "random.malicious-domain.com.",
      "vmProjectNumber": "1234567890",
      "vmInstanceId": "01234567899876543210",
      "destinationIp": "",
      "queryTime": "2025-08-08T01:49:53.712692495Z"
    },
    "threatInfo": {
      "severity": "HIGH",
      "confidence": "HIGH",
      "threatDescription": "",
      "category": "EmergentDomain",
      "threatId": "Suspicious_EmergentDomain",
      "type": "Suspicious",
      "threatIndicator": "izumisv1.cc",
      "threatIndicatorType": "FQDN",
      "threat": "Suspicious",
      "threatFeed": "suspicious-noed"
    }
  },
  "resource": {
    "type": "networksecurity.googleapis.com/DnsThreatDetector",
    "labels": {
      "resource_container": "projects/1234567890",
      "id": "",
      "location": "us-east4"
    }
  },
  "timestamp": "2025-08-08T01:49:54.092250101Z",
  "severity": "INFO",
  "logName": "projects/dns-armor-demo-project/logs/networksecurity.googleapis.com%2Fdns_threat_events",
  "receiveTimestamp": "2025-08-08T01:49:55.290965780Z"
}

Afficher les journaux dans l'explorateur de journaux

1. Accédez à la section Monitoring de la console Google Cloud, puis sélectionnez Logs explorer.

4a90c593d7e339d8.png

2. Pour filtrer tous les journaux des menaces DNS Armor, utilisez la requête suivante. Ce filtre permet de filtrer les journaux en fonction du type de ressource du détecteur de menaces DNS.

resource.type="networksecurity.googleapis.com/DnsThreatDetector"

3. Filtrer les journaux pour la région us-east4 : ajoutez un filtre pour l'emplacement. Cette requête n'affichera que les menaces détectées dans la région us-east4.

resource.type="networksecurity.googleapis.com/DnsThreatDetector"
resource.labels.location="us-east4"

4. Filtrer les journaux par réseau source : filtrez les journaux en fonction de l'adresse IP source de la requête DNS pour afficher les menaces provenant d'un réseau VPC spécifique.

Pour afficher les journaux de network-a (sous-réseaux 10.10.0.0/24 et 10.10.1.0/24) :

resource.type="networksecurity.googleapis.com/DnsThreatDetector"
(jsonPayload.dnsQuery.sourceIp:"10.10.0." OR jsonPayload.dnsQuery.sourceIp:"10.10.1.")

Pour afficher les journaux de network-b (sous-réseaux 10.20.0.0/24) :

resource.type="networksecurity.googleapis.com/DnsThreatDetector"
jsonPayload.dnsQuery.sourceIp:"10.20.0."

7. Nettoyage

Pour éviter que des frais ne vous soient facturés à l'avenir, supprimez les ressources créées dans cet atelier de programmation. Veillez à quitter le shell de la VM et à revenir à Cloud Shell lorsque vous exécutez les commandes de nettoyage.

1. Supprimez les VM.

gcloud compute instances delete vm-a-use4 --zone=us-east4-c --quiet

gcloud compute instances delete vm-a-usc1 --zone=us-central1-a --quiet

gcloud compute instances delete vm-b-use4 --zone=us-east4-c --quiet

2. Supprimez les règles de pare-feu.

gcloud compute firewall-rules delete allow-ssh-iap-a --quiet

gcloud compute firewall-rules delete allow-ssh-iap-b --quiet

3. Supprimez les passerelles Cloud NAT.

gcloud compute routers nats delete nat-a-use4 --router=router-a-use4 --region=us-east4 --quiet

gcloud compute routers nats delete nat-a-usc1 --router=router-a-usc1 --region=us-central1 --quiet

gcloud compute routers nats delete nat-b-use4 --router=router-b-use4 --region=us-east4 --quiet

4. Supprimer les routeurs Cloud Router

gcloud compute routers delete router-a-use4 --region=us-east4 --quiet

gcloud compute routers delete router-a-usc1 --region=us-central1 --quiet

gcloud compute routers delete router-b-use4 --region=us-east4 --quiet

5. Supprimez les sous-réseaux.

gcloud compute networks subnets delete subnet-a-use4 --region=us-east4 --quiet

gcloud compute networks subnets delete subnet-a-usc1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-b-use4 --region=us-east4 --quiet

6. Supprimez le détecteur de menaces DNS.

gcloud beta network-security dns-threat-detectors delete my-dns-threat-detector --location=global --quiet

7. Supprimez les VPC.

gcloud compute networks delete network-a --quiet

gcloud compute networks delete network-b --quiet

8. Félicitations

Félicitations ! Vous avez correctement configuré, déployé et testé le détecteur de menaces DNS Armor. Vous avez acquis une expérience pratique dans la protection de votre environnement Google Cloud contre les menaces basées sur le DNS.

Dans cet atelier de programmation, vous avez :

  • Vous avez provisionné un environnement réseau avec plusieurs VPC, sous-réseaux et machines virtuelles.
  • Sortie Internet configurée pour les VM privées à l'aide de Cloud NAT.
  • Vous avez déployé un détecteur de menaces DNS Armor et appris à exclure des réseaux spécifiques.
  • Simulé des menaces DNS et validé la configuration de détection des menaces.
  • Analysé les journaux des menaces dans l'explorateur de journaux pour identifier et comprendre l'activité DNS malveillante.

Et ensuite ?

Documents de référence