Azure上的企业漏洞管理 — Terraform部署的Nessus扫描器、凭据扫描、CVE-2013-3900修复及验证性重新扫描

发现数量的这种跳跃正是凭据扫描的全部论据——我在本实验中修复的高严重性CVE-2013-3900发现是一个本地检查，未验证扫描完全无法看到。

架构

专用NESSUS01扫描设备位于Subnet-Servers子网，具有通往所有三个Windows目标的凭据扫描路径。管理平面仅可通过来自管理工作站的SSH隧道访问——端口8834从未公开暴露。

扫描器加入了我企业Azure基础设施自动化系列中的现有实验室VNet，作为独立的Terraform配置部署，拥有自己的远程状态。

我做出的设计决策：

• 专用扫描器虚拟机，而非在目标上安装Nessus。 企业扫描器作为独立的网络设备放置，与目标之间具有无阻碍的视线——从也是目标的主机进行扫描会污染结果。
• 针对现有基础设施的Terraform数据源。 扫描器配置通过data块引用现有的VNet和子网，而非重复它们，状态隔离在自己的nessus-scanner.tfstate键下，以便可以创建和销毁扫描器而不影响核心实验室状态。
• Nessus Web UI（端口8834）从未公开暴露。 NSG仅允许来自管理IP的SSH（22）；我通过SSH隧道（ssh -L 8834:localhost:8834）访问UI。管理平面的暴露是扫描设备被攻陷的第一大原因。
• 仅SSH密钥认证——ed25519密钥对，扫描器上无密码认证。

阶段0——飞行前安全审查（实践你所扫描的内容）

在部署任何内容之前，我审计了现有的NSG规则——并发现了正是本实验室旨在捕获的那种错误配置：RDP规则允许源 *（互联网上的任何IP）。

飞行前审计：az network nsg list查询暴露了Allow-RDP-3389对任何源（*）开放。

我在继续之前将其收紧到当前公共IP：

修复后的同一规则——源限制为单个管理IP。

在你自己的环境中发现并修复一个暴露点，然后再将扫描器指向它，这是从“运行工具”到“做安全”的心态转变。

阶段1——使用Terraform部署扫描器

五个资源——公共IP、NSG、NIC、NSG关联和Ubuntu VM——在两分钟内部署完成：

terraform apply：添加5个，更改0个，销毁0个。输出包括可立即使用的SSH命令。

然后我通过SSH连接并执行了无头Nessus Essentials 10.12.1安装：

首次使用基于密钥的认证连接到NESSUS01——Ubuntu 24.04在10.0.1.8启动，准备好进行无头Nessus安装。

阶段2——未验证基线扫描

首次扫描：无凭据——这是网络段上的攻击者所能看到的。

针对所有三个目标（10.0.1.5、10.0.1.6、10.0.1.7）的基本网络扫描。

基线结果：3台主机共有35个发现，Auth列显示Fail——Nessus无法登录，因此每个结果仅来自外部观察。

阶段3——凭据扫描

凭据扫描是企业内部漏洞管理的标准。我通过启用远程注册表服务并在域配置文件中打开所需的防火墙规则组来准备Windows目标：

FS01上的目标准备——RemoteRegistry以自动启动运行，为域配置文件启用了WMI和文件与打印机共享规则。

我在扫描中配置了Windows凭据，并使用了企业所需的选项：绝不明文发送凭据，仅使用NTLMv2。

Windows凭据配置——域LAB，禁用NTLMv1，禁用明文凭据传输，为扫描启用远程注册表自动启动。

凭据结果：64个发现——与未验证基线相比，针对完全相同三台主机的发现增加了83%。

按严重性排序的发现，高严重性的WinVerifyTrust本地检查现在可见——这是未验证扫描无法检测到的发现。

阶段4——分析高严重性发现：CVE-2013-3900

插件#166555在DC01和FS01上都标记了WinVerifyTrust签名验证 (CVE-2013-3900)——CVSS v3基础评分8.8，Tenable VPR 9.0。EnableCertPaddingCheck注册表值缺失，使主机处于攻击者可以在不使已签名可执行文件的Authenticode签名失效的情况下附加恶意内容的状态。

完整发现分析：插件输出确认注册表值在10.0.1.5和10.0.1.6上缺失，解决方案部分记录了精确的修复路径。

为什么这个发现很重要：它是一个通过配置缓解的漏洞——不存在补丁，因为微软使修复成为可选。它在2026年的全新Windows Server 2025映像中缺失，而该CVE在13年前就已发布。这正是只有凭据扫描和配置管理才能捕获的那类问题。

阶段5——修复并验证

我根据插件的解决方案部分在受影响的主机上应用了修复——在64位和Wow6432Node注册表路径上设置EnableCertPaddingCheck = 1——然后在重新扫描之前验证了两个键：

已应用修复并使用Get-ItemProperty验证——两个注册表路径现在都返回EnableCertPaddingCheck : 1。

然后是最容易被跳过的步骤——验证重新扫描。直到扫描器确认发现消失，你才关闭工单：

验证扫描（历史：2）：高严重性CVE-2013-3900发现已解决。剩余最高严重性为中等。

发现 → 分析 → 修复 → 验证。循环闭合。

展示的技能

这对工作为何重要

漏洞管理在几乎每个安全运营、云安全和GRC角色中都是一项核心职能。本实验室涵盖了整个工作——不仅仅是运行扫描器，还包括安全地设计其放置位置、正确准备目标、区分结果中的信号与噪声、执行修复并证明其有效。未验证扫描与凭据扫描的对比以及验证重新扫描是将从业者与工具操作者区分开来的两件事。

评估报告

完整的专业交付物——执行摘要、方法论、详细的CVE-2013-3900发现分析、残余风险处置以及优先级建议——以PDF形式提供：

Vulnerability-Assessment-Report.pdf

Nessus Essentials不包括报告导出功能，因此此交付物是独立于扫描数据编写的——这本身就是免费版本遗漏的评估报告技能。

相关实验

本扫描器部署在我企业Azure基础设施自动化系列构建的环境中：

• 实验1——Terraform基础设施
• 实验2——Active Directory
• 实验3——NTFS文件服务器与RBAC
• 实验4-6——Azure RBAC

本仓库中不存储任何机密——扫描器仅使用SSH密钥认证，扫描凭据直接在Nessus控制台中输入，从未提交到代码中。