WAF与Web应用防火墙：规则配置、防护策略与误报处理
一、WAF在哪一层起作用
WAF工作在应用层，检查HTTP请求的URL、Header、Body、Cookie，匹配SQL注入、XSS、路径穿越等签名。它和服务器防火墙不是一回事，后者管端口和IP，WAF管请求内容。
独立站常见两种形态：云WAF（Cloudflare、AWS WAF）前置在CDN之前，托管型按请求计费；主机WAF（ModSecurity、宝塔自带）跑在服务器上，按规则文件维护。
两者定位不同。云WAF挡在流量到达服务器之前，适合扛DDoS和扫描；主机WAF贴近应用，能拦登录爆破，但会占用服务器CPU。服务器层面的登录限制和文件权限，属于 独立站安全加固 的范畴。
本文只讲WAF本身的规则、动作和误报，不重复端口和权限配置。
选云WAF还是主机WAF，看流量结构。日请求量在10万以下的小站，主机WAF的登录限速规则就够，没必要上云WAF套餐。日请求量过百万、或经常遭遇CC攻击，云WAF的分布式节点才能扛住。
还有一类是CDN自带WAF，比如Cloudflare免费版就带基本规则。它和独立云WAF的区别在于，CDN WAF规则粒度粗，适合中小站；付费云WAF能自定义单条规则、按路径放开误报，适合业务复杂的站。
| 维度 | 云WAF | 主机WAF |
|---|---|---|
| 位置 | CDN之前，流量未到源站 | 源站Nginx/Apache模块 |
| 计费 | 按请求量或套餐 | 软件免费，耗CPU |
| 擅长 | DDoS、扫描器、CC | 登录爆破、后台路径 |
| 误报影响 | 用户根本到不了源站 | 500错误直接暴露 |
| 适合日请求量 | 100万以上 | 10万以下 |
二、规则三档：观察、限速、阻断
每条WAF规则都要选一个动作。最常见的错误是把所有规则一上来就设成阻断，结果上线第一天就把询盘表单、Google爬虫、后台编辑全拦了。
正确做法是给每条规则定一个初始动作，再按一周观察数据调整。判定标准如下表。
| 动作 | 触发条件 | 用户体验 | 适用阶段 |
|---|---|---|---|
| 观察 Log | 新规则上线默认 | 无感知，只记日志 | 前7天 |
| 限速 Challenge | 同IP每分钟超30次命中 | 弹JS挑战或验证码 | 误报0.1%至1% |
| 阻断 Block | 已知攻击签名 | 返回403 | 误报低于0.1% |
场景示例一：给WordPress后台/wp-admin/登录接口加规则，不要直接阻断。爆破请求确实会命中，但公司同事出差用陌生IP登录也会被拦。正确做法是限速加白名单：公司出口IP加白，其余IP每分钟失败5次即临时封20分钟。
场景示例二：Googlebot抓取产品页时带较长query string，容易被通用XSS规则误判。观察日志里看到大量Googlebot UA被命中，先把爬虫路径加入例外，而不是关掉整条规则。
三、误报处理：先看日志，再加白名单
误报不是靠”调松规则”解决的，是靠精确白名单解决的。把规则整体放宽，等于把防护一起拆掉。
处理一条误报的标准流程：从WAF日志取出被拦请求，看UA、路径、参数、命中的具体规则ID；确认是正常业务后，按路径加白名单，而不是按整个域名加。
| 误报来源 | 典型表现 | 正确处置 |
|---|---|---|
| 表单提交含特殊字符 | 产品咨询里带<或引号被XSS规则拦 | 对/wp-json/contact-form路径加例外 |
| 搜索引擎爬虫 | Googlebot UA命中通用扫描规则 | 验证IP归属后按UA加例外 |
| 第三方服务回调 | Webhook带JSON Body被SQLi规则拦 | 对/webhook/路径加IP白名单 |
| 后台富文本编辑器 | 文章内容含HTML标签被拦 | 对/wp-admin/post.php加例外 |
一个常被忽略的点：白名单要按”路径加条件”加，不要按整域名加。整域名白名单等于这条规则在这个站完全失效，攻击者换个路径就能绕过。
误报率怎么算：一周内被拦请求中，人工确认为正常业务的比例。超过1%说明规则太激进，回退到观察；0.1%至1%之间用限速；低于0.1%才放心开阻断。日志解读方法见 独立站日志分析。
四、常见绕过与红线
WAF不是保险箱。它依赖签名，而攻击者会变形。以下三类请求WAF基本拦不住，必须靠应用层自己补。
第一类是合法接口被滥用。WAF看到的是正常POST，但参数被批量遍历。这类要靠接口限流和验证码，思路见 独立站API安全。
第二类是表单垃圾提交。WAF规则拦不住真人填的垃圾询盘，要靠蜜罐和reCAPTCHA，见 独立站表单反垃圾。
第三类是WAF本身被绕过。攻击者直接回源站IP，绕过CDN前置的云WAF。所以源站必须只允许CDN回源IP访问，其余端口全部关闭。
| 红线 | 后果 | 正确做法 |
|---|---|---|
| 整域名加白名单 | 规则在该站完全失效 | 按路径加例外，附条件 |
| 源站对公网开放80/443 | 攻击者绕过WAF直连 | 防火墙只放行CDN回源段 |
| 登录接口前开强拦截 | 同事出差被锁在外面 | 限速加IP白名单 |
| 规则从不复核 | 半年后误报堆积无人知 | 每月导出拦截日志复盘 |
监控要和WAF联动。拦截量突增3倍以上、或正常表单提交量跌为零，都要告警，阈值方法见 独立站监控体系。
规则来源也要挑。云WAF厂商会自带一整套托管规则集，比如OWASP核心规则集。这套规则覆盖常见注入和XSS，但误报率天生偏高，因为它面向所有网站。
正确做法是：托管规则集先全部开观察模式跑两周，把误报高的几条关掉或加例外，其余保留。不要逐条自己写规则，自己写的规则覆盖度远不如开源规则集。
每周固定抽半小时看拦截日志。重点看两类：单日拦截量突增说明可能正在被扫，误报集中在同一路径说明要加例外。
把这半小时写进月度维护清单，比临时出事故再救火划算。官网每月该做的事见 官网维护期。
| 规则来源 | 覆盖度 | 误报率 | 建议 |
|---|---|---|---|
| 厂商托管规则集 | 高 | 中高 | 先观察后启用 |
| 自定义单条规则 | 低 | 低 | 只补业务特有场景 |
| 登录限速规则 | 中 | 中 | 加IP白名单后启用 |
FAQ 常见问题
WAF新规则上线应该直接阻断吗？
WAF把询盘表单提交拦了怎么办？
云WAF和主机WAF要同时开吗？
怎么防止攻击者绕过WAF直连源站？
误报率怎么算，多少算高？
WAF能挡住垃圾询盘吗？
写在最后
WAF的价值不在于拦了多少攻击，而在于拦错了多少正常业务。前者数字好看，后者才真正掉询盘。
落地三步：新规则一律先观察7天；误报按路径加例外，不按整域名放松；每月导出拦截日志复盘一次，把误报率压到0.1%以下再开阻断。
最后补一句成本账。日请求量低于10万的小站，云WAF套餐费可能比服务器本身还贵。
这种情况下用免费CDN自带的基础WAF加主机登录限速，足够挡住九成威胁，不必为用不上的高级规则付费。
WAF不是一劳永逸的开关，是一套需要每周校准的规则体系。规则跑久了会漂移，业务变了规则也要跟着调。
一句可以记住的话：WAF调优的方向不是”多拦”，而是”拦对”——误报率比拦截量更值得盯。