如何使用小语言模型(SLM)从 Wazuh 日志与防火墙 Syslog 中检测网络攻击

安全运营中心(SOC)每天都被大量告警淹没。一家中型企业若在数百台终端上运行 Wazuh,再加上 FortiGate 等防火墙转发的 Syslog,每天轻松产生数万条事件。传统的基于规则的关联分析擅长捕捉已知模式,但对长尾威胁往往力不从心:表面上互不相关、实际上语义相关的告警群、缓慢渗透的侦察行为,或只有人类分析师才能识别出的可疑上下文。

这正是小语言模型(SLM)——不是庞大的前沿模型,而是本地部署运行的 70 亿至 140 亿参数级紧凑模型——在流程中发挥作用的地方。它不会取代 Wazuh 的检测引擎或 SIEM 的关联规则,而是位于其下游,将结构化的告警噪声转化为分析师可直接使用的推理结果。

为什么选择 SLM 而非 LLM

对于 SOC 工作负载而言,通常有三个限制条件会排除大型托管模型:

• 数据驻留要求。 受监管行业的企业客户很少允许原始安全日志离开其网络,这使得大多数基于 API 的前沿模型无法使用。
• 大规模场景下的延迟与成本。 每天对数千个告警集群评分,需要一个调用成本低、速度快的模型,而不是按前沿模型资费按 token 计费的模型。
• 任务本身并不需要前沿级推理。 将告警群按 MITRE ATT&CK 技战术分类,或撰写两句话的事件摘要,只要提示词设计得当,7B–14B 规模的模型就足以胜任。

像 Llama 3.1 8B、Qwen2.5 14B 或 Phi-4 这样的模型,通过 vLLM 或 Ollama 在本地部署运行,能取得恰到好处的平衡:指令遵循能力足以支撑结构化 JSON 输出,体积又小到可以在客户自有环境的单块 GPU 上运行。

SLM 在流程中的位置

应避免的错误是把原始日志直接输入模型。Wazuh 和防火墙已经完成了标准化处理——应充分利用这一点。SLM 的工作应从聚合(aggregation)之后开始,而不是之前。

flowchart TD
    A["Wazuh 代理 + FortiGate Syslog"] --> B["Wazuh 管理端:规则匹配与标准化"]
    B --> C["OpenSearch:按源 IP / 时间窗口聚合告警"]
    C --> D["SLM 评分服务:分类、摘要、映射至 MITRE ATT&CK"]
    D --> E["DFIR-IRIS:创建带增强信息的案件"]
    E --> F["Shuffle SOAR:根据 SLM 判定结果分支处理"]
    F --> G["PagerDuty:上报给分析师"]

Wazuh 告警本身已是结构化的 JSON——包含规则 ID、严重级别、代理信息、源/目的 IP 以及原始日志行。在告警进入模型之前,先按短时间窗口(例如五分钟)、按源 IP 或用户对相关告警进行聚合。这样可以让 SLM 针对精简的事件序列进行推理,而不是解析海量文本,从而同时降低成本并提高准确率。

SLM 真正擅长做什么

规则引擎精确但缺乏灵活性。它们擅长判断"这一确切的日志模式已经发生",却不擅长识别"这一系列本身看似平常的事件组合起来,像是一次正在进行的攻击"。这正是 SLM 能够发挥价值的差距所在:

• 事件摘要。 将 12 条相关的 Wazuh 告警,转化为值班分析师五秒内就能读完的两句话摘要,而不必翻阅原始日志。
• 跨日志源的模式推理。 将 FortiGate 上密集出现的连接拒绝,与同一源 IP 随后出现的一连串 Wazuh 认证失败关联起来,并说明为何这种组合类似于密码喷洒(password spraying)或撞库攻击(credential stuffing)——除非事先有人针对这种特定组合专门编写过规则,否则静态关联规则往往会遗漏这类推理。
• 抑制误报。 结合简短的嵌入式上下文(资产重要性、已知的维护窗口、预期的管理员行为)对告警评分,在 DFIR-IRIS 中创建案件之前就减少噪声。

输出应结构化,而非自由文本

模型不应返回一段需要 SOAR 平台用正则表达式解析的文字。应通过提示词要求其返回严格的 JSON:

{
  "severity": "high",
  "mitre_technique": "T1110.003 - Password Spraying",
  "summary": "17 failed logins across 4 accounts from a single external IP within 6 minutes, followed by one successful login.",
  "recommended_action": "disable_account_and_escalate",
  "confidence": 0.82
}

这样一来,Shuffle 便可以直接根据 severity 和 recommended_action 字段进行分支处理:将高置信度、高严重性的案件直接上报至 PagerDuty,而置信度较低的案件则排队等待分析师复核。

护栏比准确率更重要

最重要的设计决策,是明确规定模型"不能"做什么。SOC 流程中的 SLM 应仅起顾问作用——负责摘要、分类和建议,但绝不能自动关闭案件或自动修复系统。对于超过设定严重级别阈值的任何情况,都必须保留人工复核环节。这并非单纯出于谨慎,而是决定了在客户审计中面对误报漏报(false negative)时,SOC 流程是否站得住脚的关键。

没有标注数据也能起步

大多数组织并没有一份干净的"告警集群 → 正确判定"数据集可用于微调,这完全没问题。可以先从高质量的少样本提示(few-shot prompting)入手——在系统提示词中,连同组织自有的规则说明一起,嵌入几个带有正确 MITRE 映射和严重级别的告警集群示例——即可让 7B–14B 规模的模型立即达到可用的准确率。等积累了几百个经分析师验证的真实事件后,再进行微调会更有价值。

最终形成的 SOC 流程中,Wazuh 与防火墙继续做它们最擅长的事——快速、确定性的检测——而 SLM 则承担起过去往往需要凌晨两点疲惫不堪的分析师盯着屏幕才能完成的、更复杂、更依赖上下文的推理工作。