Erste Schritte mit der erweiterten Bedrohungserkennung von DNS Armor

1. Einleitung und Übersicht

DNS Armor, basierend auf Infoblox, ist ein vollständig verwalteter Dienst, der Sicherheit auf DNS-Ebene für Ihre Google Cloud-Arbeitslasten bietet. Der erweiterte Bedrohungsdetektor wurde entwickelt, um schädliche Aktivitäten so früh wie möglich in der Angriffskette zu erkennen – bei der DNS-Anfrage –, ohne die betriebliche Komplexität oder den Leistungsaufwand zu erhöhen.

In diesem Codelab finden Sie eine Schritt-für-Schritt-Anleitung zum Konfigurieren und Testen des DNS Armor-Dienstes. Sie richten die erforderliche Netzwerkinfrastruktur ein, erstellen den Bedrohungsdetektor, testen den Dienst, indem Sie DNS-Bedrohungen simulieren, und analysieren schließlich die Bedrohungslogs mit dem Log-Explorer.

Umfang

In diesem Codelab stellen Sie die folgenden Ressourcen bereit:

• Zwei VPC-Netzwerke: network-a und network-b
• network-a umfasst Subnetze und virtuelle Maschinen in den Regionen us-east4 und us-central1.
• network-b enthält ein Subnetz und eine VM nur in us-east4.
• Ein DNS Armor-Detektor für erweiterte Bedrohungen, der so konfiguriert ist, dass er DNS-Abfragen untersucht.

Lerninhalte

• So stellen Sie die erforderlichen Netzwerkressourcen bereit, einschließlich VPCs und VMs.
• So stellen Sie einen erweiterten Bedrohungsdetektor bereit und schließen bestimmte Netzwerke aus.
• So validieren Sie die Konfiguration der Bedrohungserkennung mit einem Bedrohungssimulationsskript.
• Bedrohungslogs im Log-Explorer analysieren

Voraussetzungen

• Ein Google Cloud-Projekt.
• Zugriff auf das gcloud-Befehlszeilentool

2. Vorbereitung

Aufgaben in diesem Abschnitt:

• Prüfen Sie, ob Ihr Google Cloud-Projekt die erforderlichen Einschränkungen für Organisationsrichtlinien erfüllt.
• Prüfen Sie, ob Ihr Nutzerkonto die erforderlichen IAM-Rollen und -Berechtigungen hat.
• Aktivieren Sie die Google Cloud APIs, die für dieses Codelab erforderlich sind.
• Weisen Sie dem Compute Engine-Dienstkonto die IAM-Rolle roles/logging.viewer zu.

Einschränkungen für Organisationsrichtlinien

Damit Sie dieses Codelab erfolgreich durcharbeiten können, müssen Sie die auf Ihr Projekt angewendeten Einschränkungen für Organisationsrichtlinien überprüfen. Bestimmte Richtlinien können die Bereitstellung erforderlicher Ressourcen verhindern. Die folgenden Einschränkungen können sich auf die Konfiguration dieses Codelabs auswirken:

• constraints/gcp.resourceLocations: Beschränkt die Regionen, in denen Sie Ressourcen erstellen können. Für das Codelab sind us-east4 und us-central1 erforderlich.
• constraints/compute.vmExternalIpAccess: Verhindert die Erstellung von VMs mit öffentlichen IP-Adressen, die die Einrichtung beeinträchtigen könnten, wenn Sie die Verwendung des Flags --no-address im Codelab nicht befolgen .
• constraints/compute.shieldedVm: Erzwingt die Erstellung von Shielded VMs, die in den Befehlen zum Erstellen von VMs im Codelab nicht angegeben sind, was möglicherweise zu einem Fehler führt.
• constraints/gcp.restrictServiceUsage: Beschränkt, welche Google Cloud APIs aktiviert werden können, und könnte das Codelab blockieren, wenn compute.googleapis.com, networksecurity.googleapis.com, logging.googleapis.com und monitoring.googleapis.com nicht zulässig sind.

IAM-Rollen und -Berechtigungen

Damit Sie dieses Codelab erfolgreich durchlaufen können, müssen Sie die IAM-Rollen und -Berechtigungen überprüfen, die Ihrem Nutzer zugewiesen sind. Für dieses Codelab sind die folgenden IAM-Rollen und -Berechtigungen erforderlich.

