為什麼做它 — SvrGuard

一台主機、22 個網站、看不完的 log

一台跑著 22 個正式網站的 Linux 主機，某天例行翻 access log，看到的不是訪客，是機器人：一輪一輪的 /wp-login.php、/.env、/phpMyAdmin、路徑遍歷、掃描器簽名——每天幾百次，來自世界各地。

一開始的做法跟大家一樣：看到可疑 IP，手動加進防火牆。撐了幾個星期就放棄了——對面是自動化的，你是手動的，這場仗打不贏。

現成方案為什麼不合用

規則腳本類

fail2ban 這類工具強大但規則難寫難維護，正規表達式一改就怕誤殺；判定過程沒有事證留存，事後想查「為什麼封他」查不到。

雲端 WAF 類

要把流量或 log 交給第三方，DNS 也得搬家。對自架主機的人來說，「把 log 上傳出去」本身就是不想要的事。

什麼都不做

大多數人的現狀。直到某天掃描變成入侵，才發現 log 裡早就寫滿了預告。

同樣讀日誌，差別在哪

這一類工具都是「讀日誌 → 判定 → 寫防火牆」。真正的差別不在讀不讀得到，而在讀到之後你要做多少事：

	Apache	nginx	SSH	FTP	NAS web	NAS SSH
SvrGuard	✅	✅	✅	✅	✅	✅
fail2ban	✅	✅	✅	✅	❓	❓
雲端 WAF／代管防護	✅	✅	❌	❌	❌	❌

「NAS web」是 Web Station／反向代理的存取日誌，「NAS SSH」是 NAS 上的 SSH 登入失敗——套件安裝時就把 /var/log/auth.log 設好了。DSM 內建的自動封鎖本來就會擋 SSH 登入失敗，但它只算登入失敗：掃 /.env、試 /wp-login.php 不含登入，它看不到，那正是我們在 NAS 上補的那一半。
FTP 這一欄要說清楚：我們認的是 PAM 的認證失敗紀錄（多數 FTP 伺服器走這條），fail2ban 另有各家原生格式的規則；它在 NAS 上不是原生套件，我們沒查證過實際可用性，所以標 ❓ 而不是 ❌。整體而言 fail2ban 讀得到的來源和我們一樣多，甚至更多（郵件、資料庫）——它的成本在別的地方：正規表達式與門檻要自己維護，判定過程不留事證，多台主機也沒有集中的地方看。雲端 WAF 擋得多，代價是流量與 log 要交出去。

所以自己寫了一個

需求其實很單純：讀我機器上的 log、在我機器上判定、寫我機器的防火牆，全自動，留事證，別煩我。

SvrGuard 就是這個需求的產物——單一執行檔、內建 15 條規則、原生操作 nftables／ipset、事件與事證存本機 SQLite。裝好之後，那台主機在最初 9 天內自動封鎖了 721 個攻擊 IP，來自 48 個國家，零人工介入。

它先在那台跑著 22 個網站的正式主機上值勤，才放上這個網站。它在成為產品之前，已經先當了很久的自用工具——每個功能都是因為真的需要才存在的。

三個不會妥協的設計原則

核心防護與集中管理永久免費——偵測、封鎖與看自己的機隊，是每台主機都該有的基本能力；收費只收在「持續送新資料給你」——威脅位址庫與程式更新。
Fail-open：防護永不因授權停擺——訂閱到期、斷網、授權伺服器掛了，付費功能安靜休眠，偵測與封鎖照常運作。安全軟體不該拿你的安全當人質。
資料留在你的機器——事件紀錄存你本機、隨時可匯出帶走；送到 Hub 的只有攻擊事件本身（來源 IP、規則代號與觸發它的那幾行請求）。

為什麼做 SvrGuard