WordPress 後台的登入頁面(/wp-login.php)是最常被掃描攻擊的入口,原因很簡單——每個人都知道網址在哪。暴力破解(Brute Force Attack)的手法是自動化程式每秒送出數百次帳密組合,直到猜中為止。就算沒猜中,這類流量也會讓伺服器 CPU 持續高轉,間接影響網站速度。這篇文章比較三種常見的防護做法,分別對應不同的站台規模與伺服器環境,選最適合自己情況的那條路即可。
限制登入失敗次數,從外掛入手最快
對剛架好網站或管理單一 WordPress 的站長來說,安裝外掛是最低門檻的起點。市面上有幾款外掛都能處理這件事,其中 Limit Login Attempts Reloaded 的設定邏輯最直觀,安裝後幾乎不需要額外調整就能運作。
外掛在 WordPress 核心的認證流程裡掛鉤(hook),偵測同一個 IP 位址的連續失敗次數。超過門檻後,該 IP 在指定時間內無法再送出登入請求,後台會直接回傳封鎖提示,不進入密碼比對的邏輯。
設定上有幾個項目值得調整。
- 允許失敗次數:預設通常是 4 次,可以調低到 3 次;設太低會讓自己粗心時也頻繁被鎖住
- 初次鎖定時間:建議 20 至 30 分鐘,足以打斷自動化攻擊的節奏
- 升級鎖定機制:多次觸發後延長鎖定到 24 小時,對持續掃描的 IP 效果明顯
- IP 白名單:如果自己有固定的辦公室 IP,先加進白名單,避免誤封自己
這個做法的限制在於,它是在 WordPress 應用層處理,惡意請求還是會進到主機,跑完 PHP 與資料庫的連線才被攔下。流量峰值高的時候,伺服器負擔不會因此降低,只是讓攻擊者登入不了而已。
把登入網址換掉,讓掃描工具找不到門
WordPress 登入頁面的路徑是公開規格,所有自動化掃描工具都內建了 /wp-login.php 這個目標。把這個路徑換掉,讓外部無從猜測,是從「減少被看見」的角度降低攻擊面。
WPS Hide Login 是做這件事最輕量的選項之一,啟用後在 WordPress 設定裡新增一個欄位,讓你自訂一個私有的登入路徑,例如 /manage-2026 或任何隨機字串。原始路徑存取時會收到 404,而非登入頁。
自訂路徑要注意的細節
設定好之前,有幾件事要先處理。把新路徑記在安全的地方,因為忘記路徑後只能透過 FTP 或主機控制台停用外掛才能恢復。如果有多個管理員或遠端協作成員,要確認每個人都拿到新路徑,否則他們會以為網站掛掉。
另一個值得注意的地方是快取設定。如果站台使用了頁面快取外掛,需要確認快取設定有排除新的登入路徑,以及任何與登入相關的 POST 行為,避免快取把登入狀態錯誤保留。
這個做法的實際效果
對自動化掃描工具而言,效果很明確——找不到入口就不會嘗試登入。但這屬於混淆式防護(Security through Obscurity),有心的攻擊者如果事先蒐集過站台資訊,或者路徑設得太簡單,仍有被猜到的機會。因此這個做法適合疊加在第一種之上,而非單獨使用。
透過 Cloudflare WAF 規則在流量進站前攔截
如果站台已經走 Cloudflare 的 DNS 代理,就多了一個在邊緣節點(Edge)直接過濾請求的選項。這個做法的差異在於,惡意請求被擋在 Cloudflare 的基礎設施層,根本不會抵達主機,伺服器的資源消耗自然不受影響。
Cloudflare 免費方案提供了防火牆規則(Firewall Rules),付費的 Pro 方案以上則有完整的網頁應用程式防火牆(WAF)規則集,包含預設的暴力破解防護規則。以免費方案來說,可以手動建一條規則來保護登入路徑。
用自訂規則限制登入路徑的存取
在 Cloudflare 控制台的「安全性」、「WAF」、「自訂規則」裡新增一條規則,條件設定如下。
- URI 路徑包含
/wp-login.php - 請求方法為
POST(登入表單送出) - 行動設為 Managed Challenge 或 JS Challenge
這樣一來,所有對登入頁面的表單送出都會先過一道挑戰,自動化程式幾乎無法通過。真實使用者通常察覺不到,因為 Managed Challenge 會在背景驗證,不打擾正常操作。
搭配速率限制效果更完整
單純過濾 POST 請求仍可能放過緩速攻擊——每分鐘送幾次,不觸發暴力破解定義。免費方案的速率限制規則(Rate Limiting)可以設定同一個 IP 在一定時間內超過特定次數後自動封鎖,例如每 10 分鐘 5 次 POST 到 /wp-login.php 就封鎖 1 小時。兩條規則疊加,能覆蓋快速與緩速兩種攻擊型態。
三種做法的覆蓋範圍與適用情境
三個方向各自解決不同層面的問題,理解覆蓋範圍才能判斷需要幾層防護。
| 比較項目 | 限制登入失敗次數 | 自訂登入路徑 | Cloudflare WAF 規則 |
|---|---|---|---|
| 實作門檻 | 低,裝外掛即可 | 低,裝外掛設定一個欄位 | 中,需要已走 Cloudflare 代理 |
| 攔截位置 | WordPress 應用層 | 路徑混淆,請求進站後才判斷 | 邊緣節點,請求未進主機就攔 |
| 伺服器負載 | 惡意請求仍進主機 | 惡意請求仍進主機 | 不進主機,負載無影響 |
| 適合對象 | 剛架站、管理 1–3 個站的站長 | 疊加在限制登入次數之上 | 已上 Cloudflare、重視主機效能者 |
| 主要弱點 | 高流量時主機仍承壓 | 路徑被猜到即失效 | 需要 Cloudflare 前置條件 |
對大多數站台而言,最實際的組合是外掛限制失敗次數加上自訂路徑,成本接近零。如果站台已在 Cloudflare 上,再把 WAF 規則疊進來,可以讓主機幾乎感受不到掃描流量的存在。讓自動化攻擊工具的投入成本遠高於可能的回報,它們就會轉向下一個更容易的目標。