duaa-adnan/SIEM-Detection

# Wazuh SIEM 检测工程实验室 ## 概述 本项目记录了围绕 **Wazuh** 构建的实战 SIEM 实验室第二周的内容，涵盖了从基础主机监控到自定义检测工程和自动化事件响应的演进过程。工作从 Linux 和 Windows agent 上的文件完整性监控（FIM）开始，随后进入编写和调试自定义检测规则阶段，通过从 Kali 攻击机模拟真实的 SSH 暴力破解攻击，对产生的日志进行追踪搜索，最后配置 Wazuh 的 Active Response，利用 `firewall-drop` 自动封禁恶意 IP。本报告如实记录了整个过程，包括失败的尝试、配置错误，以及最终解决问题的排查步骤。 ## 目标 - 在 Linux 和 Windows agent 上配置并验证文件完整性监控（FIM） - 为默认规则集未充分覆盖的事件编写自定义 Wazuh 检测规则 - 调试并排查编写正确但未触发的规则 - 模拟真实的 SSH 暴力破解攻击并确认端到端检测 - 通过 SIEM 仪表板分析相关的 Windows 安全事件 ID（4625、4672、4720） - 关联并导出日志，用于结构化威胁狩猎和报告 - 配置并测试 Wazuh Active Response 以自动封禁攻击 IP ## 实验架构 | 主机 | 角色 | 操作系统 | |---|---|---| | `daisy-server` | Wazuh Manager | Linux | | `Windows-Target` | Wazuh Agent | Windows 11 Home | | `Kali-WazuhAttack` | 攻击机 | Kali Linux | 所有 agent 都向单个 Wazuh Manager 汇报，实现了集中式日志收集、跨平台关联，以及对跨两种操作系统活动的“单一视窗”展示。 ## 使用的技术 - **Wazuh**（Manager v4.9.2、Agent、Dashboard）— SIEM / XDR 平台 - **文件完整性监控 (syscheck)** — Linux 和 Windows - **Wazuh 自定义规则** (`local_rules.xml`) — 检测工程 - **wazuh-logtest** — 交互式规则/解码器调试 - **Wazuh Active Response** (`firewall-drop`) — 自动化 IP 封禁 - **iptables** — 防火墙验证 - **Kali Linux** — 攻击模拟（通过 `for` 循环进行 SSH 暴力破解） - **MITRE ATT&CK** — 自定义规则的技术映射 ## 环境 - 运行在 Linux 主机 (`daisy-server`) 上的 Wazuh Manager，充当集中的收集与关联节点 - 已注册并向 Manager 汇报的 Windows 11 agent (`Windows-Target`) - 纯粹用于生成模拟恶意流量的 Kali Linux 攻击虚拟机 (`Kali-WazuhAttack`) - 通过 SSH 访问 Manager，进行规则编辑、日志跟踪和服务管理 - 报告中隐去了目标 IP 和账户标识符，以便安全分享 ## 实施过程 1. **Linux 上的 FIM（场景 1）** — 在 Manager 的 `ossec.conf` 中配置了 `syscheck`，对 `/etc` 和 `/var/log` 启用了实时监控和变更报告。通过文件创建/编辑/删除测试进行了验证。 2. **Windows 上的 FIM（场景 2）** — 注册并确认了 Windows agent，添加了配置 `realtime="yes"` 和 `report_changes="yes"` 的受监控目录 `FIM_Test`，重启了 Wazuh 服务，并验证了“添加 → 修改 → 删除”的完整告警生命周期（规则 554、550、553）。 3. **创建自定义规则（场景 3）** — 研究了现有的基础规则（用于 Linux 用户/组创建的 5901/5902），然后在 `local_rules.xml` 中编写了三条自定义规则： - **规则 100001** (level 10) — 创建了新的 Linux 用户账户 (`if_sid 5902`) - **规则 100002** (level 10) — SSH 暴力破解检测器 (`if_matched_group="authentication_failed"`, `frequency="5"`, `timeframe="120"`, `same_source_ip`) - **规则 100003** (level 7) — Windows 上插入了 USB 存储设备 (Event ID 2003) 4. **规则测试与排查（场景 4）** — 诊断了为什么规则 100002 没有触发，利用 `wazuh-logtest` 追踪到是 Manager 的 `` 块中缺少了 `etc/rules` 条目，修复了配置后，确认所有三条自定义规则均能正确匹配。 5. **SSH 暴力破解模拟（场景 5）** — 从 Kali 向目标主机以不存在的用户身份进行了多次失败的 SSH 登录尝试，确认规则 100002 针对真实的攻击流量（不仅仅是合成的测试输入）能稳定触发。 6. **Windows 安全事件分析（场景 6）** — 针对 `Windows-Target` 查询了事件 ID 4625（登录失败）、4672（特殊权限登录）和 4720（新账户）。 7. **日志分析与威胁狩猎（场景 7）** — 运行了涵盖所有自定义及相关基础规则 ID 的组合查询，将结果导出到电子表格，并检查了整个时间线的一致性。 8. **Active Response 配置（场景 8-9）** — 将 `firewall-drop` 脚本关联到规则 100002 并设置了 300 秒超时，重启了 Manager，随后重新触发了暴力破解模拟，并通过 `iptables` 确认攻击 IP 已被自动拦截并在超时后释放。 ## 检测工作流 ``` Kali attacker (SSH brute force) │ ▼ sshd auth failures on daisy-server │ ▼ Base rule 5710 (non-existent user) fires per attempt │ ▼ Custom rule 100002 (frequency: 5 hits / 120s, same source IP) │ ▼ Alert raised on Wazuh dashboard (level 10) │ ▼ Active Response triggers firewall-drop │ ▼ iptables DROP rule added for attacker IP (300s timeout) │ ▼ Rule 652 fires — IP automatically unblocked after timeout ``` ## 调查过程 - 使用 `wazuh-logtest` 将单行日志直接送入解码/规则匹配管道，以排查问题出在规则逻辑还是 Manager 的配置中 - 将基础规则的行为（规则 5710 正常触发）与自定义规则的未触发状态进行对比，将根本原因缩小为配置问题，而非规则语法问题 - 检查了 `ossec.conf` 中的 `` 块，发现缺少导致 `local_rules.xml` 无法加载的 `rule_dir` 条目 - 对比了仪表板、原始告警日志和导出的电子表格数据之间的结果，以确认一致性 - 将 `iptables` 检查与最新的攻击爆发时间对齐，以便在 Active Response 拦截超时之前正确观察到它 - 注意到并处理了更广泛的威胁狩猎时间窗口中出现的陈旧测试数据（6 月 28-29 日） ## 挑战与故障排除 | 问题 | 根本原因 | 解决方案 | |---|---|---| | 自定义规则完全未触发 | `ossec.conf` 的 `` 块中缺少 `etc/rules` | 添加了缺失的条目并重启了 Manager | | 规则 100002 漏掉了部分登录失败变体 | 使用了指向单个基础规则的 `if_matched_sid` | 更改为 `if_matched_group="authentication_failed"` 以捕获所有登录失败变体 | | 通过 `sudo` 执行 `grep` 没有返回结果 | 在 `sudo` 下直接运行 `grep` 存在引号/管道问题 | 将命令包装在 `sudo bash -c` 中 | | `iptables` 检查未显示拦截 | 在 300 秒的 Active Response 超时时间结束后才进行检查 | 重新执行暴力破解爆发，并随后立即检查 `iptables` | | 事件 ID 4625 和 4720 未返回结果 | 测试窗口期间未生成匹配的活动（Windows 登录失败 / 新建本地账户） | 确认为准确的空结果，而非工具故障 | | Windows agent 未实时获取配置更改 | Windows 需要重启服务才能重新加载 `ossec.conf` | 通过 Windows 服务管理器重启了 `WazuhSvc` | ## 攻陷指标 (IOC) - 在极短的时间窗口内，来自单一源 IP 针对不存在账户 (`baduser`) 的重复 SSH 身份验证失败 - 120 秒内来自同一源 IP 的 5 次以上登录失败的爆发模式 - 意外创建新的 Linux 用户/组（规则 5901/5902）且没有相应的变更请求 - 在受监控主机上发生的 USB 存储设备插入事件（Windows 事件 ID 2003） - 受监控的 FIM 目录内出现原因不明的文件添加/修改/删除 ## MITRE ATT&CK 映射 | 规则 | 技术 ID | 技术 | |---|---|---| | 100001 — 创建了新的 Linux 用户 | T1136 | 创建账户 | | 100002 — SSH 暴力破解 | T1110 | 暴力破解 | | 100003 — 插入了 USB 存储 | T1091 | 通过可移动介质进行复制 | ## 结果 - FIM 在 Linux 和 Windows agent 上均成功实时检测到了文件创建、修改和删除事件 - 在修复规则集配置后，通过 `wazuh-logtest` 和真实告警流量确认所有三条自定义规则均能正常工作 - 模拟的 SSH 暴力破解攻击在多次攻击运行中均被自定义规则 100002 一致检测到 - Active Response 通过 `firewall-drop` 自动拦截了攻击 IP（在 `iptables` 中得到确认），并在配置的 300 秒超时后将其释放 - Windows 事件 ID 4672（特殊权限登录）返回了 9 个合法命中；由于未生成匹配活动，事件 ID 4625 和 4720 未返回结果 - 一项组合威胁狩猎查询（规则 100001、100002、100003、5710、5760、5715）产生了 119 个关联命中，已导出以进行基于电子表格的审查 ## 展现的技能 - SIEM 部署与 agent 管理 - 在 Linux 和 Windows 上进行文件完整性监控配置 - 检测工程 — 编写具有基于频率逻辑的自定义 SIEM 规则 - 使用 `wazuh-logtest` 对未触发的检测规则进行根本原因排查 - 从专用攻击主机进行的攻击模拟（SSH 暴力破解） - Windows 安全事件日志分析（4625、4672、4720） - 跨多台主机的日志关联、导出与威胁狩猎 - SOAR 式自动化响应配置（`firewall-drop` Active Response） - 通过 `iptables` 进行防火墙规则验证 - 为自定义检测进行 MITRE ATT&CK 技术映射 - 清晰、如实地编写涵盖成功经验与死胡同的技术文档 ## 经验教训 - 如果 Manager 未配置加载规则所在的文件，那么编写正确的规则也不会触发 — 检查 `` 块现在是排查的第一步，而不是最后的手段 - 对于需要捕获多个相关子事件的基于频率的规则，`if_matched_group` 比 `if_matched_sid` 更稳健 - 相比于生成实时流量并刷新仪表板，`wazuh-logtest` 在规则调试方面的速度要快得多 - Active Response 会对系统进行真实的更改（不仅仅是告警），这使得超时时间的选择成为一项重要的设计决策 - 威胁狩猎查询中的时间戳需要再三确认 — 过宽的时间窗口可能会暴露出陈旧的、无关的测试数据 ## 未来改进 - 恢复或重新制作场景 1 中缺失的 Linux FIM 截图 - 主动触发 Windows 事件 ID 4625（登录失败）和 4720（新账户），以捕获这些规则的真实检测告警 - 将自定义规则覆盖范围扩展到最初的三个检测之外 - 根据进一步测试调整 Active Response 超时值 - 将组合威胁狩猎查询自动化为保存的仪表板视图或定时报告 ## 资源 - 技术报告 - 截图 - LinkedIn 帖子

标签：PE 加载器, Wazuh, x64dbg, 安全运营, 实验环境, 扫描框架, 自动化响应