waf防护https

判断一套 WAF 能否真正防护 HTTPS 站点，关键看它是否在 TLS 终止后解析到明文 HTTP 请求。只能转发 443 流量的 WAF，通常只能基于 IP、SNI、TLS 指纹做四层控制，无法检查 URL、Header、Body，也就难以拦截 SQL 注入、XSS、命令注入等七层攻击。以下按部署、证书、回源、策略、验证五个环节说明可执行配置。

解密点决定防护能力

七层 WAF 必须在客户端与源站之间解密 HTTPS，再对明文请求做规则匹配。常见部署方式：

• 反向代理或云 WAF CNAME：WAF 持有站点证书，客户端与 WAF 建立 TLS，WAF 解密检测后再回源。适合需要阻断七层攻击的网站。
• 透明桥或网关：流量经过 WAF 时终止 TLS 或同步证书，适合不能改 DNS 的内网。
• 旁路镜像：只复制流量告警，通常不能阻断；若不解密，只能做流量基线。
• 插件或 SDK：嵌入应用、API 网关，适合云原生和 API 场景，但覆盖面受应用改造限制。

判断标准：能否看到 HTTP 方法、路径、参数和 Body；能否对命中规则执行拦截；证书是否由 WAF 统一管理。需要七层阻断时，优先选择反向代理或云 WAF 接入。

证书与私钥管理要点

在 WAF 上部署证书时，按以下步骤检查：

1. 上传或签发与域名匹配的证书，包含完整中间证书链。
2. 配置 SNI，多域名和通配符证书要覆盖实际访问域名。
3. 开启自动续期和到期告警，避免证书过期导致服务中断。
4. 私钥权限最小化，限制导出和下载，启用操作审计。
5. 若源站也使用 HTTPS，确认回源证书与源站域名、SNI 设置一致。

注意事项：启用 HSTS 前先确认所有子域都支持 HTTPS；证书切换建议灰度，观察握手失败率和浏览器兼容性。

回源链路与真实信息

WAF 解密后，需要把请求转发给源站。跨公网回源建议使用 HTTPS，并校验源站证书；同内网可 HTTP 回源，但源站安全组应只允许 WAF 回源地址。关键配置：

• 传递 `X-Forwarded-For`、`X-Forwarded-Proto`、`Host`，源站日志才能记录真实客户端 IP 和协议。
• 源站避免直接暴露公网，若必须暴露，应限制访问来源。
• 检查回源超时、连接复用和 SNI 设置，防止 HTTPS 回源握手失败。
• 对重定向、Cookie 域、HSTS 头做联调，避免跳转循环或混合内容。

策略配置：从观察到拦截

HTTPS 流量解密后，WAF 规则才能覆盖 URL、Header、Cookie、Body、JSON、文件上传等位置。建议先观察再拦截：

• 初始阶段开启告警模式，记录规则命中，确认业务误报。
• 启用 OWASP 核心规则集，再按业务补充自定义规则，如登录、支付、API 接口。
• 对 CC 攻击和恶意爬虫配置频率限制、人机校验和 IP 信誉策略。
• 误报处理优先使用精确白名单、规则例外和参数排除，不要直接关闭整类规则。
• API 场景关注 JSON 解析、大小限制和方法限制，避免只检查表单。

性能、高可用与验证

HTTPS 解密会增加 TLS 握手和加解密开销。可启用会话复用、OCSP Stapling、HTTP/2 和连接池，并部署多节点、同步证书与策略、配置健康检查。验证时：

• 用 `openssl s_client -connect waf.example.com:443 -servername www.example.com` 检查证书链和 SNI。
• 用 `curl -vk https://example.com` 观察响应头、重定向和回源协议。
• 发送测试载荷，确认 WAF 日志能看到明文请求并触发规则。
• 监控证书到期、TLS 握手失败、5xx、延迟和拦截率。

小结

在 HTTPS 场景中，WAF 不是“转发 443 端口”即可，而是要让 WAF 在可信位置完成 TLS 终止，做好证书、回源和策略管理，再通过日志与灰度持续调优。若无法解密，应明确它只能做四层防护或旁路告警，不能替代七层 WAF 的检测与阻断。