前言

在cloudflare系列教學的"築基"三部曲(CF整體方案、流量序列、邊緣網路及回源)完成後，CF系列教學終於要開始介紹具體功能及配置了，那麼第一個功能選擇哪一個呢？思來想去，我決定選擇CF WAF。

之所以選擇這個，是因為相對於其他功能來說，CF WAF基本上是每個使用伺服器建站的個人站長都繞不過去的坎(採用靜態站點且託管在國外免費雲上的站長請無視~)，因為其他一些供應商提供的一些基礎功能(例如國內CDN供應商的防盜鏈功能)在CF是由WAF來實現的，更別說其他的功能：比如允許主流搜尋引擎爬蟲而禁止其他非法爬蟲(包括AI爬蟲)、允許或禁止存取特定的URI等等功能都是WAF來實現的，並且，DDOS的配置也會涉及一些WAF部分的功能，所以，第一個介紹的功能選WAF完全沒毛病。

另："CF WAF的特色"部分主要是講CF WAF的理論，會比較枯燥，不感興趣理論而只關心實操的朋友可以直接從"CF WAF的配置"部分開始看。

CF WAF的特點

CF WAF和一般的WAF有何不同？

CF的WAF(Web 應用防火牆)與其他品牌的WAF 有一些不同的設計理念，這導致了它沒有傳統WAF都具有的一個共有特徵：攻擊簽名庫，原因有如下幾點：

1. 智慧規則集：CF使用了一種基於機器學習和行為分析的智慧規則集來偵測和阻止攻擊。相較於傳統的靜態攻擊庫，這種方法可以更靈活地應對新出現的威脅。
2. 即時更新：CF的WAF 規則是動態更新的。這意味著它們能夠快速回應新發現的威脅，而不需要等待攻擊庫的更新和分發。
3. 整合性：CF的WAF 與其整體網路架構緊密整合(例如文章：中提到的流量序列)，可以利用全球的威脅情報和網路流量模式進行即時分析，這種整合性使得CF能夠更有效地識別和防禦攻擊。
4. 客製化規則：雖然CF沒有一個專門的攻擊庫，但它允許使用者建立自訂的WAF 規則，以滿足特定的安全需求，這種靈活性使得使用者可以針對自己特有的威脅場景進行防護。
5. 使用者友善性：CF強調簡化使用者體驗，減少了對複雜配置和手動更新的需求。透過自動化和智慧化的防護機制，使用者無需花費大量時間管理攻擊庫。

綜合來看，CF的設計理念是透過智慧化、動態化的防護機制來應對不斷變化的安全威脅，而不是依賴傳統的、靜態的攻擊簽名庫。

CF WAF相較於傳統的基於攻擊簽章庫的WAF的有自己的優缺點，要明白這些優勢需要先從傳統的基於攻擊簽章庫的WAF的優缺點說起。

基於攻擊簽章庫的傳統WAF的優缺點

傳統基於攻擊簽章庫的WAF有自己的優缺點。

優點：

1. 即時防護：
   基於簽章庫的WAF 可以立即識別並阻止已知的攻擊類型，因為這些攻擊的特徵已經記錄在簽章庫中。這種方法對已知威脅提供了快速、有效的防護。
2. 廣泛覆蓋：
   簽章庫通常包含大量已知的攻擊模式和威脅類型，涵蓋範圍廣泛，包括SQL 注入、跨站腳本(XSS)、檔案包含漏洞等常見攻擊。
3. 易於理解和管理：
   管理人員可以清楚地看到哪些攻擊簽章被啟用或停用，並了解每個簽章的具體作用。這使得WAF 的配置和管理變得更加透明和直覺。
4. 成熟度高：
   由於基於簽章的WAF 技術已經發展多年，許多產品都具有成熟的攻擊庫，經過多次迭代和優化，可靠性和穩定性較高。

缺點：

1. 依賴更新：
   簽章庫需要不斷更新以應對新的攻擊手段。如果簽章庫更新不及時，新的攻擊可能無法被識別和阻止，這使得WAF 在面對新興威脅時可能會有滯後性。
2. 誤報率高：
   基於簽章的偵測方法往往會產生較高的誤報率，因為它們僅基於特定模式匹配，可能會將合法流量誤判為攻擊。這會影響正常用戶的體驗。
