waf检测

```html

去年冬天我帮一个做电商的朋友看服务器日志，发现有个IP在凌晨三点连续发了四百多次请求，路径全是 /admin/../../etc/passwd 这类东西。朋友说网站好好的，没崩。那是因为WAF把那些请求全拦了，日志里只留下拦截记录。他根本不知道有人尝试攻击，WAF也没弹窗报警——默认策略就是静默阻断。

WAF这东西，全称Web Application Firewall，中文叫Web应用防火墙。名字听着像防火墙，但跟传统防火墙完全不是一回事。传统防火墙管的是IP和端口，比如只允许80和443端口进，其他全堵死。WAF管的是HTTP请求的内容——你发过来的URL长什么样、参数里有没有 union select、Cookie里是不是藏了 <script>。它站在应用层，盯着每一个请求的“长相”来判断好坏。

检测方式其实分两大流派。一类靠规则库，业内叫“特征匹配”。比如ModSecurity这个开源WAF，默认规则集里有一条：如果参数值里出现 ../ 且后面跟着 etc/passwd，直接拦截。简单粗暴，误报率看规则写得细不细。另一类靠行为分析，或者说机器学习。AWS的WAF现在能根据正常流量基线，自动标记异常请求。比如你的用户从来不会在搜索框里输入超过200个字符，突然有人塞了5000个字符的base64编码串，那大概率有问题。

我见过最离谱的误报来自某云WAF的“SQL注入防护”。一个用户提交表单，备注里写了“我选A还是B？”，WAF把“还是”拆成“还”和“是”，然后匹配到“or”这个关键词，直接返回403。用户一脸懵，客服查了半天才发现是WAF干的。所以规则太严也不是好事，业务被拦了比被攻击还麻烦。

真正好用的WAF得会“学习”。我观察过Cloudflare的WAF，它有个功能叫“流量标记”——先跑一周只记录不拦截，把正常请求的URL、参数长度、Content-Type分布全摸清楚，然后自动生成白名单。之后只有偏离白名单的请求才进入深度检测。这比一上来就硬拦聪明多了。不过代价是那周里如果真有人攻击，它也不管。

绕WAF的手法现在也花哨得很。早年SQL注入直接写 1' or '1'='1，现在改成 1' %0aor%0a'1'='1，用换行符和URL编码拆开关键词。还有用Unicode全角字符的，ＳＥＬＥＣＴ 这种，有些WAF的规则库没覆盖到就漏了。更高级的用分块传输编码，把恶意payload拆成多个HTTP chunk，WAF如果不会重组就看不到完整攻击串。去年爆出的一个CVE就是某商业WAF在处理chunked编码时只检查了第一个块。

那WAF到底该不该上？我的看法是：上，但别指望它包治百病。它更像小区门口的保安——能拦住翻墙的、贴小广告的，但真遇到拿着门禁卡的内鬼（比如业务逻辑漏洞），保安也没辙。我见过一个站点WAF配得严严实实，结果攻击者通过密码重置接口的越权漏洞直接改了管理员密码。WAF日志里全是正常请求，因为它压根不关心“这个用户有没有权限改别人密码”。

部署位置也有讲究。云WAF（比如阿里云、Cloudflare）改个DNS就行，但流量要绕到厂商节点，延迟增加10-30ms是常事。硬件WAF放在机房入口，延迟低，但得自己维护规则更新。还有主机层WAF，像PHP的 mod_security 模块，直接嵌在Apache里，性能损耗小，但只能保护这一个服务。选哪个看你的架构——如果用了CDN，云WAF最省事；如果是内网API，主机层WAF更合适。

最后说个真实数据。我统计过某中型电商站三个月的WAF日志：总共拦截了约12万次请求，其中SQL注入占47%，XSS占22%，剩下的是路径穿越、命令注入和扫描器探测。但人工复核后发现，真正有危害的不到300次——大部分是扫描器批量扫的，或者安全研究员在测试。换句话说，WAF帮你挡住了99%的噪音，但剩下那1%才是要命的。所以别关日志，定期看看拦截记录，比装完就不管强得多。