1. 引言
在一次真实的线上攻击事件中，WAF 的防护规则没有被突破，攻击日志里也没有明显的拦截告警，但业务系统却出现了大面积不可用。这个现象让很多同学感到困惑：WAF 明明还活着，为什么业务还是被打瘫了？本文结合这次攻击的完整复盘，梳理 WAF 完好但业务瘫痪的根因，并给出可落地的改进建议。
2. 攻击现象回顾
攻击当天，业务侧最先感知到的是接口响应变慢，随后出现大量超时和 5xx 错误。运维同学第一时间检查 WAF 控制台，发现防护状态正常，规则引擎运行正常，也没有触发明显的拦截策略。进一步排查后，确认 WAF 本身没有被绕过，也没有出现规则误杀导致的误拦截。
但与此同时，后端服务的 CPU 和内存持续走高，数据库连接数被打满，部分核心接口的 P99 延迟从几十毫秒飙升到数秒。业务最终进入半瘫痪状态，用户请求大面积失败。
3. 为什么 WAF 完好，业务依旧瘫痪
WAF 的核心职责是识别和拦截恶意请求，但它并不是全能的。下面从几个维度拆解这次事件中 WAF 没有拦住、业务却被打瘫的原因。
3.1 攻击流量没有命中 WAF 的检测规则
WAF 的检测主要依赖规则库和语义分析，针对的是明显的攻击特征，比如 SQL 注入、XSS、命令注入等。而这次攻击使用的是大量看似正常的业务请求，单看每一个请求都符合协议规范，也没有携带明显的攻击载荷，因此 WAF 的规则引擎没有产生告警。
3.2 攻击目标是业务逻辑层，而不是协议层
WAF 工作在应用层和网络层之间，更多关注请求本身是否恶意。而这次攻击瞄准的是业务逻辑层的资源消耗点，比如频繁触发慢查询、反复调用高成本接口、大量写入操作等。这类请求在 WAF 视角下是合法的，但叠加起来会迅速耗尽后端资源。
3.3 攻击流量绕过了 WAF 的流量调度
部分攻击流量直接打向了源站 IP，或者通过 CDN 回源链路绕过 WAF 的检测节点。这种情况下，WAF 根本没有机会看到这些请求，自然也就无法拦截。回源防护配置缺失，是这次事件中一个非常关键的短板。
3.4 防护能力分散，缺少联动
WAF 只负责请求检测，无法感知后端服务的健康状态。当后端已经出现资源耗尽时，WAF 并不会主动降级或限流。缺少与网关限流、负载均衡、弹性伸缩等能力的联动，导致单点防护无法形成整体防线。
4. 复盘结论
这次事件的核心结论是：WAF 完好不等于防护到位。WAF 只是安全防护体系中的一环，它擅长拦截明显的恶意攻击，但面对业务逻辑型攻击、资源耗尽型攻击和绕过型流量时，能力是有限的。业务瘫痪的根因，是防护体系缺少纵深和联动，而不是 WAF 本身失效。
5. 改进建议
针对这次复盘，建议从以下几个方向进行加固。
5.1 补齐回源防护
确保所有流量都经过 WAF 检测节点，关闭源站 IP 的直连暴露，配置回源 IP 白名单，避免攻击者绕过 WAF 直接打源站。
5.2 建立多层限流机制
在网关层和 WAF 层同时配置限流策略，针对单 IP、单用户、单接口设置独立的速率阈值，防止单一来源的请求打爆后端资源。
5.3 增加业务逻辑层防护
对高成本接口、慢查询接口、写操作接口做专项保护，增加频控、熔断和降级策略，避免业务逻辑被恶意利用。
5.4 打通安全与运维的联动
将 WAF 的告警与监控系统、弹性伸缩策略打通，当后端资源出现异常时，能够自动触发限流或扩容，形成安全与运维的协同响应。
5.5 定期开展攻击演练
通过模拟真实攻击场景，验证 WAF 规则、限流策略和回源防护是否真正有效，避免防护能力停留在纸面上。
6. 总结
WAF 完好但业务瘫痪，本质上暴露的是防护体系的不完整。安全建设不能只依赖单一产品，而要从流量入口、业务逻辑、后端资源多个层面构建纵深防御，并让安全能力与运维能力真正联动起来。希望这次复盘能给大家带来一些启发。