3. 難以應付零時差攻擊：
   對於未知的零時差攻擊，由於沒有對應的簽名，WAF可能無法進行有效偵測和防護，攻擊者可以利用未被識別的新漏洞繞過防護。
4. 效能瓶頸：
   簽章配對過程需要對每個請求進行檢查，當簽章庫規模龐大時，會增加處理時間和資源消耗，影響WAF 的效能和網站的回應速度。
5. 管理複雜性：
   隨著時間的推移，簽名庫會變得越來越大和複雜，管理和維護這些簽名變得更加困難，需要專業知識和額外的管理工作。

所以，傳統基於簽章庫的WAF 在防護已知威脅方面具有明顯優勢，但在面對新興威脅、零時差攻擊和誤報問題時存在一定的局限性，所以現代WAF 產品通常結合多種檢測技術，以彌補傳統方法的不足。

CF WAF的優缺點

相對於傳統基於攻擊簽章庫的WAF，CF 的WAF具有獨特的優缺點。

優點

1. 行為分析與機器學習：
   CF WAF 使用行為分析和機器學習來偵測和阻止攻擊，這使其能夠識別未知和新興的攻擊模式。透過即時分析流量模式和行為，可以更有效地應對動態和複雜的威脅。
2. 全球威脅情報共享：
   CF利用其全球網路收集和分析威脅情報，並將這些資訊應用於WAF 規則中。這意味著CF的WAF 能夠快速回應新的攻擊模式和威脅，提供及時和有效的防護。
3. 靈活的規則建立和管理：
   使用者可以根據自己的需求建立和調整WAF 規則，提供更大的靈活性和客製化。這種靈活性允許針對特定的應用場景和威脅進行最佳化。
4. 減少誤報：
   透過智慧規則和行為分析，CF WAF 可以減少誤報率，確保合法流量不會被誤判和攔截，提升使用者體驗。
5. 高性能和可擴展性：
   CF的分散式架構和高效的處理能力，使其能夠處理大量流量而不影響效能。快取和內容優化等功能也進一步提高了網站的回應速度和效能。
6. 易於管理和部署：
   CF 提供簡單的使用者介面和API，使用者可以輕鬆設定和管理WAF 規則，而不需要深入了解複雜的攻擊簽章庫。

缺點

1. 對高級用戶的客製化需求：
   儘管CF提供靈活的規則創建功能，但某些高級用戶可能會發現缺少特定的攻擊簽章庫限制了對特定攻擊的精確防護。
2. 依賴CF的基礎設施：
   CF WAF 的有效性取決於其全球網路和基礎設施。如果用戶的服務不完全在CF上運行，可能會面臨整合和覆蓋問題。
3. 潛在的學習曲線：
   儘管介面和API 設計簡潔易用，對於沒有經驗的使用者來說，充分利用CF WAF 的靈活性和自訂功能可能需要一定的學習和適應時間。
4. 隱私和資料控制：
   將所有流量通過CF的基礎設施處理，可能會引起一些用戶對隱私和資料控制的擔憂，特別是對敏感資料的處理和儲存。

所以總的來說，CF的WAF其實主要適合那些大規模使用CF基礎架構來建置應用程式的用戶，有其限制：如果用戶服務不全是部署在CF上，則還是需要依靠傳統的WAF類方案。

註：一些優秀的安全產品其實已經完全整合了傳統的WAF和CF WAF的優點，例如Palo Alto防火牆。

CF WAF功能介紹(Free計劃)

在Cloudflare 的Free 方案中，WAF 的功能是有限的。具體來說，Free 計畫提供了基礎的安全防護功能，但不包括智慧規則集和進階WAF 功能。

Free 計劃中WAF的一些基本特點如下：

1. 基礎規則集：Free 計畫中包含了一些基礎的WAF 規則，可以防護常見的威脅和攻擊類型，如SQL 注入、跨站腳本攻擊（XSS）等。
2. 手動規則管理：使用者可以手動新增和管理一些基本的防護規則，但這些規則相對簡單，缺乏智慧化和動態更新的特性。
3. 有限的客製化：雖然Free 計畫允許使用者建立自訂的WAF 規則，但這些規則的複雜度和數量有限，不如付費方案中的功能全面。
4. 基本的防護級別：Free 計畫主要提供基礎層級的防護，不包含進階的威脅情報和機器學習驅動的智慧規則。

