Начало работы с расширенным обнаружением угроз 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-запросов.

75d6eeb807735645.png

Что вы узнаете

  • Как подготовить необходимые сетевые ресурсы, включая 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.
  • Администратор безопасности вычислительных систем ( roles/compute.securityAdmin ): для настройки правил брандмауэра для доступа по SSH к виртуальным машинам.
  • Администратор вычислительных экземпляров (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}-compute@developer.gserviceaccount.com" \
--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. Создайте сеть network-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. Создайте облачный маршрутизатор и облачный 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. Создайте облачный маршрутизатор и облачный 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.

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.

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

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

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

sudo apt-get install git -y

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

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

4. Перейдите в каталог симулятора.

cd ib-threat-detection-simulator/threat_detection_simulator/

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

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

chmod +x run.sh

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

./run.sh info basic

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

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

a66c1757f8c74da6.png

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

c12d130c95c04e84.png

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

exit

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

Сгенерированные журналы угроз можно просмотреть в 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"
}

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

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

4a90c593d7e339d8.png

2. Для фильтрации всех журналов угроз DNS Armor используйте следующий запрос. Эта фильтрация журналов основана на типе ресурса для DNS Threat Detector.

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

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

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

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."

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.

Что дальше?

Справочная документация