Web 应用防火墙规则配置：构建有效的 WAF 防护体系

WAF（Web 应用防火墙）站在 Web 应用的最前面，负责把恶意流量挡在业务逻辑之外，是 Web 安全的关键一环。但"装了一个 WAF"和"调好了一个 WAF"是两回事：规则太松形同虚设，规则太紧又连正常用户和爬虫一起误杀。一套好规则，本质上是在安全覆盖与业务可用性之间找平衡。

参考：OWASP CRS 官方仓库 https://github.com/coreruleset/coreruleset；ModSecurity 文档 https://modsecurity.org/

一、WAF 规则类型

规则类型	说明	示例
黑名单	匹配已知攻击特征并拦截	SQL 注入、XSS 特征
白名单	只允许指定模式，其余一律拒绝	管理后台 IP 白名单
速率限制	按 IP/会话限制请求频率	登录接口每分钟 5 次
行为分析	对请求行为建模，检测异常	爬虫识别、撞库检测
规则例外	豁免合法的特殊场景	富文本编辑器允许特定 HTML

二、OWASP CRS：开箱即用的实战规则集

OWASP Core Rule Set 是开源 WAF 规则的行业标准，覆盖 SQL 注入、XSS、路径遍历、命令注入等常见攻击。把它加载进 ModSecurity，就有了基线防护：

# 先引入 CRS 的初始化配置，再引入规则
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf

# 示例 CRS 规则：检测 XSS
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES \
  "/((\%3C)|<)[^]+((\%3E)|>)/" \
  "phase:2,deny,t:none,t:normalisePath,msg:'Cross-site Scripting (XSS) Attack'"

# 路径遍历检测
SecRule REQUEST_URI|ARGS|REQUEST_HEADERS \
  "@rx /etc/passwd" \
  "phase:2,deny,t:none,msg:'Path Traversal Attack'"

CRS 用 PARANOIA 等级（1-4）控制严格程度：等级 1 适合大多数网站，误报率低；等级 4 适合金融、政务等安全要求极高的场景，但需要大量例外规则才能保证业务不停摆。

三、Cloudflare WAF 配置示例

托管型 WAF（如 Cloudflare）使用基于表达式的规则：

# 拦截对 wp-admin 的暴力破解 POST（排除办公网段）
规则名称: Block wp-admin brute force
表达式: http.request.uri.path contains "wp-admin"
        and http.request.method in {"POST"}
        and not ip.src in {192.0.2.0/24}
动作: Block

# 对 API 接口限速
规则名称: Rate Limit API
表达式: http.request.uri.path starts with "/api/"
        and http.request.method in {"POST"}
动作: Managed Challenge
速率限制: 100 次/10分钟

这里的威力在于条件组合：单独看路径或单独看方法都会造成误报，但把来源网段、方法、路径、频率组合起来，就能精确命中攻击，而不伤及无辜。

四、误报处理

误报类型	处理方法
IP 被误封	加入白名单，或适当放宽速率阈值
合法参数被误判	为该参数创建规则例外（如富文本 HTML）
正常行为被误判	降低规则敏感度，或改用 PARANOIA 1
特定业务场景	创建限定 URI + 条件的独立排除规则

处理原则是"最小豁免"：能精确到单个 URI，就不要放开整个路径；能加上 IP/方法条件，就不要豁免全站——否则豁免本身就会成为新的攻击面。

举个例子：某后台的富文本编辑器上传图片时会把 <svg> 标签原样存进数据库，而 CRS 的 XSS 规则恰恰会拦截 <svg> 相关特征，导致正常编辑保存失败。处理方式不是把整条 XSS 规则关掉，而是只对 /admin/editor/save 这个 URI、且带富文本字段名 content 的请求放行，其余路径依旧从严拦截。既保住了编辑器，也没给攻击者留后门。

另一个容易被忽略的点是规则执行顺序：托管型 WAF 通常按"白名单 → 例外 → 速率限制 → 黑名单"的优先级评估，例外规则若排在黑名单之后可能不生效。动手配置前先弄清自己平台里的规则评估顺序，否则写了半天例外却发现根本没起作用。

五、最佳实践

先记录后拦截：新规则先在日志/检测模式下跑 1-2 周，确认无误报后再切换为拦截。
把更新当例行工作：CRS 每月发布更新，订阅变更日志并定期做回归测试。
持续监控复盘：定期查看 WAF 日志里被拦截攻击的 Top 榜和误报趋势，把新出现的攻击手法沉淀为自定义规则。
纵深防御：WAF 只是第一层，配合 CDN 限速、IP 声誉库、地理定位和应用层参数校验，效果远好过在单点堆规则。

六、真实案例：促销季的撞库防护

一家电商在大促期间遭遇针对登录接口的撞库攻击：攻击者通过代理池轮换 IP，绕过了简单的按 IP 限速。最终靠三层方案解决：

WAF 层：对 /api/login 限速（每 IP 每 10 分钟 20 次），并对常见代理 IP 段下发质询；
应用层：增加验证码和账号锁定策略；
数据层：监控各 IP 段的失败登录次数，触发风控。

上线后，暴力破解尝试下降超过 95%，而正常用户登录几乎不受影响。

16IDC 观察

WAF 规则配置是"调优"而不是"安装"。把每一条规则当成一个小实验：记录改动、观察误报、评估拦截质量。规则集才会慢慢长成适合你业务的样子，而不是永远停在"默认配置"。