用 Cloudflare Rate Limiting 降低個人博客登入爆破造成的 CPU 壓力

| Web | 1 Reads

個人博客的後台通常只有站長自己會使用。即使登入密碼已經是高強度隨機密碼,登入端點被反覆提交錯誤密碼時,仍然可能造成不必要的伺服器資源消耗。

這篇文章記錄我如何使用 Cloudflare 的 Rate Limiting Rule,把大量無意義的登入嘗試擋在 VPS 之外,避免這些請求直接打到源站。

問題不一定是密碼被猜中

如果密碼是由瀏覽器或密碼管理器生成的高強度隨機密碼,線上爆破成功的概率其實非常低。

但這並不代表登入爆破完全沒有影響。真正麻煩的地方在於:

攻擊者知道登入入口
→ 反覆提交錯誤密碼
→ 應用程式執行密碼哈希驗證
→ CPU 被消耗

對使用 ASP.NET Identity、Django、Laravel、WordPress,或其他帶有密碼哈希驗證機制的系統來說,登入驗證本來就不是零成本操作。

密碼哈希在設計上就是故意消耗一定的 CPU 資源,目的是降低離線破解密碼的速度。問題是,如果大量錯誤登入請求直接打到源站,這部分成本就會由自己的 VPS 承擔。

用 Cloudflare 在外層先擋掉

如果網站已經接入 Cloudflare,就可以在請求到達 VPS 之前先做速率限制。

我使用的是 Cloudflare 的 Rate Limiting Rule,專門限制登入表單的 POST 請求。

規則思路很簡單:

  • 只匹配登入端點
  • 只限制 POST 請求
  • 按 IP 計數
  • 超過閾值後阻止或挑戰

規則示例

在 Cloudflare 後台可以進入:

Security → Security Rules → Rate Limiting Rules

然後新增一條規則,例如:

Protect login POST

匹配條件可以寫成:

lower(http.request.uri.path) eq "[LOGIN_PATH]" and http.request.method eq "POST"

其中 [LOGIN_PATH] 需要替換成自己的登入路徑,例如:

/your-login-path

這裡使用的是:

http.request.uri.path

它只匹配 URL 的 path 部分,不包含 query string。

也就是說,即使登入頁帶有 return URL 或其他查詢參數,也仍然會命中同一條規則。

速率設定

個人博客可以先從比較保守的設定開始,例如:

3 requests / 10 seconds / IP

或者:

5 requests / 1 minute / IP

動作可以選擇:

  • Block
  • Managed Challenge

如果方案支援 Managed Challenge,可以優先考慮使用它。這樣同一個 IP 在短時間內反覆提交登入表單時,Cloudflare 會先進行攔截或挑戰,請求不會繼續進入 VPS。

實際效果

這條規則不能替代強密碼,也不能替代系統更新、SSH 私鑰登入、防火牆設定等基礎安全措施。

但它能有效降低一個很現實的風險:

登入端點被反覆試錯
→ 密碼驗證消耗 CPU
→ 小型 VPS 負載升高

對個人博客來說,這是一個成本很低、收益很直接的防護措施。

還需要注意源站保護

Cloudflare 規則只保護經過 Cloudflare 的流量。

如果攻擊者能直接訪問源站 IP,那麼就有可能繞過 Cloudflare,直接對 VPS 發起請求。

因此更完整的做法是:

只允許 Cloudflare IP 訪問源站的 80 / 443 端口

這樣可以確保 Web 流量必須先經過 Cloudflare,再由 Cloudflare 的安全規則進行處理。

結論

對個人博客來說,登入爆破最現實的問題往往不是密碼真的被猜中,而是登入端點被反覆提交錯誤密碼,導致源站反覆執行密碼哈希驗證,進而造成 CPU 消耗。

如果網站已經接入 Cloudflare,給登入 POST 請求加一條 Rate Limiting Rule,是非常實用的一層防護。

核心規則可以抽象成:

lower(http.request.uri.path) eq "[LOGIN_PATH]" and http.request.method eq "POST"

這條規則簡單、直接,能把大量無效登入嘗試擋在源站之外,特別適合個人博客、小型網站和資源有限的 VPS。

This article was last edited at