• Administrator für Dienstnutzung (roles/serviceusage.serviceUsageAdmin): Zum Aktivieren der erforderlichen Google Cloud APIs für das Codelab.
• Compute Network Admin (roles/compute.networkAdmin): Zum Erstellen und Verwalten von VPC-Netzwerken, Subnetzen und Cloud NAT.
• Compute Security Admin (roles/compute.securityAdmin): Zum Konfigurieren der Firewallregeln für den SSH-Zugriff auf die virtuellen Maschinen.
• Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1): Zum Erstellen und Verwalten der für das Lab erforderlichen virtuellen Maschinen.
• Nutzer IAP-gesicherter Tunnel (roles/iap.tunnelResourceAccessor): Zum Herstellen einer Verbindung zu den virtuellen Maschinen über SSH über Identity-Aware Proxy (IAP).
• Network Security Admin (roles/networksecurity.admin): Zum Erstellen und Verwalten des DNS Armor-Bedrohungsdetektors.
• Loganzeige (roles/logging.viewer): Damit können Sie die Bedrohungslogs im Log-Explorer ansehen und analysieren.

Google Cloud APIs

Achten Sie darauf, dass die erforderlichen Google Cloud-APIs in Ihrem Projekt aktiviert sind.

1. Aktivieren Sie die erforderlichen APIs, indem Sie die folgenden gcloud-Befehle in Cloud Shell ausführen.

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

2. Prüfen Sie, ob die APIs aktiviert sind, indem Sie die folgenden gcloud-Befehle in Cloud Shell ausführen.

gcloud services list --enabled

Compute Engine-Dienstkonto

Für das Testskript sind Berechtigungen zum Lesen von Bedrohungslogs aus Cloud Logging erforderlich. Da das Skript von einer VM aus ausgeführt wird, die das Compute Engine-Standarddienstkonto verwendet, muss diesem Dienstkonto die IAM-Rolle roles/logging.viewer zugewiesen sein.

1. Legen Sie die Umgebungsvariablen fest, indem Sie die folgenden Befehle in Cloud Shell ausführen.

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

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

2. Weisen Sie dem Compute Engine-Dienstkonto die Rolle „Logging Viewer“ zu. Führen Sie die folgenden gcloud-Befehle in Cloud Shell aus.

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member="serviceAccount:${PROJECT_NUMBER}[e-mail]" \
--role="roles/logging.viewer"

3. Grundlegende Einrichtung der Umgebung

Aufgaben in diesem Abschnitt:

• Erstellen Sie VPC-Netzwerke (network-a und network-b) mit benutzerdefinierten Subnetzen.
• Konfigurieren Sie Cloud Router und Cloud NAT für den Internet-Egress in network-a und network-b.
• Erstellen Sie Firewallregeln, die SSH-Zugriff auf VMs über den IP-Bereich von IAP für network-a und network-b ermöglichen.
• Stellen Sie Linux-VMs sowohl in network-a als auch in network-b ohne öffentliche IP-Adressen bereit.

VPCs und Subnetze erstellen

1. Erstellen Sie Netzwerk-A und seine Subnetze in den Regionen us-east4 und us-central1. Führen Sie die folgenden gcloud-Befehle in Cloud Shell aus.

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. Erstellen Sie Netzwerk-B und das zugehörige Subnetz in der Region us-east4. Führen Sie die folgenden gcloud-Befehle in Cloud Shell aus.

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

Ausgehenden Internettraffic konfigurieren

1. Erstellen Sie einen Cloud Router und Cloud NAT für network-a, um den Internet-Egress für VMs ohne öffentliche IP-Adressen zu ermöglichen.

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. Erstellen Sie einen Cloud Router und Cloud NAT für network-b, um den Internet-Egress für VMs ohne öffentliche IP-Adressen zu ermöglichen.

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

Firewallregeln konfigurieren

1. Erstellen Sie Firewallregeln für network-a, um den SSH-Zugriff über den IP-Bereich von IAP zuzulassen. Führen Sie die folgenden gcloud-Befehle in Cloud Shell aus.

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

2. Erstellen Sie Firewallregeln für network-b, um den SSH-Zugriff über den IP-Bereich von IAP zuzulassen. Führen Sie die folgenden gcloud-Befehle in Cloud Shell aus.

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

Virtuelle Maschinen erstellen

1. Linux-VMs in network-a erstellen

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. Linux-VM in network-b erstellen

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

4. DNS-Bedrohungsdetektor erstellen

Aufgaben in diesem Abschnitt:

• Erstellen Sie den Bedrohungsdetektor.
• Listen Sie den Bedrohungsdetektor auf.
• Beschreiben Sie die Ressource.

Nachdem die VPCs, Subnetze und VMs bereitgestellt wurden, erstellen Sie als Nächstes den DNS-Bedrohungsdetektor.

