CrowdSec 取代 fail2ban

起因不是被入侵,是吵。

我的 nginx 接了 netdata,異常會發 Discord。它長這樣,連當下的 Top IP 和 Top Path 都一起貼給你:

診斷資訊給得很足,問題是它每天要響幾百上千次,而且絕大多數不是我的服務有事,是掃描器在敲 /wp-login.php、/.env、各種 .php 端點造成的 4xx。我的站根本沒有 PHP,但它們不知道,也不在乎,就是一直敲。

(上面那張其實是少數「真的有事」的一次,/api/spotify/audio-features 五分鐘被打了 9968 次,那是我自己的東西在迴圈。IP 我遮掉了,那幾條是我自己的出口。)

當時機器上已經有 fail2ban,而且數字很漂亮:

封過 614 個 IP,聽起來很有用。但我盯著那串通知想到一件事:他們一直在換 IP。封掉一個,下一個就換一條線再來。這樣封下去到底有沒有終點?

這篇是後來換上 CrowdSec 的完整過程:為什麼它比 fail2ban 適合這個情境、架設踩到的三個坑、這台機器六天內實際擋下什麼,以及我把自己封在門外的三次(第三次最蠢,也最值得寫)。最後是我做的 Discord 解鎖 bot,因為被自己擋在外面時,你連 SSH 都進不來。

先看這台機器長什麼樣#

後面的坑跟自我封鎖都跟架構有關,所以先把環境講清楚。

幾個對後文有影響的重點:

• 全部跑在同一台實體機上,家用固網加固定 IP,路由器把 80/443 轉進來。沒有雲端負載平衡,也沒有第二台可以在出事時頂著。
• 封鎖發生在 nftables,也就是比 nginx 更前面。所以被擋的請求連 access log 都不會留下,而你這端看到的是靜默逾時而不是拒絕連線。這個位置關係是後面所有診斷的基礎。
• CrowdSec 引擎跟 bouncer 是分開的:引擎讀 nginx 的 log 做判斷,bouncer 負責在防火牆執行。圖上那兩條虛線就是這個迴圈。
• nginx 後面掛著十幾個子網域,部落格、NAS、監控、MQTT、各種小工具都在裡面。任何一個服務的限流或錯誤,都會餵進同一份 access log,也就會餵給 CrowdSec。

還有一件跟本文有關的事:我的主網域走 Cloudflare 灰雲(只做 DNS,流量直連我家),但另一位站長把他的一個子網域用橘雲指到我這裡,那條路徑的來源 IP 是 Cloudflare 的節點。這件事在交叉監控那篇裡咬過我一次,細節寫在這裡:

為什麼不是 fail2ban#

fail2ban 沒有壞掉,它做的事一直很正常。問題在於它的模型:讀你自己的 log,累積你自己的失敗次數,封你自己看過的 IP。

對一個會換 IP 的對手,這是打地鼠。每個新 IP 對你來說都是全新的,要重新從零累積到門檻才會被封,而在那之前它已經掃完一輪了。

CrowdSec 換了個前提:別人遇過的壞 IP,你直接拿來用。

第三欄那個「交給 bouncer」是架構差異:CrowdSec 把偵測和執行拆開。引擎只負責判斷誰該擋,真正動防火牆的是另一支 bouncer。這個切分後面會變得很重要。

還有一點對我是決定性的:它是自架的。當時另一個選項是把站掛到 Cloudflare 後面讓它擋,但那等於把流量交給別人的 proxy。CrowdSec 在本機讀 log、在本機的防火牆執行,不動我現有的架構。

三個坑,全來自同一個根因#

裝 CrowdSec 只要兩行:

curl -s https://install.crowdsec.net | sudo sh
sudo apt install -y crowdsec
sudo apt install -y crowdsec-firewall-bouncer-nftables   # Ubuntu 24.04 預設 nftables

然後我就卡了一整晚,而且三個坑是同一顆骨牌推倒的。

舊版  /var/lib/crowdsec/hub/...
新版  /etc/crowdsec/hub/...

Source                          Lines read   Lines parsed
file:/var/log/nginx/access.log  41           3

修法是把斷掉的連結清乾淨再重裝規則集:

sudo find /etc/crowdsec -xtype l -delete     # 只刪「指向不存在目標」的 symlink
sudo cscli hub update
sudo cscli collections install \
  crowdsecurity/nginx crowdsecurity/sshd crowdsecurity/linux \
  crowdsecurity/whitelist-good-actors --force
sudo systemctl reload crowdsec

兩個很容易誤判的診斷細節#

cscli metrics 的數字是累計的。我一度以為解析率修好了卻沒有起色,其實新解析的行被之前那堆失敗的行稀釋著。reload 不會清空計數,要 restart 才會。想看「修完之後」的真實比例,就得重啟後重新累積。

