Laboratorio de Escaneo de Vulnerabilidades con Nessus — Azure

Ciclo completo de gestión de vulnerabilidades: escanear, encontrar, corregir, verificar — ejecutado contra mi entorno de laboratorio de Azure Active Directory en vivo usando un escáner Nessus dedicado desplegado con Terraform.

Qué Demuestra Este Laboratorio

Desplegué una máquina virtual escáner Ubuntu 24.04 dedicada en mi entorno de laboratorio de Azure AD existente, ejecuté un escaneo de línea base no autenticado y un escaneo con credenciales contra un controlador de dominio, un servidor de archivos y un cliente unido al dominio, analicé los resultados, remedié un hallazgo de gravedad Alta (CVE-2013-3900) mediante el endurecimiento del registro con PowerShell, y verifiqué la corrección con un nuevo escaneo. Este es el flujo de trabajo completo que los programas empresariales de gestión de vulnerabilidades ejecutan continuamente.

	Línea Base Sin Autenticar	Escaneo con Credenciales
Hallazgos	35	64
Visibilidad	Solo superficie de ataque externa — la vista del atacante	Dentro del SO — niveles de parches, configuración del registro, comprobaciones locales
Autenticación	Fallo (los 3 hosts)	Credenciales de Windows mediante NTLMv2, nunca enviadas en texto claro
Tiempo de escaneo	15 minutos	23 minutos

Ese salto en los hallazgos es el argumento completo para el escaneo con credenciales: el hallazgo de gravedad Alta CVE-2013-3900 que remedié en este laboratorio es una comprobación local que el escaneo sin autenticar no pudo ver en absoluto.

Arquitectura

Architecture diagram Aparato escáner NESSUS01 dedicado en Subnet-Servidores con rutas de escaneo con credenciales a los tres objetivos Windows. El plano de gestión solo se puede alcanzar mediante túnel SSH desde la estación de trabajo de administración — el puerto 8834 nunca se expone públicamente.

El escáner se une a la VNet de laboratorio existente de mi serie de Automatización de Infraestructura Azure Empresarial, desplegado como una configuración independiente de Terraform con su propio estado remoto.

Host	Función	SO	IP Privada
NESSUS01	Escáner de vulnerabilidades	Ubuntu 24.04 LTS	10.0.1.8
DC01	Controlador de dominio (lab.local)	Windows Server 2025	10.0.1.5
FS01	Servidor de archivos	Windows Server 2025	10.0.1.6
CLIENT01	Estación de trabajo unida al dominio	Windows 11 Pro	10.0.1.7

Decisiones de diseño que tomé:

Máquina virtual escáner dedicada en lugar de instalar Nessus en un objetivo. Los escáneres empresariales se colocan como dispositivos de red independientes con línea de visión despejada hacia sus objetivos: escanear desde un host que también es un objetivo contamina los resultados.
Fuentes de datos de Terraform contra infraestructura existente. La configuración del escáner referencia la VNet y subred existentes mediante bloques data en lugar de duplicarlos, con el estado aislado en su propia clave nessus-scanner.tfstate para que el escáner pueda crearse y destruirse sin tocar el estado central del laboratorio.
La interfaz web de Nessus (puerto 8834) nunca se expone públicamente. El NSG solo permite SSH (22) desde mi IP de administración; accedo a la interfaz a través de un túnel SSH (ssh -L 8834:localhost:8834). La exposición del plano de gestión es la forma número uno en que los dispositivos escáner se ven comprometidos.
Autenticación solo por clave SSH — par de claves ed25519, sin autenticación por contraseña en el escáner.

Fase 0 — Revisión de Seguridad Previa al Vuelo (Practica lo que Escaneas)

Antes de desplegar cualquier cosa, audité las reglas NSG existentes — y encontré exactamente el tipo de configuración incorrecta que este laboratorio existe para detectar: la regla RDP permitía origen * (cualquier IP en internet).

NSG before hardening Auditoría previa al vuelo: la consulta az network nsg list expone Allow-RDP-3389 abierta a cualquier origen (*).

Lo ajusté a mi IP pública actual antes de proceder:

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

NSG after hardening La misma regla después de la remediación: origen restringido a una sola IP de administración.

Encontrar y corregir una exposición en tu propio entorno antes de apuntar un escáner hacia ella es el cambio de mentalidad de "ejecutar una herramienta" a "hacer seguridad".

Fase 1 — Desplegar el Escáner con Terraform

Cinco recursos — IP pública, NSG, NIC, asociación NSG y la máquina virtual Ubuntu — desplegados en menos de dos minutos:

terraform apply: 5 añadidos, 0 cambiados, 0 destruidos. Las salidas incluyen el comando SSH listo para usar.

Luego me conecté por SSH y realicé la instalación sin interfaz gráfica de Nessus Essentials 10.12.1:

Scanner SSH session Primera conexión SSH a NESSUS01 con autenticación basada en clave — Ubuntu 24.04 activo en 10.0.1.8, listo para la instalación sin interfaz de Nessus.

Fase 2 — Escaneo de Línea Base Sin Autenticar

Primer escaneo: sin credenciales — esto es lo que un atacante en el segmento de red ve.

Basic scan configuration Escaneo de Red Básico dirigido a los tres hosts: 10.0.1.5, 10.0.1.6, 10.0.1.7.

Basic scan results Resultados de línea base: 35 hallazgos en 3 hosts, columna Auth mostrando Fail — Nessus no pudo iniciar sesión, por lo que cada resultado proviene solo de observación externa.

Fase 3 — Escaneo con Credenciales

El escaneo con credenciales es el estándar empresarial para la gestión interna de vulnerabilidades. Preparé los objetivos Windows habilitando el servicio de Registro Remoto y abriendo los grupos de reglas de firewall requeridos en el perfil de Dominio:

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

Más Populares