Defaults.Exposed › 修復 › CDN / WAF 與主機

如何修復 CDN / WAF 與主機

對你網站背後管線的兩次解讀：你是否坐落在一面防護盾後面（一個帶 Web 應用程式防火牆的 CDN，如 Cloudflare），它過濾攻擊、吸收流量高峰；以及一張地圖，說明到底是誰在運行你的 DNS、網站和信箱。兩者在我們的評分中都屬於提示性——它們不動你的評分——但它們描述了你的源站伺服器對攻擊和宕機有多暴露，以及你的提供商有多盤根錯節。前面有一面盾、再加上一組合理拆分的提供商，正是有韌性的企業該有的樣子。

對您業務的關鍵影響： 一個前面沒有防護盾的網站，會把每一次攻擊、每一次流量高峰直接接在源站伺服器上——所以一次機器人洪流、一次上線日激增，或單單一次自動化攻擊，就能讓你下線好幾個小時，而恢復全靠你自己。在前面放一個 CDN/WAF（有免費方案）能過濾掉絕大多數自動化攻擊、吸收激增，並讓網站在全球更快——對你的 IT 人員來說通常是一個下午的活，且無授權費用。另外，如果你的 DNS、網站和信箱全都在一家提供商那裡，那裡的一次宕機或攻破就會把你整個線上存在一次帶下線；在一起事件中，知道你的提供商地圖是你首先需要的東西。這兩項檢查都不改變你的評分——但兩者都描述了對停機、銷售損失和緩慢痛苦恢復的真實暴露。

這會讓您付出什麼代價

• 一場大促銷的早晨，一陣機器人流量或一次小型 DDoS 打中你沒有防護的伺服器——網站變得爬行或直接倒下，客戶在結帳處看到錯誤，你在主機手忙腳亂時損失了一整天的銷售。前面有一個 CDN/WAF 本會吸收掉它。
• 你的 DNS、網站和信箱全都經過一家提供商；那家提供商宕機，於是你的網站、你的預約系統和你的信箱在同一刻一起變黑——你甚至發不出我們已知悉問題，因為信箱也宕了。
• 一次自動化攻擊整夜探測你的網站——SQL 注入和登入爆破腳本直接捶打你的源站，因為沒有防火牆層去過濾它們——而你直到有東西壞了才知道。一個 WAF 會在那些雜訊到達你的程式碼之前就擋掉其中大部分。
• 一起事件來襲，卻沒人能回答一個基本問題：我們到底該打給誰？網站和信箱在同一台主機上嗎？誰運行 DNS？光是把管線理出來就耗掉好幾個小時，而網站還在宕著。
• 潛在客戶的 IT 團隊在簽約前掃描你，看到一台沒有 CDN/WAF 的裸源站，外加一個洩露資訊的伺服器版本回應標頭，明明白白地宣告你跑的是什麼軟體（和版本）——在最糟糕的時刻給出一個這些人連基礎都沒加固的小訊號。

為什麼它重要。 本頁兩項檢查在我們的方法學裡都屬於提示性——它們登記為零分，永遠不改變你的評分——因為它們描述的是你的基礎設施，而非測試一個通過/失敗的安全控制。我們把它們呈現出來，是因為它們映射真實的業務暴露。一個沒有 CDN/WAF 的網站，把每一次攻擊和流量高峰直接接在源站上，沒有過濾、沒有激增吸收；加上一個（Cloudflare 的免費方案是常規路子）是一家小企業能做的槓桿最高、成本最低的韌性升級之一。而一張清晰的提供商地圖——知道你的 DNS、網站和信箱是拆分還是堆疊在一家提供商上——是出了狀況時你首先需要的東西，也是一起被控制住的事件和一次徹底停擺之間的區別。

一句話說清這是什麼

每個網站都跑在某處的一台伺服器上。本頁回答的問題是：在開放的網際網路和那台伺服器之間站著什麼——以及到底是誰在運行你線上存在的各個部件？

有兩個部分：

1. **CDN / WAF——前面的盾。**CDN（內容傳遞網路）是一個坐落在你網站前面的全球網路，把你的內容快速送給任何地方的訪客，並吸收流量激增。WAF（Web 應用程式防火牆）是一個過濾器，檢查進入的請求，在它們到達你伺服器之前擋掉惡意的。流行的服務（Cloudflare、AWS CloudFront、Fastly、Akamai、Sucuri 等）把這些捆在一起。我們查看你網站的回應，回報能否看到前面有一面盾——並且也記下你跑的是什麼 Web 伺服器。

2. 主機 / 提供商地圖——誰在運行你的管線。我們讀取那些說明誰處理你 DNS（把你的網域變成位址的目錄）、誰處理你信箱的公開記錄。由此我們能判斷你的 DNS、網站和信箱是拆分在多個提供商上（有韌性），還是堆疊在一家上（便利，但是一個單點故障）。

**最重要的一點要先說清：**在我們的評分中，**這兩項都屬於提示性。**它們不影響你的評分。我們把它們呈現出來，是因為它們描述了你的業務對停機和攻擊有多暴露——這是一個不同於評分、且非常實際的問題。