用 cscli explain 一翻兩瞪眼。它會把一行 log 實際走過的 parser 鏈印出來,哪一關失敗一目瞭然:

sudo cscli explain --file /var/log/nginx/access.log --type nginx | tail -25

修好之後應該看到 crowdsecurity/nginx-logs 綠色通過並往下流進場景,而不是只剩 parser failure。

SSH 的來源只留一個#

還有一個是我自己調出來的。SSH 事件可以從 /var/log/auth.log 讀,也可以從 journalctl 讀,而兩邊是同一批事件的兩個來源。都收的話每次登入失敗會被算兩次,場景比你設定的門檻更早觸發,alert 數量也灌水。

實測兩者都解析出 261 筆,但 auth.log 要讀 10.13k 行才拿到,journalctl 只讀 330 行。所以我的 acquis.yaml 只留 journalctl:

source: journalctl
journalctl_filter:
  - "_SYSTEMD_UNIT=ssh.service"
labels:
  type: syslog

六天,1619 次#

這是這台機器最近六天的實際數字(cscli alerts list 全量統計):

拆開來看攻擊類型:

剩下的長尾是一整排 CVE 探測:CVE-2017-9841(PHPUnit RCE)、http-cve-2021-42013、CVE-2022-41082(Exchange)、thinkphp-cve-2018-20062、netgear_rce、fortinet-cve-2018-13379、jira_cve-2021-26086。這些我一個都沒裝,但它們照樣每天來敲。

攻擊不是來自「壞人的電腦」#

來源 AS 的分佈才是最有意思的一欄:

前七名幾乎全是雲端機房:Azure、DigitalOcean、阿里雲、Hetzner。掃描器跑在按小時計費的 VM 上,封掉一台,再開一台就是幾秒鐘的事,IP 還不一樣。

這正好從數據面回答了我最初那個問題:封 IP 這條路,對手的成本比你低得多。而這也是社群黑名單的價值所在,那台新開的 VM 在打到你之前,通常已經打過別人了。

Origin                       active_decisions
CAPI (community blocklist)   25.21k
crowdsec (security engine)        8

被擋的不全是壞人#

有個細節值得講清楚。某次封鎖清單裡出現 crowdsecurity/http-bad-user-agent 擋下的 167.94.146.48,查了一下屬於 Censys,做網際網路普查的研究機構,同類的還有 Shodan。它們不是要打你,是在編目全世界的公開服務。

擋不擋是你的選擇,但知道自己在擋什麼比較好。順帶一提,善意爬蟲不用擔心:whitelist-good-actors 這個 collection 預設就裝了,Google、Bing 和各家 SEO 爬蟲都在白名單裡,而且是用 rDNS 正反查驗證而不是只看 User-Agent,冒充不了。

我把自己封掉三次#

這是全篇最該被記住的部分。一套會自動封鎖的系統,遲早會封到你自己。

Ip:<我的出口IP>  crowdsecurity/nginx-req-limit-exceeded  ban  6 events

三個訊號可以立刻判斷#

被 CrowdSec 擋跟服務掛掉,症狀其實不一樣:

三個同時成立,幾乎可以直接跳到 cscli decisions list 找自己。

修法有兩層#

區網用 whitelist parser。在 s02-enrich 放一個 parser,讓整個 RFC1918 永遠不會被封:

# /etc/crowdsec/parsers/s02-enrich/lan-whitelist.yaml
name: koimsurai/lan-whitelist
description: "Never ban LAN / RFC1918"
whitelist:
  reason: "private LAN"
  cidr:
    - "192.168.0.0/16"
    - "10.0.0.0/8"
    - "172.16.0.0/12"

這條規則到目前為止已經放行了 16037 次,可以想像沒有它會有多煩。

公網出口 IP 用 allowlist。區網白名單救不了「你人在外面」的情況,那時你的來源是公網 IP:

sudo cscli allowlists create home-dev -d "我的開發機 IP"
sudo cscli allowlists add home-dev <你的出口IP>
sudo cscli allowlists inspect home-dev

用 Discord 把自己放出來#

前面三次的共同麻煩是:要解封,得先連得進去。而我被擋的時候,SSH 正是連不進去的那個東西。

當時的替代方案是手機。我用 Termux 連,平常我很喜歡它,功能該有的都有。但在路上、單手、用觸控鍵盤敲 sudo cscli decisions delete --ip ... 這種指令,而且還得先從一整張表裡認出哪個 IP 是自己,體驗實在稱不上好。

還有一件事讓情況更麻煩:CrowdSec 預設不會通知你它封了誰。profiles.yaml 裡那幾行 notifications 全是註解掉的,除非你自己去接 slack / http / email 的 plugin。所以「被自己擋」這件事從來不會主動告訴你,你只會發現連不上,然後開始猜。

# /etc/crowdsec/profiles.yaml —— 預設長這樣,通知全是註解
decisions:
 - type: ban
   duration: 4h
