WAF安全防护

如果业务已暴露在公网，并提供 Web、API 或管理后台，WAF 应作为基础防护层之一；但它不能替代代码修复和访问控制。判断是否部署，先看三点：入口是否面向不可信网络、是否处理用户输入或敏感数据、是否有人员持续处理告警和误报。满足两项以上，建议接入；只满足一项，可先做日志观察。

先明确 WAF 的边界

WAF 主要拦截 HTTP/HTTPS 流量中的已知攻击模式，如 SQL 注入、XSS、命令执行、路径穿越、常见 Webshell 上传、恶意扫描和部分 CC 攻击。它不擅长修复越权、支付逻辑缺陷、业务风控和大流量 DDoS。大流量攻击需与 CDN、DDoS 高防、云清洗联动。若应用存在未修复的高危漏洞，WAF 虚拟补丁可争取时间，但仍应排期修复。适用场景包括对外网站、小程序后端、开放 API、管理后台、电商与支付入口；内部系统如无必要，不建议直接暴露公网。

选择部署方式

• 云 WAF：通过 CNAME 或 NS 接入，部署快，规则更新及时，适合多数公网业务。注意隐藏源站 IP，回源白名单仅放行 WAF 回源段。
• 反向代理或自建：Nginx+ModSecurity、商业软硬件 WAF，适合可控性要求高、需深度定制或数据不出境的场景，但需自行维护规则、性能和证书。
• 透明代理或网桥：不改动网络拓扑，串联在链路中，适合传统 IDC；需处理高可用和逃生机制。
• 主机 Agent 或 Ingress：K8s Ingress、API 网关或主机模块，适合容器和微服务，但防护粒度依赖应用框架。

选择标准：接入是否影响现有 DNS 和证书；是否支持 HTTP/2、WebSocket、gRPC；是否可获取真实客户端 IP；是否有高可用和逃生机制；日志能否对接 SIEM。

核心策略先观察后拦截

上线初期建议用“观察/告警”模式运行 1 至 2 周，至少覆盖一个完整业务周期。统计规则命中 TOP、误报 URL、正常业务参数。确认误报后，再逐步切换为拦截。规则集优先启用 OWASP Core Rule Set 或厂商推荐规则，再按业务补充：

• 对登录、注册、支付、搜索、文件上传、API 接口单独设规则。
• 对 JSON/XML 请求体开启解析，否则只查 URL 会漏报。
• 对 CC 攻击设置频率阈值、人机校验或 JS 挑战，避免直接封禁影响正常用户。
• 对管理后台限制来源 IP，并启用二次认证。
• 对文件上传限制类型、大小、内容检测，并配合后端校验。

注意：正则规则过多会增加延迟，需关注 P99 延迟和 CPU 使用率。

接入与配置步骤

1. 梳理域名、端口、协议、证书和源站 IP，确认回源方式。
2. 在 WAF 添加防护域名，上传证书或配置回源 HTTPS。
3. 修改 DNS 解析到 WAF 提供的 CNAME；若不能改 DNS，考虑反向代理。
4. 配置源站防火墙，仅允许 WAF 回源 IP 访问，防止直接绕过。
5. 配置真实 IP 获取，后端日志记录 X-Forwarded-For 或 X-Real-IP，并只信任 WAF 代理。
6. 选择规则集，开启观察模式，接入日志和告警。
7. 验证业务功能：登录、支付、上传、回调、WebSocket、移动端 API。
8. 调优白名单，处理误报后切换拦截。
9. 定期查看规则更新、证书到期、回源健康状态。

误报与放行管理

误报不可避免，关键是可定位、可回滚。处理流程：

• 从告警中获取请求 ID、规则 ID、URL、参数、UA、源 IP 和时间。
• 在 WAF 日志中复现请求，判断是攻击还是正常业务。
• 若为正常业务，优先缩小规则条件，如指定 URL、参数、方法，而不是全站关闭规则。
• 对无法立即修复的漏洞，用虚拟补丁精确拦截。
• 白名单应设置有效期和审批，避免长期放行整段 IP 或整个路径。
• 保留变更记录，误拦截导致故障时可快速回滚。

运维监控与应急

日常关注：QPS、拦截率、误报率、规则命中 TOP、源站 5xx、WAF 延迟、证书有效期、回源失败。建议设置分级告警：攻击突增、拦截量骤升、误报激增、源站不可用。应急时：

• 确认攻击类型，切换相关规则为拦截，必要时开启 CC 防护。
• 对恶意 IP 临时封禁或限速，但注意 NAT 和移动出口影响。
• 与 CDN、DDoS 高防联动，清洗大流量。
• 保留原始日志，按合规要求留存不少于 6 个月。
• 事后复盘规则缺口，补充自定义规则并修复代码漏洞。

WAF 的价值取决于接入正确、规则调优和持续运维。先观察后拦截、精确白名单、源站防绕过、日志可追溯，是落地时的四个关键动作。把它作为纵深防御的一层，而不是唯一防线。