漏洞控制器

去年冬天，漏洞我蹲在客户机房的控制地板上，盯着屏幕上跳动的漏洞日志。一个SQL注入攻击正试图穿过WAF，控制但每次都被弹了回去。漏洞客户在旁边问：“这玩意儿到底怎么判断哪些是控制攻击、哪些是漏洞正常请求？”我指着屏幕上那段被拦截的payload说：“它不判断，它只是控制匹配。匹配上了就拦，漏洞匹配不上就放。控制”

这就是漏洞漏洞控制器的本质——一个规则匹配引擎。听起来简单得过分，控制但真正让它跑起来，漏洞麻烦事一堆。控制

规则不是漏洞越多越好

刚入行那会儿，我以为规则库越庞大越安全。某次给一家电商平台部署WAF，我导入了社区维护的十几万条规则。结果上线第一天，后台投诉炸了：用户上传商品图片被拦、客服系统里带“select”字样的聊天记录被拦、连后台管理员改个商品描述都触发告警。

误杀率飙到7%。运维总监打电话过来，声音都在抖：“你们这控制器是来保护业务的，还是来搞死业务的？”

后来我学乖了。规则要精简，要针对业务定制。那个电商平台最后只保留了三千多条核心规则，误杀率降到0.3%以下。剩下的靠行为分析兜底。漏洞控制器不是铜墙铁壁，它更像筛子——筛孔太大漏攻击，筛孔太小堵业务。找到那个平衡点，比堆规则难十倍。

绕过与反绕过，永不停歇的猫鼠游戏

写规则的人和在找绕过方法的人，永远在较劲。你以为把union select加进黑名单就完事了？攻击者把空格换成/**/，把大小写混着写，把关键词拆成un/**/ion sel/**/ect。你补一条规则，他换一种编码。你上正则，他用注释混淆。

我见过最离谱的绕过：攻击者把SQL注入语句拆成十几个HTTP请求，每个请求只带一个字符，靠服务端拼接执行。这种慢速攻击，传统规则匹配根本抓不住。后来我们加了请求频率关联分析，才把这条路堵上。

但堵上一条，还有下一条。HTTP参数污染、分块传输编码、Unicode规范化差异……每个协议层的细节都可能成为绕过通道。漏洞控制器的规则库每周都在更新，不是因为新漏洞多，是因为旧漏洞的新绕过手法层出不穷。

日志比规则更值钱

真正让我对漏洞控制器改观的，是一次溯源分析。客户被拖库了，但WAF没报警。我翻了三天日志，发现攻击者用了某种罕见的编码方式，规则没匹配上。但日志里留下了完整的请求序列——从探测到利用，一共47个请求，时间跨度两小时。

我把这47个请求的payload提取出来，写成新规则。后来这套规则拦住了三个不同攻击者的类似尝试。漏洞控制器的价值，一半在拦截，一半在记录。拦截失败的请求，恰恰是优化规则的最好素材。

现在我看一个WAF好不好，先看它的日志字段全不全、检索快不快、能不能做关联分析。规则可以抄，日志体系抄不来。

它只是个工具

有次和同行吃饭，他说他们公司买了某大厂的WAF，号称AI驱动、零误报、自动防御。我问：“那你们安全团队几个人？”他说：“三个。”我说：“那你们迟早出事。”

漏洞控制器再智能，也是工具。工具需要人调、人看、人判断。规则匹配有盲区，行为分析有阈值，AI模型有对抗样本。把安全全押在一个控制器上，跟把家门钥匙藏在门口地毯下没区别——防君子不防小人。

我现在给客户部署WAF，第一件事是调日志级别，第二件事是设告警阈值，第三件事是教他们怎么看日志。控制器只是第一道防线，后面还得有人盯着。没人盯的WAF，跟没装一样。

机房那台设备还在跑，日志还在刷。攻击者还在试，规则还在更新。这场猫鼠游戏没有终点，漏洞控制器只是其中一枚棋子。用好它，别迷信它。