Начало работы с расширенным обнаружением угроз DNS Armor

1. Введение и обзор

DNS Armor, работающий на базе Infoblox , — это полностью управляемый сервис, обеспечивающий безопасность на уровне DNS для рабочих нагрузок Google Cloud. Его усовершенствованный детектор угроз предназначен для обнаружения вредоносной активности на самом раннем этапе цепочки атак — в DNS-запросе — без усложнения работы и снижения производительности.

В этой лабораторной работе представлены пошаговые инструкции по настройке и тестированию службы DNS Armor . Вы настроите необходимую сетевую инфраструктуру, создадите детектор угроз, протестируете службу, симулируя DNS-угрозы, и, наконец, проанализируете журналы угроз с помощью Logs Explorer.

Что вы построите

В этой лабораторной работе вам предстоит подготовить следующие ресурсы:

• Две сети VPC: network-a и network-b
• network-a будет включать подсети и виртуальные машины в регионах us-east4 и us-central1 .
• network-b будет включать подсеть и виртуальную машину исключительно в us-east4 .
• Расширенный детектор угроз DNS Armor, настроенный на проверку DNS-запросов.

Чему вы научитесь

• Как предоставить необходимые сетевые ресурсы, включая VPC и виртуальные машины.
• Как развернуть расширенный детектор угроз и исключить определенные сети.
• Как проверить конфигурацию обнаружения угроз с помощью сценария моделирования угроз.
• Как анализировать журналы угроз в Logs Explorer.

Что вам понадобится

• Проект Google Cloud.
• Доступ к инструменту командной строки gcloud .

2. Предпосылки

В этом разделе вам предстоит выполнить следующие задачи:

• Убедитесь, что ваш проект Google Cloud соответствует необходимым ограничениям политики организации.
• Убедитесь, что ваша учетная запись пользователя имеет необходимые роли и разрешения IAM.
• Включите API Google Cloud, необходимые для этой лабораторной работы.
• Назначьте роль IAM roles/logging.viewer учетной записи службы Compute Engine.

Ограничения политики организации

Для успешного выполнения этой лабораторной работы проверьте ограничения политики организации, применяемые к вашему проекту. Некоторые политики могут препятствовать предоставлению необходимых ресурсов. Следующие ограничения могут повлиять на конфигурацию этой лабораторной работы:

• constraints/gcp.resourceLocations : Ограничивает регионы, в которых можно создавать ресурсы; для кодовой лаборатории требуются us-east4 и us-central1 .
• constraints/compute.vmExternalIpAccess : предотвращает создание виртуальных машин с публичными IP-адресами, что может помешать настройке, если вы не будете следовать рекомендациям по использованию флага --no-address в кодовой лаборатории.
• constraints/compute.shieldedVm : принудительно создает защищенные виртуальные машины, которые не указаны в командах создания виртуальных машин в кодовой лаборатории, что может привести к ошибке.
• constraints/gcp.restrictServiceUsage : ограничивает, какие API Google Cloud могут быть включены, и может заблокировать кодовую лабораторию, если она не разрешает compute.googleapis.com , networksecurity.googleapis.com , logging.googleapis.com и monitoring.googleapis.com .

Роли и разрешения IAM

Для успешного выполнения этой лабораторной работы проверьте роли IAM и разрешения, предоставленные вашему пользователю. Для выполнения этой лабораторной работы требуются следующие роли IAM и разрешения.

• Администрирование использования служб ( roles/serviceusage.serviceUsageAdmin ): для включения требуемых API Google Cloud для кодовой лаборатории.
• Администратор вычислительной сети ( roles/compute.networkAdmin ): для создания и управления сетями VPC, подсетями и Cloud NAT.
• Compute Security Admin ( roles/compute.securityAdmin ): для настройки правил брандмауэра для доступа по SSH к виртуальным машинам.
• Compute Instance Admin (v1) ( roles/compute.instanceAdmin.v1 ): для создания и управления виртуальными машинами, необходимыми для лаборатории.
• Пользователь туннеля, защищенного IAP ( roles/iap.tunnelResourceAccessor ): для подключения к виртуальным машинам с использованием SSH через прокси-сервер Identity-Aware Proxy (IAP).
• Администратор сетевой безопасности ( roles/networksecurity.admin ): для создания и управления детектором угроз DNS Armor.
• Просмотрщик журналов ( roles/logging.viewer ): для просмотра и анализа журналов угроз в Logs Explorer.

API Google Cloud

Убедитесь, что в вашем проекте включены необходимые API Google Cloud.

1. Включите необходимые API , выполните следующие команды gcloud в Cloud Shell.

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

2. Убедитесь, что API включены , выполните следующие команды gcloud в Cloud Shell.

gcloud services list --enabled

Учетная запись службы Compute Engine