其中，基礎規則集的主要內容包含如下：

1. SQL 注入防護：
   • 偵測並阻止透過SQL 查詢語句注入惡意程式碼的攻擊行為。
2. 跨站腳本(XSS) 防護：
   • 阻止惡意腳本注入網頁，從而保護使用者資料和瀏覽器安全。
3. 本機檔案包含(LFI) 和遠端檔案包含(RFI) 防護：
   • 防止攻擊者透過包含檔案的漏洞執行惡意程式碼。
4. 跨站請求偽造(CSRF) 防護：
   • 阻止攻擊者透過偽造的請求強制使用者執行不必要的操作。
5. 命令注入防護：
   • 偵測並阻止透過命令列參數注入惡意程式碼的攻擊行為。
6. 路徑遍歷防護：
   • 阻止攻擊者存取和操作伺服器上的任意檔案。
7. 文件上傳漏洞防護：
   • 偵測並阻止透過檔案上傳功能進行惡意檔案注入的攻擊。
8. 暴力破解防護：
   • 阻止頻繁且重複的登入嘗試，防止帳號被暴力破解。
9. 惡意爬蟲和自動化工具防護：
   • 識別和阻止惡意爬蟲和自動化工具的存取請求，保護網站內容和資源。
10. DDoS 攻擊緩解：
    • 自動偵測並緩解大規模的分散式阻斷服務(DDoS) 攻擊，確保網站可用性。

這些基礎規則集和具體防護內容構成了Cloudflare WAF 的核心保護機制，幫助使用者有效抵禦各種網路攻擊和安全威脅。

CF WAF的配置

CF WAF區域可設定功能介紹

在上一節我提到Free計畫中CF WAF的基礎功能，其實對於CF WAF的具體配置來說，還是很簡單的，基礎規則集是預設生效：

所以在WAF部分可以配置的也就3項，自訂規則：

速率限制(這部分內容後續我在講DDOS功能的時候說)：

工具：

CF WAF自訂規則

自訂規則簡述

自訂規則的設定邏輯是基於使用者定義的條件和對應的操作來偵測和防護特定類型的流量：基於CF提供的"傳入請求比對條件"和"可選操作"，使用者自己進行適當的規則配置以及運用邏輯符號(or、and)，再結合CF的自動化程序、DDOS防護等，就可以"組合"起來實現多種實用功能：例如允許主流搜尋引擎的爬蟲而攔截其他爬蟲、攔截異常的UA、防盜鍊等等，Free計畫提供的5條WAF規則正常情況下已經足夠滿足個人站長的需要了。

自訂規則支援的條件類型非常多：

最後還有一個cookie值的字段，我就不單獨在浪費一張截圖了，而支援的操作如下：

自訂規則支援的操作

託管質詢

託管質詢是一種自動化的安全檢查機制，透過向訪客提出一系列驗證請求來確定其是否為合法使用者。這些質詢通常用於偵測和阻止惡意機器人（bots）、爬蟲以及其他自動化攻擊，同時確保合法使用者能夠正常存取網站。

"託管質詢"處理流程如下：

1. 觸發條件：
   • 託管質詢會在請求滿足特定條件（如某些規則、閾值或偵測到的可疑行為）時觸發。觸發條件可以包括IP 位址、請求頻率、請求標頭內容、地理位置等。
2. 質詢類型：
   • CAPTCHA：顯示圖形驗證碼，要求使用者輸入以驗證他們是人類。
   • JavaScript 挑戰：透過讓使用者的瀏覽器執行一段JavaScript 程式碼來驗證請求的合法性。如果瀏覽器成功執行程式碼，則表示請求來自真實使用者。
   • 行為挑戰：基於使用者行為的分析來確定其合法性，例如滑鼠移動、點擊等人類行為特徵。
3. 用戶回應：
   • 訪客需要完成質詢，例如輸入驗證碼或等待JavaScript 挑戰完成。如果成功通過質詢，則請求被允許繼續；否則請求被阻止。
