4. 高频误报告警的抑制规则调优

为什么“高频误报”不能靠关规则解决

某类告警每天触发上千次，绝大多数来自同一批内部扫描器、监控探针或业务健康检查。直接禁用规则会同时丢掉真实攻击；正确做法是先定位触发条件，再选择抑制、阈值或白名单中最窄的一种手段，把噪声压下去而保留攻击可见性。

以“内部漏洞扫描器触发 Web 攻击特征告警”为例，典型触发链是：扫描器 IP → 固定 User-Agent → 对多个 URL 发起含攻击特征的请求 → WAF/IDS 规则命中 → SIEM 生成告警。抑制规则必须绑定到这条链上可稳定识别的字段，而不是只按“告警名称”一刀切。

从告警样本中提取可抑制字段

调优前先拉取最近 7 天该类告警的原始事件，按以下字段做聚合统计，找出“高频且低风险”的共同特征：

若某组字段组合覆盖了 95% 以上的告警，且这些告警的目标资产均为测试环境、来源均为授权扫描器，则可优先使用白名单；若来源分散但行为高度重复，则用阈值聚合；只有在确认该场景完全无攻击价值时，才使用抑制规则。

编写抑制规则：以 Splunk 为例

以下规则对“来自扫描器网段、User-Agent 为 Nessus、目标为测试环境”的 SQLi 告警进行白名单抑制，同时保留原始事件用于审计：

# 白名单抑制规则（Splunk savedsearches.conf 片段）
[SQLi_Scanner_Whitelist_Suppress]
search = index=waf sourcetype=waf:alert rule_name="SQLi-*"
  | eval is_scanner=if(cidrmatch("10.20.30.0/24", src_ip) AND
      match(user_agent, "Nessus|AppScan|AWVS") AND
      dest_asset_tag="test-env", 1, 0)
  | where is_scanner=0
  | table _time, src_ip, dest_ip, rule_name, url, user_agent
schedule = */5 * * * *
alert.suppress = 1
alert.suppress.period = 1h
alert.suppress.fields = src_ip, rule_name

关键点：where is_scanner=0 只过滤掉白名单内的告警，其余告警仍正常触发；alert.suppress.fields 按源 IP 和规则名去重，避免同一扫描器对同一规则反复告警。

阈值聚合规则：把 1200 条压成 1 条

若扫描器 IP 不固定，无法做白名单，则改用阈值聚合。以下规则在 5 分钟窗口内统计同一源 IP 触发同类规则的次数，超过 50 次才生成一条“扫描行为”告警：

# 阈值聚合规则（Splunk correlation search）
[SQLi_Scanner_Threshold_Aggregate]
search = index=waf sourcetype=waf:alert rule_name="SQLi-*"
  | bin _time span=5m
  | stats count as hit_count, dc(url) as url_count by src_ip, rule_name, _time
  | where hit_count >= 50
  | eval severity="medium", category="scanning-activity"
  | table _time, src_ip, rule_name, hit_count, url_count, severity
schedule = */5 * * * *
alert.suppress = 1
alert.suppress.period = 30m
alert.suppress.fields = src_ip, rule_name

这样单次可疑请求仍会触发原始告警，只有高频重复行为才被聚合，既降低噪声又不会掩盖真实攻击。

验证：噪声下降且不掩盖攻击

规则上线后，用以下方法验证：

1. 噪声对比：统计规则生效前后 24 小时该类告警数量，预期下降 ≥ 90%。
2. 攻击可见性：用非白名单 IP 模拟一次 SQLi 请求，确认仍能触发告警。
3. 审计回溯：确认被抑制的原始事件仍写入索引，可通过 index=waf is_scanner=1 查询。
4. 误杀检查：检查是否有真实攻击源恰好落在白名单网段内，若有则收窄白名单条件。