waf是什么

```html

去年夏天，朋友的公司被刷了。不是DDoS那种把带宽堵死的蛮力攻击，是那种精心构造的SQL注入——请求里夹着 UNION SELECT，伪装成正常的商品搜索参数。服务器日志里一片祥和，数据库却已经把用户表整个吐了出来。事后复盘，他们才发现，那台服务器前面什么都没挡。防火墙？有，但那是网络层的，只看IP和端口，压根不管HTTP请求里包着什么。这就是WAF要解决的问题。

WAF，全称Web Application Firewall，中文叫Web应用防火墙。名字里带“防火墙”三个字，但它跟传统防火墙完全不是一回事。传统防火墙工作在网络层和传输层，像个门卫，查的是你从哪来、要到哪个门。WAF站在应用层，它拆开你的HTTP请求，看里面的内容——URL、参数、Cookie、请求体，甚至HTTP头部里的每一个字段。它关心的是你“说什么”，而不是你“从哪来”。

打个比方。传统防火墙是小区大门，看车牌、看门禁卡。WAF是你家门口的保安，你进了小区它不管，但你要进我家门，它得翻你包，看你有没有带刀。SQL注入、跨站脚本（XSS）、文件包含、命令注入——这些攻击的恶意代码都藏在正常的HTTP请求里，网络层防火墙看不见，WAF能看见。

那WAF具体怎么判断一个请求是恶意还是正常？两种路子。一种是基于规则的，也叫签名匹配。安全团队维护一个规则库，里面存着已知攻击的特征。比如请求参数里出现 1' OR '1'='1 这种典型SQL注入片段，规则一匹配，直接拦截。这种方式准，但滞后——新攻击手法出来，得先有人发现，再写规则，再更新。另一种是基于行为的，或者叫异常检测。WAF先学习正常流量的模式，比如某个接口平时参数都是数字，突然来了个带尖括号和引号的，那就可疑。这种方式能抓未知攻击，但容易误报，调优是个细活。

实际部署里，WAF有几种形态。硬件盒子，串在链路里，性能好但贵，扩容麻烦。软件WAF，装在服务器上，比如ModSecurity，灵活但吃资源，还得自己维护规则。云WAF这几年用得最多，把域名解析指向WAF厂商的节点，流量先过它们的清洗中心再回源。省事，弹性好，小团队尤其喜欢。不过云WAF有个绕不开的问题：你的流量得先经过别人的服务器。对数据敏感的业务，这是个决策点。

我见过不少团队把WAF当万能药。上了WAF，就觉得安全了。其实WAF只是纵深防御里的一层。它挡得住自动化扫描器和脚本小子，挡不住逻辑漏洞。比如一个电商网站，满减优惠券可以无限叠加——这是业务逻辑问题，请求本身完全合法，WAF看不出任何异常。再比如，攻击者用正常的参数一点点试探，每个请求都像人发的，WAF的规则和模型都很难判定。所以WAF得配合代码审计、权限控制、输入验证一起用，单靠它兜不住底。

还有个常被忽略的点：WAF的日志。很多团队开了WAF就不管了，拦截记录从来不看的。其实那些被拦下来的请求是金矿——谁在扫你、用什么手法、从哪个IP来、盯上了哪个接口。定期翻一翻，能提前发现很多问题。有次我帮人看日志，发现某个IP连续三天在试 /admin 路径下的各种备份文件，.bak、.old、.zip 挨个试。虽然WAF都拦了，但说明对方已经盯上这个站了，后续可能有更针对性的攻击。这种信号，不看日志根本不知道。

选WAF的时候，别光看厂商吹的拦截率。问几个具体问题：规则库多久更新一次？误报了怎么处理，能不能快速加白名单？日志保留多久，能不能对接自己的SIEM？性能损耗多少，高峰期会不会成为瓶颈？这些才是日常运维里天天要面对的事。拦截率99.9%听起来漂亮，但那0.1%的误报如果正好卡在支付回调上，业务就断了。

说到底，WAF是个工具，不是答案。它把HTTP流量里的脏东西筛出来，给应用层加了一道缓冲。但应用本身的安全，终究得靠写代码的人。WAF能挡掉八成以上的自动化攻击，剩下的两成，得靠人盯着。