Como começar a usar a detecção avançada de ameaças do DNS Armor

1. Introdução e visão geral

O DNS Armor, com tecnologia Infoblox, é um serviço totalmente gerenciado que oferece segurança na camada de DNS para suas cargas de trabalho do Google Cloud. O detector avançado de ameaças foi projetado para detectar atividades maliciosas no início da cadeia de ataque (a consulta de DNS) sem adicionar complexidade operacional ou sobrecarga de desempenho.

Este codelab oferece instruções detalhadas para configurar e testar o serviço DNS Armor. Você vai configurar a infraestrutura de rede necessária, criar o detector de ameaças, testar o serviço simulando ameaças de DNS e, por fim, analisar os registros de ameaças usando o Explorador de registros.

O que você vai criar

Neste codelab, você vai provisionar os seguintes recursos:

• Duas redes VPC: network-a e network-b
• network-a vai incluir sub-redes e máquinas virtuais nas regiões us-east4 e us-central1.
• network-b vai incluir uma sub-rede e uma máquina virtual somente em us-east4.
• Um detector avançado de ameaças do DNS Armor configurado para inspecionar consultas DNS.

O que você vai aprender

• Como provisionar os recursos de rede necessários, incluindo VPCs e máquinas virtuais.
• Como implantar um detector avançado de ameaças e excluir redes específicas.
• Como validar a configuração de detecção de ameaças usando um script de simulação de ameaças.
• Como analisar registros de ameaças no Explorador de registros.

O que é necessário

• Um projeto do Google Cloud.
• Acesso à ferramenta de linha de comando gcloud.

2. Pré-requisitos

Nesta seção, você realizará as seguintes tarefas:

• Verifique se o projeto do Google Cloud atende às restrições necessárias da política da organização.
• Confirme se sua conta de usuário tem os papéis e as permissões do IAM necessários.
• Ative as APIs do Google Cloud essenciais para este codelab.
• Atribua o papel do IAM roles/logging.viewer à conta de serviço do Compute Engine.

Restrições da política da organização

Para concluir este codelab, verifique as restrições da política da organização aplicadas ao seu projeto. Algumas políticas podem dificultar o provisionamento dos recursos necessários. As seguintes restrições podem afetar a configuração deste codelab:

• constraints/gcp.resourceLocations: restringe as regiões em que é possível criar recursos. O codelab exige us-east4 e us-central1.
• constraints/compute.vmExternalIpAccess: impede a criação de máquinas virtuais com endereços IP públicos, o que pode interferir na configuração se você não seguir o uso da flag --no-address no codelab .
• constraints/compute.shieldedVm: força a criação de VMs protegidas, que os comandos de criação de VM do codelab não especificam, podendo causar um erro.
• constraints/gcp.restrictServiceUsage: limita quais APIs do Google Cloud podem ser ativadas e pode bloquear o codelab se ele não permitir compute.googleapis.com, networksecurity.googleapis.com, logging.googleapis.com e monitoring.googleapis.com.

Permissões e papéis do IAM

Para concluir este codelab, verifique os papéis e as permissões do IAM concedidos ao seu usuário. Os seguintes papéis e permissões do IAM são necessários para concluir este codelab.

• Administrador do uso do serviço (roles/serviceusage.serviceUsageAdmin): para ativar as APIs do Google Cloud necessárias para o codelab.
• Administrador de rede do Compute (roles/compute.networkAdmin): para criar e gerenciar redes VPC, sub-redes e o Cloud NAT.
• Administrador de segurança do Compute (roles/compute.securityAdmin): para configurar as regras de firewall para acesso SSH às máquinas virtuais.
• Administrador de instâncias do Compute (v1) (roles/compute.instanceAdmin.v1): para criar e gerenciar as máquinas virtuais necessárias para o laboratório.
• Usuário do túnel protegido pelo IAP (roles/iap.tunnelResourceAccessor): para se conectar às máquinas virtuais usando SSH pelo Identity-Aware Proxy (IAP).
• Administrador de segurança de rede (roles/networksecurity.admin): para criar e gerenciar o detector de ameaças do DNS Armor.
• Visualizador de registros (roles/logging.viewer): para ver e analisar os registros de ameaças no Explorador de registros.

APIs Google Cloud

Verifique se as APIs do Google Cloud necessárias estão ativadas no seu projeto.

1. Ative as APIs necessárias e execute os seguintes comandos gcloud no Cloud Shell.

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

2. Verifique se as APIs estão ativadas e execute os seguintes comandos gcloud no Cloud Shell.

gcloud services list --enabled

