WAF误拦截与真实攻击如何区分

昨晚改完站点防火墙规则，我兴冲冲去后台发文章，结果页面直接甩给我一个 403。第一反应是“完了，被打了”，第二反应是“我是不是把自己给拦了”。相信不少折腾过宝塔 WAF 的朋友都经历过这种心跳——改完规则后，正常业务反而先躺枪。

我的经验是，别急着关防护，先看客户端到底返回了什么。如果浏览器弹的是防火墙自带的拦截提示页，或者干脆一个标准 403，那大概率是 WAF 在边缘层动手了；可要是返回 500、502，或者应用自己吐出的 JSON 错误体，比如提示 token 无效，那问题多半在后端 PHP/Node.js 运行环境或数据库，这时候去防火墙里翻半天纯属白费劲。

确认是防火墙干的之后，我会让操作的人原样复现一次受阻行为，同时记下精确到秒的时间戳、公网 IP、完整 URL 和请求方式。然后进防火墙插件的拦截日志模块，按 IP 和时间段筛出那条记录，重点看三样东西：命中的是 SQL 注入、XSS、POST 过滤还是 CC 防御；被判定为恶意的是请求头、URL 参数还是表单体里的哪一段；以及 User-Agent 是不是因为用了 Postman 或 Python 脚本被爬虫策略一票否决了。这一步就像破案找证据，比瞎猜快得多。

找到原因后，最考验人的是判断这到底是误伤还是真攻击。我自己踩过的坑是：在后台发一篇讲 SQL 优化的教程，正文里带了 UNION SELECT 字样，直接被 SQL 注入规则拦下——这明显是内容与规则打架，属于误拦截。但如果接口在公网被陌生客户端塞进恶意格式，那就算偶尔误伤也不能全站撤防。判定完再动手，而且坚决不干“关整站防火墙”“全局关掉 SQL 注入防御”这种图省事的事，那等于把门全敞开。

微调我一般按影响范围从小到大来：某个接口频繁误触，就只在 URL 白名单里针对那个路径跳过特定那条规则；全局规则太严，就微调触发它的正则；如果是固定第三方回调，比如支付通知或 Webhook，就用 IP 白名单加特定回调 URL 的组合放行，绝不对公开接口全面撤防。

改之前一定截图或导出配置留底，写清楚动了哪条规则、针对哪个路径。改完用完全一致的请求体、IP 和客户端环境复测，确认响应码恢复正常；再拿明显的测试攻击载荷去打非白名单路径，确认其他接口的拦截能力还在。之后两到四小时盯着实时日志，看有没有新的变相拦截，或者异常流量绕过规则打进来。一旦出现不可预测的异常，立刻按记录回滚，重新设计放行粒度。

最后提醒一句，也是我反复告诫自己的：拦截日志只能说明流量在边缘被匹配了，绝不等于后端漏洞已经修好。高频触发拦截的入口，代码层的参数化查询、数据净化和权限校验该做还得做，别把宝全押在 WAF 上。