Pierwsze kroki z zaawansowanym wykrywaniem zagrożeń DNS Armor

1. Wstęp i omówienie

DNS Armor, oparta na technologii Infoblox, to w pełni zarządzana usługa, która zapewnia zabezpieczenia na poziomie DNS dla Twoich zbiorów zadań w Google Cloud. Zaawansowany detektor zagrożeń został zaprojektowany tak, aby wykrywać szkodliwą aktywność na najwcześniejszym etapie łańcucha ataku – w zapytaniu DNS – bez zwiększania złożoności operacyjnej ani obciążenia wydajności.

W tym ćwiczeniu znajdziesz instrukcje krok po kroku dotyczące konfigurowania i testowania usługi DNS Armor. Skonfigurujesz niezbędną infrastrukturę sieciową, utworzysz detektor zagrożeń, przetestujesz usługę, symulując zagrożenia DNS, a na koniec przeanalizujesz logi zagrożeń za pomocą eksploratora logów.

Co utworzysz

W tym module utworzysz te zasoby:

• 2 sieci VPC: network-a i network-b
• network-a będzie obejmować podsieci i maszyny wirtualne w regionach us-east4 i us-central1.
• network-b będzie zawierać podsieć i maszynę wirtualną wyłącznie w us-east4.
• Zaawansowany detektor zagrożeń DNS Armor skonfigurowany do sprawdzania zapytań DNS.

Czego się nauczysz

• Jak udostępnić niezbędne zasoby sieciowe, w tym sieci VPC i maszyny wirtualne.
• Jak wdrożyć zaawansowany detektor zagrożeń i wykluczyć określone sieci.
• Jak zweryfikować konfigurację wykrywania zagrożeń za pomocą skryptu symulacji zagrożeń.
• Jak analizować logi zagrożeń w eksploratorze logów.

Czego potrzebujesz

• Projekt Google Cloud.
• Dostęp do narzędzia wiersza poleceń gcloud.

2. Wymagania wstępne

W tej sekcji wykonasz te czynności:

• Sprawdź, czy Twój projekt Google Cloud spełnia wymagane ograniczenia zasad organizacji.
• Sprawdź, czy Twoje konto użytkownika ma wymagane role i uprawnienia IAM.
• Włącz interfejsy Google Cloud API niezbędne do tego laboratorium.
• Przypisz do konta usługi Compute Engine rolę uprawnień roles/logging.viewer.

Ograniczenia zasad organizacji

Aby ukończyć to ćwiczenie, sprawdź ograniczenia zasad organizacji zastosowane w Twoim projekcie. Niektóre zasady mogą utrudniać udostępnianie niezbędnych zasobów. Na konfigurację tego laboratorium mogą mieć wpływ te ograniczenia:

• constraints/gcp.resourceLocations: ogranicza regiony, w których możesz tworzyć zasoby; ćwiczenie z programowania wymaga us-east4 i us-central1.
• constraints/compute.vmExternalIpAccess: uniemożliwia tworzenie maszyn wirtualnych z publicznymi adresami IP, co może zakłócić konfigurację, jeśli nie będziesz postępować zgodnie z instrukcjami w tym samouczku dotyczącymi używania flagi --no-address .
• constraints/compute.shieldedVm: wymusza tworzenie chronionych maszyn wirtualnych, których polecenia tworzenia maszyn wirtualnych w tym samouczku nie określają, co może powodować błąd.
• constraints/gcp.restrictServiceUsage: ogranicza liczbę interfejsów Google Cloud API, które można włączyć, i może zablokować codelab, jeśli nie zezwala na compute.googleapis.com, networksecurity.googleapis.com, logging.googleapis.com i monitoring.googleapis.com.

Role i uprawnienia

Aby ukończyć te ćwiczenia z programowania, sprawdź role i uprawnienia IAM przyznane Twojemu użytkownikowi. Aby ukończyć to ćwiczenie, musisz mieć te role i uprawnienia.

