Dane139/nessus-home-lab

# Nessus 漏洞扫描与修复 **第 1 部分（共 2 部分）：本地手动部署** *本项目涵盖了漏洞管理的基础机制。如需了解我是如何运用这些概念，并使用 Infrastructure as Code 在云端完全自动化部署 Nessus 扫描器的，请查看* [通过 Terraform 在 Azure 中自动化部署 Nessus](https://github.com/Dane139/Azure-nessus-lab) ### 目标 在 Azure 中自动化部署安全基础设施之前，我希望先深入了解操作系统级别漏洞扫描的核心机制。本次实验的目标是部署一台 Nessus 扫描器，针对 Windows Server 2025 实例分别运行未经身份验证和经过身份验证的扫描，并通过 PowerShell 和注册表编辑系统性地修复已发现的安全漏洞。 ### 环境与工具 - **漏洞扫描器：** Nessus Essentials（通过 Tenable 学术项目升级至 Nessus Essentials Plus） - **目标系统：** Windows Server 2025 Datacenter (DC01) - **网络设置：** 本地虚拟机环境 - **脚本/自动化：** PowerShell ## 步骤 1：未经身份验证的发现扫描 为了建立基线，我在未提供任何凭证的情况下对目标 Windows Server 运行了基本的网络扫描。这模拟了外部攻击者的视角，在任何身份验证发生之前映射出暴露的端口和服务。  ## 步骤 2：经过身份验证的（带凭证）扫描设置 带凭证的扫描能够提供真正的可视化能力。通过向目标系统进行身份验证，Nessus 可以从内到外对其进行检查，从而发现缺失的操作系统补丁、软件漏洞以及注册表配置错误。 为了使 Nessus 能够成功进行身份验证并扫描 Windows Server，我必须启用 `RemoteRegistry` 服务并配置 Windows 防火墙以允许传入的 SMB 流量（端口 445）。我通过执行以下 PowerShell 命令实现了这一点：

查看防火墙与注册表设置脚本

``` # 在 Windows Server 上通过 PowerShell 运行： Set-Service -Name RemoteRegistry -StartupType Automatic Start-Service RemoteRegistry # 确保 Windows 防火墙允许 Nessus 访问： netsh advfirewall firewall add rule name='Nessus' dir=in action=allow protocol=tcp localport=445 ```

 ## 步骤 3：系统修复 在查看了带凭证的扫描结果后，发现的主要问题是缺失操作系统级别的安全更新以及一项特定的高严重性注册表配置错误。 ### 1. 通过编程方式修补操作系统漏洞 我没有在 Windows GUI 中点击操作，而是使用了 `PSWindowsUpdate` 模块，强制系统通过 CLI 获取、接受并安装所有待处理的 Windows 安全更新。

查看 PSWindowsUpdate 脚本

``` # 安装通过 CLI 管理更新的模块 Install-Module PSWindowsUpdate -Force # 获取、接受并安装所有挂起的更新 Get-WindowsUpdate -Install -AcceptAll ```

 ### 2. 修复 CVE-2013-3900 (CVSS 8.8) 扫描还标记了一个与 WinVerifyTrust 签名验证相关的高严重性漏洞。为了清除此发现，我遵循了 Microsoft 官方的 MSRC 更新指南，并应用了建议的注册表更改，以启用更严格的 Authenticode 签名验证。 我创建并执行了包含以下配置的 `.reg` 文件：

查看注册表修复文件

``` Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"=dword:1 [HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config] "EnableCertPaddingCheck"=dword:1 ```

  ## 步骤 4：验证（重新扫描） 漏洞管理生命周期中最关键的步骤是验证。在应用了操作系统级别的补丁并重新启动服务器之后，我运行了一次验证扫描。 虽然最初的操作系统补丁成功清除了大部分严重和高危漏洞，但随后的重新扫描显示，一些应用程序级别的漏洞仍然存在——特别是与 Microsoft Edge 浏览器相关的漏洞 (CVE-2026-6919)。 在推送了 Edge 的应用程序更新后，我运行了最后一次带凭证的扫描。系统返回了干净的结果摘要，仅显示 **信息级别** 的发现，这证实了整体系统风险的大幅降低。  ## 故障排除与经验总结 - **操作系统补丁与应用程序补丁：** 本次实验进一步证实，运行 Windows Update 并不是万能的。您必须积极管理第三方和应用程序级别的补丁（例如基于 Chromium 的浏览器），才能真正保护主机的安全。 - **“编译插件”陷阱：** 在应用新的许可证后，Nessus 的 Web 界面卡在了“编译插件”界面。我付出了惨痛的代价才学到，Nessus 在更新期间会下载并索引一个庞大的插件数据库，这很容易耗费 10 到 30 分钟。您只能耐心等待它运行完成。 - **CLI 与 Web UI 同步问题：** 我原以为在插件冻结期间我的许可证升级失败了，于是进入 CLI 强制注册（`.\nessuscli.exe fetch --register [CODE]`）。结果抛出了 `HTTP/1.1 400 Bad Request` 错误。我意识到发生这种情况是因为许可证实际上片刻前已在 Web UI 中成功处理，在 Web 服务器来得及同步之前就将该代码标记为了“已使用”。 - **报告功能的许可障碍：** Tenable 将高级报告功能锁定在更高级别的版本中。我利用 Tenable 学术项目将我的免费版升级到了 Nessus Essentials Plus，这使我能生成非常详细的 HTML 格式的“按主机列出的漏洞”报告，而不仅仅是查看基本的面板概览。

标签：AI合规, BlazeGraph, CVE修复, GPT, IPv6, Nessus, OpenCanary, PB级数据处理, PowerShell, PSWindowsUpdate, RemoteRegistry, SMB, Tenable, Windows Server 2025, 子域名枚举, 安全合规, 安全基线, 安全实验, 安全运维, 教学环境, 数据包嗅探, 注册表编辑, 漏洞修复, 漏洞管理, 端口445, 系统安全, 网络代理, 网络安全, 网络安全培训, 身份认证扫描, 错误配置检测, 隐私保护, 靶场环境