公司有個系統是以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也沒辦法正常使用系統，傷腦筋@@
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, 自己不會重寫的話, 就要多引進其他工具來補強.
先確認是誤判還是真正的攻擊
針對被阻擋的請求，先檢查 Cloud Armor Log，看具體的 Request URI、Query Parameters，確認是否是 WordPress 內部的正常行為，還是真的有攻擊跡象。
若有特定的 WordPress 功能（例如發佈文章、插件 API）頻繁被誤判，這些在另外處理。
調整 WAF 規則，僅針對 WordPress 相關 API
不一定要直接關掉整個 SQL Injection 規則，可嘗試針對 WordPress 會觸發的 API（如 /wp-admin/、/wp-json/）來放寬規則：
使用 Google Cloud Armor 的自訂 Rule
Armor 允許自訂 rule exclusion，可以先讓所有請求進入 preview mode，確認哪些 args（參數）或 header 是被錯誤攔截的，然後針對這些參數加白名單：
{
"expression": "request.path.matches('/wp-admin/.*')",
"action": "ALLOW"
}
只對 WordPress 管理介面放行，而不是完全關掉 WAF 規則。
如 WordPress 套件無法改，考慮 Nginx Reverse Proxy，可以在 Cloud Armor 前加一層 Nginx Reverse Proxy，針對 wp-admin 或 wp-json API 做參數 rewrite，避免參數格式剛好符合 SQL Injection 攻擊模式。對特定 User-Agent 或 Referer（例如：Googlebot、內部 IP）設例外規則。
以上參考
iThome鐵人賽
看影片追技術
