CrowdSec 與 Fail2Ban，入侵防護的規則與社群威脅情報

首次發布

2004 年

2020 年

開發語言

Python

Go

防禦視野

單機日誌

單機 + 社群共享情報

規則形式

正規表達式過濾器

Parser、Scenario、Bucket 組成的管線

情報來源

本地規則與手動黑名單

本地規則 + 中央 API 信譽資料

封鎖執行者

Action 腳本（iptables、firewalld 等）

Bouncer 元件（防火牆、反向代理、CDN 等）

典型適用

單機、小型服務、資源受限環境

多節點、雲端、需要共享情報的環境

二、Fail2Ban 的規則與運作機制

Fail2Ban 的設定雖然直覺，但它的規則體系其實有明確的分層。理解這三層架構，是妥善維運 Fail2Ban 的基礎，也是判斷它是否適合你環境的關鍵。

Filter、Jail 與 Action 的三層架構

第一層是 Filter，負責定義「什麼樣的日誌內容算可疑」。Filter 通常以 filter.d/*.conf 的形式存在，內容是一組正規表達式，用來從日誌行中擷取時間、來源 IP 與失敗原因。第二層是 Jail，負責定義「針對哪個服務、用什麼門檻、封鎖多久」。Jail 會引用一個 Filter，並指定日誌路徑、最大重試次數、觀察時間窗與封鎖時間。第三層是 Action，負責定義「找到之後要做什麼」，例如呼叫 iptables、nftables、firewalld 或傳送通知。

這樣的拆分讓規則可以重複利用。例如同一個 sshd Filter 可以被多個 Jail 引用，分別套用到不同連接埠或不同日誌來源。管理者只需要在 jail.local 中覆寫參數，不必更動原始 Filter，就能調整封鎖策略。這種「預設規則 + 本地覆寫」的模式，是 Fail2Ban 能夠長期穩定運作的重要原因。

正規表達式：威力與維護成本

Fail2Ban 的偵測能力幾乎完全建立在正規表達式之上。好處是彈性極高，只要日誌格式能被文字描述，就能寫出對應的 Filter；壞處則是規則的品質高度依賴撰寫者的經驗。過於寬鬆的表達式會造成誤判，把正常使用者擋在門外；過於嚴謹的表達式則可能漏掉變形攻擊。更麻煩的是，當應用程式更新日誌格式時，舊 Filter 可能默默失效，而管理者往往要等到攻擊發生後才會發現。

社群雖然提供了大量現成 Filter，涵蓋 SSH、Apache、Nginx、Postfix、WordPress 等常見服務，但這些規則的維護狀態參差不齊。部分冷門服務的 Filter 可能多年沒有更新，遇到新版日誌格式時就需要手動修正。這也是許多維運人員對 Fail2Ban 又愛又恨的原因：它很可靠，但需要定期照顧。

Fail2Ban 的社群規則與限制

Fail2Ban 的社群貢獻主要集中在 GitHub 上的 Filter 與 Action 腳本，並沒有類似「威脅情報交換」的機制。也就是說，社群共享的是「怎麼辨識攻擊」，而不是「誰正在攻擊」。每台主機仍然是獨立的觀測點，必須自己累積足夠的失敗次數，才能觸發封鎖。這種設計確保了隱私與自主性，但也意味著防禦總是慢一步：你必須先被嘗試攻擊，才能學會封鎖。

此外，Fail2Ban 的封鎖通常是「全有或全無」的 IP 層級封鎖，缺乏信譽評分或風險分級的概念。同一個 IP 可能只嘗試了一次，就被其他主機的通報列入黑名單；也可能嘗試了四次，剛好在門檻以下而完全沒事。這種二元判斷在面對分散式、低頻率的攻擊時，顯得力不從心。

三、CrowdSec 的規則管線與威脅情報生態

CrowdSec 最引人注目的地方，在於它把入侵防護拆解成一條可觀測、可擴充的資料管線。它不再把「讀日誌」與「封鎖 IP」綁在同一個程序裡，而是讓每個階段各司其職，並透過本地 API 串接。這樣的設計不僅提升了擴充性，也讓威脅情報的共享成為可能。

Parser、Bucket、Scenario、Decision 四階段管線

CrowdSec 的處理流程可以分為四個階段。首先是 Parser，負責把原始日誌轉換成結構化事件，例如從 Nginx 的存取日誌中擷取出來源 IP、請求路徑、狀態碼與使用者代理。Parser 支援 Grok 模式，對於常見日誌格式有現成的 Hub 套件可直接安裝。

其次是 Bucket 與 Scenario。Bucket 負責在記憶體中累積一段時間內的事件，Scenario 則定義「什麼樣的事件組合算攻擊」。例如「同一 IP 在十分鐘內出現五次 SSH 登入失敗」就是一個典型的 Scenario。當 Bucket 中的事件達到 Scenario 設定的條件時，就會產生一個 Decision，也就是「對某個 IP 採取某種處置」的指令。

最後，Decision 會透過本地 API 發布，並由 Bouncer 訂閱執行。Bouncer 是實際執行封鎖的元件，可以是 iptables、nftables、Nginx、HAProxy、Cloudflare 或任何能接收決策的服務。這種「決策與執行分離」的設計，讓同一套偵測邏輯可以同時套用到多種基礎設施，也讓封鎖動作可以集中在一個地方管理。

社群情境庫與信譽評分機制

CrowdSec Hub 提供了豐富的 Collections、Parsers、Scenarios 與 Bouncers。Collections 是一組預先打包好的規則組合，例如 crowdsecurity/sshd 就包含了 SSH 相關的 Parser 與 Scenario。管理者可以用 cscli collections install 一鍵安裝，大幅降低設定門檻。

更關鍵的是中央 API 的信譽評分。當你的 CrowdSec 偵測到某個 IP 發動攻擊時，它會將這個觀測結果匿名化後上傳，形成一個「訊號」。中央 API 會彙整全球訊號，計算每個 IP 的信譽分數，並將結果回傳給所有訂閱者。這意味著一個正在掃描全球的殭屍網路 IP，可能在你還沒被攻擊前，就已經被列入你的封鎖清單。這種「先發制人」的能力，是 Fail2Ban 完全無法提供的。

本地 API、中央 API 與區塊清單

CrowdSec 的本地 API 是整個系統的神經中樞，負責接收 Parser 產生的事件、管理 Scenario 狀態、發布 Decision，並提供 cscli 指令查詢。中央 API 則扮演情報交換平台，接收匿名訊號並回傳信譽資料。兩者之間的通訊可以設定為雙向、單向或完全關閉，讓管理者依照隱私需求調整。

除了即時決策，CrowdSec 也支援「區塊清單」模式，定期從中央 API 下載惡意 IP 清單，匯入防火牆或反向代理。這種模式適合無法即時連線的環境，或希望降低 API 呼叫頻率的站點。整體而言，CrowdSec 的情報生態比 Fail2Ban 豐富許多，但也因此需要更清楚的資料治理策略。

四、效能、資源與誤判率實測對比

工具再好，也要能在實際環境中穩定運作。以下從資源消耗、處理能力與誤判率三個面向，比較兩者的實測表現。

記憶體與 CPU 資源佔用

Fail2Ban 以 Python 撰寫，常駐記憶體約在 30MB 至 80MB 之間，視載入的 Jail 數量與日誌量而定。由於它採用輪詢方式追蹤日誌，當日誌檔案龐大或正規表達式過於複雜時，CPU 使用率會明顯上升。對於只有少數服務的小型主機而言，這樣的資源消耗完全可以接受；但若同時監控數十個日誌來源，效能就會開始吃緊。

CrowdSec 以 Go 撰寫，編譯成單一靜態執行檔，常駐記憶體通常在 50MB 至 150MB 之間，視載入的 Parser、Scenario 與 Bouncer 數量而定。由於 Go 的併發模型較適合處理大量日誌串流，CrowdSec 在高負載下的 CPU 表現通常較為平穩。不過，CrowdSec 的元件較多，若同時執行本地 API、多個 Bouncer 與 AppSec 功能，整體資源佔用會比 Fail2Ban 高一些。

項目

Fail2Ban

CrowdSec

常駐記憶體

約 30–80 MB

約 50–150 MB

CPU 特性

日誌量大時正規表達式較吃重

串流處理較平穩，元件多時總量較高

日誌處理方式

輪詢檔案

串流讀取

橫向擴充

需自行管理多台

支援多節點與中央 API 架構

誤判率與調校成本

Fail2Ban 的誤判主要來自兩個地方：正規表達式寫得太寬鬆，或門檻設得太低。例如將 SSH 登入失敗門檻設為三次，就可能把打錯密碼的正常使用者擋住。調校方式通常是觀察日誌、調整 maxretry 與 findtime，必要時加入 ignoreip 白名單。這個過程需要一些經驗，但整體來說可控。

CrowdSec 的誤判來源較多元，包括 Scenario 條件、信譽評分與社群訊號。由於它會參考其他主機的通報，理論上誤判率較低，因為單一主機的異常觀測不會立刻導致全球封鎖。不過，若某個 IP 被大量惡意通報，而你的服務正好需要與它通訊，就可能發生「被封鎖的正常來源」。這時需要透過 cscli decisions delete 或白名單機制來處理。CrowdSec 提供 cscli alerts list 與 cscli metrics，讓管理者能追蹤每個決策的來源與理由，這對於降低調校成本很有幫助。

整體而言，Fail2Ban 的調校偏向「手工藝」，需要逐條規則調整；CrowdSec 的調校則偏向「政策管理」，需要決定哪些情報來源可信、哪些 Scenario 要啟用、哪些 IP 要白名單。兩者都需要投入時間，但方向不同。

五、部署實戰：設定範例與維運要點

接下來透過實際範例，說明兩者的安裝與設定方式。以下範例以 Debian／Ubuntu 環境為例，其他發行版僅需替換套件管理指令。

Fail2Ban 的 jail.local 實作範例

安裝 Fail2Ban 後，不建議直接修改 jail.conf，而是建立 jail.local 進行覆寫。以下是一個保護 SSH 與 Nginx 的範例：

[DEFAULT]

bantime = 1h

findtime = 10m

maxretry = 5

ignoreip = 127.0.0.1/8 ::1 192.168.1.0/24

[sshd]

enabled = true

port = ssh

filter = sshd

logpath = /var/log/auth.log

maxretry = 3

[nginx-http-auth]

enabled = true

filter = nginx-http-auth

port = http,https

logpath = /var/log/nginx/error.log

maxretry = 5

bantime = 6h

這段設定會封鎖 SSH 連續三次失敗的來源一小時，並將 Nginx 認證失敗的來源封鎖六小時。內網與本機位址則列入白名單，避免誤擋。設定完成後，使用 fail2ban-client status 與 fail2ban-client status sshd 即可查看運作狀態。

CrowdSec 的安裝與 cscli 操作

CrowdSec 的官方安裝腳本會自動偵測環境並設定基本規則。安裝完成後，建議先安裝 Linux 與 SSH 相關的 Collection：

sudo cscli collections install crowdsecurity/linux

sudo cscli collections install crowdsecurity/sshd
sudo systemctl reload crowdsec
接著安裝防火牆 Bouncer，讓 Decision 能實際執行封鎖：
sudo apt install crowdsec-firewall-bouncer-iptables

sudo systemctl enable --now crowdsec-firewall-bouncer
日常維運可透過以下指令掌握狀況：
cscli metrics
cscli decisions list
cscli alerts list
cscli hub list
cscli metrics 會顯示 Parser 的命中率、Bucket 的溢位次數與 Decision 的數量，是診斷規則是否有效的重要工具。cscli decisions list 則列出目前所有封鎖決策，包含來源、原因與到期時間。若發現誤擋，可用 cscli decisions delete --ip x.x.x.x 手動解除。

對於多節點環境，可以讓多台主機的 CrowdSec 連線到同一台本地 API，或使用中央 API 共享情報。CrowdSec 也支援「主從架構」，由一台 LAPI 集中管理決策，其他節點作為 Worker 上報事件。這種彈性是 Fail2Ban 難以比擬的。

六、社群威脅情報的價值、風險與合規
CrowdSec 最吸引人的特色，同時也是最需要謹慎以對的地方，就是社群威脅情報。它讓防禦從「被動等待」變成「主動預防」，但也帶來隱私、誤判與治理上的新課題。

群眾外包的雙面刃
社群情報的價值在於規模。單一主機看到的攻擊樣本有限，但全球數萬台主機的觀測彙整後，就能描繪出完整的攻擊基礎設施圖像。當某個 IP 在多個地區、多種服務上同時發動攻擊，它的信譽分數就會快速下降，其他主機也能提前封鎖。這種「一人被攻擊，眾人受益」的模式，大幅提升了整體防禦效率。

然而，群眾外包也意味著情報品質參差不齊。若某台主機的規則設定錯誤，把正常流量誤判為攻擊並上報，就可能導致該 IP 被其他主機連帶封鎖。CrowdSec 透過信譽評分與多重訊號驗證來降低這種風險，但無法完全消除。管理者仍需定期檢視 cscli alerts list，確認封鎖決策是否合理。

隱私與資料回傳的考量
CrowdSec 的中央 API 只接收匿名化的訊號，例如「某個 IP 在某段時間內觸發了某個 Scenario」，並不會上傳原始日誌內容。這樣的設計在隱私與情報價值之間取得了平衡。不過，對於高度敏感的環境，管理者仍可選擇關閉中央 API，只使用本地規則與手動匯入的區塊清單。

在合規層面，若組織受到 GDPR 或其他資料保護法規約束，應確認 CrowdSec 的資料處理政策是否符合要求。CrowdSec 提供企業版與自架中央 API 的選項，讓組織能在自己的基礎設施內運行情報交換，避免資料外流。相對地，Fail2Ban 完全在本機運作，沒有資料回傳問題，對於極度重視隱私的環境反而更單純。

七、選型建議與混合部署策略
看完兩者的架構與實測，最後回到最實際的問題：你該選哪一套？答案取決於環境規模、維運能力與風險偏好。
適用場景對照
如果你的環境是單一主機、服務數量不多、資源有限，而且希望設定簡單、不依賴外部服務，Fail2Ban 仍然是相當可靠的選擇。它的規則直覺、社群資源豐富，遇到問題也容易找到解法。對於個人部落格、小型企業官網或內部測試機，Fail2Ban 的性價比很高。

如果你有多台伺服器、使用雲端或容器環境、希望抵禦分散式攻擊，而且願意投入時間理解管線式架構，CrowdSec 會是更現代的選擇。它的社群情報能補足單機視野的不足，Bouncer 架構也能輕易整合防火牆、反向代理與 CDN。對於成長中的服務或需要集中管理的團隊，CrowdSec 的擴充性明顯較佳。

兩者並行的混合架構
實務上，兩者並不互斥。有些團隊會讓 CrowdSec 負責社群情報與跨節點決策，Fail2Ban 則負責特定應用程式的本地封鎖。例如用 CrowdSec 處理 SSH 與 Web 層的共享情報，用 Fail2Ban 監控冷門服務的日誌。這樣既能享受社群情報的優勢，又能保留 Fail2Ban 在特定場景的彈性。

另一種做法是先導入 CrowdSec 的區塊清單模式，將惡意 IP 匯入現有的 Fail2Ban 黑名單，逐步過渡。這種「漸進式遷移」可以降低學習成本，也讓團隊有時間評估 CrowdSec 的誤判率與維運負擔。無論選擇哪條路，重點都是先建立可觀測性：確認日誌有被正確解析、決策有被記錄、封鎖有被驗證，再逐步調整規則。

結論
Fail2Ban 與 CrowdSec 代表了入侵防護的兩個時代。Fail2Ban 以簡單、自主、低依賴取勝，適合單機與資源受限的環境；CrowdSec 以管線化、社群情報與分散式架構見長，適合多節點與需要共享情報的場景。兩者都能有效阻擋暴力破解與常見掃描，但面對分散式、低頻率的攻擊時，CrowdSec 的群體免疫機制明顯更具優勢。

選擇的關鍵不在於「誰比較強」，而在於「你的環境需要什麼」。若你重視隱私與自主，且環境單純，Fail2Ban 依然是值得信賴的老將；若你追求可擴充性與情報共享，並願意投入學習成本，CrowdSec 則能帶來更前瞻的防禦視野。最務實的做法，是先從可觀測性做起，理解自己的攻擊樣貌，再選擇合適的工具組合。畢竟，最好的入侵防護不是功能最多的那一套，而是你能夠持續維運、真正理解其運作邏輯的那一套。



                
                

                    🏠 返回首頁