Для тестового скрипта требуются разрешения на чтение журналов угроз из Cloud Logging. Поскольку скрипт будет выполняться на виртуальной машине с использованием учётной записи службы Compute Engine по умолчанию, этой учётной записи службы должна быть назначена роль IAM roles/logging.viewer .

1. Задайте переменные среды , выполните следующие команды в Cloud Shell.

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

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

2. Предоставьте роль наблюдателя журналов администратору Compute Engine SA. Выполните следующие команды gcloud в Cloud Shell.

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

3. Базовая настройка среды

В этом разделе вам предстоит выполнить следующие задачи:

• Создайте сети VPC ( network-a и network-b ) с пользовательскими подсетями.
• Настройте облачные маршрутизаторы и облачный NAT для выхода в Интернет в network-a и network-b .
• Создайте правила брандмауэра, чтобы разрешить SSH-доступ к виртуальным машинам из диапазона IP-адресов IAP как для network-a так и network-b .
• Предоставьте виртуальные машины Linux в network-a и network-b без публичных IP-адресов.

Создание VPC и подсетей

1. Создайте сеть network-a и её подсети в регионах us-east4 и us-central1 . Выполните следующие команды gcloud в 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. Создайте сеть b и её подсеть в регионе us-east4 . Выполните следующие команды gcloud в 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

Настроить выход в Интернет

1. Создайте Cloud Router и Cloud NAT для network-a чтобы разрешить выход в Интернет для виртуальных машин без публичных IP-адресов.

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. Создайте Cloud Router и Cloud NAT для network-b , чтобы разрешить выход в Интернет для виртуальных машин без публичных IP-адресов.

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

Настроить правила брандмауэра

1. Создайте правила брандмауэра для network-a , чтобы разрешить доступ по SSH из диапазона IP-адресов IAP. Выполните следующие команды gcloud в 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. Создайте правила брандмауэра для network-b чтобы разрешить доступ по SSH из диапазона IP-адресов IAP. Выполните следующие команды gcloud в Cloud Shell.

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

Создание виртуальных машин

1. Создайте виртуальные машины Linux в 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. Создайте виртуальную машину Linux в 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. Создайте детектор угроз DNS

В этом разделе вам предстоит выполнить следующие задачи:

• Создайте детектор угроз.
• Перечислите детекторы угроз.
• Опишите ресурс.

Теперь, когда VPC, подсети и виртуальные машины подготовлены, следующим шагом будет создание детектора угроз DNS.

Примечание: Детектор угроз DNS — это ресурс уровня проекта. Используйте флаг --excluded-networks чтобы исключить определённые сети VPC.

1. Создайте детектор угроз с помощью команды gcloud beta network-security dns-threat-detectors create . Используйте флаг --excluded-networks , чтобы исключить сеть 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. Перечислите детектор угроз, чтобы подтвердить создание.

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

3. Опишите ресурс , чтобы убедиться, что network-b правильно указан в excludedNetworks .

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

Пример вывода:

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. Тестирование настройки

В этом разделе вам предстоит выполнить следующие задачи:

• Подключитесь к виртуальным машинам по SSH.
• Установите Git на виртуальные машины.
• Клонируйте репозиторий симулятора обнаружения угроз Infoblox.
• Запустите скрипт и проанализируйте полученный результат.

Проверьте правильность настройки, сгенерировав эмулированные вредоносные DNS-запросы с ваших виртуальных машин. Необходимо отслеживать записи в журнале для запросов из network-a , тогда как для network-b.

Примечание: Эти инструкции предназначены специально для vm-a-use4 . Чтобы сгенерировать вредоносные DNS-запросы с vm-a-usc1 и vm-b-use4 , повторите все шаги, описанные в этом разделе, для каждой соответствующей виртуальной машины.

1. Подключитесь к vm-a-use4 по SSH . Выполните следующие команды gcloud в Cloud Shell.

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

2. Установите Git на виртуальную машину.

Примечание: эту команду следует выполнять на виртуальной машине, а не в Cloud Shell.

sudo apt-get install git -y

3. Клонируйте репозиторий симулятора обнаружения угроз Infoblox.

Примечание: эту команду следует выполнять на виртуальной машине, а не в Cloud Shell.

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

4. Измените каталог на каталог симулятора.

Примечание: эту команду следует выполнять на виртуальной машине, а не в Cloud Shell.

cd ib-threat-detection-simulator/threat_detection_simulator/

5. Запустите скрипт и проанализируйте полученный результат.

Примечание: Этот скрипт имитирует различные DNS-угрозы, отправляя запросы на известные вредоносные или подозрительные домены. Он предназначен только для тестирования и демонстрации.

