怎么验证WAF防护有效？攻防演练入门方法

一、为什么必须验证

WAF 配好了不代表有效。可能规则没开、可能流量没走 WAF、可能某类攻击根本不在防护范围内。只有主动测过，才知道防护的真实水平。

二、方法一：模拟攻击测试

在自有站点上发起模拟攻击，观察 WAF 是否拦截。这是最直接的方法。

# SQL 注入模拟（对自有站点测试）
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://你的域名/product?id=1%27%20OR%20%271%27%3D%271"

# XSS 模拟
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://你的域名/search?q="

# 敏感文件探测
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://你的域名/.env"

# 预期结果：返回 403（被 WAF 拦截）
# 若返回 200/404 且页面正常 → 说明未拦截 ⚠️

测试用例清单

三、方法二：穿透测试

验证能否绕过 WAF 直连源站——这是最容易被忽视但最重要的测试。

# 方式 1：直接访问源站 IP
curl -I --resolve 你的域名:443:你的源站IP https://你的域名/
# 预期：连接超时 / 403（源站保护生效）
# 若返回 200 → 源站暴露，攻击者可绕过 WAF ⚠️

# 方式 2：查历史 DNS 记录
# 通过第三方 DNS 历史查询工具检查是否泄露源站 IP

# 方式 3：检查未接入的子域名
nslookup mail.你的域名
nslookup dev.你的域名
# 若解析到源站 IP → 泄露风险 ⚠️

四、方法三：压力测试

验证 CC 防护的阈值是否合理。注意：压力测试可能影响业务，务必在低峰期并在获得授权的情况下进行。

# 使用 ab 或 wrk 对自有站点做限速测试
# 注意：先确认测试是否会影响正常用户

ab -n 1000 -c 50 https://你的域名/test-page

# 观察：
#   ├─ 前多少请求被放行？（阈值）
#   ├─ 超出后是否触发限速/验证？
#   └─ 服务器 CPU / 内存是否可控？

# 更安全的方式：用 WAF 控制台的"演练模式"
# 部分厂商提供沙箱环境，不影响线上

五、方法四：日志回溯

不主动测试，而是分析历史日志，看 WAF 在真实攻击中的表现。

# 统计拦截率
总攻击请求数 = grep 攻击特征 access.log | wc -l
被拦截数   = grep " 403 " access.log | wc -l
拦截率     = 被拦截数 / 总攻击请求数

# 重点关注"未被拦截的攻击"：
#   日志里有明显攻击特征，但返回 200 的请求
grep "union select\|../\|

六、验证报告模板

WAF 防护有效性验证报告

  验证时间：2025-XX-XX
  验证范围：www.example.com

  一、规则防护
    ✅ SQL 注入       拦截 8/8
    ✅ XSS            拦截 6/6
    ⚠️ 命令注入       拦截 3/5  ← 需补规则
    ✅ 敏感文件       拦截 5/5

  二、源站保护
    ✅ 直连源站 IP     拒绝
    ✅ 未接入子域名    已清理
    ✅ 数据库端口      未暴露

  三、CC 防护
    ✅ 单 IP 限速      5 秒触发
    ✅ 人机验证        正常弹出
    ⚠️ 分布式 CC      部分绕过  ← 需全局限速

  四、结论与整改
    1. 补充命令注入规则（含反引号）
    2. 增加全局 QPS 限制
    3. 下周复测

七、注意事项

1. 只测自己的站点：测试他人站点是违法行为
2. 低峰期执行：压力测试可能影响正常用户
3. 留存测试记录：便于复盘和向厂商反馈
4. 定期做：建议每季度一次全面验证
5. 业务变更后必做：改版、换架构后要重新验证

八、小结

验证 WAF 有效性要靠主动演练，而不是等被打。模拟攻击测规则、穿透测试查源站、压力测试验阈值、日志回溯找漏报——四种方法组合使用，形成完整的安全验证闭环。建议每季度做一次，并在业务重大变更后重新验证。