公司有个系统是以WordPress以及各种套件组成，有开放对外。

现在遇到的问题是我启用Google Cloud Armor preconfigured WAF rules，开发Team同仁就会反应常常遇到网页回应404，看Log发现都是触发了规则导致被Deny

原本都是看哪条规则，如果是太严格的那种(风险只是警告)，我就会在Policy的地方把这条规则拿掉。例如：owasp-crs-v030301-id942430-sqli：Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12)

不过目前系统要上线(WordPress对外公开有个"上线"的功能)，我发现变成会触发到SQL Injection的Rule，我查了一下这种是比较高风险，例如：owasp-crs-v030301-id942260-sqli：Detects basic SQL authentication bypass attempts 2/3 这种

感觉一直遇到问题就把防火墙规则bypass掉，这样是不是有点鸵鸟心态...因为一开始测试防火墙也都是用preview mode(侦测不阻挡)，前阵子有被DDOS过，都没有被阻挡，还好有被速率规则Deny掉，所以现在要把高风险的Rule拿掉我是有点抖抖的

但是开发Team同仁回覆这种套件的东西他们也没办法改原始码，然后WordPress又很多会动态生成参数，可能会被系统误判成SQL Injection攻击，我就算要白名单放行也不知道怎么处理

想请教各位有甚么比较好的方式可以处理吗？我爬了一些文章，基本上就是两种1. 允许规则放行 2. 修改触发规则的程式码

主要是系统本身就是对外，WordPress又常会被攻击，把一些高风险的Rule拿掉我觉得不是那么恰当，但是这样User也没办法正常使用系统，伤脑筋@@

2 个回答

3

Ray

iT邦大神 1 级 ‧ 2025-02-08 17:15:12

OWASP Policy 属于通用型的 WAF 规则, 除非你的程式是全部自己刻出来的, 在原始码阶段, 就用白箱扫描工具把程式调整好, 否则, 她很难适应特定现成的 Application 套件去调整, 因为这些套件开发者, 有可能在开发时, 就不理 OWASP 的安全原则, 那一定会冲突.

在开发阶段就没有参考 OWASP 的软体, 不适合直接套用 OWASP Policy WAF.

建议使用: 专为 WordPress 设计的 WAF 防御工具, 例如: WordFence, Cloudflare, Bitninja...等, 它们都有针对 WordPress 调整过的 Policy, 可以让套件顺利且安全的执行, 然后外面再套上 Cloud Armor 做网路层和 Web Server/Load Balancer 对 DDoS 的防守, 至于 Application 层 (WordPress) 的误报, 就让 Cloud Armor 全部放行不要处理.

我经常同时使用两三套 WAF 互补长短, 不会从头到尾只依赖一套而已;
根据不同特性, 有些 WAF 工具放在 Web Server 之外, 有些会建在主机内.
这也更能有效抵抗资安面对的瑞士乳酪理论（Swiss Cheese Model）.

WAF 误报是很常见的事情, 要不就改原始码, 要不就自己改写 WAF Policy, 如果你只会 on/off 别人写好的 Policy, 自己不会重写的话, 就要多引进其他工具来补强.

0

Gary

iT邦好手 1 级 ‧ 2025-02-10 16:38:57

  1. 先确认是误判还是真正的攻击
    针对被阻挡的请求，先检查 Cloud Armor Log，看具体的 Request URI、Query Parameters，确认是否是 WordPress 内部的正常行为，还是真的有攻击迹象。
    若有特定的 WordPress 功能（例如发布文章、插件 API）频繁被误判，这些在另外处理。

  2. 调整 WAF 规则，仅针对 WordPress 相关 API
    不一定要直接关掉整个 SQL Injection 规则，可尝试针对 WordPress 会触发的 API（如 /wp-admin/、/wp-json/）来放宽规则：

  • 建立 WAF exception rule：针对特定路径 /wp-admin/* 允许某些规则。
  • 自订 rule exclusion：仅对某些 args 或 body 参数放行，避免整体关闭规则。

  1. 使用 Google Cloud Armor 的自订 Rule
    Armor 允许自订 rule exclusion，可以先让所有请求进入 preview mode，确认哪些 args（参数）或 header 是被错误拦截的，然后针对这些参数加白名单：
    {
    "expression": "request.path.matches(\'/wp-admin/.*\')",
    "action": "ALLOW"
    }
    只对 WordPress 管理介面放行，而不是完全关掉 WAF 规则。

  2. 如 WordPress 套件无法改，考虑 Nginx Reverse Proxy，可以在 Cloud Armor 前加一层 Nginx Reverse Proxy，针对 wp-admin 或 wp-json API 做参数 rewrite，避免参数格式刚好符合 SQL Injection 攻击模式。对特定 User-Agent 或 Referer（例如：Googlebot、内部 IP）设例外规则。

以上参考