如何在 Cloudflare WAF 中建立限速規則：防範暴力破解、阻斷惡意 DDoS 與保護 API 端點實戰指南

在當代網路環境中，無論是個人部落格、企業官方網站還是 SaaS 雲端平台，幾乎每天都在承受來自全球自動化殭屍網絡（Botnet）與爬蟲程式的威脅。黑客常透過腳本反覆嘗試帳號密碼進行「暴力破解（Brute Force）」、頻繁調用高負載查詢介面消耗主機資源，或是針對 API 端點大量發送惡意請求發動「七層應用層 DDoS 攻擊」。

作為全球領先的雲端安全與內容傳遞網路（CDN）巨頭，Cloudflare 在其「Web 應用程式防火牆（WAF）」中提供了強大而靈活的「限速規則（Rate Limiting Rules）」功能。透過精準的請求頻率控制，站長能在毫秒之間識別並攔截異常突發流量，確保後端原伺服器（Origin Server）的穩定運行。

本文將帶你一步步了解限速規則的建置流程、關鍵參數設定技巧與經典防禦情境。

---

建立 Cloudflare WAF 限速規則的逐步操作

只要登入 Cloudflare 管理後台，就能透過直覺的可視化介面或複合表達式完成部署：

1. 登入 Cloudflare 儀表板
   前往 Cloudflare Dashboard 並登入您的帳戶。
2. 選定目標網域
   在站點清單中，點選您準備配置安全防禦的目標網站域名（Zone）。
3. 導航至 WAF 安全設置頁面
   在左側功能導航欄中，依序點擊「安全性（Security）」 > 「WAF」。
4. 進入限速規則分頁
   在 WAF 頂部標籤頁中，切換至「限速規則（Rate limiting rules）」，並點擊右側的「建立規則（Create rule）」按鈕。

---

核心配置參數詳解與實戰設定

在限速規則編輯頁面中，系統提供了高度自訂的條件過濾器與動作定義：

參數設定項目	功能說明與配置建議	實戰設定範例
規則名稱（Rule Name）	為此條防護規則建立清楚明確的描述名稱，方便日後維護檢視。	Protect WordPress Login POST
匹配條件（Incoming Request）	定義哪些請求會被納入計數監控。可依 URI 路徑、HTTP 方法、查詢參數、標頭等設定。	(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")
計數特徵（Characteristics）	決定以何種維度作為獨立計數的依據。預設通常為「訪客 IP（IP Address）」。進階版亦可選擇特定標頭或 Cookie。	IP
請求閾值（Requests）	設定在指定的時間窗口內，允許單一特徵來源發送的最大請求次數。	5 requests
時間窗口（Period）	評估請求頻率的滑動時間區間（例如 10 秒、1 分鐘等）。	1 minute
響應動作（Action）	當請求頻率超過閾值時，Cloudflare 邊緣節點採取的處置動作。	Managed Challenge（受控驗證） 或 Block（直接阻斷）
緩解持續時間（Duration）	觸發超額處置後，該來源在多長時間內將持續受到限制（可設 10 秒至數小時）。	1 minute

---

常見的三大防禦實戰情境

情境 1：保護 WordPress 登入入口，阻斷暴力破解

WordPress 預設的 /wp-login.php 與 /xmlrpc.php 是黑客腳本最常發動暴力撞庫的目標。透過限制 POST 請求頻率，能徹底瓦解字典檔攻擊：

• 匹配表達式：
  (http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")
• 閾值設定：1 分鐘內超過 5 次請求。
• 動作：Block（回傳 HTTP 429 狀態碼）或 Managed Challenge。
• 緩解時間：限制 5 分鐘。

情境 2：保護機敏 API 端點與簡訊/郵件驗證碼介面

許多 Web 服務提供「發送驗證碼」或「重設密碼」API，常被有心人士拿來當作簡訊轟炸（SMS Bombing）工具，導致網站主承擔巨額第三方簡訊費用：

• 匹配表達式：
  (http.request.uri.path starts_with "/api/v1/auth/send-code" and http.request.method eq "POST")
• 閾值設定：1 分鐘內超過 2 次請求。
• 動作：Block。
• 緩解時間：限制 1 小時。

情境 3：排除內部管理員與已知辦公室 IP 白名單

如果內部團隊或爬蟲（如 Googlebot）需要頻繁存取某些資源，務必在匹配條件中加入例外排除，避免自身業務受到誤傷：

• 匹配表達式：
  (http.request.uri.path starts_with "/api/" and not ip.src in {203.0.113.1 198.51.100.5})

---

最佳實踐與防誤殺注意事項

1. 上線初期善用「Log（僅記錄）」模式
   新建限速規則時，建議先將動作設為「Log」，並持續觀察 24 至 48 小時的觸發記錄。確認沒有誤傷正常用戶的操作節奏後，再將動作切換為正式的「Block」或「Managed Challenge」。
2. 謹防 NAT 共用 IP 誤殺合法用戶
   大學校園、大眾運輸 WiFi、大型企業辦公室或公發行動網路往往採用 NAT 架構，成百上千位用戶共用同一個公網對外 IP。如果閾值設定得過於極端（例如 1 秒超過 3 次即封鎖），極容易造成大批合法訪客無法瀏覽。在多數情境下，優先採用「Managed Challenge（受控驗證）」會比直接暴力封鎖更加友善且安全。
3. 留意 Cloudflare 方案配額限制
   Cloudflare 免費方案（Free Tier）通常提供有限的限速規則條數與基本計費額度；而 Pro、Business 與 Enterprise 企業級方案則支援更精細的標頭比對、自訂 429 錯誤回應頁面與更高的並發處理能力。在規模擴充時應定期檢視用量報表。