ChrisHuber1/siem-automation

# SIEM 自动化 针对 Wazuh SIEM 部署的自动化监控、分类和告警。在我的 Wazuh manager 崩溃且宕机 3 天都没人（包括我自己）发现后，我构建了这个系统。 该系统包含三个部分：一个用于检测并自动重启失败 SIEM 服务的 watchdog，一个用于分类告警并发送每日报告的 AI 驱动的分类 bot，以及一个用于检查标记的漏洞是否实际影响受影响主机的 CVE 验证 pipeline。 ## 为什么会有这个项目 我在一个包含多台 Linux 主机的家庭实验室中运行 Wazuh。2026 年 5 月，Wazuh manager 在重启后崩溃了；`/var/ossec/var/run/` 中过期的 PID 文件导致服务无法重启。因为生成告警的系统正是宕机的那个系统，所以没有生成任何告警。 3 天后我碰巧手动检查时才发现。这是不可接受的。 ## 组件 ### SIEM Watchdog 按 cron 计划运行，通过 SSH 登录到 SIEM 主机，并检查 Wazuh 服务的健康状况。 - 检测过期的 PID 文件并在重启前清除它们 - 自动重启崩溃的服务（每 24 小时最多尝试 2 次，以避免重启循环） - 成功重启 = HIGH 级别发现；重启失败 = CRITICAL 级别 + 电话通知 - 在 JSON 状态文件中跟踪重启尝试，避免无休止地重试 ### 2. AI 分类 Bot 通过 SSH 获取最近的 Wazuh 告警，使用 Claude 对其进行分类，并发送每日摘要。 - 预检健康检查：如果 Wazuh manager 宕机，会立即发送紧急告警，而不是尝试从死掉的服务中获取告警 - 零告警 + 健康 manager 会被标记为异常情况（而不是“平静的一天”） - 优雅处理 SSH 失败；不再因无法访问的主机而崩溃 - 通过 ntfy 推送通知发送报告 ### 3. CVE 验证 Wazuh 会激进地标记内核 CVE。其中大多数实际上并不适用于正在运行的内核版本。 - 从 Wazuh 告警中提取标记的 CVE - 通过 NVD API 检查每个 CVE 的受影响版本范围 - 与每台主机上实际运行的内核版本进行比较 - 生成报告：确认真实 vs. 误报，并附带推理过程 - 误报将获得 Wazuh 规则覆盖（level 0 抑制），从而停止生成告警 **示例发现：** Wazuh 在一台运行 6.8 版本内核的主机上标记了 CVE-2026-31461。NVD 的受影响范围从 6.13 开始。这是一个误报；该主机并未运行存在漏洞的版本。已添加抑制规则。 ### 4. 告警 - 所有 CRITICAL 发现均发送 ntfy 推送通知 - 基于文件的冷却时间（每个 agent 1 小时），防止 cron 运行产生告警垃圾信息 - 通过 Windows SAPI 发出“Master we need your input”的语音提示，用于人工介入决策 ## 决策与权衡 **选择 ntfy 而非 PagerDuty/Slack：** 这是家庭实验室，不是企业环境。ntfy 是免费且可自托管的，我可以在 30 秒内在手机上订阅。PagerDuty 有点大材小用。Slack 需要一个 workspace。而 ntfy 就能直接工作。 **基于文件的冷却而非速率限制：** 速率限制器会更优雅，但带有时间戳的文件是可调试的。我可以通过读取文件来查看上一次告警是何时触发的。如果冷却机制坏了，我可以通过删除一个文件来修复它。 **每 24 小时最多重启 2 次：** 无限重启循环比服务宕机更糟糕。如果服务在尝试 2 次后仍然无法保持运行，说明存在根本性的问题，需要人工介入查看。 **使用 Claude 进行分类，而非检测：** Wazuh 负责检测。Claude 负责对结果进行分类和优先级排序。使用 LLM 进行检测会漏掉 Wazuh 专门构建的基于规则的模式。 **自定义 Wazuh 规则而非修改默认设置：** 误报覆盖在 `local_rules.xml` 中使用自定义规则（100100+ 范围），从不修改默认规则集。这在 Wazuh 升级中得以保留，并且可以轻松查看到底调整了哪些内容。 ## 误报调整 | 规则 ID | 抑制内容 | 原因 | |---|---|---| | 100101 | 来自运维主机的 Root SSH | Cron 任务以 root 身份进行 SSH 健康检查；并非未经授权的访问 | | 100160 | CVE-2026-31461 | NVD 受影响范围从 6.13 开始；主机运行的是 6.8 | | 100170 | SIEM 主机上的 Sudo 告警 | Cloud-init 默认为服务账号提供 NOPASSWD ALL 权限 | ## 架构 ``` Cron (hourly) | v +-------------------+ +------------------+ | SIEM Watchdog |--SSH-->| SIEM Host | | (check health, | | (Wazuh manager) | | auto-restart) | +------------------+ +-------------------+ | v (findings) +-------------------+ +------------------+ | Triage Bot |--SSH-->| Wazuh API | | (Claude classify, | | (fetch alerts) | | daily report) | +------------------+ +-------------------+ | v (alerts) +-------------------+ | ntfy push |----> Phone notification | Windows SAPI |----> Audible alert +-------------------+ ``` ## 当前状态 正在我的家庭实验室的生产环境中运行。自部署以来，watchdog 已捕获并自动解决了两次 Wazuh manager 崩溃。CVE 验证消除了每个扫描周期中 10 个虚假的严重告警。分类 bot 每天都会将摘要发送到我的手机上。 ## 我会做出哪些改变 - 为 SIEM 健康状况添加 Prometheus 指标，而不是仅仅依赖基于 SSH 的检查。这将为我提供历史正常运行时间数据以及与 Grafana 的告警集成。 - CVE 验证可以缓存 NVD 响应，以避免在不同的扫描周期中对相同的 CVE 进行重复的 API 调用。

标签：Homebrew安装, Maven, Python, Wazuh, 内存分配, 告警分类, 大模型, 无后门, 漏洞验证, 自动化运维, 逆向工具