正则引擎的“贪心”陷阱
说实话，现在不少 WAF 还在用基于正则的规则匹配。正则这东西，写起来简单，跑起来嘛……你懂的。底层实现大多是 NFA（非确定性有限自动机），有个臭名昭著的毛病：回溯。
比如这个规则：
^(.+)+$，看着人畜无害，对吧？但你给它一个不带换行符的长字符串，它就能跑到天荒地老。为什么？因为正则引擎面对量词嵌套时，会尝试所有可能的路径组合——所谓“灾难性回溯”。我见过最离谱的一个 case，一条 50 字符的 payload，匹配耗时 3 分钟。就这，还怎么扛 DDoS？好在后来我们强制迁移到了 DFA（确定性有限自动机）引擎，加上一些剪枝策略。DFA 保证每个字符只处理一次，没有回溯。代价呢？编译时间长，内存占用翻倍。但线上表现，QPS 从 800 直接拉到 5000 以上，99分位延迟从 200ms 降到 2ms。值。
绕过与对抗：语义分析的救场
正则规则天然有盲区。参数编码、大小写变形、JSON 嵌套逃逸……黑名单规则永远追不上攻击者的脑洞。去年我们做过一个测试，拿 ModSecurity 默认规则集去拦 SQLi，结果 3000 个变异样本漏了 40%。不是规则不够多，是语法理解太浅。
后来干脆自研了一个小型的语义分析模块。不是整个解析 SQL 语法树——那太重了。而是在请求参数里做词法分析，识别出 SQL 关键字、字符串边界、注释符号，然后构建一个轻量的令牌序列，在此之上跑异常检测模型。误报率一下子压到 0.01% 以下。不过坑也不少：性能开销比纯正则高出 2-3 倍，必须用 C++ 重写热路径，并且做了大量 SIMD 优化才稳住。
落地的三个大坑，个个要命
坑一：配置一把梭，不区分业务流量很多团队部署 WAF 直接“阻断模式”，对全站开启所有规则。结果……误杀一片，运营追着安全跑。解法：必须有个观察期。先放行但打标签，分析误报率，用历史流量回放做基线。然后针对不同 API 制定不同防护组。比如登录接口开暴力破解防护，查询接口开 SQLi，静态资源直接 bypass。——这一套做下来，上线平稳得像没加 WAF 一样。
坑二：规则更新周期长，跟不上 0day
传统 WAF 靠厂商推送规则，从漏洞公布到规则生效，快则半天，慢则一周。招 P0 分分钟。我们搞了个“热规则”机制：允许安全团队用 Lua 写临时策略，直接注入 Nginx 执行，不用重启。代价是，Lua 脚本质量全靠人肉审核，出过几次内存泄漏。后来加了脚本沙箱和超时限制才算稳下来。
坑三：HTTPS 解密的高成本
这是最容易被忽略的。WAF 要做深度检测，必须看请求体，那就得终止 TLS。CPU 开销直接多出 30%。我们一开始没感觉，直到大促流量翻 10 倍，WAF 集群差点打挂。最后是分了流：静态资源域名不做解密，动态 API 才过 WAF，并且用了硬件加速卡。钱砸下去，效果才出来。
工程美学——我喜欢这个词。真正好的 WAF 架构，不只规则精准，还要像水一样渗透在链路里，无感，坚不可摧。这背后的算法、内存管理、并发模型，处处是算计。写正则的人，要懂自动机；调策略的人，要懂贝叶斯。没有银弹，只有trade-off。