Conta de serviço do Compute Engine

O script de teste exige permissões para ler registros de ameaças do Cloud Logging. Como o script será executado em uma VM que usa a conta de serviço padrão do Compute Engine, o papel roles/logging.viewer do IAM precisa ser atribuído a essa conta.

1. Defina as variáveis de ambiente e execute os comandos a seguir no Cloud Shell.

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

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

2. Conceda o papel de leitor do Logging à SA do Compute Engine. Execute os seguintes comandos gcloud no Cloud Shell

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

3. Configuração básica do ambiente

Nesta seção, você realizará as seguintes tarefas:

• Crie redes VPC (network-a e network-b) com sub-redes personalizadas.
• Configure o Cloud Router e o Cloud NAT para saída da Internet em network-a e network-b.
• Crie regras de firewall para permitir o acesso SSH às VMs do intervalo de IP do IAP para network-a e network-b.
• Provisione máquinas virtuais Linux em network-a e network-b sem endereços IP públicos.

Criar VPCs e sub-redes

1. Crie a rede "network-a" e as sub-redes nas regiões us-east4 e us-central1. Execute os seguintes comandos gcloud no 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. Crie a rede "network-b" e a sub-rede dela na região us-east4. Execute os seguintes comandos gcloud no 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

Configurar saída da Internet

1. Crie o Cloud Router e o Cloud NAT para network-a e permita a saída da Internet para VMs sem IPs públicos.

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. Crie o Cloud Router e o Cloud NAT para network-b e permita a saída da Internet para VMs sem IPs públicos.

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

Configurar regras de firewall

1. Crie regras de firewall para network-a permitir o acesso SSH do intervalo de IP do IAP. Execute os seguintes comandos gcloud no 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. Crie regras de firewall para network-b permitir o acesso SSH do intervalo de IP do IAP. Execute os seguintes comandos gcloud no Cloud Shell.

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

Criar máquinas virtuais

1. Criar VMs do Linux em 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. Criar VM do Linux em 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. Criar o detector de ameaças de DNS

Nesta seção, você realizará as seguintes tarefas:

• Crie o detector de ameaças.
• Liste o detector de ameaças.
• Descreva o recurso.

Com as VPCs, sub-redes e máquinas virtuais provisionadas, a próxima etapa é criar o detector de ameaças de DNS.

Observação:o detector de ameaças de DNS é um recurso no nível do projeto. Use a flag --excluded-networks para excluir redes VPC específicas.

1. Crie o detector de ameaças usando o comando gcloud beta network-security dns-threat-detectors create. Use a flag --excluded-networks para excluir 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. Liste o detector de ameaças para confirmar a criação.

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

3. Descreva o recurso para verificar se network-b está listado corretamente em excludedNetworks.

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

Exemplo de resposta:

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. Testar a configuração

Nesta seção, você realizará as seguintes tarefas:

• Conecte-se por SSH às VMs.
• Instale o Git nas VMs.
• Clone o repositório do simulador de detecção de ameaças da Infoblox.
• Execute o script e analise a saída gerada.

Valide a configuração gerando consultas DNS maliciosas simuladas das suas VMs. Você vai observar entradas de registro para consultas originadas de network-a, mas nenhum registro será gerado de network-b..

Observação:estas instruções são específicas para vm-a-use4. Para gerar consultas de DNS maliciosas de vm-a-usc1 e vm-b-use4, replique todas as etapas detalhadas nesta seção para cada máquina virtual respectiva.

1. Use SSH para acessar vm-a-use4. Execute os seguintes comandos gcloud no Cloud Shell.

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

2. Instale o Git na VM.

Observação:esse comando precisa ser executado na VM, não no Cloud Shell.

sudo apt-get install git -y

3. Clone o repositório do simulador de detecção de ameaças da Infoblox.

Observação:esse comando precisa ser executado na VM, não no Cloud Shell.

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

4. Mude o diretório para o diretório do simulador.

Observação:esse comando precisa ser executado na VM, não no Cloud Shell.

cd ib-threat-detection-simulator/threat_detection_simulator/

5. Execute o script e analise a saída gerada.

Observação:esse script simula várias ameaças baseadas em DNS enviando consultas a domínios maliciosos ou suspeitos conhecidos. Ele foi projetado apenas para fins de teste e demonstração.