4. 結果處理：
   • 成功通過質詢的請求將繼續被處理，允許存取網站或資源。
   • 未能透過質詢的請求將被阻止，訪客會收到相應的提示或錯誤訊息。

託管質詢主要用於以下場景：
• 防止DDoS 攻擊：透過質詢機制減緩大量惡意請求，保護伺服器資源。
• 阻止惡意機器人：防止自動化腳本和惡意爬蟲的訪問，保護網站內容和資料。
• 提高網站安全性：減少惡意流量，提高網站整體的安全性和穩定性。

JS質詢

JS 質詢是一種透過執行JavaScript 程式碼來驗證請求是否來自真實使用者而不是自動化程式（如惡意機器人）的安全檢查機制。這個機制主要用於區分人類使用者和自動化腳本，以確保只有合法使用者能夠存取網站。

"JS質詢"處理流程如下：

1. 觸發條件：
   • JS 質詢會在請求滿足特定條件（如某些規則、閾值或偵測到的可疑行為）時觸發。觸發條件可以包括IP 位址、請求頻率、請求標頭內容、地理位置等。
2. 質詢過程：
   • 當請求觸發JS 質詢時，CF會傳送一段JavaScript 程式碼給客戶端瀏覽器。
   • 瀏覽器必須執行這段JavaScript 程式碼。這個過程通常是透明的，使用者不會察覺。
3. 驗證請求：
   • 執行JavaScript 程式碼後，瀏覽器會自動將執行結果傳回CF。
   • CF驗證執行結果。如果結果正確，則表示請求來自真實使用者；如果結果不正確或瀏覽器未能執行程式碼，則請求可能來自自動化程式。
4. 結果處理：
   • 透過質詢：如果驗證通過，請求將被允許繼續，使用者可以正常存取網站。
   • 未通過質詢：如果驗證未通過，請求將被阻止，使用者會收到相應的錯誤訊息或提示。

JS質詢和託管質詢使用的場景一致。

互動式質詢

互動式質詢是一種透過要求使用者完成特定的互動操作（如驗證碼、點擊確認按鈕等）來驗證請求是否來自真實使用者的安全檢查機制。這個機制主要用來區分人類使用者和自動化程式（如惡意機器人），確保只有合法使用者能夠存取網站。

"互動式質詢"處理流程如下：

1. 觸發條件：
   • 互動式質詢會在請求滿足特定條件（如某些規則、閾值或偵測到的可疑行為）時觸發。觸發條件可以包括IP 位址、請求頻率、請求標頭內容、地理位置等。
2. 質詢過程：
   • 當請求觸發互動式質詢時，Cloudflare 會向用戶端顯示互動式驗證頁面。
   • 此頁通常包含一個驗證碼（如reCAPTCHA）或其他形式的互動式挑戰（如點擊確認按鈕、拖曳滑桿等）。
3. 用戶回應：
   • 使用者需要完成頁面上顯示的互動操作，例如輸入驗證碼或完成滑桿驗證。
   • 完成操作後，驗證結果會傳回Cloudflare。
4. 驗證請求：
   • Cloudflare 驗證使用者的回應。如果回應正確，則表示請求來自真實使用者；如果回應不正確或使用者未能完成操作，則請求可能來自自動化程序。
5. 結果處理：
   • 透過質詢：如果驗證通過，請求將被允許繼續，使用者可以正常存取網站。
   • 未通過質詢：如果驗證未通過，請求將被阻止，使用者會收到相應的錯誤訊息或提示。

互動式質詢和JS質詢以及託管質詢使用的場景一致。

跳過

「跳過」操作允許你根據特定條件指定某些請求不受特定WAF 規則或整個WAF 的限制。這意味著這些請求會直接繞過定義的WAF 檢查，並繼續其處理流程。這對於一些合法的請求，但可能會觸發誤報或不需要嚴格檢查的場景，提供了一種靈活性。

"跳過"處理流程如下：

1. 觸發條件：
   • 配置跳過操作時，需要設定特定的條件。當請求滿足這些條件時，跳過操作就會被執行。觸發條件可以包括IP 位址、請求方法、URI 路徑、請求頭內容、地理位置等。