• Этот инструмент генерирует трафик DNS-запросов, выполняя локальные команды dig для указанного списка доменов. Его основная цель — имитация вредоносной DNS-активности.
• В расширенном режиме анализа по умолчанию он реплицирует угрозы различных категорий, включая стандартный фишинг и вредоносное ПО, а также сложные угрозы.
• Эти расширенные симуляции включают запросы к реальным доменам алгоритма генерации доменов (DGA), связанным с семействами вредоносных программ Mylobot и Suppobox, а также эмулируют атаки DNS-туннелирования (DNST).

Более подробную информацию о скрипте и имитируемых им угрозах можно найти в репозитории GitHub .

Примечание: эту команду следует выполнять на виртуальной машине, а не в Cloud Shell.

Сделайте скрипт исполняемым.

chmod +x run.sh

Запустите скрипт.

./run.sh info basic

6. Пример вывода

На снимке экрана ниже показана часть вывода скрипта с виртуальной машины в сети a. Вывод показывает, что было обнаружено 100% угроз.

На снимке экрана ниже показана часть выходных данных скрипта виртуальной машины в сети b. В результатах указано, что обнаружено 0% угроз. Это ожидаемо, поскольку сеть b была исключена при создании детектора угроз.

7. Вернитесь в Cloud Shell , выйдя из сеанса SSH.

exit

Примечание: прежде чем перейти к следующему разделу, повторите шаги с 1 по 5, чтобы сгенерировать вредоносные DNS-запросы от vm-a-usc1 и vm-b-use4.

6. Просмотр журналов угроз в обозревателе журналов

Сгенерированные журналы угроз можно просмотреть в Logs Explorer после запуска тестового скрипта, так как они записываются в Cloud Logging.

Образец записи в журнале

В этом разделе представлен пример записи журнала об обнаруженной DNS-угрозе, демонстрирующий подробную информацию, собранную DNS Armor, включая исходный IP-адрес, запрашиваемый домен и категорию угрозы. Он служит справочным материалом для понимания структуры и содержания журналов, которые вы будете анализировать.

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

Просмотр журналов в обозревателе журналов

Примечание: в этом разделе мы будем использовать консоль GCP.

1. Перейдите в раздел Monitoring в консоли Google Cloud Console, затем выберите Logs explorer .

2. Отфильтруйте все журналы угроз DNS Armor , используя следующий запрос. Он фильтрует журналы по типу ресурса для детектора угроз DNS.

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

Примечание: журналы угроз не должны отображаться для виртуальных машин в network-b , поскольку эта сеть была исключена при создании детектора угроз.

3. Фильтрация журналов для региона us-east4 с добавлением фильтра по местоположению. Этот запрос покажет только угрозы, обнаруженные в регионе us-east4.

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

Примечание: журналы угроз не должны отображаться для виртуальных машин в network-b , поскольку эта сеть была исключена при создании детектора угроз.

4. Фильтрация журналов по исходной сети . Фильтрация журналов на основе исходного IP-адреса DNS-запроса позволяет увидеть угрозы, исходящие из определенной сети VPC.

Чтобы просмотреть журналы из network-a (подсети 10.10.0.0/24 и 10.10.1.0/24):

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

Чтобы просмотреть журналы из network-b (подсети 10.20.0.0/24):

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

Примечание: журналы угроз не должны отображаться для виртуальных машин в network-b , поскольку эта сеть была исключена при создании детектора угроз.

7. Уборка

Чтобы избежать будущих расходов, удалите ресурсы, созданные в этой лабораторной работе. Обязательно выйдите из оболочки виртуальной машины и вернитесь в Cloud Shell перед выполнением команд очистки.

1. Удалите виртуальные машины.

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. Удалите правила брандмауэра.

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

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

3. Удалите шлюзы 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. Удалить облачные маршрутизаторы

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. Удалите подсети.

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. Удалить детектор угроз DNS.

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

7. Удалите VPC.

gcloud compute networks delete network-a --quiet

gcloud compute networks delete network-b --quiet

8. Поздравления

Поздравляем! Вы успешно настроили, развернули и протестировали детектор угроз DNS Armor. Вы приобрели практический опыт защиты своей среды Google Cloud от DNS-угроз.

В этой лабораторной работе вам предстоит:

• Обеспечил сетевую среду с несколькими VPC, подсетями и виртуальными машинами.
• Настроил выход в Интернет для частных виртуальных машин с использованием Cloud NAT.
• Развернули детектор угроз DNS Armor и научились исключать определенные сети.
• Смоделированы угрозы DNS и проверена конфигурация обнаружения угроз.
• Анализ журналов угроз в Logs Explorer для выявления и понимания вредоносной активности DNS.

Что дальше?

Справочные документы

• Обзор расширенного обнаружения угроз | Cloud DNS
• Представляем DNS Armor для снижения рисков системы доменных имен | Блог Google Cloud
• Создайте детектор DNS-угроз | Google Cloud