• Essa ferramenta gera tráfego de consultas DNS executando comandos dig locais para uma lista especificada de domínios. O objetivo principal é simular atividades maliciosas de DNS.
• No modo de análise avançada padrão, ele replica ameaças em várias categorias, incluindo phishing e malware padrão, além de ameaças avançadas.
• Essas simulações avançadas envolvem consultas a domínios reais do algoritmo de geração de domínios (DGA, na sigla em inglês) associados às famílias de malware Mylobot e Suppobox, além de emular ataques de tunelamento de DNS (DNST, na sigla em inglês).

Para mais detalhes sobre o script e as ameaças que ele simula, consulte o repositório do GitHub.

Observação:esse comando precisa ser executado na VM, não no Cloud Shell.

Torne o script executável.

chmod +x run.sh

Execute o script.

./run.sh info basic

6. Exemplo de saída

A captura de tela abaixo mostra parte da saída do script de uma VM na rede-a. A saída mostra que 100% das ameaças foram detectadas.

A captura de tela abaixo mostra parte da saída do script de uma VM na rede-b. A saída mostra que 0% das ameaças foram detectadas. Isso é esperado porque "network-b" foi excluída durante a criação do detector de ameaças.

7. Saia da sessão SSH e volte ao Cloud Shell.

exit

Observação:antes de passar para a próxima seção, repita as etapas de 1 a 5 para gerar consultas DNS maliciosas de vm-a-usc1 e vm-b-use4..

6. Ver registros de ameaças na Análise de registros

Os registros de ameaças gerados podem ser visualizados no Explorador de registros após a execução do script de teste, já que são gravados no Cloud Logging.

Exemplo de entrada de registro

Esta seção fornece uma entrada de registro de amostra para uma ameaça de DNS detectada, demonstrando as informações detalhadas capturadas pelo DNS Armor, incluindo o IP de origem, o domínio consultado e a categoria de ameaça. Ele serve como referência para entender a estrutura e o conteúdo dos registros que você vai analisar.

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

Ver registros na Análise de registros

Observação:nesta seção, vamos usar o console do GCP.

1. Acesse a seção Monitoring no console do Google Cloud e selecione Logs explorer.

2. Para filtrar todos os registros de ameaças do DNS Armor, use a seguinte consulta. Isso filtra os registros com base no tipo de recurso do detector de ameaças de DNS.

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

Observação:os registros de ameaças não devem aparecer para VMs em network-b, já que essa rede foi excluída durante a criação do detector de ameaças.

3. Filtre os registros da região us-east4 e adicione um filtro para o local. Essa consulta vai mostrar apenas as ameaças detectadas na região us-east4.

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

Observação:os registros de ameaças não devem aparecer para VMs em network-b, já que essa rede foi excluída durante a criação do detector de ameaças.

4. Filtre os registros por rede de origem, com base no endereço IP de origem da consulta DNS, para ver ameaças originadas de uma rede VPC específica.

Para ver os registros de network-a (sub-redes 10.10.0.0/24 e 10.10.1.0/24):

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

Para ver os registros de network-b (sub-redes 10.20.0.0/24):

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

Observação:os registros de ameaças não devem aparecer para VMs em network-b, já que essa rede foi excluída durante a criação do detector de ameaças.

7. Limpeza

Para evitar cobranças futuras, exclua os recursos criados neste codelab. Saia do shell da VM e volte ao Cloud Shell ao executar os comandos de limpeza.

1. Exclua as 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. Exclua as regras de firewall.

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

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

3. Exclua os gateways NAT do Cloud.

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. Exclua os Cloud Routers

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. Exclua as sub-redes.

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. Exclua o detector de ameaças de DNS.

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

7. Exclua as VPCs.

gcloud compute networks delete network-a --quiet

gcloud compute networks delete network-b --quiet

8. Parabéns

Parabéns! Você configurou, implantou e testou o detector de ameaças do DNS Armor. Você ganhou experiência prática na proteção do seu ambiente do Google Cloud contra ameaças baseadas em DNS.

Neste codelab, você:

• Provisionou um ambiente de rede com várias VPCs, sub-redes e máquinas virtuais.
• Configurou a saída da Internet para VMs particulares usando o Cloud NAT.
• Implantou um detector de ameaças do DNS Armor e aprendeu a excluir redes específicas.
• Simulamos ameaças de DNS e validamos a configuração de detecção de ameaças.
• Analisou registros de ameaças na Análise de registros para identificar e entender atividades DNS maliciosas.

Qual é a próxima etapa?

Documentos de referência

• Visão geral da detecção avançada de ameaças | Cloud DNS
• Apresentamos o DNS Armor para mitigar riscos do sistema de nomes de domínio | Blog do Google Cloud
• Criar um detector de ameaças de DNS | Google Cloud