kingsrule50/nessus-vulnerability-scanning-lab

# Nessus 漏洞扫描实验环境 — Azure       **完整的漏洞管理生命周期 — 扫描、发现、修复、验证 — 使用由 Terraform 部署的专用 Nessus 扫描器，在我的实时 Azure Active Directory 实验环境中执行。** ## 本实验环境展示的内容 我向现有的 Azure AD 实验环境中部署了一台专用的 Ubuntu 24.04 扫描器虚拟机，针对域控服务器、文件服务器和加入域的客户端分别执行了无认证的基线扫描和凭证扫描，分析了扫描结果，通过 PowerShell 注册表加固修复了一个高危级别的发现（CVE-2013-3900），并通过重新扫描验证了修复效果。这是企业漏洞管理程序持续运行的完整工作流。 | | 无认证基线扫描 | 凭证扫描 | |---|---|---| | **发现数量** | 35 | **64** | | **可见性** | 仅限外部攻击面 — 攻击者视角 | 深入操作系统内部 — 补丁级别、注册表配置、本地检查 | | **身份验证** | 失败（全部 3 台主机） | 通过 NTLMv2 提供 Windows 凭证，绝不明文发送 | | **扫描时间** | 15 分钟 | 23 分钟 | 发现数量的激增充分证明了凭证扫描的必要性 — 我在本实验中修复的高危 CVE-2013-3900 发现是一个**本地检查**，无认证扫描根本无法发现它。 ## 架构  *Subnet-Servers 中专用的 NESSUS01 扫描器设备，具有指向所有三个 Windows 目标的凭证扫描路径。管理平面只能通过管理员工作站的 SSH 隧道访问 — 端口 8834 从不对外公开。* 扫描器加入了我 [企业级 Azure 基础设施自动化系列](https://github.com/kingsrule50/ntfs-lab-terraform) 中现有的实验 VNet，作为独立的 Terraform 配置进行部署，并拥有自己的远程状态。 | 主机 | 角色 | 操作系统 | 私有 IP | |---|---|---|---| | **NESSUS01** | 漏洞扫描器 | Ubuntu 24.04 LTS | 10.0.1.8 | | **DC01** | 域控服务器 (lab.local) | Windows Server 2025 | 10.0.1.5 | | **FS01** | 文件服务器 | Windows Server 2025 | 10.0.1.6 | | **CLIENT01** | 加入域的工作站 | Windows 11 Pro | 10.0.1.7 | **我做出的设计决策：** - **使用专用扫描器虚拟机，而不是将 Nessus 安装在目标上。** 企业级扫描器通常作为独立的网络设备部署，以确保与目标之间无障碍的视线 — 从同时也是扫描目标的主机上进行扫描会污染扫描结果。 - **针对现有基础设施使用 Terraform data source。** 扫描器配置通过 `data` 块引用现有的 VNet 和子网，而不是重写它们，并且状态隔离在其独立的 `nessus-scanner.tfstate` 密钥中，以便在不影响核心实验状态的情况下创建和销毁扫描器。 - **Nessus Web UI（端口 8834）绝不对外公开。** NSG 仅允许来自我管理员 IP 的 SSH (22) 访问；我通过 SSH 隧道访问 UI（`ssh -L 8834:localhost:8834`）。管理平面的暴露是扫描器设备被攻陷的首要原因。 - **仅限 SSH 密钥认证** — ed25519 密钥对，扫描器上无密码认证。 ## 阶段 0 — 预先安全审查（践行你所扫描的内容） 在部署任何内容之前，我审核了现有的 NSG 规则 — 结果发现了正是本实验旨在捕获的那种错误配置：RDP 规则允许**源 `*`**（互联网上的任何 IP）。  *飞行前审计：`az network nsg list` 查询显示 Allow-RDP-3389 对任何源 (`*`) 开放。* 在继续之前，我将其限制为我当前的公网 IP： ``` az network nsg rule update -g RG-FileServerLab --nsg-name NSG-RDP \ -n Allow-RDP-3389 --source-address-prefixes $(curl -s ifconfig.me) ```  *修复后的同一规则 — 源被限制为单一的管理员 IP。* 在将扫描器指向你自己的环境之前发现并修复其中的暴露风险，是从“运行工具”到“做安全”的思维转变。 ## 阶段 1 — 使用 Terraform 部署扫描器 五个资源 — 公网 IP、NSG、NIC、NSG 关联和 Ubuntu 虚拟机 — 在两分钟内部署完成：  *`terraform apply`：新增 5 个，更改 0 个，销毁 0 个。输出包含即开即用的 SSH 命令。* 然后我通过 SSH 连接，安装了 Nessus Essentials 10.12.1，并确认 `nessusd` 服务处于活动状态：  *使用密钥认证 SSH 登录 NESSUS01 — nessusd 在 Ubuntu 24.04 上处于活动运行状态。* ## 阶段 2 — 无认证基线扫描 首次扫描：无凭证 — 这是网络段上的攻击者所看到的视角。  *针对所有三台主机的基础网络扫描：10.0.1.5、10.0.1.6、10.0.1.7。*  *基线结果：3 台主机共发现 35 个漏洞，身份验证列显示失败 — Nessus 无法登录，因此所有结果仅来自于外部观察。* ## 阶段 3 — 凭证扫描 凭证扫描是企业内部漏洞管理的标准。我通过在域配置文件中启用 Remote Registry 服务并打开所需的防火墙规则组来准备了 Windows 目标： ``` 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 ```  *FS01 上的目标准备工作 — RemoteRegistry 随系统自动启动，WMI 和文件与打印机共享规则已为 Domain 配置文件启用。* 我在扫描中配置了企业要求的安全选项的 Windows 凭证：绝不以明文形式发送凭证，并仅使用 NTLMv2。  *Windows 凭证配置 — 域 LAB，已禁用 NTLMv1，已禁用明文凭证传输，为扫描启用了 Remote Registry 自动启动。*  *凭证扫描结果：发现 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 上缺少该注册表值，并在 Solution 部分记录了确切的修复路径。* 为什么这个发现很重要：它是一个**基于配置缓解**的漏洞 — 没有可用的补丁，因为微软将其修复设置为可选启用。在 2026 年全新的 Windows Server 2025 镜像中，它依然处于缺失状态，这距离该 CVE 发布已经过去了 13 年。这正是只有凭证扫描和配置管理才能发现的那类问题。 ## 阶段 5 — 修复与验证 我根据插件的 Solution 部分，在受影响的主机上应用了修复 — 在 64 位和 Wow6432Node 注册表路径下均设置了 `EnableCertPaddingCheck = 1` — 然后在重新扫描之前验证了这两个键： ``` New-Item -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null Set-ItemProperty -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" ` -Name "EnableCertPaddingCheck" -Value "1" -Type String New-Item -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null Set-ItemProperty -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" ` -Name "EnableCertPaddingCheck" -Value "1" -Type String ```  *应用并使用 `Get-ItemProperty` 验证修复 — 两个注册表路径现在都返回 EnableCertPaddingCheck : 1。* 然后是大多数人会跳过的步骤 — 验证性重新扫描。在扫描器确认漏洞已消除之前，不要关闭工单：  *验证扫描（历史记录：2）：高危的 CVE-2013-3900 发现已解决。剩余的最高严重程度为中危。* **发现 → 分析 → 修复 → 验证。闭环完成。** ## 展示的技能 | 技能 | 体现位置 | |---|---| | 漏洞管理生命周期 | 端到端：基线扫描、凭证扫描、分析、修复、验证 | | Nessus 部署与操作 | 在 Ubuntu 上使用 Essentials 10.12.1，扫描策略配置，凭证扫描 | | 安全的扫描器架构 | 专用虚拟机，仅通过 SSH 隧道访问的管理平面，基于密钥的认证，最小权限的 NSG | | 基础设施即代码 | 使用 Terraform data source 对接现有基础设施，隔离的远程状态 | | Azure 网络安全 | 通过 Azure CLI 进行 NSG 审计与加固，源 IP 限制工作流 | | Windows 加固 | 基于注册表的缓解（CVE-2013-3900），Remote Registry / WMI / 防火墙准备 | | CVSS 与风险解读 | CVSS 8.8 / VPR 9.0 分析，凭证扫描与未认证扫描可见性对比 | | PowerShell 管理 | 服务配置，防火墙规则组，带验证的注册表修复 | ## 为什么这对求职很重要 漏洞管理是几乎所有安全运营、云安全和 GRC 岗位的核心职能。本实验展示了我能够胜任整个工作流程 — 不仅仅是运行扫描器，而是安全地规划其部署位置，正确准备目标，在结果中去伪存真，执行修复并证明其有效性。无认证与凭证扫描的对比以及验证性重新扫描，正是区分真正的安全从业者与单纯工具操作员的关键所在。 ## 相关实验 该扫描器部署在我搭建的 **企业级 Azure 基础设施自动化系列** 环境中： - [实验 1 — Terraform 基础设施](https://github.com/kingsrule50/ntfs-lab-terraform) - [实验 2 — Active Directory](https://github.com/kingsrule50/ntfs-lab-ad) - [实验 3 — NTFS 文件服务器与 RBAC](https://github.com/kingsrule50/ntfs-lab-fileserver) - [实验 4–6 — Azure RBAC](https://github.com/kingsrule50/ntfs-lab-rbac) *本实验中使用的所有凭证均是在运行时从 Azure Key Vault 中获取的 — 本仓库中不存储任何密钥。*

标签：AI合规, Azure, ECS, GPT, Nessus, Terraform, USENIX Security 2025, 安全合规, 插件系统, 漏洞管理, 网络代理, 自动化运维