這會讓你付出什麼代價

這些不是抽象的風險——它們是一個沒有防護、盤根錯節的設定把小問題變成糟糕一天的日常方式。

• **在最要緊的那天被打下線。**你的網站坐落在源站伺服器上，前面什麼都沒有。在一次上線或促銷的早晨，流量激增——或一陣不大的機器人洪流來襲——伺服器應付不來。頁面逾時，結帳出錯，你在主機救火時損失了一整天的營收。一個 CDN 吸收激增、一個 WAF 過濾垃圾流量；兩者合起來，就是忙碌的一天和宕了一上午之間的區別。

• **一切同時變黑。**你的 DNS、網站和信箱全都經過一家提供商。那家提供商宕機（所有提供商最終都會遇到），於是你的網站、你的預約系統和你的信箱同時消失。你既處理不了訂單，也連給客戶發封我們已知悉的郵件都做不到——因為信箱也宕了。拆分提供商意味著一次故障是被控制住的，而非徹底的。

• **你的程式碼直接挨每一次攻擊。**沒有 WAF，每一次自動化探測——注入嘗試、登入爆破、已知漏洞掃描器——都不經過濾地打中你的應用程式碼。你是在賭你的軟體永遠完美無瑕、修補齊全。一個 WAF 會在那些自動化雜訊到達你之前擋掉其中絕大多數，把持續的背景攻擊變成大體被過濾。

• **因為沒人有那張地圖而緩慢、驚慌的事件處置。**有東西壞了，而第一個小時浪費在等等，誰運行我們的 DNS？信箱和網站在同一台主機上嗎？該打給誰？上。當你的提供商地圖不清楚時，每一起事件都從零開始。事先知道這張地圖，就把一場慌亂變成一通電話。

• **給謹慎買家的糟糕第一印象。**潛在客戶的 IT 團隊在簽約前掃描你，看到一台沒有 CDN/WAF 的裸源站——外加一個公然宣告你確切軟體和版本的伺服器回應標頭。這是一個小訊號，但它在恰好錯誤的時刻把你放進了連基礎都沒加固那一欄。

它實際上是什麼

CDN / WAF——那一層防護

當一位訪客（或一名攻擊者）請求你的網站時，請求要麼直接去你的源站伺服器，要麼先經過一個 CDN/WAF。如果前面有一面盾，那面盾可以：

• **過濾惡意請求（WAF 那部分）：**在注入嘗試、機器人攻擊和已知漏洞利用模式到達你程式碼之前擋掉它們。
• **吸收流量（CDN 那部分）：**從離每位訪客近的伺服器提供快取內容，並吸收激增，使一次高峰——無論正當還是敵意——都不壓垮你的源站。
• **讓網站更快：**從鄰近的邊緣伺服器送達的內容，對全球訪客載入更快。

我們透過查看這些服務在你網站回應標頭裡留下的指紋來偵測一面盾——例如 cf-ray 回應標頭（Cloudflare）、x-amz-cf-id（Amazon CloudFront）、x-served-by（Fastly）、x-akamai-transformed（Akamai）或 x-sucuri-id（Sucuri）。我們也讀取 Server 回應標頭來識別你底層的 Web 伺服器（nginx、Apache、IIS、LiteSpeed、Caddy 等），並標記任何過度分享的 X-Powered-By 回應標頭。

良好的狀態長什麼樣：在你源站前面偵測到一個 CDN/WAF，並且一個不宣告具體版本號的 Server 回應標頭。

主機 / 提供商地圖——你的基礎設施依賴

你的網域悄悄指向好幾個不同的服務：

• DNS——把 yourbusiness.com 變成實際伺服器位址的目錄。我們讀取你的網域名稱伺服器（NS）記錄，並識別常見提供商（Cloudflare、AWS Route 53、Azure DNS、GoDaddy、Namecheap、DigitalOcean、Hetzner、Linode，以及各地區註冊商等）。
• 信箱——你的郵件在哪裡處理。我們讀取你的 MX 記錄，並識別常見提供商（Google Workspace、Microsoft 365、Proofpoint、Mimecast、Barracuda、Zoho 等）。

由此我們能看出這些職責是拆分在多個提供商上（一處故障不會拖垮其他），還是堆疊在單一提供商上（便利，但一次宕機或攻破就帶走一切）。

**良好的狀態長什麼樣：**至少，DNS 由一個專門、可靠的提供商持有，而不是和其餘一切捆在同一個帳戶裡——這樣你網域的目錄就不和你的主機及收件匣同命運。

如何修復（免費，約一個下午）

**把這交給你的 IT 人員或網頁開發人員——修復是免費的。**在常見的免費方案上，把一個 CDN/WAF 放到你網站前面不花一分錢，而隱藏你的伺服器版本是一行設定。沒有授權要買。（這裡的付費選項只有監控、組合追蹤和稽核——絕不是修復本身。）業主唯一的決定是：對，在網站前面放一面盾。

因為兩項檢查都是提示性的，這裡沒有一樣是計分的——但一個 CDN/WAF 是一家小企業能做的最有價值的韌性升級之一，所以值得做。

