JSON-MSON/siem-home-lab

# 家庭 SIEM 实验环境 (Wazuh) ## 演示内容 构建并验证一条真实的自定义 SIEM 检测规则 —— 不仅是安装 Wazuh，而是证明一条规则确实能够捕获其设计用于防范的攻击，在它悄无声息地失效时进行调试，并在宣布完成之前通过真实的现场攻击确认修复结果。 ## 环境配置 - **Wazuh manager、indexer 和 dashboard：** 自托管，单节点，运行于 Ubuntu Server 虚拟机上 - **受监控主机：** 同一台虚拟机，通过 Wazuh 内置的本地自我监控（agent ID `000`）实现 —— 根据设计，在 manager 主机上不需要也无法安装独立的 agent - **攻击者：** Kali Linux 虚拟机，位于同一隔离的实验网络中 - **攻击工具：** Hydra，SSH 凭据暴力破解 ## 流程 ### 1. 确认 manager 监控自身 Wazuh manager 会自动包含一个内置的本地 agent（ID `000`）来读取主机自身的日志 —— 独立的 `wazuh-agent` 包无法与 `wazuh-manager` 安装在同一台机器上；包管理器本身会将其作为冲突阻止，因为这没有必要。 ``` sudo /var/ossec/bin/agent_control -l ``` 已确认：`ID: 000, Name: ubuntu-target (server), IP: 127.0.0.1, Active/Local` ### 2. 将认证日志添加为监控源 ``` syslog /var/log/auth.log ``` 添加到 `/var/ossec/etc/ossec.conf` 中，与 manager 现有的默认监控源并列。 ### 3. 编写用于 SSH 暴力破解尝试的自定义检测规则 ``` 5760 Multiple SSH authentication failures from same source - possible brute force (T1110) T1110 ``` 此规则将来自同一源 IP 的重复 SSH 身份验证失败升级为带有标签的暴力破解告警，并映射到 MITRE ATT&CK 技术 **T1110 (Brute Force)**。 ### 4. 调试 —— 规则在首次尝试时未触发 一次实时的 Hydra 运行产生了 206 次告警命中，但没有一个是自定义规则触发的 —— 它们属于另一条不相关的 Wazuh 内置规则。与其假设规则已损坏并猜测修复方法，不如直接使用 `wazuh-logtest` 对照已知的样例日志进行验证，这暴露了两个真实且截然不同的 bug： - **缺少 `frequency`/`timeframe` 属性。** `` 要求在 `` 标签本身上设置这些属性，以定义可计数的窗口时间 —— 没有它们，规则就没有实际的评估逻辑，并且会悄无声息地永远不触发，无论其他所有内容看起来多么正确。 - **基础规则 ID 错误。** 该规则原本用于监视规则 `5716` 的出现，但 `wazuh-logtest` 显示，在这种 Wazuh 版本上，这种特定的日志格式实际上解码为规则 `5760` —— 这是一个差一位的错误假设，即使应用了 frequency/timeframe 的修复，也会使该规则永久失效。 ### 5. 在重新攻击之前，直接验证修复结果 ``` sudo /var/ossec/bin/wazuh-logtest ``` 同一行样例日志，提交四次（匹配 `frequency="4"` 阈值），在第四次提交时正确触发了规则 `100010` —— 通过工具自身的输出得到确认，不依赖于任何实时网络流量。 ### 6. 通过真实攻击进行确认 ``` hydra -t 4 -l codemane1 -P /usr/share/wordlists/rockyou.txt ssh://192.168.81.130 ``` （`-t 4` 限制并行连接 —— OpenSSH 自身的 `PerSourcePenalties` 防御机制开始丢弃来自攻击者的连接，因为 Hydra 默认使用 16 线程设置，这是一个值得注意的真正的 SSH 加固功能。） 结果：规则 `100010` 在针对真实攻击流量时触发了 23 次，正确归因了源 IP（`192.168.81.128`）并引用了 MITRE 技术 T1110。 ## 关键发现 一条“看起来正确”的检测规则和一条真正能触发的检测规则是两码事。两个独立且具体的 bug —— 缺少 frequency/timeframe 配对以及基础规则 ID 不正确 —— 都必须被找到并修复，这条规则才能捕获到任何东西；而且如果先直接进行现场攻击，而不是先针对 `wazuh-logtest` 进行测试，这两个 bug 都不会显而易见。这就是检测工程背后的真正规范：先在隔离环境中验证逻辑，然后再针对真实流量进行确认 —— 而不是反过来。 ## 此仓库中的文件 - `wazuh_detection_evidence.json` —— 来自实时 Hydra 触发检测的真实告警记录，包括 `firedtimes`、源 IP 和 MITRE 映射 - `screenshots/` —— 见下文 ## 截图    ## 在生产环境中我会采取的不同做法 - 将使用 `wazuh-logtest` 测试每条自定义规则作为固定的首要步骤，而不是在实时测试失败后的备用手段 —— 这样就能在几分钟内捕获此处的两个 bug，而不是在一整轮攻击运行之后。 - 在首次尝试之前调整 Hydra 的线程数，使其保持在任何已启用的 SSH 速率限制之下，而不是通过一次失败的运行来发现限制阈值。 - 扩展此规则集，以涵盖与此实验环境相关的其他映射到 MITRE 的技术（例如，特权升级尝试、异常的 sudo 活动），而不是在验证了一条规则后就止步不前。

标签：AMSI绕过, Wazuh, 威胁检测, 安全实验环境, 安全运营, 扫描框架