當網站遇到盲掃：我們如何用分層架構減少風險

💬 「安全不是阻擋攻擊，而是讓攻擊不起作用。」

我們每天都會在 Cloudflare 看到一些陌生的請求：
/wp-admin、/.env、/xmlrpc.php、/laravel/info.php…。

乍看之下好像很可怕，
實際上，它們只是網路世界的背景雜訊——
一群在黑暗中亂敲門的人。

重要的不是「有人敲門」，
而是「門後的結構是否能自我保護」。

這篇文章想分享的是：
在我們採用 SvelteKit + Cloudflare（前端） 與 Kirby + Caddy（後端） 的架構下，
我們如何讓這些掃描變成毫無意義的噪音。

---

一、盲掃是什麼？為什麼你不用慌

所謂的盲掃，就是機器人用固定字典嘗試各種常見弱點：

• WordPress 的後台
• Laravel 的 .env
• XAMPP 的 phpinfo.php
• 舊 CMS 的設定檔

他們並不知道你使用什麼技術，
只是將網路當作一個大型刮刮樂，用「亂敲門」的方式尋找機會。

多數時候，這些請求會得到：
404（找不到路徑） 或 403（禁止存取）。
如果你的系統回應的是這類狀態碼，
那代表它已經保護好自己了。

---

二、分層架構可以自然減少風險

我們的技術組合（SvelteKit → Cloudflare → Caddy → Kirby）
天生就具備一種「分層式保護」的效果。

1. 前端：SvelteKit + Cloudflare

這一層是最先接觸外部請求的。
大部分盲掃路徑根本不屬於我們的路由，
因此會在第一層就被自然地回應 404。

還有一件很關鍵的事：
在 Cloudflare Workers 的架構裡，是沒有實體檔案系統的。
這意味著就算有人掃 /.env 一千次，也找不到任何東西。

2. 後端：Caddy + Kirby

後端被放在第二層，只負責真正需要的資料請求。
我們會封鎖 Kirby 的核心路徑與內容檔，
並確保資料只能透過 SvelteKit 的 API 端進入後台。

換句話說，就算有人繞過 Cloudflare，
後端仍然需要「正確的 Token」或「合法的存取流程」才能進入。

3. 內容層：Kirby 的結構本身也很安全

Kirby 使用平面檔案儲存內容，但內容不暴露在公開路徑下，
只有 Panel 或 API 才能讀取。

這使得內容層天然是封閉的。

---

三、我們的目標不是「反擊」，而是「減少影響」

我們不會把時間花在追逐每一個攻擊來源、黑名單或錯誤訊號上，
而是建立一個能穩定面對各種變化的結構。

這包括：

• 僅開放真正需要的 API
• 限制不該曝光的路徑
• 壓低 Cloudflare 邊緣的噪音量
• 對 Panel 做基本的入口保護
• 使用 Token 驗證確保資料只能由前端合法呼叫

這些做法不需要每天更新規則，
也不需要頻繁關注攻擊型態。
一旦結構設計正確，
新增的攻擊就像風吹過一樣，不會造成實質影響。

---

四、這些盲掃對我們的架構意味着什麼？

坦白說，它們沒有意義。
因為我們的每一層都有自己的邏輯：

層級	攻擊可能性	為什麼沒效果
Cloudflare	掃 WordPress/Laravel	前端沒有這些路徑，直接 404
Workers	掃 .env	根本沒有檔案系統
Caddy	想繞過前端直打後端	有路徑保護、Token 檢查
Kirby	嘗試讀內容檔	/content 和 /site 不公開

即使攻擊數量再多，
也只會變成 Cloudflare Observability 裡的一小條灰色訊號。

---

五、我們真正關注的不是攻擊，而是「可持續性」

九千歲的安全觀念是這樣的：
安全不是某一次設定，而是一種可以長期維持的習慣。

所以我們會：

• 在 OpenProject 建一個「安全維護」任務類型
• 定期檢查 Logs 裡是否有新的型態
• 每半年輪替一次 API Token
• 偶爾調整 WAF 讓噪音更乾淨
• 在 Caddy 保留最基本的阻擋規則

不是為了追求「永遠不被攻擊」，而是確保「攻擊不會造成壓力」。

---

六、結語：安全是一種節奏，不是一種反應

當我們看到盲掃、404 或錯誤路徑時，
我們不會緊張，
也不會把它視為重大事件。

這些只是網路世界的日常噪音。

我們更關心的是：

• 系統是否能平靜地吞下這些流量？
• 後端是否保持隱蔽？
• API 是否有明確權限？
• 流程是否能持續維護？
• 架構是否容易理解與調整？

當答案都是肯定的時候，
安全自然會跟著產生。