内容摘要：去年冬天，一个做电商的朋友半夜给我打电话，说网站后台被人拖库了。我问他有没有上WAF，他愣了两秒：“那玩意儿不是大公司才用的吗？”第二天我帮他看了日志，攻击者用的是最基础的SQL注入，payload里

去年冬天，绿盟一个做电商的应用防朋友半夜给我打电话，说网站后台被人拖库了。火墙我问他有没有上WAF，绿盟他愣了两秒：“那玩意儿不是应用防大公司才用的吗？”第二天我帮他看了日志，攻击者用的火墙是最基础的SQL注入，payload里连编码都没做，绿盟直接明文怼过来。应用防这件事让我意识到，火墙很多人对Web应用防火墙的绿盟认知还停留在“知道有这么个东西，但觉得离自己很远”的应用防阶段。

绿盟的火墙WAF我接触过几个版本，最早是绿盟硬件盒子，后来有了虚拟化版本和云原生形态。应用防硬件款长得跟交换机差不多，火墙前面板一排指示灯，插上电接进网络里就能干活。部署方式无非就是桥接、旁路或者反向代理，桥接模式最省事，流量直接穿过去，不用改网络拓扑。但桥接有个坑——如果WAF本身出问题，整个链路就断了。所以后来很多客户更愿意用旁路部署，只做检测和告警，不阻断流量。这种模式对可用性影响最小，代价是攻击已经打到服务器上了你才知道。

绿盟WAF的规则库更新频率还算勤快，每周都有推送。我见过他们的规则管理界面，按OWASP Top 10分了类，SQL注入、XSS、命令注入这些常见类型都有独立开关。有个细节挺有意思：规则可以设成“观察模式”和“拦截模式”，观察模式下只记录不阻断，适合刚上线时摸清业务流量特征。这个设计很实用，因为直接开拦截很容易把正常请求也挡了。我就遇到过客户把后台管理路径写进了规则黑名单，结果管理员自己都登不进去。

检测引擎这块，绿盟用的是基于语义分析的方案，不是单纯靠正则匹配。举个例子，1' or '1'='1这种经典注入，正则很容易识别，但攻击者把参数拆成1' o/**/r '1'='1，中间插注释绕过，纯正则就抓瞎了。语义分析会解析SQL语法结构，判断这个参数到底是不是在构造合法查询。当然这也不是万能药，遇到编码变形或者分块传输，还是得靠多层解码和协议解析来兜底。

性能方面，硬件型号不同差别很大。低端款吞吐量几百兆，插到千兆链路里就成了瓶颈。有一回客户抱怨网站变慢，查了半天发现WAF的SSL解密把CPU吃满了——所有HTTPS流量都要在WAF上拆开检查再重新加密，这活儿本来就重。后来把SSL卸载放到负载均衡上，WAF只处理明文HTTP，问题才解决。所以买WAF不能只看规则数量，得算清楚自己的并发连接数和SSL吞吐需求。

云原生版本是这两年推得比较多的。容器化部署，跑在K8s里，跟Ingress Controller集成。好处是弹性伸缩方便，业务扩容时WAF实例跟着自动加。但配置起来比硬件盒子麻烦，CRD定义、Sidecar注入、证书管理，没点K8s功底还真搞不定。我见过一个团队用Helm Chart部署，结果values.yaml里有个参数写错了，WAF实例起不来，排查了一下午。

日志和报表功能中规中矩。攻击事件按源IP、攻击类型、目标URL做了聚合，能导出PDF报告。但说实话，那个报告模板几年没大改过，图表样式还是老一套。真正有用的反而是原始日志的API接口，可以对接SIEM或者自建分析平台。我帮朋友那次就是通过API把日志拉到Elasticsearch里，用Kibana做了个实时攻击地图，老板看了觉得挺酷，其实底层就是地理IP库加聚合查询。

价格方面，硬件款从几万到几十万不等，看吞吐量和功能授权。云原生版本按实例数或流量计费，小规模用起来成本低不少。但不管哪种，买之前最好先跑一遍POC，用真实业务流量测误报率和延迟。厂商销售都会说“零误报”，听听就好。我见过最离谱的误报是把用户昵称里的“select”关键词给拦了，因为规则匹配到了SQL关键字。这种问题不实测根本发现不了。

说到底，WAF不是银弹。它能挡住脚本小子的批量扫描，但挡不住针对业务逻辑的精准攻击。朋友那次被拖库，根本原因是他把数据库账号密码硬编码在前端JS里了——这种问题WAF管不了。防火墙终究是外围防线，代码里的洞还得靠代码来补。