MDPorsch/Threat-Detection-with-Wazuh-SIEM
GitHub: MDPorsch/Threat-Detection-with-Wazuh-SIEM
一个基于 Wazuh SIEM 的蓝队威胁检测实践指南，涵盖 SSH 暴力破解检测、文件完整性监控、主动响应和 CIS 合规审计等核心安全运营技能。
Stars: 0 | Forks: 0
# 蓝队：使用 Wazuh SIEM 进行威胁检测
### 网络安全家庭实验室系列
## 概述
**日期：** 2026年3月19日
**环境：** Ubuntu VM + Kali Linux (VirtualBox on MacBook M4)
**难度：** 中级
**耗时：** ~180 分钟
这是一个视角的转换。本次练习站在防御者的角度。使用 Wazuh SIEM，我配置了检测规则，实时监控攻击触发警报，设置了自动主动响应，针对 CIS Benchmark 审计系统，并监控文件完整性。我生成的每一个警报都直接对应于之前练习中的攻击。
## 目标
- 修复 Wazuh agent 配置并建立 manager-agent 连接
- 实时检测 SSH 暴力破解攻击
- 理解 MITRE ATT&CK 警报映射
- 配置文件完整性监控 (FIM)
- 检测可疑用户账户创建
- 针对 CIS Benchmark 运行配置评估
- 修复真实的安全发现
- 配置主动响应以自动封锁攻击者
- 集成 Suricata IDS 与 Wazuh
- 启动漏洞检测
## 工具与环境
| 项目 | 详情 |
|------|--------|
| 主机 | MacBook M4 |
| VM 平台 | VirtualBox |
| Agent VM | Ubuntu 25.10 (192.168.4.113) |
| Manager VM | Kali Linux (192.168.4.198) |
| SIEM | Wazuh v4.14.2 |
| IDS | Suricata 7.0.10 |
| 工作目录 | ~/lab/ex07 |
## 分步指南
### Step 1 — 修复 Wazuh Agent 配置
在之前的设置中，两个 VM 上都已经安装了 Wazuh，但 agent 指向的是一个旧的 IP 地址。在 Ubuntu 上更新了 agent 配置：
```
sudo nano /var/ossec/etc/ossec.conf
```
更改前：
```
10.0.2.3
```
更改后：
```
192.168.4.198
```
重启 agent：
```
sudo systemctl daemon-reload
sudo systemctl restart wazuh-agent
```
验证 agent 已连接到 Kali 上的 manager：
```
sudo /var/ossec/bin/agent_control -l
```
输出：
```
ID: 000, Name: kali (server), IP: 127.0.0.1, Active/Local
ID: 001, Name: GoMyCodeEndpoint, IP: any, Active
```
**Wazuh 架构：**
```
Ubuntu (Agent) → sends logs → Kali (Manager) → analyses → Dashboard
```
所有数据流经 manager。仅在 agent 上配置不足以进行检测或响应 —— 这是本次实验中学到的关键一课。
### Step 2 — 实时 SSH 暴力破解检测
从 Kali 发起 SSH 登录尝试：
```
for i in {1..10}; do ssh wronguser@192.168.4.113; done
```
立即检查 Wazuh dashboard 的 Threat Hunting 标签页。
生成的警报：
```
sshd: Attempt to login using a non-existent user ← rule 5710, severity 5
sshd: Attempt to login using a denied user ← rule 5718, severity 5
```
所有 5 次尝试均记录了相同的时间戳 —— 实时捕获。
展开一个警报以查看完整详情：
```
data.srcip: 192.168.4.198 ← Kali — the attacker
data.srcuser: wrongpassword ← username attempted
agent.name: GoMyCodeEndpoint ← Ubuntu — the target
full_log: Invalid user wrongpassword from 192.168.4.198 port 57426
```
**自动应用的 MITRE ATT&CK 映射：**
```
T1110.001 ← Password Guessing
T1021.004 ← SSH lateral movement
Tactic: Credential Access, Lateral Movement
```
**自动标记的合规框架：**
```
GDPR: IV_35.7.d
HIPAA: 164.312.b
PCI-DSS: 10.2.4, 10.2.5
NIST: AU.14, AC.7
```
### Step 3 — 文件完整性监控 (FIM)
在受监控目录中创建测试文件：
```
sudo touch /etc/test-fim-alert.txt
echo "wazuh fim test" | sudo tee /etc/test-fim-alert.txt
```
从 manager 强制立即执行 FIM 扫描：
```
sudo /var/ossec/bin/agent_control -r -u 001
```
输出：`Wazuh agent_control: Restarting Syscheck/Rootcheck on agent: 001`
FIM 警报出现在 dashboard 中：
```
/etc/test-fim-alert.txt ← our test file
File added
Rule: 100201
Severity: 7
```
捕获到的额外 FIM 警报显示了后台系统变更：
- Snap packages 正在安装
- CUPS 打印机服务配置被修改
- Systemd 服务文件被添加
### Step 4 — 检测后门账户创建
模拟攻击者创建后门用户账户：
```
sudo useradd testattacker
sudo passwd testattacker
```
Wazuh 警报立即出现：
```
New user added to the system ← rule 5902, severity 8
New group added to the system ← rule 5901, severity 8
```
严重性 8 —— 中高。在真实的 SOC 中，这会立即引起分析师的注意，因为创建新用户账户是典型的攻击者持久化技术。
**事件响应 —— 移除后门账户：**
```
sudo userdel -r testattacker
cat /etc/passwd | grep testattacker # confirmed gone
```
Wazuh 也记录了删除操作：
```
Group (or user) deleted from the system ← rule 5903, severity 3
```
完整的审计追踪：
```
New user added → severity 8 ← suspicious activity
User deleted → severity 3 ← remediation confirmed
```
### Step 5 — 配置评估 (CIS Benchmark)
修复了 SCA 策略版本检查以适配 Ubuntu 25.10：
```
sudo nano /var/ossec/ruleset/sca/cis_ubuntu22-04.yml
```
更改前：
```
- "f:/etc/os-release -> r:Ubuntu 22.04"
```
更改后：
```
- "f:/etc/os-release -> r:Ubuntu"
```
为了实验目的，将 SCA 扫描间隔减少到 5 分钟：
```
yes
yes
5m
yes
```
配置评估结果显示针对 CIS Ubuntu Benchmark 执行了 **204 项检查**。
**主要发现：**
| 检查项 | 结果 | 严重性 |
|-------|--------|---------|
| /tmp 是独立分区 | ✅ 通过 | — |
| /tmp 上的 nodev 选项 | ✅ 通过 | — |
| /tmp 上的 noexec 选项 | ❌ 失败 | Medium |
| /etc/shells 权限 | ❌ 失败 | Medium |
| systemd-journal-upload 已启用 | ❌ 失败 | Medium |
| 审计日志空间警告 | ❌ 失败 | Medium |
### Step 6 — 修复真实发现
修复了 CIS Benchmark 中关于 `/tmp noexec` 的发现：
**临时修复：**
```
sudo mount -o remount,noexec /tmp
mount | grep /tmp
```
输出：`tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noexec,...)`
**永久修复（重启后生效）：**
```
sudo nano /etc/fstab
```
添加了：
```
tmpfs /tmp tmpfs defaults,rw,nosuid,nodev,noexec,relatime 0 0
```
验证永久修复：
```
sudo mount -a
mount | grep /tmp
```
输出确认：挂载选项中永久包含 `noexec`。 ✅
### Step 7 — 主动响应：自动封锁攻击者
在 Kali 上的 **manager** 中添加主动响应配置：
```
firewall-drop
local
5710,5718
180
```
这告诉 Wazuh：当规则 5710 或 5718 触发（SSH 登录失败）时，自动运行 `firewall-drop` 封锁攻击 IP 180 秒。
**测试主动响应：**
Step 1 — 攻击前检查 iptables（无封锁）：
```
sudo iptables -L INPUT -n
```
干净 —— 只有 UFW 规则，没有 IP 封锁。
Step 2 — 从 Kali 发起 SSH 失败尝试：
```
for i in {1..10}; do ssh wronguser@192.168.4.113; done
```
Step 3 — 随后立即检查 iptables：
```
sudo iptables -L INPUT -n
```
输出：
```
DROP all -- 192.168.4.198 0.0.0.0/0 ← Kali automatically BLOCKED!
```
Step 4 — 180 秒后封锁自动解除。 ✅
**完整的主动响应周期：**
```
Attack detected → IP blocked automatically (0 seconds)
180 seconds later → IP unblocked automatically
```
### Step 8 — Suricata 集成
Suricata (IDS) 已在 Ubuntu 上运行 —— 收集了 109MB 的网络事件。通过以下方式将其与 Wazuh 集成：
**在 Ubuntu agent 上：**
```
json
/var/log/suricata/eve.json
```
**修复 manager 上的 JSON 解码器限制：**
```
sudo nano /var/ossec/etc/local_internal_options.conf
```
添加了：`analysisd.decoder_order_size=512`
Suricata 警报出现在 Wazuh dashboard 中：
```
Suricata: Alert - ET INFO Possible Kali Linux hostname in DHCP Request Packet
Rule: 86601
Severity: 3
```
自练习 3 以来，Suricata 一直默默检测 Kali 在网络中的存在 —— 每次 Kali 连接时都通过 DHCP 广播进行标记。
### Step 9 — 漏洞检测
确认 Ubuntu 上已清点 1,996 个软件包：
```
sudo sqlite3 /var/ossec/queue/db/001.db "SELECT count(*) FROM sys_programs;"
```
输出：`1996`
减少了漏洞扫描间隔并触发了 CVE feed 下载。等待后：
```
sudo du -sh /var/ossec/queue/vd/feed/
```
输出：`7.6G` —— 完整的 CVE 数据库已下载。
漏洞检测处理需要额外时间将 1,996 个软件包与 CVE 数据库进行交叉引用。结果将在 feed 下载完成后的 1-2 小时内显示在 dashboard 中。
## 错误与修复
### 错误 1 — Agent 配置中的 Manager IP 错误
**发生了什么：** Wazuh agent 指向旧 IP `10.0.2.3` —— 没有日志流向 manager。
**修复：** 将 `/var/ossec/etc/ossec.conf` 中的 `` 更新为 `192.168.4.198`。
**教训：** 设置 SIEM 时务必验证 agent-manager 的连通性。
### 错误 2 — 仅在 Agent 上配置主动响应
**发生了什么：** 在 Ubuntu agent 上添加了主动响应配置 —— 封锁未触发。
**修复：** 将配置添加到 Kali **manager** 上。Manager 负责编排响应。
**教训：** 在 Wazuh 中，manager 控制主动响应。仅配置 agent 是不够的。
### 错误 3 — Suricata JSON 解码器错误
**发生了什么：** `wazuh-analysisd: ERROR: Too many fields for JSON decoder` —— Suricata 复杂的嵌套 JSON 超出了默认限制。
**修复：** 在 `local_internal_options.conf` 中添加 `analysisd.decoder_order_size=512`。
**教训：** 复杂的日志格式通常需要调整解码器配置。
### 错误 4 — SCA 策略版本不匹配
**发生了什么：** 配置评估未显示结果 —— CIS 策略要求 Ubuntu 22.04，但系统运行的是 25.10。
**修复：** 修改 `cis_ubuntu22-04.yml` 中的版本检查以匹配任何 Ubuntu 版本。
**教训：** 始终检查策略与操作系统版本的兼容性。
## 关键收获
1. **Manager 架构至关重要** —— 主动响应和 Suricata 检测都需要在 manager 端配置，而不仅仅是 agent 端
2. **MITRE ATT&CK 映射是自动的** —— Wazuh 无需手动配置即可将每个警报映射到攻击技术和合规框架
3. **主动响应非常强大** —— 零人工干预的自动 IP 封锁
4. **FIM 捕获利用后行为** —— 受监控目录中的每个文件更改都被记录
5. **CIS Benchmark 发现真实差距** —— 204 项自动检查识别出了我们修复的实际配置错误
6. **调试 SIEM 问题能深入理解架构** —— 每一步故障排除都揭示了 Wazuh 组件的交互方式
## 现实意义
| 练习技能 | 现实应用 |
|----------------|----------------------|
| SIEM 警报分析 | SOC 分析师日常工作 |
| MITRE ATT&CK 映射 | 威胁情报与事件响应 |
| 主动响应配置 | 自动化安全运营 |
| CIS Benchmark 评估 | 安全审计与合规 |
| FIM 监控 | 入侵后取证调查 |
| IDS 集成 | 网络安全监控 |
Wazuh 被全球数千家组织用作其主要 SIEM。了解如何配置、故障排除和解读其警报，直接适用于 SOC 分析师、安全工程师和蓝队角色。
标签：AMSI绕过, ATTACK-Python-Client, ATT&CK映射, CIS Benchmark, DNS 反向解析, GitHub Advanced Security, Homelab, SSH暴力破解, Suricata, VirtualBox, Wazuh, x64dbg, 主动响应, 入侵检测系统, 威胁检测, 安全加固, 安全实验, 安全数据湖, 现代安全运营, 网络安全, 速率限制处理, 防御视角, 隐私保护