2. 配置跳過規則：
   • 在Cloudflare WAF 設定中，建立或編輯一條防火牆規則，選擇"跳過"作為操作，並指定應跳過的規則或檢查。
3. 跳過處理：
   • 當一個請求滿足配置的條件時，該請求將跳過指定的WAF 規則或檢查，不會觸發相應的防護措施。請求將直接通過，進入下一個處理階段。

"跳過"主要用於以下場景：
• 誤報處理：如果某些合法請求經常觸發WAF 規則導致誤報，可以使用跳過操作來避免這些請求被阻止。
• 特定流量最佳化：對於某些可信任的流量來源（如內部系統、可信任IP 等），可以設定跳過操作，減少不必要的檢查，並提高處理效率。
• 調試和測試：在開發和測試過程中，可以使用跳過操作繞過某些WAF 規則，以便更快地進行調試和驗證。

阻止

"阻止"操作指示WAF 在偵測到符合特定條件的請求時，立即拒絕該請求，防止其繼續傳遞到網站伺服器。這是防護措施中的關鍵步驟，用於保護網站免受各種攻擊和惡意行為的影響。

"阻止"處理流程如下：

1. 觸發條件：
   • 配置阻止操作時，需要設定特定的條件。當請求滿足這些條件時，阻止操作會被執行。觸發條件可以包括IP 位址、請求方法、URI 路徑、請求頭內容、地理位置、查詢字串、用戶代理等。
2. 配置阻止規則：
   • 在Cloudflare WAF 設定中，建立或編輯一條防火牆規則，選擇「Block」作為操作，並指定應封鎖的條件或規則。
3. 阻止處理：
   • 當一個要求滿足配置的條件時，Cloudflare WAF 會拒絕該請求，傳回對應的HTTP 狀態碼（通常是403 Forbidden 或406 Not Acceptable）。請求將不會到達目標伺服器。

"阻止"主要用於以下場景：
• 防止攻擊：阻止已知的攻擊模式，如SQL 注入、跨站腳本（XSS）、跨站請求偽造（CSRF）等。
• 阻止惡意流量：攔截來自惡意IP 位址、惡意機器人或爬蟲的請求，保護網站資源和資料。
• 強化安全防護：防止特定類型的惡意要求，提升網站的安全性和可靠性。

託管質詢、jS質詢和互動式質詢各自的優劣勢及使用優先級

託管質詢）、JS 質詢和互動式質詢是三種不同的安全驗證機制，它們各有優劣勢，適用於不同的場景。

託管質詢：
優勢
• 自動更新：由CF管理和更新，無需使用者手動設定。
• 高效防護：能夠有效防禦多種類型的攻擊，包括DDoS 和惡意機器人。
• 使用者友善：在必要時展示驗證，不會過度打擾使用者。
劣勢
• 潛在誤報：可能會誤攔截合法用戶，尤其是在挑戰機制較為嚴格時。
• 依賴CF配置：使用者對特定質詢形式的控制較少。

JS 質詢：
優勢
• 無縫體驗：大多數情況下，使用者不會察覺到質詢的存在，體驗流暢。
• 自動化阻斷：有效阻止沒有JavaScript 支援的自動化工具和機器人。
劣勢
• 腳本依賴：依賴瀏覽器支援JavaScript，對於不支援JavaScript 的裝置和瀏覽器可能無效。
• 可能繞過：進階攻擊者可能會編寫腳本繞過JavaScript 質詢。

互動式質詢：
優勢
• 高準確性：透過人類難以模擬的互動操作，有效區分真實使用者和機器人。
• 強力防護：適用於高風險場景，提供更高的安全性。
劣勢
• 使用者體驗影響：需要使用者進行手動操作，可能會影響使用者體驗，特別是在頻繁出現時。
• 適應性差：對使用者設備和網路環境的適應性要求較高，可能在某些情況下不便使用。

這3種質詢方式適用的場景及設定優先順序建議如下：
• 託管質詢優先順序較高，因為它由CF管理，可以根據最新的威脅情報動態調整，適用於大多數場景下的常規防護，適合想要簡化配置並依賴CF專業管理的用戶
• JS 質詢優先於互動式質詢，因為它對使用者體驗影響較小，適用於希望在不影響使用者體驗的情況下阻止大部分自動化攻擊的場景。
• 互動式質詢優先順序最低，但在高風險情況下，可能會直接觸發，以提供最強的安全保障，適用於高安全性要求的場景，如登入頁面、敏感資料存取等，防止進階自動化攻擊。

