隨著網路攻擊的面向持續擴大，極風雲創作為Cloudflare的經銷商觀察到許多客戶利用Cloudflare 的 Web Application Firewall (WAF) 來減緩攻擊。這對客戶來說非常有幫助，但由於WAF 每天處理數百萬筆請求，產生誤判（false positive）幾乎是無可避免的。因此，我們會建議客戶的預設防護設定仍需要進一步微調。
我們會協助客戶取得必要數據，並針對其環境調整規則。本篇文章將介紹 Cloudflare 技術，幫助客戶理解 WAF 為何會觸發特定行動，以及我們如何透過優化來降低誤判、提高防護品質。
WAF 是什麼？僅靠 Log 行動還不夠嗎？
Cloudflare 的 WAF 可保護原始伺服器免受各種第七層（Layer 7）攻擊，這類攻擊專門針對應用層。WAF 提供的工具包括：
- Managed Rules：由 Cloudflare 的安全分析師編寫，用於防護常見漏洞（CVE）、OWASP 安全風險，以及如 Log4Shell 的漏洞。
- Custom Rules：客戶可利用功能強大的 Rules Language 編寫自訂規則。
- Rate Limiting Rules、惡意上傳檔案偵測、外洩憑證偵測 等。
這些工具皆建立於 Rulesets Engine 上。當規則表達式匹配時，Engine 將執行對應的 Action。
「Log」行動可以模擬規則行為，確認 Engine 是否觸發規則，並將事件記錄下來，這些日誌可透過 Security Analytics、Security Events、Logpush 或 Edge Log Delivery 取得。
然而，僅知道規則匹配了還不夠，尤其當一個規則表達式可能包含多條邏輯路徑時，例如：
若 HTTP request header 中包含 “authorization” key 或 HTTP host header 的小寫值以 “cloudflare” 開頭，則記錄。
對應的 Rules Language 語法如下：
any(http.request.headers[*] contains "authorization") or starts_with(lower(http.host), "cloudflare")
這種表達式在除錯時會遇到幾個問題：究竟是表達式左側（LHS）還是表達式右側（RHS）匹配？如 Base64 解碼、URL 解碼或轉小寫等函數可能改變原始資料，增加判斷哪個欄位導致匹配的難度。
此外，許多 Rulesets 內的規則都可能匹配。像 Cloudflare OWASP 規則集會累計不同規則的分數，當分數超過設定門檻時才觸發動作。
由於 Cloudflare Managed 與 OWASP 規則的表達式是私密的，客戶只能從標題、標籤與描述推測規則功能，例如「SonicWall SMA – Remote Code Execution – CVE:CVE-2025-32819」。這就會產生疑問：究竟是哪些欄位導致匹配？這是誤判嗎？
這時候，Payload Logging 就派上用場，它可以幫助我們追蹤到底是哪個欄位及其值（經過轉換後）導致規則匹配。
Payload Logging 是什麼？
Payload Logging 功能會記錄與規則匹配的請求欄位及其值。這能降低模糊性，提供資訊給客戶檢查誤判、確保規則正確性，並協助微調規則以提升效能。
例如前述表達式中，Payload Log 會紀錄匹配的 LHS 或 RHS，而非兩者同時紀錄。
Payload Logging 的運作方式
Payload Logging 與 Rulesets Engine 都建立在 Wirefilter（ Cloudflare 核心防火牆引擎）上，其核心是一套用 Rust 編寫的物件系統，實作了 Compiler trait 來編譯抽象語法樹（AST）。
當 Engine 執行表達式且結果為 true 時，表達式與 Execution Context 將送至 Payload Logging Compiler 重新評估。Execution Context 提供執行所需的參數值，重新評估後，符合條件的欄位將被紀錄。
Payload Log 的結構是一個欄位與值的對應表：
{ “http.host”: “cloudflare.com”, “http.method”: “get”, “http.user_agent”: “mozilla”}
備註：這些日誌可用客戶提供的公鑰加密，並可透過 Logpush 自動解密，或使用 CLI 工具、Worker 或 Cloudflare 控制台進行解密。
已推出的調整
在 Wirefilter 中，有些欄位為陣列型態，例如 http.request.headers.names 包含請求的所有 Header 名稱：
[“content-type”, “content-length”, “authorization”, “host”]
過去的 Payload Logging 會記錄整個陣列：
http.request.headers.names[*] = [“content-type”, “content-length”, “authorization”, “host”]
新版則僅部分評估陣列並紀錄符合條件的索引，例如只紀錄包含「c」的 header：
http.request.headers.names[0,1] = [“content-type”, “content-length”]
部分匹配與運算子
- eq：精確匹配
- in、contains、matches：部分匹配，支援正則
新版 Payload Logging Compiler 會只紀錄部分匹配結果，例如：
any(http.request.headers[*] contains “c”)
結果只紀錄符合條件的 header，而非全部。這樣不僅清楚，也減少日誌處理量。對於大量資料的欄位（如 http.request.body.raw）尤其有效，原本可能記錄數 KB，現在只記錄幾個 byte。
新版 Payload Log 也會紀錄部分匹配的前後內容（before/after，最多 15 bytes），例如：
http.request.headers[0,1] = [ { “before”: null, “after”: “ontent-length” }, { “before”: null, “after”: “ontent-type” } ]
優化措施
- Managed Rules 常用正則來偵測惡意請求，編譯與解析正則消耗 CPU
- 正則與中間狀態會快取於記憶體，減少重複編譯
- 使用 smallvec 減少 heap 配置，優化效能
「TRUNCATED」情況
有時日誌會顯示 TRUNCATED，因每個防火牆事件都有大小限制。改進後，Payload Log 平均大小從 1.5 KB 降到 500 bytes，降低截斷率達 67%。
未來展望
- 現行的 UTF-8 編碼可能無法完整呈現二進位資料（Binary Data），未來可能改為 byte array 或其他序列化格式
- Payload Log 存儲格式目前為 JSON，也將測試 CBOR、Cap’n Proto、Protobuf 等二進位格式，以提升處理速度與維護向後相容性
- Payload Logging 目前僅適用於 Managed Rules，未來將擴展至 Custom Rules、WAF Attack Score、Content Scanning、Firewall for AI 等
Payload Logging 的可視化提升，能讓客戶清楚了解 WAF 的防護行為是否如預期。透過日誌特異性改善，我們也在持續優化可靠性、延遲，並將擴展到更多 WAF 產品。
極風雲創為台灣Cloudflare首選經銷商，並且為台灣擁有最多Cludflare企業客戶的合作夥伴，若想開始啟用 Payload Logging，可與極風雲創的顧問團隊聯繫。
