文章总结： 文档分析了Wazuh规则5108将LinuxOOM事件作为高优先级安全告警推送SOC通道引发的噪音问题，指出OOM本质属于系统可用性故障而非安全事件。作者建议通过自定义规则将此类告警静默并移交监控平台处理，详细给出了XML配置代码、部署验证步骤及适用场景建议。该方案有助于明确SOC职责边界，降低告警疲劳，从而提升安全运营中心信噪比与响应效率。 综合评分： 96 文章分类： 安全运营,安全工具,实战经验,应急响应,安全建设
Wazuh 实战：为什么 OOM 告警不该进 SOC 主通道
原创
imBobby imBobby
imBobby的自留地
2026年3月25日 16:47 广东
事件背景
某生产环境在夜间收到一条 P0：
[P0 严重] Wazuh 安全告警规则 ID：5108 告警级别：Level 12描述：System running out of memory. Availability of the system is in risk.
现场问题确实存在：主机触发了 Linux OOM Killer，业务进程被杀。 事件分析显示，争议点不在“是否严重”，而在“是否应该走安全告警通道”。
问题不在严重性，而在归属
OOM 是高优先级故障，但默认归类更接近可用性事件。 SOC 主通道更适合承载“需要安全响应链路第一时间处理”的事件。
从职责边界看，HIDS 更适合关注这类内容：
- 异常登录、暴力破解、提权链路
- 关键文件完整性变更
- 恶意进程、可疑持久化行为
- 具备攻击语义的系统调用与审计轨迹
而以下内容更适合监控平台主责：
- 内存耗尽（OOM）
- 磁盘容量、CPU 饱和
- 服务吞吐/延迟劣化
- 网络带宽拥塞
在实践中，如果把 OOM 按 Level 12 直接推到 SOC 主通道，常见副作用是：
- 告警响应人员疲劳加重
- 入侵类告警被噪音稀释
- 安全通道逐步失去“高可信”属性
内置规则 5108 拆解
5108 的定义位于 0020-syslog_rules.xml：
<!-- /var/ossec/ruleset/rules/0020-syslog_rules.xml --><rule id="5108" level="12"> <if_sid>5100</if_sid> <match>Out of Memory: </match> <description>System running out of memory. Availability of the system is in risk.</description> <mitre> <id>T1499</id> </mitre> <group>service_availability,...</group></rule>
触发路径通常是：
- 内核日志出现
Out of Memory: - 5100 完成
program_name=kernel预匹配 - 5108 命中并按 Level 12 触发
这意味着它会绕过很多常规过滤，直接进入高优先级告警流。
同属 510x 的规则中，像 5103（Ping of Death）和 5104（网卡混杂模式）具备更直接的安全语义，优先级策略通常应当区分处理。
关于 MITRE 映射的实际含义
5108 映射到 MITRE ATT&CK T1499（Endpoint Denial of Service）并不等同于“每次 OOM 都是攻击”。
在真实生产环境中，OOM 的常见来源往往是发布回归、内存泄漏、容器限额缺失或批处理配置问题。
因此更稳妥的策略是：
- 在可用性监控链路中把 OOM 当成核心故障持续追踪
- 在安全链路中优先检测“导致资源耗尽的可疑行为”
处理方案：在 Wazuh 中静默 5108，由监控平台承接
Wazuh 支持通过子规则覆盖内置规则。
下面的做法是继承 5108 并设置 level=0：
/var/ossec/etc/rules/custom_syslog_suppress.xml
<!-- 屏蔽 OOM 对应的内置规则 5108 --><group name="local,syslog,linuxkernel,">
<rule id="100108" level="0"> <if_sid>5108</if_sid> <description>Suppressed: OOM alert is infra issue, not security event</description> </rule>
</group>
落地时有四个细节值得保留：
- 自定义规则 ID 通常使用
100000+段，避免与内置规则冲突 group与父规则语义保持一致，后续检索更直观level=0表示完全静默，不进入告警推送- 规则文件不要加
<?xml ...?>头，Wazuh 规则文件通常不带该声明
部署与验证
1) 写入规则
sudo tee /var/ossec/etc/rules/custom_syslog_suppress.xml > /dev/null << 'EOF2'<!-- 屏蔽 OOM 对应的内置规则 5108 --><group name="local,syslog,linuxkernel,">
<rule id="100108" level="0"> <if_sid>5108</if_sid> <description>Suppressed: OOM alert is infra issue, not security event</description> </rule>
</group>EOF2
2) 设置权限
sudo chown root:wazuh /var/ossec/etc/rules/custom_syslog_suppress.xmlsudo chmod 640 /var/ossec/etc/rules/custom_syslog_suppress.xml
3) 使用 wazuh-logtest 验证
sudo /var/ossec/bin/wazuh-logtest
输入样例：
Mar 25 00:00:00 myserver kernel: Out of Memory: Killed process 12345 (python3)
预期关键字段：
id: '100108'level: '0'description: 'Suppressed: OOM alert is infra issue, not security event'
4) 重启 Manager
sudo systemctl restart wazuh-managersudo systemctl status wazuh-manager
什么时候不宜直接静默
以下场景更适合先“降级和分流”，不要一步到位静默：
- 现网尚未建立完善的主机资源监控与告警
- 正在排查疑似资源耗尽型攻击
- 响应流程尚未形成可用性事件闭环
实践里更稳妥的路径通常是：先降级到次级告警通道，运行一段时间观察误报与漏报，再决定是否彻底静默。
总结
这种调整的核心不是“弱化 OOM 事件”，而是把事件放到正确通道：
- 安全通道只承载安全响应链路需要优先处理的内容
- 可用性故障交给监控体系做持续跟踪与恢复治理
告警边界清晰后，SOC 通道的信噪比和响应效率都会明显提升。
参考资料
Wazuh 官方文档
- Custom Rules – 自定义规则、
if_sid继承与覆盖 - Rules Classification – Level 0-15 分级语义
规则源码
- 0020-syslog_rules.xml – 规则
5108定义与 510x 规则组
MITRE ATT&CK
- T1499 – Endpoint Denial of Service – 5108 对应技术映射
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：imBobby的自留地 imBobby imBobby《Wazuh 实战：为什么 OOM 告警不该进 SOC 主通道》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论