• Administrator użycia usługi (roles/serviceusage.serviceUsageAdmin): aby włączyć wymagane interfejsy API Google Cloud na potrzeby codelabu.
• Administrator sieci Compute (roles/compute.networkAdmin): umożliwia tworzenie sieci VPC, podsieci i Cloud NAT oraz zarządzanie nimi.
• Administrator zabezpieczeń Compute (roles/compute.securityAdmin): do konfigurowania reguł zapory sieciowej dla dostępu SSH do maszyn wirtualnych.
• Administrator instancji Compute (v1) (roles/compute.instanceAdmin.v1): umożliwia tworzenie maszyn wirtualnych wymaganych w laboratorium i zarządzanie nimi.
• Użytkownik tunelu zabezpieczonego przez IAP (roles/iap.tunnelResourceAccessor): umożliwia łączenie się z maszynami wirtualnymi za pomocą SSH przez serwer proxy identyfikujący tożsamość (IAP).
• Administrator ds. bezpieczeństwa sieci (roles/networksecurity.admin): może tworzyć detektor zagrożeń DNS Armor i nim zarządzać.
• Wyświetlający logi (roles/logging.viewer): umożliwia wyświetlanie i analizowanie logów zagrożeń w eksploratorze logów.

Interfejsy Google Cloud APIs

Sprawdź, czy w projekcie są włączone wymagane interfejsy API Google Cloud.

1. Włącz niezbędne interfejsy API, uruchamiając w Cloud Shell te gcloud polecenia.

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

2. Sprawdź, czy interfejsy API są włączone, uruchamiając w Cloud Shell te gcloud polecenia.

gcloud services list --enabled

Konto usługi Compute Engine

Skrypt testowy wymaga uprawnień do odczytywania logów zagrożeń z Cloud Logging. Skrypt będzie wykonywany na maszynie wirtualnej korzystającej z domyślnego konta usługi Compute Engine, dlatego do tego konta usługi musi być przypisana rola uprawnień roles/logging.viewer.

1. Ustaw zmienne środowiskowe, uruchamiając w Cloud Shell te polecenia:

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

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

2. Przyznaj konto usługi Compute Engine rolę przeglądającego logi. Uruchom w Cloud Shell te polecenia gcloud:

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

3. Podstawowa konfiguracja środowiska

W tej sekcji wykonasz te czynności:

• Utwórz sieci VPC (network-a i network-b) z niestandardowymi podsieciami.
• Skonfiguruj routery Cloud Router i Cloud NAT na potrzeby ruchu wychodzącego z internetu w obu regionach network-a i network-b.
• Utwórz reguły zapory sieciowej zezwalające na dostęp SSH do maszyn wirtualnych z zakresu adresów IP IAP w przypadku obu sieci network-a i network-b.
• Aprowizuj maszyny wirtualne z systemem Linux w strefach network-a i network-b bez publicznych adresów IP.

Tworzenie sieci VPC i podsieci

1. Utwórz sieć-a i jej podsieci w regionach us-east4 i us-central1. Uruchom w Cloud Shell te polecenia gcloud.

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. Utwórz sieć-b i jej podsieć w regionie us-east4. Uruchom w Cloud Shell te polecenia gcloud.

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

Konfigurowanie ruchu wychodzącego z internetu

1. Utwórz router Cloud Router i Cloud NAT dla network-a, aby umożliwić maszynom wirtualnym bez publicznych adresów IP wychodzenie z internetu.

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. Utwórz router Cloud Router i Cloud NAT dla network-b, aby umożliwić maszynom wirtualnym bez publicznych adresów IP wychodzenie z internetu.

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

Konfigurowanie reguł zapory sieciowej

1. Utwórz reguły zapory sieciowej dla network-a, aby zezwolić na dostęp SSH z zakresu adresów IP IAP. Uruchom w Cloud Shell te polecenia gcloud.

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

2. Utwórz reguły zapory sieciowej dla network-b, aby zezwolić na dostęp SSH z zakresu adresów IP IAP. Uruchom w Cloud Shell te polecenia gcloud.

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

Tworzenie maszyn wirtualnych

1. Tworzenie maszyn wirtualnych z systemem Linux w regionie 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. Tworzenie maszyny wirtualnej z systemem Linux w strefie 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. Tworzenie detektora zagrożeń DNS

W tej sekcji wykonasz te czynności:

• Utwórz detektor zagrożeń.
• Wyświetl listę detektorów zagrożeń.
• Opisz zasób.

Po utworzeniu sieci VPC, podsieci i maszyn wirtualnych następnym krokiem jest utworzenie detektora zagrożeń DNS.

