用本地 Qwen 搭建人工掌控的告警分析实验室

把本地大模型接进安全告警系统，最难的未必是让它写出分析报告，而是确保告警没漏、处理状态能恢复、模型不会把日志里的恶意文本当成指令。

作者用 Wazuh、OpenSearch 和本地 Qwen 搭了一个人工运行的安全运营中心（SOC）实验室。它验证了一个有限但实用的方向：AI 可以辅助调查，前提是数据链路可靠、结论经过校验，而且基础设施的操作权始终留在人手里。

模型只负责分析，系统怎样守住权限边界

这套实验环境分成两部分：Ubuntu 24.04 虚拟机承担安全事件采集和 Wazuh 服务，Windows 工作站运行 Python 助手与 LM Studio。

Wazuh Agent 从 Ubuntu 终端采集事件，Wazuh Manager 处理告警，OpenSearch Indexer 保存数据。Python 助手负责查询和整理，SQLite 记录处理状态及报告，LM Studio 承载 Qwen 3.5 4B Instruct，最后由人工分析员审核结论、决定下一步。

这里的关键不是组件数量，而是权限分工。助手使用受限的只读账号，通过 SSH 端口转发访问 Indexer，并进行 TLS 验证。AI 不能执行防火墙命令、修改服务器配置，也不能自动封禁 IP。

模型可以提出调查建议，但没有执行处置的权限。

这比单纯在提示词里要求模型「不要乱操作」更具体：即使输出出了问题，也没有直接修改基础设施的执行通道。不过，作者明确说，这只是人工操作的概念验证，没有实现持续监控，也不是生产级 SOC。

告警取不全，分析写得再好也不可靠

最初的 Python 客户端只取最新 20 条告警。演示时够用，事件一多就可能漏掉需要调查的记录。模型拿到的材料不完整，后面的报告自然可能偏离实际情况。

作者改用 OpenSearch Scroll 分页，读取符合查询条件的有限快照。一次集成测试中，OpenSearch 报告有 152 条匹配告警，客户端取回 152 条，并验证了 152 个唯一事件 ID。

这组数字支持的是：那次查询快照的分页读取正常。它不能证明系统覆盖了全部历史告警，也不能证明持续产生的新事件都会被捕获。作者还遇到过 Scroll 清理操作的权限问题，需要调整 reader 权限，让查询流程能够正常收尾，同时避免给予多余访问能力。

状态管理也做了类似调整。最初，已处理事件 ID 保存在 JSON 文件中；后来迁入 SQLite，用来保存事件标识和事件报告，改善恢复与重试的可靠性。

验证包括迁移已有的 20 个事件 ID、确认数据库完整性，以及在 Markdown 导出文件缺失后，从数据库恢复一份合成事件报告。

这些工作看起来没有模型推理亮眼，却决定了流程能不能继续跑。报告文件丢失后是否需要重新调用模型，失败后重试会不会重复处理，都需要应用保存可信的状态，不能指望模型替系统记住。

JSON 合法，不代表安全结论正确

Python 助手通过 LM Studio 的本地 API 兼容端点调用 Qwen，把选定事件交给模型，并要求输出结构化 JSON。保存报告前，应用会检查必需字段。

一次合成 SSH 认证失败事件测试中，模型给出的处置分类是 SUSPICIOUS，建议继续调查并检查相关日志。这说明调用和输出流程可以工作，却不足以证明模型判断准确。

作者观察到，模型可能混淆客户端源端口与目标服务端口，也可能把一次登录失败理解成暴力破解。前者读错了网络字段，后者则把有限证据扩展成了更强的判断。因此，报告需要区分「日志已经显示的事实」与「模型提出的假设」。

日志还可能携带提示注入（Prompt Injection）。攻击者把操纵模型的文字塞进日志内容，试图让它把认证失败判断成认证成功。

作者用合成 SSH 日志做过实验。在一次有记录的复测中，模型保留了登录失败的判断；但更早的测试曾出现封禁 IP 的不安全建议。随后，作者加入保守的建议过滤和回归测试，约束输出符合只读调查范围。

安全日志是待分析的证据，不能成为模型要服从的指令。

一次复测通过，只能说明该样例下的表现。它没有证明系统能抵抗所有提示注入，过滤建议也不等于保证每条建议都安全。

我的判断

这篇最有价值的地方，是作者没有把「本地模型能生成报告」包装成「安全分析已经自动化」。数据检索、持久化、输出校验和权限限制，都被放在了具体实现里讨论。

仓库包含 31 个使用模拟对象、可离线运行的 Python 测试，通过 GitHub Actions 在 Python 3.10 和 3.12 上执行，并覆盖事件身份、持久状态、结构化响应与只读边界等检查。这些证据有助于确认程序按预期工作，但不能替代真实攻击场景下的检测评估。

原文没有提供误报率、漏报率、调查耗时或模型性能对照，也没有比较纯规则报告与 Qwen 报告的实际收益。因此，「它能帮分析员省多少事」仍缺少数据支持。作者计划补充更真实的告警回放、更好的性能测量，以及更强的本地模型网络限制。

我的取舍是：字段提取、事件计数、明确的规则匹配，优先交给确定性代码；模型更适合整理证据、提出待核查的问题。全靠模板可能缺少解释弹性，全靠模型又容易把推测写成结论，两者需要有清楚的分工。

本地部署也不能直接等同于安全。作者明确承认，本地模型服务的网络限制仍需进一步验证。人工审核是必要环节，但审核者也必须能看到原始证据，才有条件判断模型有没有读错。

能拿来做什么

• 给日常 AI 日志分析工具增加模型前，先验证查询分页和事件身份。可以沿用文中的核对思路，对照匹配总数、实际取回数量和唯一事件 ID 数量，并明确验证覆盖的是哪次查询快照。
• 用 Python 或 Node 编排分析流程时，把处理状态与导出文件分开保存。参考作者的 SQLite 做法，让报告可以重新导出，避免文件缺失后只能从头处理。
• 展示 AI 调查报告时，分别呈现原始证据、模型假设和建议动作。除了校验 JSON 字段，还要核查端口含义、事件次数等技术上下文，避免把结构正确误当成结论可靠。
• 把含有操纵指令的日志纳入回归样例，并在权限层限制助手能力。若当前目标只是辅助调查，就让系统保持只读，具体处置继续由人决定。