總的來說，這三種質詢操作可以靈活結合使用(對於一般用戶，使用託管質詢即可)，根據具體需求和安全策略進行配置，以達到最佳的防護效果。

自訂規則配置實踐範例

講了這麼多理論，總是要有點乾貨，下面我將一些常用的需求及自訂規則對應配置方式整理出來，大家按需選擇即可。

允許經過CF驗證的自動化程序抓取網站信息

這應該是個人部落客都需要的，在允許包括主流搜尋引擎在內的自動化程式收錄網站的同時，攔截掉其他惡意的爬蟲，透過"and"可以添加限定條件，如下圖：

註："要跳過的WAF組件"是必選的，不過具體選哪幾個大家可以依照自己的需求選擇，我是選的前3個。

上圖中，如果不加"and"就是對託管二級域名下的所有子域名都生效；通過添加"and"可以限定只允許認證的自動化程序(搜尋引擎爬蟲等)對主機名稱"blog.tangwudi .com"對應的網站進行訪問。

這條規則只是顯式允許了合法的自動化程序的訪問，並未拒絕惡意爬蟲，需要結合後面的針對非法自動程序進行"託管質詢"規則一起來實現既放行合法自動化程序同時阻止惡意自動化程序的功能。

註1：將上述規則中的"跳過"改為"阻止"，就可以阻止主流搜尋引擎機器人對網站的訪問

註2：已知自動化程序包含許多類別，如有需要是可以針對這些類別進行精細化控制的，這主要是透過"已通過驗證自動程序類別"字段來控制。例如，您可以單獨阻止人工智慧(AI) 機器人、爬蟲在未經您允許的情況下爬取你的網站內容並訓練大型語言模型(LLM) 然後重新生成內容，這條規則需要位於"允許已知自動程序"的規則之前，具體配置如下：

對異常流量(主要是惡意爬蟲)進行託管質詢

規則配置如下：

這條規則結合前面允許"已知自動程式"的規則，其實就實現了對非CF認證的自動程式(包括惡意爬蟲)開啟著名的CF"5秒盾"，當然，也有破CF"5秒盾"的方法，不過，起碼提高了惡意爬蟲的爬取門檻，能攔下絕大部分惡意爬蟲就算成功。

允許對網站特定URI的訪問

為啥有這個需求？其實CF是可以識別並放行非惡意自動化程序，不過這需要花錢升級pro：

對於Free計劃的用戶而言，就只能手動放行對特定URI路徑的訪問，例如，博客有RSS功能，就需要開放各種RSS相關自動化程序對博客RSS的周期性訪問：

API介面存取也是一樣的處理方式。

透過UA允許特定自動化程序的訪問

這種主要是針對UA(UserAgent)的判定，如果一些自動化程式有自己特定的UA關鍵字，就可以使用該方式，例如，透過UA控制允許google機器人訪問，當然，也可以透過"and"添加其他限制條件，例如Google的ASN號：

註1：上圖只是以Google機器人舉例，實際上要允許谷歌機器人存取只需要前面講到的允許"已知自動程式"訪問即可。

註2：如果只是針對有明確UA內容(且無其他額外判定條件)的請求進行限制，後面的用戶代理阻止功能更方便。

防盜鏈

防盜鏈功能主要是對"引用方"(http頭部中的referer)字段內容的判斷，例如，透過google搜尋引擎搜到你的網站地址並點擊訪問過來的請求，referer裡就有google的關鍵字，同理，其他搜尋引擎搜尋過來的訪問請求也一樣(透過其他網站上的連結訪問過來也一樣)。

以我的部落格地址為例，假如我只允許google和bing搜尋引擎以及友站"abc.example.com"友鏈過來的訪問，而禁止其他任何網站的鏈接，那麼規則如下：

自訂規則部分總結

其實，上面介紹的實踐範例只是我覺得最常用的，欄位部分還有很多項目，例如：cookie、國家/地區、IP來源位址、請求方法、http版本、威脅分數等等，這些項目透過"and"和"or"可以產生非常多的組合，實現非常靈活的功能，大家可以根據自己實際的需求來配置，我就不多說了，免得說我像個老婆婆一樣囉嗦。

