BrandonRoos/wazuh-detection-engineering-lab

这不仅仅是一篇安装指南。它记录了攻击模拟、遥测分析、误导线索、根因分析、检测规则更改以及验证过程。 我发现了三个已确认的检测盲区，并构建了两种类型的修复方案：实时文件完整性监控（FIM）和由 `auditd` 支持的手写关联规则。 ## 🎯 快速概览 本项目演示了： - Wazuh manager、indexer、dashboard 和 Linux agent 的部署 - 使用 FIM 和 `auditd` 收集 Linux 遥测数据 - 映射到 MITRE ATT&CK 的 Atomic Red Team 测试 - 自定义 Wazuh XML 规则的开发与验证 - 跨 endpoint、collector、decoder、rule 和 dashboard 层的根因分析 - 误报分析与基于证据的故障排查 - Proxmox 虚拟化、Linux 管理与资源规划 - 基于真实会话记录构建的清晰技术文档 | 领域 | 本仓库中的证据 | | --- | --- | | 检测测试 | 在更改前后测试了三种模拟行为 | | 根因分析 | 诊断了缺失的 FIM 范围、定期扫描时机、audit 摄取以及静默的 rule 80700 | | 检测工程 | 实时 FIM 以及自定义 rule 100100 | | 验证 | 重新运行了精确的测试，并记录了生成的 Wazuh 规则 | | 可重复性 | [`configs/`](configs/) 下的可部署配置示例 | | 交流沟通 | 此处的执行摘要以及按时间顺序记录的详细工程日志 | ## 🧭 导航 - [架构](#architecture) - [已闭环的三项技术](#three-techniques-closed) - [案例研究 1：短暂的 shell 制品](#case-study-1-short-lived-shell-artifact) - [案例研究 2：一个控制策略，另一种检测](#case-study-2-one-control-another-detection) - [案例研究 3：基于 audit 的自定义规则](#case-study-3-audit-based-custom-rule) - [故障排查重点](#troubleshooting-highlights) - [复现控制策略](#reproduce-the-controls) - [局限性](#limitations) - [后续计划](#whats-next) - [完整构建笔记](docs/full-build-notes.md) ## 🗂️ 仓库结构图 ``` wazuh-detection-engineering-lab/ ├── README.md ├── configs/ │ ├── README.md │ ├── auditd/ │ │ └── t1082-hostname.rules │ └── wazuh/ │ ├── agent-audit-log.xml │ ├── agent-fim.xml │ └── local_rules.xml └── docs/ ├── full-build-notes.md └── images/ ├── phase1-infrastructure/ └── phase2-detection-engineering/ ``` ## 🖥️ 架构 | 虚拟机 (VM) | 角色 | 资源 / 详情 | 地址 | | --- | --- | --- | --- | | `wazuh-aio` | Wazuh manager、indexer 和 dashboard | Wazuh 4.14.6 | `192.168.2.101` | | `victim-01` | 一次性 Linux 目标机和 Wazuh agent | Ubuntu Server 22.04 | `192.168.2.102` | | `kali-01` | 攻击机和扫描机 | Kali 滚动发布版 | `192.168.2.103` | | `ollama-01` | 本地 LLM 推理 | 纯 CPU 的 Ollama | `192.168.2.104` | 宿主机是一台配备 32 GB 内存的联想 ThinkCentre M710q。构建过程初始基于 Proxmox VE 9.2.2；宿主机更新后的后续 UI 截图显示版本为 9.2.4。 实验室流量使用位于 pfSense 后方、处于隔离状态的 `192.168.2.0/24` 网段。 这些地址是私有的且不可路由。虽然它们仍然暴露了实验室的内部寻址方案，但为了清晰展示拓扑结构，此处依然将其保留。  ## 🧰 工具与版本 | 组件 | 版本或详情 | | --- | --- | | Hypervisor | Proxmox VE 9.2.2 | | SIEM | Wazuh 4.14.6，从 4.9.2 升级而来 | | 受害者机 | Ubuntu Server 22.04.5 | | 攻击模拟 | 通过 Invoke-AtomicRedTeam 执行的 Atomic Red Team | | Linux 审计 | `auditd` 和 `audispd-plugins` | | 测试 shell | PowerShell Core 7.6.3 和 Bash | | 本地推理 | Ollama，使用 `llama3.1:8b` 和 `jimscard/whiterabbit-neo:13b` | ## ✅ 已闭环的三项技术 | # | 技术 / 测试 | 初始结果 | 更改 | 验证 | | --- | --- | --- | --- | --- | | 1 | T1059.004-1 — 创建并执行 Bash Shell 脚本 | 无相关告警 | 在 `/tmp` 上添加了实时 FIM | 在两次重新运行中触发了 rule 550 | | 2 | T1082-3 — 列出操作系统信息 | 无相关告警 | 复用了相同的实时 FIM 控制策略 | 在 `/tmp/T1082.txt` 上触发了 rule 550 | | 3 | T1082-8 — 主机名发现 | 无告警 | 添加了 `auditd`、audit 日志摄取和 rule 100100 | rule 100100 触发了四次 | 这项工作产生了两条经过验证的检测路径：用于快速文件活动的实时 FIM，以及用于没有文件制品的活动的、由 audit 支持的自定义关联规则。 要自行部署这些控制策略，请参阅 [`configs/README.md`](configs/README.md) 中的逐步应用与验证指南。这四个代码片段中有两个需要手动合并到 `ossec.conf` 中，因此这不是一次简单的盲目粘贴。 ## 🔬 案例研究 1：短暂的 shell 制品 ### 测试 我运行了 Atomic Red Team 测试 `T1059.004-1`。它写入 `/tmp/art.sh`，执行它，并在清理期间将其删除。 ``` Invoke-AtomicTest T1059.004 -TestNumbers 1 ```  ### 初始结果 命令执行成功，但我没有发现相关的 Wazuh 告警。 广泛的搜索显示了 217 个标记为“存储数据操纵”的事件。文档检查表明它们是计划内的 CIS 基准检查，而不是来自测试的证据。  在测试时间窗口内出现了两个 rule 510 事件。它们的详细信息指出了 `/usr/bin/diff` 和宽泛的 rootcheck 特征，因此它们的时机只是巧合。  直接搜索 `/tmp` 未返回任何结果。  ### 根本原因 默认的 `syscheck` 范围不包含 `/tmp`。其定期扫描频率也为 43,200 秒，而 Atomic 测试在大约一秒钟内创建并删除了该脚本。  ### 修复 我添加了一个单独的实时 FIM 条目，而不是将每个默认目录都更改为实时监控。 ``` /tmp ``` 可复用的片段位于 [`configs/wazuh/agent-fim.xml`](configs/wazuh/agent-fim.xml)。 ### 验证 我重启了 agent 并运行了相同的 Atomic 测试两次。这两次运行都在 `/tmp/art.sh` 上产生了 rule 550 事件。 | 时间 | 路径 | 规则 | 级别 | | --- | --- | --- | --- | | Jul 12, 2026 15:37:05 | `/tmp/art.sh` | 550 — 完整性校验和已更改 | 7 | | Jul 12, 2026 15:37:58 | `/tmp/art.sh` | 550 — 完整性校验和已更改 | 7 | Wazuh 还记录了对 `/tmp/Invoke-AtomicTest-ExecutionLog.csv` 的更改，从而为每次运行提供了第二个制品。  ## 🔁 案例研究 2：一个控制策略，另一种检测 Atomic 测试 `T1082-3` 将操作系统信息写入 `/tmp/T1082.txt`，读取它，然后将其删除。 ``` Invoke-AtomicTest T1082 -TestNumbers 3 ``` 此测试与第一个案例共享相同的快速写入和删除模式。我重新运行了它，而没有添加其他规则或再次更改配置。 Wazuh 在 `15:55:06` 为 `/tmp/T1082.txt` 产生了一个 rule 550 事件。因此，一个有针对性的控制策略解决了这两个开放的文件制品检测盲区。 我没有为 `uname`、`cat` 或 `uptime` 添加直接告警。这些实用程序很常见，仅凭它们的名字进行告警会产生微弱且嘈杂的检测。 ## 🛠️ 案例研究 3：基于 audit 的自定义规则 ### 测试 Atomic 测试 `T1082-8` 运行 `hostname`。它不会创建任何可供 FIM 观察的文件。 ``` Invoke-AtomicTest T1082 -TestNumbers 8 ``` ### 构建与诊断 我是从 endpoint 向外进行排查的，而不是盲目更改 Wazuh 规则。 1. 安装并启用了 `auditd`。 2. 为 `/usr/bin/hostname` 添加了 `execve` audit 规则。 3. 使用 `ausearch` 确认了内核事件。 4. 添加了 Wazuh 对 `/var/log/audit/audit.log` 的收集。 5. 使用 `wazuh-logtest` 检查解码和规则选择。 6. 添加了本地 rule 100100 并重启了 manager。  内核 audit 层正常工作，并且 Wazuh 解码了该事件。剩下的问题是规则选择：通用的 audit rule 80700 在级别 0 匹配，并没有产生告警。 ### 关联规则 我在 `/var/ossec/etc/rules/local_rules.xml` 下添加了 rule 100100，它继承自 rule 80700 并匹配 Wazuh 解码后的 `audit.execve.a0` 字段。 ``` 80700 hostname T1082 - System Information Discovery: hostname command executed (audit) T1082 ```  可部署的示例包括： - [`configs/auditd/t1082-hostname.rules`](configs/auditd/t1082-hostname.rules) - [`configs/wazuh/agent-audit-log.xml`](configs/wazuh/agent-audit-log.xml) - [`configs/wazuh/local_rules.xml`](configs/wazuh/local_rules.xml) ### 验证 我重启了 `wazuh-manager`，重新运行了测试 8并确认在级别 5 出现了四个 rule 100100 告警，且具有预期的描述和 T1082 映射。  ## 🧯 故障排查重点 ### Agent 与 manager 版本不匹配 受害者的 Wazuh 4.14.6 agent 无法在 4.9.2 manager 上注册。agent 日志报告其版本必须小于或等于 manager 版本。 我创建了 Proxmox 快照，并将 manager、indexer、dashboard 和 Filebeat 一起升级，以避免内部组件版本漂移。 ``` apt install --only-upgrade wazuh-manager wazuh-indexer wazuh-dashboard filebeat ```  ### 升级后 dashboard 证书不匹配 升级后 dashboard 进入了重启循环。`journalctl` 显示新配置期望使用不同的证书文件名。 我将现有证书软链接到预期的名称，重启了 dashboard，然后确认 agent 已激活。 ``` ln -s wazuh-dashboard-key.pem dashboard-key.pem ln -s wazuh-dashboard.pem dashboard.pem ```  ### 时间与搜索上下文错误 UTC 的 agent 日志、未设置的受害者时区以及 dashboard 的本地显示，使得一个有效的 FIM 更改看起来比测试发生得更早。 我纠正了时区和 NTP 状态，然后使用了 endpoint FIM 面板，而不是依赖宽泛的 Threat Hunting 文本搜索。 ``` sudo timedatectl set-timezone America/New_York sudo timedatectl set-ntp true ``` ### 精简置备与实际使用情况对比 Proxmox 警告虚拟磁盘分配超出了报告的可用容量。`lvs` 显示实际物理使用率仅约为 29%，因此我记录了该风险并对其进行了监控，而不是进行不必要的更改。 ### 本地 LLM 限制 Ollama 虚拟机无法在分配六个 vCPU 的情况下启动，因此我将其减少到了四个。纯 CPU 的模型测试还表明，较大的模型不适合在此宿主机上进行交互式使用。 Open WebUI 暴露了 `jimscard/whiterabbit-neo:13b` 的一个单独的工具支持错误。我将该 UI 兼容性问题与完整笔记中的 CPU 性能测量结果分开处理。 ## ♻️ 复现控制策略 每一个修复都是位于 [`configs/`](configs/) 下的一个小巧且可复用的代码片段。**[`configs/README.md`](configs/README.md)** 指南是说明每个片段具体位置的单一信息源，此外它还提供了一个循序渐进的**应用与验证**操作指南，该指南将 agent 和 manager 的步骤区分开来。 | 制品 | 宿主机 | 用途 | | --- | --- | --- | | [`agent-fim.xml`](configs/wazuh/agent-fim.xml) | Wazuh agent | 针对 `/tmp` 的实时 FIM | | [`agent-audit-log.xml`](configs/wazuh/agent-audit-log.xml) | Wazuh agent | Wazuh 收集 `audit.log` | | [`t1082-hostname.rules`](configs/auditd/t1082-hostname.rules) | 受监控主机 | 针对 `hostname` 的内核 audit 规则 | | [`local_rules.xml`](configs/wazuh/local_rules.xml) | Wazuh manager | 自定义 Wazuh rule 100100 | 两个 agent 片段会**合并**到 `ossec.conf` 中，audit 规则作为其自身的文件**放入** `/etc/audit/rules.d/` 下，而 rule 100100 则被**添加**到 manager 的 `local_rules.xml` 中。这些都是有针对性的示例，而不是完整的替换配置——请将它们合并到你现有的设置中，并在更广泛部署之前在实验室中进行验证。 ## 🖼️ 证据与完整笔记 [完整构建笔记](docs/full-build-notes.md) 保留了摘要无法展示的时间顺序记录：弯路、相互矛盾的线索、命令、决策、修复以及后续待处理的工作。 截图证据按阶段分组： - [`docs/images/phase1-infrastructure/`](docs/images/phase1-infrastructure/) - [`docs/images/phase2-detection-engineering/`](docs/images/phase2-detection-engineering/) ## ⚠️ 局限性 - 这是一个家庭实验室的概念验证，而不是生产级别的部署。 - 对繁忙的 `/tmp` 目录进行实时监控可能会产生噪音，并且需要进行调整。 - Rule 100100 已针对文档化的 Atomic 测试进行了验证，但仍需要进行长期的基线化。 - 截图仅捕获了一次测试会话，不能替代导出的事件或自动化的回归测试。 - pfSense 规则加固和长期的误报调整仍然是待解决的事项。 ## 🚀 后续计划 - 在实验室 VLAN 和管理访问之间添加 pfSense 规则。 - 对 rule 100100 进行基线化，并调整嘈杂的 FIM 活动。 - 测试不写入 `/tmp` 的行为，包括凭证访问场景。 - 添加有用检测的 Sigma 版本，并将其与 Wazuh XML 进行比较。 - 添加可重复的验证脚本和经过脱敏处理的样本事件。 - 将真实的 Wazuh API 输出接入到独立的 AI 辅助 SOC 项目中。 ## 🔗 相关项目 基础设施和网络背景位于 [Home-Lab 仓库](https://github.com/BrandonRoos/Home-Lab)。

标签：AI风险缓解, Proxmox, Root-cause分析, SOC实验室, Wazuh, 攻击模拟, 驱动签名利用