Uwaga: detektor zagrożeń DNS to zasób na poziomie projektu. Użyj flagi --excluded-networks, aby wykluczyć określone sieci VPC.

1. Utwórz detektor zagrożeń za pomocą polecenia gcloud beta network-security dns-threat-detectors create. Użyj flagi --excluded-networks, aby wykluczyć 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. Wyświetl listę detektorów zagrożeń, aby potwierdzić utworzenie.

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

3. Opisz zasób, aby sprawdzić, czy network-b jest prawidłowo wymieniony w sekcji excludedNetworks.

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

Przykładowe dane wyjściowe:

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. Testowanie konfiguracji

W tej sekcji wykonasz te czynności:

• Połącz się z maszynami wirtualnymi za pomocą SSH.
• Zainstaluj Git na maszynach wirtualnych.
• Sklonuj repozytorium symulatora wykrywania zagrożeń Infoblox.
• Uruchom skrypt i przeanalizuj wygenerowane dane wyjściowe.

Sprawdź konfigurację, generując na maszynach wirtualnych emulowane złośliwe zapytania DNS. Powinny być widoczne wpisy logu dotyczące zapytań pochodzących z network-a, a żadne logi nie będą generowane z network-b..

Uwaga: te instrukcje dotyczą konkretnie vm-a-use4. Aby wygenerować złośliwe zapytania DNS z vm-a-usc1 i vm-b-use4, powtórz wszystkie czynności opisane w tej sekcji dla każdej maszyny wirtualnej.

1. Połącz się z maszyną wirtualną vm-a-use4 za pomocą SSH. Uruchom w Cloud Shell te polecenia gcloud.

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

2. Zainstaluj Git na maszynie wirtualnej.

Uwaga: to polecenie należy wykonać na maszynie wirtualnej, a nie w Cloud Shell.

sudo apt-get install git -y

3. Sklonuj repozytorium symulatora wykrywania zagrożeń Infoblox.

Uwaga: to polecenie należy wykonać na maszynie wirtualnej, a nie w Cloud Shell.

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

4. Przejdź do katalogu symulatora.

Uwaga: to polecenie należy wykonać na maszynie wirtualnej, a nie w Cloud Shell.

cd ib-threat-detection-simulator/threat_detection_simulator/

5. Uruchom skrypt i przeanalizuj wygenerowane dane wyjściowe.

Uwaga: ten skrypt symuluje różne zagrożenia związane z DNS, wysyłając zapytania do znanych złośliwych lub podejrzanych domen. Jest przeznaczona wyłącznie do celów testowych i demonstracyjnych.

• To narzędzie generuje ruch zapytań DNS, wykonując lokalne polecenia dig dla określonej listy domen. Jego głównym celem jest symulowanie złośliwej aktywności DNS.
• W domyślnym trybie analizy zaawansowanej replikuje zagrożenia w różnych kategoriach, w tym standardowe wyłudzanie informacji i złośliwe oprogramowanie, a także zaawansowane zagrożenia.
• Te zaawansowane symulacje obejmują zapytania do rzeczywistych domen algorytmu generowania domen (DGA) powiązanych z rodzinami złośliwego oprogramowania Mylobot i Suppobox, a także emulują ataki tunelowania DNS (DNST).

Więcej informacji o skrypcie i symulowanych przez niego zagrożeniach znajdziesz w repozytorium GitHub.

Uwaga: to polecenie należy wykonać na maszynie wirtualnej, a nie w Cloud Shell.

Ustaw skrypt jako wykonywalny.

chmod +x run.sh

Uruchom skrypt.

./run.sh info basic

6. Przykładowe dane wyjściowe

Zrzut ekranu poniżej przedstawia część danych wyjściowych skryptu z maszyny wirtualnej w sieci A. Wyniki pokazują, że wykryto 100% zagrożeń.

Zrzut ekranu poniżej przedstawia część danych wyjściowych skryptu z maszyny wirtualnej w sieci b. Wynik pokazuje, że wykryto 0% zagrożeń. Jest to oczekiwane, ponieważ sieć b została wykluczona podczas tworzenia detektora zagrożeń.

7. Wróć do Cloud Shell, zamykając sesję SSH.

exit

Uwaga: zanim przejdziesz do następnej sekcji, powtórz kroki 1–5, aby wygenerować złośliwe zapytania DNS z vm-a-usc1 i vm-b-use4..

