nessus-vulnerability-scanning-lab

Gestão de vulnerabilidades empresarial no Azure — scanner Nessus implantado via Terraform, varredura autenticada, remediação da CVE-2013-3900 com re-varredura verificada

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

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.

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

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:

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:

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:

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

Basic Network Scan visando os três hosts: 10.0.1.5, 10.0.1.6, 10.0.1.7.

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:

Preparação do alvo no FS01 — RemoteRegistry em execução com inicialização Automática, regras WMI e File & Printer Sharing habilitadas para o perfil de Domínio.

Configurei credenciais Windows na varredura com as opções de segurança que as empresas exigem: nunca enviar credenciais em texto claro e apenas NTLMv2.

Configuração de credenciais Windows — domínio LAB, NTLMv1 desabilitado, transmissão de credenciais em texto claro desabilitada, inicialização automática do Remote Registry habilitada para a varredura.

Resultados com credenciais: 64 ocorrências — um aumento de 83% em relação à linha de base não autenticada contra exatamente os mesmos três hosts.

Ocorrências ordenadas por severidade, com a verificação local de alta severidade WinVerifyTrust agora visível — uma ocorrência que a varredura não autenticada não tinha como detectar.

Fase 4 — Analisar a Ocorrência Alta: CVE-2013-3900

O plugin #166555 sinalizou WinVerifyTrust Signature Validation (CVE-2013-3900) no DC01 e no FS01 — pontuação base CVSS v3 8.8, VPR 9.0 da Tenable. O valor de registro EnableCertPaddingCheck estava ausente, deixando os hosts em um estado onde um atacante poderia anexar conteúdo malicioso a um executável assinado sem invalidar sua assinatura Authenticode.

Análise completa da ocorrência: a saída do plugin confirma que o valor de registro está ausente em 10.0.1.5 e 10.0.1.6, com o caminho exato de correção documentado na seção Solution.

Por que esta ocorrência importa: é uma vulnerabilidade de mitigação por configuração — não existe patch porque a Microsoft tornou a correção opcional. Ela veio ausente em imagens novas do Windows Server 2025 em 2026, treze anos após a publicação do CVE. Esta é exatamente a classe de problema que apenas a varredura com credenciais e a gestão de configuração capturam.

Fase 5 — Corrigir e Verificar

Apliquei a correção nos hosts afetados conforme a seção Solution do plugin — definindo EnableCertPaddingCheck = 1 nos caminhos de registro de 64 bits e Wow6432Node — e verifiquei ambas as chaves antes de executar nova varredura:

Correção aplicada e verificada com Get-ItemProperty — ambos os caminhos de registro agora retornam EnableCertPaddingCheck : 1.

Depois, a etapa que a maioria das pessoas pula — a nova varredura de verificação. Você não encerra o chamado até o scanner confirmar que a ocorrência desapareceu:

Varredura de verificação (History: 2): a ocorrência de severidade Alta CVE-2013-3900 está resolvida. A maior severidade restante é Média.

Encontrar → analisar → corrigir → verificar. Ciclo fechado.

Habilidades Demonstradas

Por Que Isso Importa para o Trabalho

A gestão de vulnerabilidades é uma função central em praticamente todas as funções de operações de segurança, segurança em nuvem e GRC. Este laboratório cobre o trabalho completo — não apenas operar um scanner, mas arquitetar sua implantação com segurança, preparar alvos corretamente, distinguir sinal de ruído nos resultados, executar uma correção e comprovar que funcionou. A comparação entre varredura sem e com credenciais e a nova varredura de verificação são as duas coisas que separam profissionais de operadores de ferramentas.

Relatório de Avaliação

O entregável profissional completo — resumo executivo, metodologia, análise detalhada da ocorrência CVE-2013-3900, disposição de risco residual e recomendações priorizadas — está disponível em PDF:

Vulnerability-Assessment-Report.pdf

O Nessus Essentials não inclui exportação de relatórios, então este entregável foi elaborado de forma independente a partir dos dados da varredura — o que é, por si só, a habilidade de elaboração de relatórios de avaliação que o nível gratuito exclui.

Laboratórios Relacionados

Este scanner é implantado no ambiente construído pela minha série Enterprise Azure Infrastructure Automation:

• Lab 1 — Terraform Infrastructure
• Lab 2 — Active Directory
• Lab 3 — NTFS File Server & RBAC
• Labs 4–6 — Azure RBAC

Nenhum segredo é armazenado neste repositório — o scanner usa apenas autenticação por chave SSH, e as credenciais de varredura foram inseridas diretamente no console do Nessus, nunca commitadas no código.