路由器把正常业务拦成攻击告警？两步向 ET Open 报告误报

痛点场景

路由器上的 Threat Prevention（威胁防护）开了一阵子，某天上午公司内部一个管理页面突然打不开、某项云端业务时通时断。进事件一查，一条"检测到攻击行为"赫然在列，而源地址与目的地址分明都是自家正常业务。业务没错、网络没错，错的是检测规则——这就是误报。

误报不管它，事件列表天天刷屏，真攻击反而被淹没；一气之下关掉整套防护，又把安全底线丢了。正确姿势是第三条路：向特征库官方报告误报，让规则在源头修正。

检测规则从哪来

Threat Prevention 基于 Suricata 引擎，与 ET Open 数据库结合使用，监控入站和出站流量。ET Open 是社区维护的开放入侵检测特征库，靠海量签名（行为特征）逐条匹配流量。覆盖面广的代价就是个别签名会误伤正常业务——这不是缺陷的终点：通过报告误报，可以帮助提高检测准确性并增强系统效率，官方为此提供了正式的反馈通道。

第一步：在事件页记下签名 ID

• 前往 SRM > Threat Prevention > 事件；
• 找到那条误报事件，记下它的行为特征 ID（即签名 ID，术语上叫 SID）。

顺手在事件详情里复核一眼源地址、目的地址与端口，确认命中的确实是自家正常业务流量——把真攻击当误报报出去，方向就反了。

第二步：提交 ET 反馈表

向 ET Open 报告误报需提交 ET 反馈表（Emerging Threats 官网的表单）：

• 问题类型选择"误报"；
• SID 一栏填入上一步记下的行为特征 ID；
• 表单其余必填信息补齐（命中的业务流量说明、大致时间与频率等，写得越具体越利于复核）；
• 单击发送反馈提交。

至此反馈进入 ET Open 的规则修正流程，后续版本的特征库更新会带出修正后的签名。

提交之后做什么

• 保持 Threat Prevention 及特征库随 SRM 更新——误报修正要靠库更新分发到设备；
• 等待期间持续观察事件页：该签名的命中频率、是否还拦同一业务，作为后续跟进依据；
• 多台路由器的环境，同一签名报一次即可，其余设备等同一个库更新。

预防与建议

• 给运维团队维护一份"已知误报签名清单"：签名 ID、涉及业务、报告日期一列列记清，值班新人看到告警先对表，不打无准备的仗；
• 特征库更新后回看一遍历史高频道告警，确认旧误报是否已被修正消化；
• 误报报告值得养成习惯——报的人越多，开放特征库对正常业务的甄别就越准，整个生态受益。

诚鑫致达科技在客户现场的威胁防护运维记录里专设一页"误报台账"，每笔都跟着签名 ID 和反馈状态——安全设备告警的可信度，就是靠这样一单一单喂回来的。