Hinweis:Der DNS-Bedrohungsdetektor ist eine Ressource auf Projektebene. Mit dem Flag --excluded-networks können Sie bestimmte VPC-Netzwerke ausschließen.

1. Erstellen Sie den Threat Detector mit dem Befehl gcloud beta network-security dns-threat-detectors create. Verwenden Sie das Flag --excluded-networks, um network-b auszuschließen.

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. Listen Sie den Bedrohungsdetektor auf, um die Erstellung zu bestätigen.

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

3. Beschreiben Sie die Ressource, um zu prüfen, ob network-b korrekt unter excludedNetworks aufgeführt ist.

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

Beispielausgabe:

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. Einrichtung testen

Aufgaben in diesem Abschnitt:

• Stellen Sie eine SSH-Verbindung zu den VMs her.
• Installieren Sie Git auf den VMs.
• Klonen Sie das Repository für den Infoblox-Simulator zur Bedrohungserkennung.
• Führen Sie das Skript aus und analysieren Sie die generierte Ausgabe.

Überprüfen Sie die Einrichtung, indem Sie emulierte schädliche DNS-Abfragen von Ihren VMs generieren. Sie sollten Logeinträge für Anfragen sehen, die von network-a stammen. Für Anfragen von network-b. werden keine Logs generiert.

Hinweis:Diese Anleitung bezieht sich speziell auf vm-a-use4. Um schädliche DNS-Abfragen von vm-a-usc1 und vm-b-use4 zu generieren, wiederholen Sie alle in diesem Abschnitt beschriebenen Schritte für jede virtuelle Maschine.

1. Stellen Sie eine SSH-Verbindung zu vm-a-use4 her. Führen Sie die folgenden gcloud-Befehle in Cloud Shell aus.

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

2. Installieren Sie Git auf der VM.

Hinweis:Dieser Befehl sollte auf der VM und nicht in Cloud Shell ausgeführt werden.

sudo apt-get install git -y

3. Klonen Sie das Repository für den Infoblox-Simulator zur Erkennung von Sicherheitsrisiken.

Hinweis:Dieser Befehl sollte auf der VM und nicht in Cloud Shell ausgeführt werden.

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

4. Wechseln Sie mit in das Verzeichnis des Simulators.

Hinweis:Dieser Befehl sollte auf der VM und nicht in Cloud Shell ausgeführt werden.

cd ib-threat-detection-simulator/threat_detection_simulator/

5. Führen Sie das Skript aus und analysieren Sie die generierte Ausgabe.

Hinweis:Dieses Script simuliert verschiedene DNS-basierte Bedrohungen, indem Anfragen an bekannte schädliche oder verdächtige Domains gesendet werden. Sie ist nur für Test- und Demonstrationszwecke vorgesehen.

• Mit diesem Tool wird DNS-Abfrageverkehr generiert, indem lokale „dig“-Befehle für eine bestimmte Liste von Domains ausgeführt werden. Sein Hauptzweck besteht darin, schädliche DNS-Aktivitäten zu simulieren.
• Im standardmäßigen erweiterten Analysemodus werden Bedrohungen in verschiedenen Kategorien repliziert, darunter Standard-Phishing und ‑Malware sowie erweiterte Bedrohungen.
• Diese erweiterten Simulationen umfassen Anfragen an tatsächliche DGA-Domains (Domain Generation Algorithm), die mit den Malware-Familien Mylobot und Suppobox verknüpft sind, und emulieren auch DNST-Angriffe (DNS Tunneling).

Weitere Informationen zum Skript und den simulierten Bedrohungen finden Sie im GitHub-Repository.

Hinweis:Dieser Befehl sollte auf der VM und nicht in Cloud Shell ausgeführt werden.

Machen Sie das Skript ausführbar.

chmod +x run.sh

Führen Sie das Skript aus.

./run.sh info basic

6. Beispielausgabe

Der Screenshot unten zeigt einen Teil der Skriptausgabe einer VM in network-a. Die Ausgabe zeigt, dass 100% der Bedrohungen erkannt wurden.

Der Screenshot unten zeigt einen Teil der Skriptausgabe einer VM in Netzwerk B. Die Ausgabe zeigt, dass 0% der Bedrohungen erkannt wurden. Das ist zu erwarten, da network-b bei der Erstellung des Bedrohungsdetektors ausgeschlossen wurde.

7. Kehren Sie zu Cloud Shell zurück, indem Sie die SSH-Sitzung beenden.

exit

Hinweis:Bevor Sie mit dem nächsten Abschnitt fortfahren, wiederholen Sie die Schritte 1 bis 5, um schädliche DNS-Abfragen von vm-a-usc1 und vm-b-use4. zu generieren.

