nileshmethri/wazuh-siem-lab
GitHub: nileshmethri/wazuh-siem-lab
基于 VirtualBox 和 Wazuh 的双节点 SIEM 实验室，通过模拟真实攻击场景并编写自定义检测规则，帮助安全从业者练习事件调查与检测工程技能。
Stars: 0 | Forks: 0
# Wazuh SIEM 家庭实验室 — 检测真实攻击
## 这是什么
一个运行在 VirtualBox 上的双节点 SIEM 实验室。一台机器运行完整的 Wazuh 堆栈（manager + indexer + dashboard）。另一台充当被监控的 endpoint。我模拟了对 endpoint 的攻击，编写了检测规则，调查了告警，并记录了我的发现。
## 堆栈和版本
| 组件 | 版本 |
|---|---|
| Wazuh Manager | 4.7.5 |
| Wazuh Indexer | 4.7.5 (OpenSearch 2.8.0) |
| Wazuh Dashboard | 4.7.5 |
| Wazuh Agent | 4.7.5 |
| OS (server) | Ubuntu Server 22.04 LTS |
| OS (agent) | Ubuntu Server 22.04 LTS |
| Hypervisor | VirtualBox 7.x |
| Host OS | Windows 11 |
## 架构
```
graph TD
A[Host Machine - Windows 11]
A --> B[Wazuh Server
Ubuntu 22.04] A --> C[Ubuntu Endpoint
Wazuh Agent] C -->|1514 TCP| B C -->|1515 TCP| B B -->|443 HTTPS| D[Wazuh Dashboard] E[Attack Simulation] -->|SSH Port 22| C ``` **wazuh-server** — 运行 Wazuh manager（接收和处理日志）、OpenSearch indexer（存储所有内容）和 dashboard（端口 443 上的 Web UI）。至少需要 4 GB RAM 和 2 GB swap，否则 indexer 在启动时会静默超时。 **wazuh-agent** — 一个干净的 Ubuntu 22.04 安装，运行着 Wazuh agent。这是被监控的机器。SSH 被故意保持开放，以便我可以从宿主机模拟针对它的远程攻击。 两台虚拟机都使用 Bridged Adapter 网络，这样它们就能在本地网络上获得真实的 IP 并可以直接通信。 ## 检测用例 ### 1. SSH Brute Force — 内置规则 **我做了什么：** 在我的主 PC 上使用假用户名（`fakeuser`）并加上 `BatchMode=yes` 运行了 10 次快速 SSH 登录尝试，以强制立即失败。 **触发了什么：** - Rule **5710** (level 5) — 每次尝试的单次失败登录 - Rule **5712** (level 10) — 当失败次数超过阈值时，Wazuh 的关联引擎将其标记为 brute force **MITRE 映射（由 Wazuh 自动标记）：** - T1110 — Brute Force - T1110.001 — Password Guessing - T1021.004 — Remote Services: SSH **让我惊讶的地方：** 我本以为需要配置一些东西。但我没有。Rule 5712 自动触发了。更有趣的工作是调查——点进原始告警，阅读源 IP，检查是否有任何尝试成功，理解为什么 Wazuh 每次失败的 SSH 尝试会生成两行日志（一行是 `invalid user`，一行是 `failed password`）。 ### 2. Privilege Escalation — 自定义规则 **我做了什么：** 在 agent 上运行 `sudo su` 提权到 root shell。Wazuh 的默认 rule 5402 会捕获这个，但它的 level 是 3——和 `sudo apt update` 的严重程度一样。这对于分诊来说毫无用处。 **我写的规则：** ```
5402
COMMAND=/usr/bin/su
Possible root escalation via sudo su
T1548.003
```
文件位置：`/var/ossec/etc/rules/local_rules.xml`
**为什么是 `COMMAND=/usr/bin/su` 而不是 `sudo su`：**
我的第一个版本使用了 `sudo su `，并且从未触发。我在 Wazuh dashboard 的 Table 视图中打开了原始告警并查看了 `full_log` 字段。实际的日志行是：
```
Jun 15 18:18:24 wazuh-agent sudo: agent : TTY=tty1 ; PWD=/home/agent ; USER=root ; COMMAND=/usr/bin/su
```
日志中并不存在 "sudo su" 这个短语。系统记录的是解析后的二进制路径，而不是你输入的命令。修正了匹配字符串后，重启 manager，它立即触发了。
**MITRE 映射：** T1548.003 — Abuse Elevation Control Mechanism: Sudo and Sudo Caching
### 3. 文件完整性监控
**我做了什么：** 在 `/etc/` 中创建了一个新文件，并向 `/etc/passwd` 追加了一行。
**触发了什么：**
- Rule **554** — 添加了新文件（`/etc/fim-test-final`）
- Rule **550** — 文件完整性校验和已更改（`/etc/passwd`）
**坑点：** 默认的 FIM 在 12 小时的计划任务上运行。好几个小时都没有出现任何内容。解决方法是在 agent 配置中的 `/etc` 目录添加 `realtime="yes"`：
```
/etc
```
使用 realtime 模式，告警会在文件更改后的几秒钟内出现。如果没有它，你需要等待半天才能确认你的规则是否有效。
### 4. 漏洞检测
**我做了什么：** 启用了内置的 vulnerability detector 并添加了 Canonical (Ubuntu) CVE feed。
**结果：** 在 agent 上发现了 468 个 CVE。0 个 Critical，2 个 High，362 个 Medium，104 个 Low。
**High 级别的是什么：** 两个具有已知未修补 CVE 的软件包——我不会去修补它们，它们是实验室虚拟机。但工作流程（查找 -> 按严重程度分诊 -> 检查是否可利用 -> 决定是否修补）才是最重要的。
**需要的配置更改：**
在 server 上的 `/var/ossec/etc/ossec.conf` 中，Canonical provider 已安装但默认禁用：
```
no
jammy
...
```
没有这个，它将不会扫描 Ubuntu 机器。我花了不该花的那么长时间才找到这个。
## 出了什么问题以及我会怎么做
### FIM 连续两天产生零告警
扫描在运行——我可以在日志中看到它。但 dashboard 中没有出现任何告警。问题在于：agent 连接后的第一次扫描会创建 baseline。如果你在第一次扫描运行之前创建了测试文件，这些文件就已经在 baseline 中了。没有任何东西可以用来对比 (diff)。你必须在 baseline 存在之后再进行更改。
在受监控的目录中添加 `realtime="yes"` 可以完全绕过这个问题，而且这也是生产环境部署应该采用的配置方式。
### Agent 无法连接到互联网
VirtualBox 默认的 NAT adapter 可用于互联网访问，但会破坏虚拟机到虚拟机的通信。Bridged Adapter 对两者都适用，但前提是你选择了正确的物理 adapter。我使用的是 WiFi，并且一直选错 adapter（列出了三个——WiFi、Ethernet 和一个虚拟 adapter）。弄错这个会产生静默失败：`wget` 会尝试 IPv6，超时，然后什么也不做。
修复方法：使用 `wget -4` 或 `curl -4` 强制使用 IPv4。更长远的修复方法：将两台虚拟机都设置为 Bridged Adapter，指向同一个物理 WiFi adapter。
### DHCP 不断更改 server IP
每次 wazuh-server 虚拟机重启时，路由器都会为其分配一个新的 IP。这会破坏 agent 注册并导致 dashboard URL 发生变化。请设置静态 IP。
在第一天就做这件事，而不要在你已经重建了三次 agent 注册之后才做。
### 我会怎么做
- **在做任何其他事情之前设置静态 IP。** 一旦地址不再变动，所有其他问题都会变得更容易调试。
- **在安装前添加 swap。** 安装程序没有足够清楚地警告你 4 GB RAM 是硬性底线，而不是建议。
- **从一开始就使用 SSH。** 在 VirtualBox 终端窗口中进行复制粘贴是很痛苦的。从宿主机通过 SSH 连接，一切都会变得正常。
- **从第一天起就使用 realtime 模式测试 FIM。** 12 小时的计划扫描对实验室毫无用处。你会浪费好几个小时 wondering 你的规则是否有效。
Ubuntu 22.04] A --> C[Ubuntu Endpoint
Wazuh Agent] C -->|1514 TCP| B C -->|1515 TCP| B B -->|443 HTTPS| D[Wazuh Dashboard] E[Attack Simulation] -->|SSH Port 22| C ``` **wazuh-server** — 运行 Wazuh manager（接收和处理日志）、OpenSearch indexer（存储所有内容）和 dashboard（端口 443 上的 Web UI）。至少需要 4 GB RAM 和 2 GB swap，否则 indexer 在启动时会静默超时。 **wazuh-agent** — 一个干净的 Ubuntu 22.04 安装，运行着 Wazuh agent。这是被监控的机器。SSH 被故意保持开放，以便我可以从宿主机模拟针对它的远程攻击。 两台虚拟机都使用 Bridged Adapter 网络，这样它们就能在本地网络上获得真实的 IP 并可以直接通信。 ## 检测用例 ### 1. SSH Brute Force — 内置规则 **我做了什么：** 在我的主 PC 上使用假用户名（`fakeuser`）并加上 `BatchMode=yes` 运行了 10 次快速 SSH 登录尝试，以强制立即失败。 **触发了什么：** - Rule **5710** (level 5) — 每次尝试的单次失败登录 - Rule **5712** (level 10) — 当失败次数超过阈值时，Wazuh 的关联引擎将其标记为 brute force **MITRE 映射（由 Wazuh 自动标记）：** - T1110 — Brute Force - T1110.001 — Password Guessing - T1021.004 — Remote Services: SSH **让我惊讶的地方：** 我本以为需要配置一些东西。但我没有。Rule 5712 自动触发了。更有趣的工作是调查——点进原始告警，阅读源 IP，检查是否有任何尝试成功，理解为什么 Wazuh 每次失败的 SSH 尝试会生成两行日志（一行是 `invalid user`，一行是 `failed password`）。 ### 2. Privilege Escalation — 自定义规则 **我做了什么：** 在 agent 上运行 `sudo su` 提权到 root shell。Wazuh 的默认 rule 5402 会捕获这个，但它的 level 是 3——和 `sudo apt update` 的严重程度一样。这对于分诊来说毫无用处。 **我写的规则：** ```
标签：Wazuh, 安全实验室