6. Wyświetlanie logów zagrożeń w Eksploratorze logów

Wygenerowane logi zagrożeń można wyświetlić w Eksploratorze logów po uruchomieniu skryptu testowego, ponieważ są one zapisywane w Cloud Logging.

Przykładowy wpis logu

Ta sekcja zawiera przykładowy wpis w dzienniku wykrytego zagrożenia DNS, który pokazuje szczegółowe informacje przechwycone przez DNS Armor, w tym źródłowy adres IP, domenę, której dotyczyło zapytanie, i kategorię zagrożenia. Służy on jako punkt odniesienia do zrozumienia struktury i zawartości logów, które będziesz analizować.

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

Wyświetlanie logów w Eksploratorze logów

Uwaga: w tej sekcji będziemy używać konsoli GCP.

1. W konsoli Google Cloud przejdź do sekcji Monitoring, a następnie wybierz Logs explorer.

2. Aby przefiltrować wszystkie logi zagrożeń DNS Armor, użyj tego zapytania. Filtruje logi na podstawie typu zasobu detektora zagrożeń DNS.

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

Uwaga: dzienniki zagrożeń nie powinny być wyświetlane w przypadku maszyn wirtualnych w sieci network-b, ponieważ została ona wykluczona podczas tworzenia detektora zagrożeń.

3. Filtruj logi dla regionu us-east4, dodaj filtr lokalizacji. To zapytanie wyświetli tylko zagrożenia wykryte w regionie us-east4.

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

Uwaga: dzienniki zagrożeń nie powinny być wyświetlane w przypadku maszyn wirtualnych w sieci network-b, ponieważ została ona wykluczona podczas tworzenia detektora zagrożeń.

4. Filtrowanie logów według sieci źródłowej – filtruj logi na podstawie źródłowego adresu IP zapytania DNS, aby zobaczyć zagrożenia pochodzące z określonej sieci VPC.

Aby wyświetlić logi z network-a (podsieci 10.10.0.0/24 i 10.10.1.0/24):

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

Aby wyświetlić logi z network-b (podsieci 10.20.0.0/24):

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

Uwaga: dzienniki zagrożeń nie powinny być wyświetlane w przypadku maszyn wirtualnych w sieci network-b, ponieważ została ona wykluczona podczas tworzenia detektora zagrożeń.

7. Czyszczenie

Aby uniknąć przyszłych opłat, usuń zasoby utworzone w tym laboratorium. Podczas uruchamiania poleceń czyszczenia pamiętaj, aby zamknąć powłokę maszyny wirtualnej i wrócić do Cloud Shell.

1. Usuń maszyny wirtualne.

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. Usuń reguły zapory sieciowej.

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

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

3. Usuń bramy 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. Usuń routery 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. Usuń podsieci.

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. Usuń detektor zagrożeń DNS.

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

7. Usuń sieci VPC.

gcloud compute networks delete network-a --quiet

gcloud compute networks delete network-b --quiet

8. Gratulacje

Gratulacje! Udało Ci się skonfigurować, wdrożyć i przetestować detektor zagrożeń DNS Armor. Zdobyłeś(-aś) praktyczne doświadczenie w zakresie ochrony środowiska Google Cloud przed zagrożeniami opartymi na DNS.

W tych ćwiczeniach z programowania:

• utworzyć środowisko sieciowe z wieloma sieciami VPC, podsieciami i maszynami wirtualnymi;
• Skonfigurowano wychodzący ruch internetowy dla prywatnych maszyn wirtualnych za pomocą Cloud NAT.
• wdrożono detektor zagrożeń DNS Armor i dowiedziano się, jak wykluczać określone sieci;
• symulowane zagrożenia DNS i zweryfikowana konfiguracja wykrywania zagrożeń.
• Analizowanie logów zagrożeń w eksploratorze logów w celu identyfikowania i rozumienia szkodliwej aktywności DNS.

Co dalej?

Dokumentacja

• Omówienie zaawansowanego wykrywania zagrożeń | Cloud DNS
• Wprowadzenie DNS Armor w celu ograniczenia ryzyka związanego z systemem nazw domenowych | Blog Google Cloud
• Tworzenie detektora zagrożeń DNS | Google Cloud