# notifications:
#   - slack_default
#   - http_default

所以我在既有的 Discord bot 上加了兩個指令,順便把「查」跟「解」一起解決。但這裡有個架構問題:bot 跑在容器裡,而 CrowdSec 是主機服務,容器碰不到主機的 cscli。

把 docker socket 或主機 root 權限掛進容器可以解決,但那等於讓一個對外連網的 bot 拿到整台機器的控制權。所以我改成檔案佇列:

容器能做的只有一件事:丟一個請求檔進佇列。真正執行 cscli 的是主機上以 root 常駐的 watcher,它讀請求、驗證、執行、把結果寫回。就算 bot 被打穿,攻擊者也只能丟請求檔,而且動作限定在白名單裡,拿不到 CrowdSec 的控制權。

watcher 的關鍵幾行:

ALLOWLIST = "parole"          # 解鎖後順手加進這個 allowlist
ALLOWLIST_TTL = "4h"          # 只給 4 小時,不永久放行

def valid_ip(s):
    try:
        ipaddress.ip_address(s)   # 擋 command injection
        return True
    except ValueError:
        return False

if action == "unblock":
    ip = str(req.get("ip", ""))
    if not valid_ip(ip):
        return {"ok": False, "output": f"invalid ip: {ip}"}
    rc, out = run(["decisions", "delete", "--ip", ip])
    ensure_allowlist()
    run(["allowlists", "add", ALLOWLIST, ip, "-e", ALLOWLIST_TTL])

三個設計上的細節:

做完之後,/crowdsec_list 直接把目前封鎖清單攤在手機上,每筆都有 IP、觸發的場景、還剩多久:

認出自己那筆之後,/crowdsec_unblock 填 IP 就解開,回覆會告訴你 parole 給了多久:

清單上那些 IP 順帶說明了一件事:http-cve-2021-41773、http-wordpress-scan、http-sensitive-files,全是前面統計裡的那幾種,而且 AS 查下去又是 Google Cloud 和 Azure。連被我拿來當示範的這一批,都還是跑在雲端機房上的掃描器。

最後那個讓整件事成立的關鍵,其實很簡單:bot 是主動連出去 Discord 的。你的 IP 被防火牆 DROP,擋的是「連進來」的方向,完全不影響 bot 那條既有的對外連線。所以你被鎖在門外時,它照樣收得到你的指令。

一個架在自己機器上的 web 管理面板做不到這件事,因為你連得到它才能用它,而你正好連不到。用手機 SSH 則是繞過了封鎖(行動網路是另一個 IP),但你還是得在手機上打完整的指令。

回到最初:Discord 安靜了嗎#

安靜了,但原因跟我當初打算做的事不一樣。

當時除了裝 CrowdSec,我還準備了一份 netdata 的告警靜音檔,想把 4xx 那組 route 到 silent,只留 5xx 和「變慢」。寫好了、指令也備妥了。

結果剛剛翻了一下:

$ ls /etc/netdata/health.d/
（空的）

$ ls ~/Server/netdata-web-noise-silence.conf
-rw-rw-r-- 1 timo9378 timo9378 2922  netdata-web-noise-silence.conf

那個靜音檔從來沒部署過,還躺在家目錄裡。而我確實很久沒被 4xx 告警吵過了。

原因是 4xx 自己消失了。現在同一份 access log 抽 6038 行來算:

掃描器在打到 nginx 之前就被 bouncer 在防火牆層 drop 掉了,log 裡根本不會留下那筆 404,4xx 比例自然壓在門檻底下,告警就不會觸發。

這個結果比我原本要做的好得多。靜音是把儀表遮起來,而這是真的沒事發生。如果當初我先部署了靜音檔,現在 netdata 就算真的遇到掃描潮也不會叫,我會失去一個有效的訊號;而現在它一叫,通常就真的有事,像文章開頭那張,那次是我自己的 Spotify API 在迴圈。

fail2ban 後來怎麼了#

老實說,我沒有正式退役它。CrowdSec 上線之後就沒再管,直到後來才發現它其實停在一個尷尬的狀態:服務沒在跑,設定檔還留著。

$ systemctl is-active fail2ban
inactive
$ systemctl is-enabled fail2ban
disabled

它是怎麼停掉的也有點好笑:當初為了加區網白名單,我在 jail.d/ 丟了一個 drop-in,那個檔讓它開機解析失敗,從此就沒起來過。而我沒發現,因為那段期間 CrowdSec 一直在擋,沒有任何症狀。

這裡的教訓不是「fail2ban 不好」,而是:兩套功能重疊的防護並存,最危險的不是衝突,是你以為兩邊都在守。如果那時停掉的是 CrowdSec,我大概也要過很久才會知道。要換就換乾淨,並且確認新的那套真的在動。

一頁式清單#