web应用防火墙是什么

你正登录一个购物网站，输入账号密码，火墙点击“提交”。应用防这个请求穿过网络，火墙到达服务器。应用防服务器把请求转给背后的火墙应用——可能是用 Java 写的，也可能是应用防 PHP 或 Python。应用查数据库、火墙验证身份、应用防返回订单列表。火墙整个过程不到一秒。应用防但就在这一秒里，火墙攻击者可能已经尝试了十几种方式：SQL 注入、应用防跨站脚本、火墙命令执行、应用防路径遍历。这些攻击不靠暴力破解，而是利用应用本身的逻辑漏洞。防火墙管不了它们。传统网络防火墙看的是 IP 和端口，而攻击流量长得和正常流量一模一样。

Web 应用防火墙（WAF）就是干这个的。它不关心数据包从哪来、到哪去，它拆开 HTTP 请求，看里面的内容。URL 里有没有奇怪的 union select？表单字段里是不是塞了 <script>？参数值有没有包含 ../etc/passwd？WAF 用一套规则库去匹配这些特征。匹配上了，就拦截、记录、告警。听起来很直接，但实际用起来，麻烦事不少。

WAF 的部署方式有好几种。最传统的是反向代理模式：所有流量先经过 WAF 服务器，再由它转发给后端应用。这种模式看得最清楚，但 WAF 自己不能挂，否则整个站点下线。还有一种是透明桥模式，串在交换机里，对网络改动小，但配置起来没那么灵活。云 WAF 这几年更常见——DNS 解析到 WAF 厂商的节点，攻击流量在云端被清洗掉，只有干净请求才回源。小公司喜欢这种，不用自己维护硬件，按量付费。缺点是延迟多几毫秒，而且数据要经过第三方。

规则怎么来的？早期靠人工写正则表达式。比如检测 or 1=1 这种经典注入。但攻击者会变形：or/**/1=1、or 1 like 1、大小写混写、URL 编码。正则越写越多，误报也越来越多。后来有了基于语义分析的 WAF，不只看字符串，还解析 SQL 语法树。再后来，机器学习也掺和进来——用正常流量训练模型，偏离基线的请求就报警。效果嘛，看场景。有的模型把用户改密码也当成异常，因为平时没人改。

我个人的看法：WAF 不是银弹。它更像一个补丁层。应用本身写得烂，WAF 能挡掉一些自动化扫描器，但挡不住逻辑漏洞。比如越权访问——用户 A 能看用户 B 的订单，WAF 怎么知道？请求里参数是 order_id=123，完全合法。除非你把业务规则也写进 WAF，那维护成本就上天了。所以真正靠谱的做法是：代码里做好输入验证、参数化查询、输出编码。WAF 作为兜底，防住那些已知的、批量化的攻击。别指望它解决所有问题。

还有一点常被忽略：WAF 自己也会成为攻击目标。规则文件如果被上传漏洞覆盖，攻击者就能绕过检测。或者用慢速攻击把 WAF 的连接池打满，后端应用反而被拖死。所以 WAF 的运维不比应用简单——要定期更新规则、看误报日志、调阈值、做性能测试。我见过一个团队，上了 WAF 之后半年没看过日志，直到数据库被拖库才发现。WAF 报警了，但没人理。

选 WAF 的时候，别光看规则数量。问几个具体问题：支持自定义规则吗？误报怎么处理？能不能只记录不拦截？日志格式能不能对接 SIEM？云 WAF 的话，节点分布在哪，回源带宽多大？这些比“AI 检测”之类的宣传词实在得多。最后，任何 WAF 都需要调优。默认配置要么太松，要么太紧。花两周时间看日志、加白名单、改规则，比买最贵的版本管用。

说到底，WAF 是一层过滤网。网眼太大，漏东西；网眼太小，正常业务过不去。找到那个平衡点，才是它真正发挥作用的时候。