Laboratório de Varredura de Vulnerabilidades com Nessus — Azure

Ciclo de vida completo de gestão de vulnerabilidades — varrer, encontrar, corrigir, verificar — executado contra meu ambiente de laboratório Azure Active Directory ativo usando um scanner Nessus dedicado, implantado via Terraform.

O Que Este Laboratório Demonstra

Implantei uma VM de scanner Ubuntu 24.04 dedicada no meu ambiente de laboratório Azure AD existente, executei uma varredura de linha de base não autenticada e uma varredura com credenciais contra um controlador de domínio, um servidor de arquivos e um cliente ingressado no domínio, analisei os resultados, corrigi uma ocorrência de severidade Alta (CVE-2013-3900) via endurecimento de registro com PowerShell e verifiquei a correção com uma nova varredura. Este é o fluxo de trabalho completo que os programas empresariais de gestão de vulnerabilidades executam continuamente.

	Linha de Base Não Autenticada	Varredura com Credenciais
Ocorrências	35	64
Visibilidade	Apenas superfície de ataque externa — a visão do atacante	Dentro do SO — níveis de patch, configuração do registro, verificações locais
Autenticação	Falha (nos 3 hosts)	Credenciais Windows via NTLMv2, nunca enviadas em texto claro
Tempo de varredura	15 minutos	23 minutos

Esse salto nas ocorrências é todo o argumento a favor da varredura com credenciais — a ocorrência de severidade Alta CVE-2013-3900 que corrigi neste laboratório é uma verificação local que a varredura não autenticada não conseguia ver de forma alguma.

Arquitetura

Diagrama de arquitetura Scanner dedicado NESSUS01 na Subnet-Servers com caminhos de varredura com credenciais para todos os três alvos Windows. Plano de gerenciamento acessível apenas via túnel SSH a partir da estação de trabalho de administração — a porta 8834 nunca é exposta publicamente.

O scanner ingressa na VNet existente do laboratório da minha série Enterprise Azure Infrastructure Automation, implantado como uma configuração Terraform independente com seu próprio estado remoto.

Host	Função	SO	IP Privado
NESSUS01	Scanner de vulnerabilidades	Ubuntu 24.04 LTS	10.0.1.8
DC01	Controlador de domínio (lab.local)	Windows Server 2025	10.0.1.5
FS01	Servidor de arquivos	Windows Server 2025	10.0.1.6
CLIENT01	Estação de trabalho ingressada no domínio	Windows 11 Pro	10.0.1.7

Decisões de design que tomei:

VM de scanner dedicada em vez de instalar o Nessus em um alvo. Scanners empresariais são posicionados como appliances de rede independentes com linha de visão desobstruída para seus alvos — varrer a partir de um host que também é um alvo contamina os resultados.
Fontes de dados do Terraform contra a infraestrutura existente. A configuração do scanner referencia a VNet e a subnet existentes via blocos data em vez de duplicá-los, com estado isolado em sua própria chave nessus-scanner.tfstate para que o scanner possa ser criado e destruído sem tocar no estado principal do laboratório.
A interface web do Nessus (porta 8834) nunca é exposta publicamente. O NSG permite apenas SSH (22) a partir do meu IP de administração; acesso à interface através de um túnel SSH (ssh -L 8834:localhost:8834). A exposição do plano de gerenciamento é a forma número um de appliances de scanner serem comprometidos.
Apenas autenticação por chave SSH — par de chaves ed25519, sem autenticação por senha no scanner.

Fase 0 — Revisão de Segurança Pré-Voo (Pratique o Que Você Varre)

Antes de implantar qualquer coisa, auditei as regras NSG existentes — e encontrei exatamente o tipo de configuração incorreta que este laboratório existe para capturar: a regra RDP permitia origem * (qualquer IP na internet).

NSG antes do endurecimento Auditoria pré-voo: a consulta az network nsg list expõe Allow-RDP-3389 aberta para qualquer origem (*).

Restringi para o meu IP público atual antes de prosseguir:

az network nsg rule update -g RG-FileServerLab --nsg-name NSG-RDP \
  -n Allow-RDP-3389 --source-address-prefixes $(curl -s ifconfig.me)

NSG após o endurecimento A mesma regra após a correção — origem restrita a um único IP de administração.

Encontrar e corrigir uma exposição no seu próprio ambiente antes de apontar um scanner para ele é a mudança de mentalidade de "operar uma ferramenta" para "fazer segurança".

Fase 1 — Implantar o Scanner com Terraform

Cinco recursos — IP público, NSG, NIC, associação de NSG e a VM Ubuntu — implantados em menos de dois minutos:

Aplicação do Terraform terraform apply: 5 adicionados, 0 alterados, 0 destruídos. Os outputs incluem o comando SSH pronto para uso.

Em seguida, conectei via SSH e realizei a instalação headless do Nessus Essentials 10.12.1:

Sessão SSH do scanner Primeira conexão SSH ao NESSUS01 com autenticação por chave — Ubuntu 24.04 ativo em 10.0.1.8, pronto para a instalação headless do Nessus.

Fase 2 — Varredura de Linha de Base Não Autenticada

Primeira varredura: sem credenciais — é isso que um atacante no segmento de rede vê.

Configuração da varredura básica Basic Network Scan visando os três hosts: 10.0.1.5, 10.0.1.6, 10.0.1.7.

Resultados da varredura básica Resultados da linha de base: 35 ocorrências em 3 hosts, coluna Auth mostrando Falha — o Nessus não conseguiu fazer login, então cada resultado vem apenas da observação externa.

Fase 3 — Varredura com Credenciais

A varredura com credenciais é o padrão empresarial para gestão de vulnerabilidades interna. Preparei os alvos Windows habilitando o serviço Remote Registry e abrindo os grupos de regras de firewall necessários no perfil de Domínio:

Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Domain
Set-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" -Enabled True -Profile Domain

nessus-vulnerability-scanning-lab

Mais Populares