WAF 能在 PHP 打补丁之前争取时间

Cloudflare 发布了什么

2026 年 10 月 21 日，Cloudflare 针对这两个 CVE 发布了托管 WAF 规则。以下内容均为厂商称。

• 规则名为 "Generic Rules - Anomalous Execution - 1" 到 "- 7"。
• 规则位于 Managed Free Ruleset（Free 套餐，默认开启）和 Managed Ruleset（Pro、Business 和 Enterprise）。
• 动作为 Block。
• Managed Response Firewall Default 规则集新增了一条响应侧规则，默认拦截。

这项缓解措施在 Cloudflare 的边缘节点上运行，源站上的 PHP 仍然没有打补丁。详细信息、依据和链接整理在 Cloudflare WAF 页面。

Cloudflare 还称，它观察到了针对其客户的攻击流量，攻击者也在修改 payload 以绕过 WAF 规则。这是 Cloudflare 自己的遥测数据，没有公布流量规模或攻击指标。实际意味着，今天能拦住的请求形式，明天换个样子就可能漏过去。

为什么源站必须拒绝其他所有来源

WAF 只能看到经过它的流量。你的服务器仍然有 IP 地址，攻击者可以从旧的 DNS 记录、证书透明度日志、邮件头或全网扫描中找到它。如果源站的 80 和 443 端口对任何人都有响应，直接发往这个 IP 的请求根本不会经过 WAF。

所以，在开放的源站前面放一个 WAF，只能过滤那些自愿经过它的攻击者。下面的步骤让源站拒绝直接连接。

把源站锁定为只接受 Cloudflare

Cloudflare 的指南列出了几种方法并给出评级，按从强到弱排列如下。

1. Cloudflare Tunnel

cloudflared 在你的服务器上运行，主动向 Cloudflare 建立出站连接。然后在防火墙上封掉所有入站 Web 流量，这样只有隧道能到达站点，也就没有可供攻击的公网监听端口了。配置方法见 Cloudflare Tunnel 文档。Cloudflare 指出，Authenticated Origin Pulls 不适用于走隧道的主机名，因为没有入站监听。

2. Authenticated Origin Pulls (mTLS)

Cloudflare 向源站出示客户端证书，源站拒绝没有证书的连接。这需要 SSL/TLS 模式为 Full 或 Full (strict)，所有套餐都可用。Cloudflare 的共享证书只能证明请求来自 Cloudflare 的网络。要证明请求经过的是你的账户，需要上传自己的证书（区域级或按主机名）。全局、区域级 和 按主机名 三种模式的配置指南都在 Cloudflare 文档里。

nginx 上源站这一侧的配置如下，CA 文件放在配置指南指定的位置。

ssl_client_certificate /etc/nginx/certs/cloudflare.crt;
ssl_verify_client on;

Apache 上的配置。

SSLVerifyClient require
SSLCACertificateFile /path/to/origin-pull-ca.pem

从外部机器用 curl -k https://ORIGIN_IP/ -H 'Host: example.com' 测试，握手应当失败。

3. 防火墙放行 Cloudflare IP 段

Cloudflare 在 cloudflare.com/ips 公布其 IP 段，纯文本列表在 https://www.cloudflare.com/ips-v4 和 https://www.cloudflare.com/ips-v6。Cloudflare 文档给出的 iptables 写法是先放行来自每个 IP 段的 Web 流量，再丢弃其余所有 Web 流量。

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  iptables -I INPUT -p tcp -m multiport --dports http,https -s "$ip" -j ACCEPT
done
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
  ip6tables -I INPUT -p tcp -m multiport --dports http,https -s "$ip" -j ACCEPT
done
iptables  -A INPUT -p tcp -m multiport --dports http,https -j DROP
ip6tables -A INPUT -p tcp -m multiport --dports http,https -j DROP

运行之前先看一遍列表内容，并确认你自己的 SSH 和监控访问不依赖这些端口。Cloudflare 把这种方法排在前两种之后，理由是它 "vulnerable to IP spoofing"。IP 段很少变化，新的段会在启用前公布，但还是要定期更新。云服务商有各自的安全组工具，可以做同样的事。

检查泄露

检查仅 DNS 记录里有没有暴露源站 IP（mail、ftp 或 direct 等子域名的 A 记录，以及 SPF 记录），不要让邮件走 Web 服务器，如果源站 IP 曾经公开过，考虑更换。Cloudflare 的 源站保护指南 涵盖了这些内容。

其他防火墙：资料怎么说

有几款产品工作在主机层或应用层。下表只列出我们查到的资料对它们的说法。

这些产品都不会改动 PHP 可执行文件。插件级防火墙本身就是 PHP 应用代码，而 mod_php 的攻击可能在任何应用代码运行之前就触发。不要指望它们能挡住。

下一步

1. 打补丁。换到已修复的构建，即 8.5.12、8.4.27、8.3.36 或 8.2.35，旧分支用厂商的 backport。按你的发行版或面板查看 /fix。
2. 重启所有 PHP worker。旧进程退出之前，装了新包的服务器仍然没有修好。
3. 用 打补丁之后 页面从 Web 一侧验证。

如果今天没法打补丁，加上 临时设置，并保留 WAF 和锁定的源站。

最后审阅：2026年10月22日