141条OWASP规则上线，零误报：OCI WAF为WordPress高流量站点的配置实践

起点

在将一个高流量WordPress门户从AWS迁移到OCI的过程中，首要任务之一是重建AWS上已有的WAF防护（带有OWASP规则和自定义规则的WebACL）。OCI在基础套餐中提供集成到负载均衡器的WAF，无额外费用——与AWS相比每月可节省$271。

挑战不在于启用WAF，而在于启用全部141条OWASP规则而不破坏生产环境中的任何功能。

OWASP规则通过模式匹配来拦截攻击。高流量WordPress站点会产生看起来像攻击的模式——分析工具的Cookie、包含特殊字符的URL参数、认证Header。如果不进行精细调整，误报率会很高。

OCI WAF的架构

OCI WAF运行在两个独立的流水线中——理解这一点对于正确配置至关重要：

请求访问控制（Request Access Control）：基于IP、地理位置、Header、Cookie等条件进行ALLOW或BLOCK的规则。首先执行。

请求保护（Request Protection，OWASP）：141个能力模块，用于检查请求内容中的SQL注入、XSS、LFI、RFI及其他恶意模式。独立于访问控制执行。

访问控制中的ALLOW规则不能阻止保护规则对请求的检查。两个流水线完全独立。

这是整个配置中最重要的发现：访问控制的ALLOW不会绕过OWASP。如需条件绕过，条件必须直接设置在保护规则本身上。

141条OWASP规则

OCI WAF的OWASP能力模块涵盖主要攻击类别：

942xxx — SQL注入（SQLi）：检测参数、Header和Cookie中的SQL载荷。

941xxx — 跨站脚本（XSS）：检测请求任意部分中注入的脚本。

930xxx — 本地文件包含（LFI）：检测路径遍历和本地文件访问尝试。

931xxx — 远程文件包含（RFI）：检测通过参数中的URL进行远程文件包含的企图。

全部141个能力模块从一开始就以BLOCK模式激活。然后是真正的工作：在将真实流量指向新WAF之前，识别并解决误报问题。

我们发现的误报

1. 分析工具Cookie触发SQL注入规则

最大的问题立即浮现：分析工具（Google Analytics、Facebook Pixel、TikTok Ads等）的Cookie包含带有特殊字符模式的值——美元符号、连字符、数字序列——OWASP CRS将其归类为可能的SQL注入。

格式为`-1234-5678.90-`的Cookie值，在942xxx规则看来像是带有数字运算符的SQL注入片段。同样的逻辑也适用于同意管理工具（Privaci、OneTrust等）Cookie中经过JSON编码的值。

解决方案：将42个Cookie加入所有141个能力模块的排除列表。这指示WAF不检查这些特定Cookie的值，同时对其他所有字段保持防护。

2. Next.js Image的`?url=`参数

端点`/_next/image?url=https://...`使用一个名为`url`的参数，其中包含完整的URL。931xxx（RFI）和930xxx（LFI）规则将参数中的URL检测为远程文件包含的迹象——从模式上说技术正确，但对于这个合法端点来说是误报。

解决方案：将`url`参数从SQL注入（942xxx）、RFI（931xxx）和LFI（930xxx）规则中排除。已接受并记录的风险：如果攻击者专门在`url`参数中发送SQL注入载荷，WAF将不会拦截。

3. 已登录的WordPress用户

WordPress管理员和编辑携带认证Cookie（`wordpress_logged_in_*`和`wordpress_sec_*`），其值为Base64哈希，包含OWASP规则解读为潜在攻击的字符。结果：已登录用户在浏览wp-admin时被拦截。

正确的解决方案不是排除Cookie，而是在用户已认证时条件性地绕过整个OWASP流水线。这就是OCI WAF中最微妙的陷阱所在。

陷阱：如何实现OWASP的条件性绕过

直觉上的做法是在访问控制中创建一条ALLOW规则，当`wordpress_logged_in_*` Cookie存在时允许通过，期望这些请求跳过OWASP检查。这行不通——流水线是独立的，如上所述。

正确的做法是直接在OWASP保护规则上添加一个条件，指示WAF仅在条件为真时（用户未认证）应用规则。

有效的条件：

!contains(to_string(keys(http.request.cookies)), 'wordpress_logged_in_')

解读：仅当Cookie名称列表中不包含`wordpress_logged_in_`前缀时才应用OWASP规则。由于Cookie的哈希后缀因安装而异，通过`contains()`对Cookie名称串联字符串进行前缀匹配是唯一可移植的方式。

注意：即使API接受配置，`http.request.headers.cookie`在OCI WAF运行时中也无法作为字符串正常工作。请始终使用`http.request.cookies`（已解析的Cookie映射）配合`keys()`来访问Cookie名称。

与OKE负载均衡器的集成

在OCI中，当OKE集群通过云控制器管理器（CCM）配置负载均衡器时，WAF策略必须附加到该LB上——而不是手动创建的LB。尝试为WAF创建独立的LB并将CCM的LB置于其后，会导致不必要的复杂性和路由问题。

正确的流量路径：互联网 → OCI WAF策略（附加到CCM LB）→ OKE节点 → Pod。

在此LB后面的Pod中使用Nginx时有一个重要细节：`$binary_remote_addr`变为负载均衡器的IP，而非真实客户端IP。这会破坏任何基于IP的限速功能。

Nginx修复方案：添加带有LB子网CIDR的`set_real_ip_from`以及`real_ip_header X-Forwarded-For`。否则所有客户端共享同一个限速桶。

与AWS WAF的功能对等

完成全部配置后，我们将OCI WAF与AWS上原有的WebACL进行了比较。结果是在关键防护方面完全对等：

OWASP核心规则集：两个平台等效。

认证用户绕过：OCI通过保护规则上的条件实现，AWS通过自定义规则实现。

IP信誉列表：OCI免费套餐中不包含，通过WordPress VM上安装的CrowdSec补偿——基于集体情报拦截恶意IP。

结果

141条OWASP规则在生产环境中激活，终端用户零误报，WordPress编辑和管理员零误报。SQL注入、XSS、LFI和RFI均被拦截。费用：$0/月（含在OCI弹性负载均衡器中）。

精细调整工作历时约两天。这项投资是值得的：规则激进但校准不当的WAF比关闭WAF更糟糕——它会拦截合法用户，并使人们对这个工具失去信任。

WAF不是拨动开关那么简单，而是防护性与可用性之间的持续校准。做对了，用户感知不到它的存在，攻击者无法逾越它。