augustopedra1978/home-lab-cybersecurity

# 🛡️ 网络安全家庭实验室 — Wazuh SIEM/XDR、CIS Hardening 及多 SIEM 集成         ## 📋 目录 1. [项目概述](#1-visão-geral-do-projeto) 2. [家庭实验室架构](#2-arquitetura-do-home-lab) 3. [阶段 1 — 基础：安装 Wazuh](#3-fase-1--fundação-instalação-do-wazuh) 4. [阶段 2 — CIS Benchmark Hardening (24% → 87%)](#4-fase-2--hardening-cis-benchmark-24--87) 5. [阶段 3 — 磁盘加密](#5-fase-3--criptografia-de-disco-bitlocker) 6. [阶段 4 — 多 SIEM 集成 (Splunk, Sysmon, Suricata)](#6-fase-4--integrações-multi-siem-splunk-sysmon-suricata) 7. [阶段 5 — 安全远程访问](#7-fase-5--acesso-remoto-seguro) 8. [阶段 6 — Hardening 后审计](#8-fase-6--auditoria-pós-hardening) 9. [家庭网络 Hardening](#9-hardening-de-rede-doméstica) 10. [漏洞管理 — CVE-2026-43503 案例](#10-gestão-de-vulnerabilidades--caso-cve-2026-43503) 11. [经验教训与 notable 根本原因](#11-lições-aprendidas-e-causas-raiz-notáveis) 12. [展现的技术能力](#12-competências-técnicas-demonstradas) 13. [已知局限与路线图](#13-limitações-conhecidas-e-roadmap) ## 1. 项目概述 本项目记录了网络安全家庭实验室的构建、运行和持续 hardening 过程，重点关注： - 在虚拟化环境中部署和运行 SIEM/XDR (Wazuh) - 根据 **CIS Benchmark v3.0.0** 对 Windows 11 endpoint 进行 hardening，将合规分数从 **24% 提升至 87%** - 使用 TPM+PIN (BitLocker) 进行全盘加密 - 将三个安全数据源 (Sysmon, Suricata, Wazuh 原生) 与二级 SIEM (Splunk) 集成 - 配置安全的远程访问，无需向互联网暴露端口 - 持续审计 hardening 对系统实际可用性的副作用 - 严格记录每个技术事件的根本原因，并在进行任何修复之前进行实证验证 ### 技术栈 | 组件 | 版本 | 功能 | |---|---|---| | Oracle VirtualBox | 7.2.8 | Windows 宿主机上的 Hypervisor | | Ubuntu Server | 24.04.4 LTS | Wazuh 服务器操作系统 | | Wazuh Indexer | 4.14.5 | 搜索引擎 (OpenSearch) | | Wazuh Manager | 4.14.5 | 分析与关联引擎 (OSSEC) | | Wazuh Dashboard | 4.14.5 | Web 可视化界面 | | Filebeat OSS | 7.10.2 | Pipeline Manager → Indexer | | Wazuh Agent | 4.14.5 | Windows endpoint 数据采集 | | Sysmon | 15.21 | 深度进程/注册表遥测 (SwiftOnSecurity config) | | Suricata | 8.0.6 | 网络 IDS (Emerging Threats Open ruleset) | | Splunk Enterprise / Universal Forwarder | 10.x / 10.4.1 | 二级 SIEM 及转发 pipeline | | Tailscale | 1.98.8 | 用于远程访问的 mesh VPN (WireGuard) | | BitLocker | Windows 11 Pro 原生 | 磁盘加密 (TPM+PIN) | ## 2. 家庭实验室架构 ``` ┌───────────────────────────────────────────────────────────────────┐ │ REDE DOMÉSTICA (exemplo) │ │ 192.168.0.0/24 │ │ │ │ ┌────────────────────────────────────┐ ┌──────────────────────┐│ │ │ NOTEBOOK WINDOWS 11 PRO │ │ VM UBUNTU SERVER ││ │ │ (IP fixo reservado por MAC) │ │ (IP fixo por MAC) ││ │ │ │ │ ││ │ │ ┌───────────────┐ │ │ ┌────────────────┐ ││ │ │ │ Wazuh Agent │──── TCP 1514 ───┼───┼─▶│ Wazuh Manager │ ││ │ │ │ Sysmon 15.21 │ │ │ ├────────────────┤ ││ │ │ │ Suricata 8.0.6│ │ │ │ Wazuh Indexer │ ││ │ │ ├───────────────┤ │ │ │ (OpenSearch) │ ││ │ │ │ Splunk │◀── NAT 10.0.3.x┼───┼──┤ Filebeat │ ││ │ │ │ Enterprise │ (Universal │ │ ├────────────────┤ ││ │ │ │ (porta 9997) │ Forwarder) │ │ │Wazuh Dashboard │ ││ │ │ ├───────────────┤ │ │ │ (porta 443) │ ││ │ │ │ BitLocker │ │ └──┴────────────────┘ ││ │ │ │ (TPM + PIN) │ NIC1: Bridge (LAN) ─┘ ││ │ │ ├───────────────┤ NIC2: NAT (10.0.3.x, host-only interno)││ │ │ │ Tailscale │ ││ │ │ │ (VPN mesh) │ ││ │ │ └───────────────┘ ││ │ └────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ ROTEADOR — DHCP + NextDNS (DoH/DoT) + WPA2/WPA3 │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ Outros dispositivos: Smart TV, smartphones, smartwatch, │ │ notebook secundário, desktop — todos com NextDNS configurado │ └───────────────────────────────────────────────────────────────────┘ ``` ### 架构决策 | 决策 | 理由 | |---|---| | 虚拟机使用 **Bridge** 模式 (非 NAT/Host-Only) | 允许在 LAN 上进行 agent↔manager 直接通信，无需额外的 NAT 层 | | 虚拟机配置 **第二块 NAT 模式网卡** | 规避 VirtualBox 的一个实际限制 (基于 Wi-Fi 的 Bridge 下的 VM→host 流量不稳定) — 专门用于 VM→Splunk 通信及 Dashboard 的端口转发 | | 路由器上通过 MAC binding 设定 **固定 IP** (虚拟机和笔记本) | 防止 DHCP 续约导致连接中断，并确保安全日志随时间推移具备持续的可追溯性 | | 路由器上通过 DHCP 配置 **NextDNS** | 为整个网络提供 DNS 过滤，无需逐个设备进行配置 | | **Splunk 作为二级 SIEM**，通过 Wazuh 的 `alerts.json` 供给 | 避免重复摄入 (Sysmon/Suricata 的原始数据不直接发送给 Splunk — 而是先经过 Wazuh 的分析和富化) | ## 3. 阶段 1 — 基础：安装 Wazuh ### 3.1 第一次尝试 — 立即失败 ``` curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh && sudo bash ./wazuh-install.sh -a # 错误: bash: ./wazuh-install.sh: No such file or directory ``` **原因：** 版本 URL 错误导致 `curl` 将脚本内容直接输出到屏幕，而不是将其保存为文件。 ### 3.2 严重问题 — IPv6 导致的无提示超时 **症状：** 官方脚本在 `Starting Wazuh indexer installation` 步骤无限期卡住，长达数小时没有任何错误提示。 **诊断：** ``` ps aux | grep apt # root 2673 apt-get install wazuh-indexer=4.14.5-* -y -q (卡住数小时) wget https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-indexer/wazuh-indexer_4.14.5-1_amd64.deb # Connecting to packages.wazuh.com|2600:9000:...|:443... failed: Connection timed out wget -4 https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-indexer/wazuh-indexer_4.14.5-1_amd64.deb # Connecting to packages.wazuh.com|13.227.207.4|:443... connected. 200 OK ``` **确认的根本原因：** 服务器 `packages.wazuh.com` (托管于 CloudFront) 返回 IPv6 地址作为首选连接方式。所使用的 GPON 光纤网络无法正确将 IPv6 路由到该特定服务器，从而导致无提示超时 — 这被官方脚本内部使用的 `apt-get` 的 `-q` (静默) 标志所掩盖。 **采用的解决方案：** 通过 Windows 浏览器下载 `.deb` 包 (原生 IPv4，实测约 350 Mbps)，并通过 VirtualBox 共享文件夹 / SCP 传输到虚拟机 — 将传输时间从数小时 (超时) 缩短至几秒钟。 ### 3.3 问题 — 缺少 TLS 证书 **症状：** 通过 `dpkg` 手动安装后，`wazuh-indexer.service` 无法启动 (`exit code 1`, `OpenSearchException`)。 **原因：** 手动安装 (逐个安装包) 不会自动生成向导式官方脚本所创建的 TLS 证书。 **解决方案：** ``` curl -sO https://packages.wazuh.com/4.9/wazuh-certs-tool.sh chmod +x wazuh-certs-tool.sh sudo bash wazuh-certs-tool.sh -A sudo /usr/share/wazuh-indexer/bin/indexer-security-init.sh ``` ### 3.4 本阶段解决的其他问题 | 问题 | 原因 | 解决方案 | |---|---|---| | `unattended-upgrades` 阻塞 APT | Ubuntu 的自动更新服务竞争 APT lock | `systemctl disable/stop unattended-upgrades` | | SSH 无法访问 | 服务已安装但未激活 (`inactive (dead)`) | `systemctl enable --now ssh` | | 虚拟机键盘特殊字符输入异常 | `us` 布局无法持久化应用 ABNT2 | 完全从 Windows 使用 SSH，消除对图形控制台的依赖 | | 使用通配符的 `chmod` 失败 (`cannot access '*'`) | 顺序错误 — 先限制了目录 (500) 后限制了文件 | 在对目录执行 `chmod 500` **之前**，先对文件应用 `chmod 400` | ### 3.5 阶段 1 最终结果 | 组件 | 状态 | |---|---| | wazuh-indexer 4.14.5 | ✅ active (running) | | wazuh-manager 4.14.5 | ✅ active (running) | | wazuh-dashboard 4.14.5 | ✅ active (running) | | filebeat 7.10.2 | ✅ 已安装并验证 | | Windows Agent 4.14.5 | ✅ 活跃，ID 001 | **本阶段投入的总时间：** 约 40 小时，主要耗费在诊断 IPv6 问题上 — Wazuh 官方未针对此网络场景提供相关文档说明。 ## 4. 阶段 2 — CIS Benchmark Hardening (47% → 87%) 系统化应用 **CIS Microsoft Windows 11 Enterprise Benchmark v3.0.0** (共 482 项控制措施)，分为 6 个实施波次，每次执行前均进行风险筛选。 ### 4.2 分数演进 | 步骤 | 分数 | 应用的控制措施 | |---|---|---| | 基线 (Windows 11 Home，通过注册表手动 hardening) | 24% | — | | 基线 (升级到 Pro 之后，波次应用之前) | 47% (227/482) | — | | 波次 1 — 审计策略 | 47%* | 27 | | 波次 2 — 安全选项 | 48% | 5 | | 波次 3 — 服务和防火墙 | 49% | 3 | | 波次 4 — 管理模板 | 65% | 79 | | 波次 5 — VBS / Credential Guard / BitLocker (策略) / App Guard | 86% | 99 | | 波次 6 — Sandbox / Preview Builds | **87%** | 4 | \* *波次 1 已正确应用 (通过 `auditpol /get` 手动验证)，但并未反映在 Dashboard 的可见分数中 — 见第 11.2 节 (根本原因：扫描器语言不兼容)。* ### 4.2 应用过程中发现并修复的脚本 Bug 每个波次都涉及根据 Wazuh SCA 自身导出的 CSV 生成自动化 PowerShell 脚本。这暴露了实际的工程 Bug，所有 Bug 均已记录并修复： | Bug | 波次 | 原因 | 修复 | |---|---|---|---| | 路径替换错误 (`HKLM:_LOCAL_MACHINE\...`) | 4 和 5 | 使用了字符串切片 (`path[4:]`) 而非直接替换 (`.replace()`) | 统一使用 `.replace('HKEY_LOCAL_MACHINE', 'HKLM:')` | | 多值控制只应用了所需 5 个值中的 1 个 | 4 | Parser 每条规则只获取了最后一个注册表值，而非全部 | 重写 Parser 以捕获每个控件的所有名称/值对 | | 具有相同 CIS ID 的两个控件之间出现“手动值”冲突 | 4 | 以 CIS ID 为索引的 overrides 字典，但两个不同的控件共用了同一个 ID | overrides 改为以 (CIS ID + 值名称) 为索引，而不仅是 CIS ID | | "Hardened UNC Paths" 格式错误 | 4 | 缺少 Wazuh regex 预期值中的逗号后空格 | 调整为精确的格式 | | Attack Surface Reduction 仅应用了 11 条必需规则中的 1 条 | 4 | 控件范围界定不足 | 应用了包含全部 11 个 ASR 规则 GUID 的完整列表 | ### 4.3 记录在案的例外情况 (已评估并接受风险) | 类别 | 控件 | 理由 | |---|---|---| | 登录 / Microsoft 账户 | 3 | 历史记录事件确认存在被锁定风险 (需通过 Windows 恢复环境进行恢复) | | 睡眠 / 休眠 / 屏幕超时 | 2 | 同样的风险模式 — 历史上每约 1 分钟就会被锁定一次的事件 | | Bluetooth Support Service / Print Spooler | 2 | 确认正在使用 (蓝牙外设和打印) | | RDP (7 项高风险配置) | 7 | 用户正在积极使用 RDP (客户端和服务器) | | Apps / Microsoft Store | 8 | 确认使用了 Store 和 App Installer | | BitLocker — 拒绝写入未加密的可移动驱动器 | 2 | 确认使用了未加密的 U 盘/外置硬盘 | | 按 ID/类别的设备安装限制 | 6 | 需要组织定义的批准设备列表 — 没有适用于家庭环境的通用安全默认值；使用模式几乎涵盖了所有可限制的设备类别 | | Application Guard | 6 | 依赖未启用的可选硬件/功能 | | 审计 (第 17 节，27 项控件) | 27 | 因扫描器语言不兼容而受阻 — 见第 11.2 节 | ### 4.4 Hyper-V 无回归测试 在应用波次 5 (启用 Virtualization Based Security) 之前，鉴于公开报告称这些版本组合存在不稳定性，针对 VirtualBox 7.2.8 和 Windows 原生 Hyper-V 之间进行了正式的兼容测试。 **协议：** 1. 在进行任何更改之前对虚拟机进行完整快照 2. 通过 `optionalfeatures` 启用 Hyper-V 3. 重启宿主机 4. 验证：虚拟机启动、Wazuh 服务完整性、网络连通性 (0% 丢包)、Windows agent 状态 **结果：** ✅ 通过 — 所有服务运行正常，网络或功能无回归。 ## 5. 阶段 3 — 磁盘加密 ### 5.1 配置 - 认证模式：**TPM + PIN** (通过 hardening 波次 5 中应用的策略强制要求) - 加密范围：**整个驱动器** (微软对于已投入使用的系统的官方建议，而非“仅限已用空间”) - 恢复密钥备份：Microsoft 账户 + 本地文件 (双重冗余) ### 5.2 事件 — 因 Active Directory 要求导致受阻 **症状：** `"BitLocker 无法联系域。请检查您是否已连接到网络..."` **根本原因：** CIS 控件 `OSRequireActiveDirectoryBackup = 1` (在波次 5 中应用) 要求在允许激活系统盘的 BitLocker **之前**，必须将恢复密钥存储在 Active Directory 中。在没有加入域的机器上，这个要求永远无法满足 — 设计上造成了永久性的死锁。 **解决方案：** ``` Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Name "OSRequireActiveDirectoryBackup" -Value 0 gpupdate /force ``` **记录在案的决策：** 评估了仅为满足此控件而将笔记本加入 Active Directory 域的方案 — 因比例失调而被否决 (为了满足单一策略，需要一台专用的、永久运行的 Domain Controller)。建议将其作为未来独立的实验室项目，而不是解决此阻塞的方法。 ### 5.3 结果 - 全盘加密 (约 932 GB) 完成，耗时大大低于最初估计，得益于处理器 AES-NI 硬件加速 - 实际验证：在随后的启动中，在登录屏幕之前正确提示输入 PIN ## 6. 阶段 4 — 多 SIEM 集成 (Splunk, Sysmon, Suricata) ### 6.1 集成架构 (级联，无重复) ``` [ Sysmon ] ──┐ ├──▶ [ Agente Wazuh ] ──▶ [ Wazuh Manager ] ──▶ [ Splunk ] [ Suricata ] ──┘ ``` 刻意的架构决策：Sysmon 和 Suricata **不**直接将数据发送给 Splunk。两者均由 Wazuh agent 收集，经 Manager 处理/富化 (关联、MITRE ATT&CK、严重性分类)，随后才通过单一通道 (`alerts.json`) 转发给 Splunk — 避免了重复摄取并节省了宿主机资源。 ### 6.2 Splunk — Universal Forwarder **集成方法：** 在 Wazuh 服务器 (VM) 上安装 Splunk Universal Forwarder，监控 `/var/ossec/logs/alerts/alerts.json` 并转发给 Windows 宿主机上的 Splunk Enterprise。 **配置过程中的事件：** | 事件 | 原因 | 解决方案 | |---|---|---| | Splunk 许可证过期 | 60天的 Enterprise 试用期满 | 迁移至 **Splunk Free** 许可证 (永久免费，500 MB/天 — 适用于实验室规模) | | 即使完全关闭防火墙，接收端口上仍持续出现 `ERR_CONNECTION_REFUSED` | **VirtualBox 网络限制**：通过 Wi-Fi 上的 Bridge 网卡进行的 VM→host 流量无法正确完成 ( “hairpin”问题) | 给虚拟机添加**第二块 NAT 模式网卡** — VirtualBox 为宿主机提供了一个固定且可靠的内部网关，绕过了 Bridge 的限制 | **排除原因的过程** (出于方法论的严谨性而记录)：测试特定防火墙规则 → 测试无限制的宽泛规则 → 纠正网络配置文件 (公共/专用) → 完全禁用防火墙进行测试 → **仍然失败** → 确认原因是结构性的 (Bridge/Wi-Fi)，而非配置问题 — 最终通过 NAT 解决。 ### 6.3 Sysmon - 版本 15.21，采用社区基准配置 - 配置 Wazuh agent 读取 `Microsoft-Windows-Sysmon/Operational` 通道 **事件：** `` 块被插入到 agent 配置文件中 `` 开始标签**之前** — XML 元素超出了根文档范围，导致 `Invalid element` 错误并使 agent 服务彻底崩溃 (`No client configured. Exiting`)。通过将块重新定位到根元素内部得到了修复。 ### 6.4 Suricata - 版本 8.0.6，Npcap 采用与 WinPcap 兼容的模式 - 安装在不带空格的目录 (`C:\Suricata`) 中，以避免默认安装文件夹路径包含空格的已知 bug - Ruleset：Emerging Threats Open (78 个规则文件，加载了约 41,000 个特征签名) **事件与修复：** | 事件 | 原因 | 解决方案 | |---|---|---| | 对默认安装目录的硬编码路径有多个引用 | 无论选择何种安装目录，安装程序都会在 `suricata.yaml` 的 9 个位置写入 `C:\Program Files\Suricata\` | 批量替换所有出现的地方 | | 9 个特征签名的解析错误 (`unknown rule keyword 'file.magic'`) | 适用于 Windows 的 Suricata 构建版本不支持 `libmagic` | 按 SID 逐一禁用受影响的 9 个特征签名 | | Wazuh Manager 中出现 `Too many fields for JSON decoder` | Suricata 的 `eve.json` 中的 `stats` 类型事件超出了 Wazuh JSON 解码器的字段限制 | 在 Suricata 的输出配置 (`eve-log`) 中禁用 `stats` 事件类型 — 保留 `alert`, `flow`, `dns`, `http`, `tls` | **可见性范围 (自觉认知到的)：** 安装在 endpoint 本身的 Suricata 只能看到进出该主机的流量 — 而非整个家庭网络。要实现完整的网络可见性，需要额外的硬件 (在可网管交换机上进行 Port Mirroring/SPAN，或专用的网关虚拟机)。就本实验室的目的而言 (保护 endpoint 和学习)，此范围被认为是合适的，并且在教学上更胜一筹 (减少了无关流量的干扰)。 ## 7. 阶段 5 — 安全远程访问 ### 7.1 方案评估 | 选项 | 评估 | |---|---| | 在路由器上直接进行 Port Forwarding | ❌ 被否决 — 将 Dashboard 直接暴露在互联网的自动扫描之下 | | Cloudflare Tunnel | 可行 (最多 50 个用户免费)，但需要自有域名 — 对于个人使用场景不划算 | | **Tailscale (mesh VPN, WireGuard)** | ✅ 入选 — 无需开放端口，无成本，适合个人使用 | ### 7.2 使用场景修正 最初的计划假设是在笔记本保持开机并位于家中时，从**另一台设备** (例如：手机) 进行访问 — Tailscale 正是针对此场景直接安装在虚拟机上的。然而，实际的使用场景有所不同：是**同一台物理笔记本**移动到了其他网络中。 由于虚拟机处于 Bridge 模式 (绑定到家庭局域网)，其 IP 一旦离开该网络便不复存在。采用的解决方案是利用现有的 NAT 网卡 (为 Splunk 创建的) 进行**端口转发**：宿主机的 `localhost:8443` → 虚拟机的 443 端口 (Dashboard)，通过 VirtualBox 的内部 NAT 实现 — 无论笔记本处于哪个外部网络中均可运行。 **实际验证：** 已在真实的外部网络中成功测试 (不仅仅是家中的模拟)。 ## 8. 阶段 6 — Hardening 后审计 在完成 6 个 hardening 波次之后，进行了一项系统且主动的审计：重建在波次 4 和 5 中应用的确切的 177 项控件的列表，并以编程方式将其与用户实际使用习惯 (设备、应用程序、服务) 相关的关键字进行交叉比对。 ### 8.1 识别并修复的实际阻塞 | 控件 | 影响 | 冲突 | |---|---|---| | `AllowCamera = 0` | 完全阻止摄像头 (内置和未来的外接设备) | 用户计划使用网络摄像头 | | `Turn off access to the Store = Enabled` | 阻止 Microsoft Store — 与之前排除的控件不同，它位于 benchmark 的另一部分 | 与之前为了使用 Store/App Installer 而决定的排除项直接冲突 | | `DisableFileSyncNGSC = 1` | 完全阻止 OneDrive 客户端 | 个人备份策略所需 (见第 9.3 节) | 每一次修正都需要额外的调试：最初的回退尝试使用了假设的注册表路径，结果证明是不正确的 — 只有通过与原始应用的配置数据进行直接比对才能确认，这强化了**在假定原因之前先核实真实来源**的实践。 ### 8.2 已评估并保留的项目 (无实际冲突) - 通过 Phone Link 同步短信/通知 — 未使用的功能 - 阻塞与 Kernel DMA Protection 不兼容的设备的策略 — 对使用中的硬件影响极小 (笔记本无 Thunderbolt 接口) ## 9. 家庭网络 Hardening ### 9.1 路由器 - 已禁用 WPS - 已配置 WPA2/WPA3 (过渡模式，激活了 SAE) - 通过 DHCP 为整个网络配置了 NextDNS (DoH/DoT) - 已修改管理员密码 - 审查了 DMZ / Port Forwarding (无不必要的暴露) - 通过 MAC binding 为虚拟机和主笔记本预留了固定 IP ### 9.2 设备清单 | 设备 | DNS 保护 | 备注 | |---|---|---| | 实验室虚拟机 | NextDNS (从网络继承) | 预留固定 IP | | 主笔记本 | NextDNS (从网络继承) | 预留固定 IP；同时安装了原生 NextDNS 应用 (家庭外的保护) | | 副笔记本 | NextDNS (从网络继承) | — | | 台式机 | NextDNS (从网络继承) | — | | 智能 TV | NextDNS (从网络继承) | — | | 智能手机 (2部) | NextDNS (从网络继承) | — | | 智能手表 | NextDNS (从网络继承) | — | ### 9.3 备份策略 (3-2-1 原则) 安全态势审计发现笔记本的个人/专业数据完全没有备份 — 该问题在同一个 hardening 周期内得到了纠正： - **第 1 层 (已实施)：** OneDrive 对 Documents、Desktop 和 Pictures 文件夹进行自动备份 (包含 1 TB 存储空间的套餐) - **第 2 层 (计划中)：** 定期通过外置硬盘进行物理拷贝，并带有独立的加密 ## 10. 漏洞管理 — CVE-2026-43503 案例 在记录的这段时期内，漏洞 **CVE-2026-43503 ("DirtyClone")** 被公开披露 — 这是 Linux kernel 中的一个本地提权漏洞 (CVSS 8.8)，属于 *DirtyFrag* 家族，起因是在克隆 socket buffer (`skbuff`) 期间 `SKBFL_SHARED_FRAG` 标志的传递出现错误。修复程序已于 2026 年 5 月合并到 mainline kernel (v7.1-rc5) 中，主要影响那些默认开启无特权用户 namespace 的发行版 (Debian, Ubuntu, Fedora)。 **采取的行动：** ``` # 在环境中的所有 VM 上执行 (Wazuh Lab + 学习用 VM) uname -r ``` **结果：** 在检查时，所有验证的实例均使用的是过时的 (易受攻击的) kernel。所有实例都已更新并重启以应用补丁： ``` sudo apt update && sudo apt upgrade -y sudo reboot ``` **实践教训：** 发行版的安装日期并不能保证免受所使用的 ISO 镜像构建之后披露的漏洞的影响 — 检查 kernel 版本和应用补丁应该是一个持续的过程，而不是安装后的一锤子买卖。 ## 11. 经验教训与 notable 根本原因 ### 11.1 任何结构性更改之前的预防性备份 在进行任何更改之前对虚拟机进行快照和备份配置文件 (`ossec.conf`, `suricata.yaml`)，使得在多个事件中能够快速回滚，而无需返工。 ### 11.2 因 SCA 扫描器语言不兼容导致的假阴性 27 项审计控制 (CIS Benchmark 的第 17 节) 已通过 `auditpol` 正确配置并经过手动验证 — 但是 Wazuh SCA 寻找的是**英语**的结果字符串 (`"Success and Failure"`)，而处于葡萄牙语环境下的操作系统返回的却是 `"Êxito e Falha"`。无论系统的实际配置如何，扫描器永远无法将该控件识别为通过 — 这是工具记录在案的限制，而不是 hardening 的失败。 ### 11.3 在接受假设之前始终进行实证验证 在项目的推进过程中，合理的假设 (虚拟机卡死的原因、BitLocker 锁定的原因、Splunk 故障的原因) 多次需要根据直接的日志证据进行否决或细化 — 绝不仅凭表面上的合理性就予以接受。系统性的排除过程 (逐一测试并排除假设) 比任何单一的猜测都更有效，无论它最初看起来多么合理。 ### .4 更换操作系统版本不能替代主动的 Hardening 从 Windows 11 Home 迁移到 Pro **并没有**自动更改任何安全配置 — 仅仅是提供了工具 (Local Group Policy Editor、Hyper-V)，需要后续的手动配置才能影响合规性分数。这一点已通过在迁移后、在进行任何额外 hardening 之前的两次相同的 SCA 扫描得到了实证确认。 ### 11.5 安全控制措施之间可能发生冲突 BitLocker 因 Active Directory 备份要求而受阻的情况 (第 5.2 节) 说明了重要的模式：一项在**其原始环境中** (具有域的企业环境) 正确的合规控制，可能在另一种环境 (独立家庭环境) 中造成实际的功能死锁。识别并记录这些例外情况 — 而不是盲目地应用控制措施 — 是 GRC 的一项核心能力。 ## 12. 展现的技术能力 | 领域 | 证据 | |---|---| | **SIEM/XDR** | 完整的 Wazuh 4.14.5 安装、配置与运行 | | **Linux 管理** | Ubuntu Server 24.04.4 — systemd、网络、底层诊断 (kernel、IPv6、权限) | | **Windows Hardening** | CIS Benchmark v3.0.0 — 应用了 218 项控件，分数从 47% 提升至 87% | | **合规性分析** | 对 247 项故障进行系统化分类并寻找根本原因，区分是 bug 还是合法的操作例外 | | **风险例外管理** | 超过 60 项带有技术理由和风险评估的记录在案的例外情况 | | **系统化排障** | 通过假设排除和日志证据诊断超过 15 起技术事件 | | **磁盘加密** | 实施带有 TPM+PIN 的 BitLocker，包括解决策略冲突 | | **多 SIEM 集成** | Sysmon/Suricata → Wazuh → Splunk 的级联架构，无数据重复 | | **网络 IDS** | Suricata 的安装、规则调优和解决不兼容问题 | | **安全远程访问** | mesh VPN (Tailscale) 和 NAT port-forwarding，无需向互联网暴露端口 | | **漏洞管理** | 在多台虚拟机上验证并修复 kernel 的 CVE | | **PowerShell / Bash** | 用于 hardening、诊断和修复的自动化脚本，具备对实际脚本 bug 的调试能力 | | **技术文档** | 结构化、可追溯且可复现的报告 | **参考的框架：** CIS Controls v8 · CIS Benchmark (Microsoft Windows 11) · MITRE ATT&CK · NIST SP 800-53 (通过 Wazuh SCA 进行映射) ## 13. 已知局限与路线图 ### 13.1 已知局限 (已记录，未解决) | 项目 | 状态 | |---|---| | 虚拟机偶尔的启动不稳定 (偶发性 kernel panic) | 根本原因尚未确切认定；通过调整半虚拟化提供程序得到了缓解 (未消除)；可通过重试启动来规避，无数据丢失 | | Credential Guard 已配置但在 runtime 未激活 | 由于硬件 BIOS 中未公开 VT-d/IOMMU 选项而受阻 — HVCI 依然保持活跃，作为可用的等效保护层发挥功能 | | 2 个因系统 ACL 受阻的控件 (News/Widgets) | 即使拥有管理员权限也无法写入 — 疑似 Tamper Protection/ASR 干扰，但假设尚未证实 | ### 13.2 路线图 - [ ] 高级 Suricata 自定义规则调优 - [ ] 关于 Dashboard 导航 (Wazuh) 和 SPL (Splunk) 的深度培训课程 - [ ] 本地物理备份 (3-2-1 策略的第 2 层) - [ ] 独立的 Active Directory 实验室 (专用 Domain Controller 虚拟机 + 客户端虚拟机)，作为单独的学习项目 - [ ] 评估 Kali Linux 虚拟机，用于受控的攻击模拟和生成验证警报

**网络安全家庭实验室 — Blue Team / SOC / GRC** *用于专业作品集的技术文档*

标签：GitHub Advanced Security, GPT, Metaprompt, 安全加固, 安全实验环境, 服务器监控, 漏洞管理, 网络安全, 隐私保护