由於Free計畫只有5條自訂規則的額度，所以創建規則的時候，大家盡量把優先權相同且操作相同的規則合併成一條：例如操作都是"跳過"、"阻止"、"託管質詢"等等，這樣除了少數優先順序要求非常高的規則(例如禁止AI機器人爬網那種)，其他的都進行合併後，5條自訂規則的額度就足夠了。

另外，要設定CF WAF的自訂規則，需要設定人員對欄位中的各種概念有一定程度的了解，例如ASN、引用方(referer)、使用者代理(UserAgent)的意義和實際流量中對應的內容，例如，openai機器人的UA內容是這樣：

需要先知道其UA是這個內容，才能夠知道如何利用自訂規則的用戶代理字段去匹配，否則，你想要配置規則都會不知道如何下手～。

IP存取規則

其實，IP存取規則不應該在WAF部分來寫，因為在流量序列中，IP存取規則是位於WAF功能之前的：

不過功能很簡單，且在CF控制台中，也是位於WAF部分：

所以乾脆在這裡一起寫了，另外還有一個"用戶代理阻止"的功能，也打包一起說了。

那麼，IP存取規則主要作用是什麼呢？顧名思義，讓你可以控制哪些IP位址(或IP位址範圍)或ASN號碼可以存取你的網站，哪些不能。

註：透過國家控制是企業版功能，Free方案不支援。

例如我想要允許某個IP範圍(假設為192.168.100.0/24)造訪我的網站，同時禁止Google(AS15169)和微軟(AS8075)的IP來訪問我的網站，則設定如下：

所以，雖然使用自訂規則也可以實現這個功能，不過如果目標明確(透過IP或ASN就能夠直接鎖定的)，使用IP存取規則比使用自訂規則更方便快捷。

用戶代理阻止

CF的WAF提供了兩種主要的方法來阻止特定的用戶代理(UserAgent)：透過前面講過的自訂規則以及工具部分的用戶代理阻止：

儘管這兩者看似有重疊，但它們有不同的用途和靈活性：

1. 自訂規則：
   • 靈活性：自訂規則可讓你根據各種條件（如IP 位址、ASN、地理位置、請求路徑等）來建立複雜的防火牆規則，包括封鎖特定的使用者代理程式。你可以定義規則的邏輯和優先級，滿足更細緻的需求。
   • 應用場景：適合需要複雜條件的防護場景。例如，你可能需要結合多個條件（如使用者代理程式和請求路徑）來阻止某些惡意流量。
2. 使用者代理阻止功能：
   • 專精：這個功能專門用來阻止特定的用戶代理。它提供了一個簡化的介面和操作方式，使得管理用戶代理變得更直接和方便。
   • 應用場景：適合需要快速、簡單地阻止某些用戶代理的情況。例如，你發現某些爬蟲或惡意工具使用特定的用戶代理，你可以快速新增這些用戶代理到封鎖清單中。

所以，其實和前面的IP存取規則類似，用戶代理阻止的功能也可以使用自訂規則來實現，只是自訂規則提供了更大的靈活性和細粒度的控制，而專門的用戶代理阻止功能則提供了一個簡單、快速的方式來處理用戶代理相關的攔截需求，兩者可以根據特定的防護需求和操作複雜性來選擇使用。

總結

終於把CF WAF的功能講完了，其實這部分內容配置起來並不復雜，常用的操作也就那3種(跳過、阻止、託管質詢)，但是要從整體脈絡上講清楚CF WAF的特點以及和傳統WAF相比的優劣勢，卻需要涉及很多專業知識，並且這樣才能真正了解"自訂規則"的不同之處。

對CF WAF的一句話總結：和CF全球網路無縫集成，利用人工智慧和機器學習，結合DDoS 保護、Bot 管理和安全分析，以自訂規則為補充，完成對實時流量的監控和防護，並自動偵測並應對各種網路攻擊。

所以，其實單獨把CF WAF拿出來講沒啥意義，因為它本來就是CF眾多功能模組聚合在一起的整體效果的體現。