1. 在你網站前面放一個 CDN/WAF

最常見、免費的路子是 Cloudflare：

1. 建立一個免費的 Cloudflare 帳戶並新增你的網域。
2. Cloudflare 讀取你現有的 DNS 記錄；檢查它們是否正確匯入。
3. 把你網域的網域名稱伺服器（在你的註冊商處）改成 Cloudflare 給你的那兩個。這就是把流量路由經過 Cloudflare 的開關。
4. 把 SSL/TLS 模式設為 Full（strict），使加密在訪客 → Cloudflare → 你的源站之間保持端到端。（避免 Flexible，它讓最後一段不加密。）
5. CDN 和一個基線 WAF 現在已啟動。你之後可以調整 WAF 規則，但預設值已經過濾了不少。

其他路子，取決於你的技術堆疊：

• AWS CloudFront——建立一個指向你源站的分發；搭配 AWS WAF 做過濾。如果你已經在 AWS 上，這最合適。
• Sucuri WAF——基於 DNS，無需在你伺服器上做任何改動；如果你不能動源站，它不錯。
• Fastly / Akamai——企業級的 CDN/WAF，通常用於較大或較高流量的網站。

切換後，測試網站，確認 HTTPS 處處可用，並觀察一天。不要過度快取那些必須保持個人化或即時的頁面（已登入區域、購物籃、結帳）。

2. 停止宣告你的伺服器版本

無論你加不加 CDN，都把你伺服器宣告的版本隱藏起來——那是你白白遞給攻擊者的資訊。

Nginx：

server_tokens off;

Apache（在主設定裡）：

ServerTokens Prod
ServerSignature Off

移除一個過度分享的 X-Powered-By 回應標頭（例如來自 PHP 或某個應用程式框架），在伺服器或 CDN 層面——在 Cloudflare 上你可以用一條回應標頭轉換規則把它剝掉。

3. 核對一下你的提供商地圖（可選，約 10 分鐘）

看看你的 DNS、網站和信箱實際活在哪裡：

• 如果三者都在一個提供商帳戶裡，考慮至少把 DNS 遷到一個專門的提供商（Cloudflare DNS 免費且快）。單單這一處拆分，就意味著你網域的目錄能在一次主機宕機中存活下來。
• 把地圖寫下來——DNS 提供商、Web 主機、信箱提供商、註冊商，以及每一個的登入/支援聯絡人。這一頁紙，是一起事件中你面前最有用的東西。

平台說明

• Google Workspace / Microsoft 365：這些是你的信箱提供商，不是你的網站。在網站前面放一個 CDN/WAF 不觸碰信箱，反之亦然——它們是各自獨立的決定。（信箱在 Google/Microsoft、網站在 Cloudflare 後面，是一個完全不錯、刻意拆分的設定。）
• **託管建站平台（Wix、Squarespace、Shopify）：**這些把自己的 CDN 和一定程度的 WAF 防護作為平台的一部分，所以即便我們的回應標頭檢查沒點出一個提供商，你也可能已經被防護。你通常不能在前面加自己的 Cloudflare；那也沒關係——平台替你處理了。
• **自有主機上的 WordPress：**前面加一層免費 Cloudflare 的理想候選。把它和一個安全外掛的防火牆結合，做應用層規則。

常見錯誤

• **因為網站小就跑一台裸源站。**小網站和大網站一樣會挨同樣的自動化攻擊和機器人洪流——機器人不會先查你的營收。免費的 CDN/WAF 方案正是為小網站而存在的；不用它就是把一個簡單的勝果留在桌上。
• **用 Cloudflare 的 Flexible SSL。**它顯示一把小鎖，卻讓 Cloudflare 和你源站之間的連線不加密。永遠用 Full（strict），使它端到端加密。
• **快取錯誤的東西。**過度快取已登入頁面、購物籃或結帳，可能把一個客戶的內容或過時價格顯示給另一個客戶。快取靜態內容；讓個人化和交易頁面不快取。
• **沒意識到就把一切堆疊在一家提供商上。**便利沒問題，前提是它是一個自覺的選擇——但許多企業是在那次把三者一起帶下線的宕機中，才發現 DNS、網站和信箱共用一個帳戶。讓它成為一個決定，而非一個發現。
• **把伺服器版本留在顯眼處。**這是一個免費、一行、容易被忘的加固步驟。把它關掉。

關於評分的說明

把話說得徹底明白：**這兩項檢查都不影響你的評分。**它們在我們的方法學裡登記為提示性、零分，我們絕不會因為一個沒防護的源站或一個單一提供商設定而罰你。我們回報它們，是因為它們描述了對停機、攻擊和緩慢事件恢復的真實暴露——也因為加一個免費的 CDN/WAF 是一家小企業能做的最有價值的升級之一。如果你在這裡什麼都不做，你的評分不變。如果你在網站前面放一面盾、並把 DNS 拆分出去，你就免費讓業務變得明顯更有韌性。這才是看待本頁的正確方式：不是一個要去守的數字，而是一次值得拿下的韌性升級。

常見問題