6. Bedrohungslogs im Log-Explorer ansehen

Die generierten Bedrohungslogs können nach dem Ausführen des Testskripts im Log-Explorer aufgerufen werden, da sie in Cloud Logging geschrieben werden.

Beispiel für einen Logeintrag

In diesem Abschnitt finden Sie einen Beispiel-Logeintrag für eine erkannte DNS-Bedrohung, der die von DNS Armor erfassten detaillierten Informationen enthält, einschließlich der Quell-IP-Adresse, der abgefragten Domain und der Bedrohungskategorie. Sie dient als Referenz, um die Struktur und den Inhalt der Logs zu verstehen, die Sie analysieren.

{
  "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"
}

Logs im Log-Explorer ansehen

Hinweis:In diesem Abschnitt verwenden wir die GCP Console.

1. Rufen Sie in der Google Cloud Console den Bereich Monitoring auf und wählen Sie Logs explorer aus.

2. Wenn Sie nach allen DNS Armor-Bedrohungslogs filtern möchten, verwenden Sie die folgende Abfrage. Dadurch werden Logs nach dem Ressourcentyp für den DNS-Bedrohungsdetektor gefiltert.

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

Hinweis:Für VMs in network-b sollten keine Bedrohungslogs angezeigt werden, da dieses Netzwerk bei der Erstellung des Bedrohungsdetektors ausgeschlossen wurde.

3. Wenn Sie Logs für die Region „us-east4“ filtern möchten, fügen Sie einen Filter für den Standort hinzu. Mit dieser Abfrage werden nur die Bedrohungen angezeigt, die in der Region „us-east4“ erkannt wurden.

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

Hinweis:Für VMs in network-b sollten keine Bedrohungslogs angezeigt werden, da dieses Netzwerk bei der Erstellung des Bedrohungsdetektors ausgeschlossen wurde.

4. Protokolle nach Quellnetzwerk filtern: Filtern Sie die Protokolle anhand der Quell-IP-Adresse der DNS-Abfrage, um Bedrohungen zu sehen, die von einem bestimmten VPC-Netzwerk ausgehen.

So rufen Sie Logs von network-a (Subnetze 10.10.0.0/24 und 10.10.1.0/24) auf:

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

So rufen Sie Logs von network-b (Subnetze 10.20.0.0/24) auf:

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

Hinweis:Für VMs in network-b sollten keine Bedrohungslogs angezeigt werden, da dieses Netzwerk bei der Erstellung des Bedrohungsdetektors ausgeschlossen wurde.

7. Bereinigen

Löschen Sie die in diesem Codelab erstellten Ressourcen, um zukünftige Gebühren zu vermeiden. Achten Sie darauf, die Shell der VM zu beenden und zu Cloud Shell zurückzukehren, wenn Sie die Bereinigungsbefehle ausführen.

1. Löschen Sie die VMs.

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. Löschen Sie die Firewallregeln.

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

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

3. Löschen Sie die Cloud NAT-Gateways.

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. Cloud Router löschen

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. Löschen Sie die Subnetze.

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. Löschen Sie den DNS-Bedrohungsdetektor.

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

7. Löschen Sie die VPCs.

gcloud compute networks delete network-a --quiet

gcloud compute networks delete network-b --quiet

8. Glückwunsch

Glückwunsch! Sie haben den DNS Armor-Gefahrendetektor erfolgreich konfiguriert, bereitgestellt und getestet. Sie haben praktische Erfahrung im Schutz Ihrer Google Cloud-Umgebung vor DNS-basierten Bedrohungen gesammelt.

In diesem Codelab haben Sie Folgendes getan:

• Sie haben eine Netzwerkumgebung mit mehreren VPCs, Subnetzen und virtuellen Maschinen bereitgestellt.
• Ausgehender Internetzugriff für private VMs mit Cloud NAT konfiguriert.
• Sie haben einen DNS Armor-Bedrohungsdetektor bereitgestellt und gelernt, wie Sie bestimmte Netzwerke ausschließen.
• Simulierte DNS-Bedrohungen und validierte die Konfiguration der Bedrohungserkennung.
• Bedrohungslogs im Log-Explorer analysiert, um schädliche DNS-Aktivitäten zu identifizieren und nachzuvollziehen.

Nächste Schritte

Referenzdokumente

• Erweiterte Bedrohungserkennung – Übersicht | Cloud DNS
• DNS Armor zur Minimierung von Risiken im Domain Name System | Google Cloud-Blog
• DNS-Bedrohungsdetektor erstellen | Google Cloud