DDoS 防護推薦：規格表比不出來的 7 個項目

確認並判斷防禦量級

在談判斷標準之前，有三個數據事實會影響所有後續判斷。

第一，年度風險由少數極端事件主導。

2025 年我們觀測到的月度峰值，平均是 712 Gbps，中位數只有 390 Gbps，兩者差距近一倍，代表分布嚴重偏斜。也就是說，並不是每個月都有 712 Gbps 的攻擊，而是少數幾個月的極端值把平均拉高了。季度層級的落差更大：第三季平均 1,205 Gbps，第四季只有 204 Gbps。

這件事的採購意涵是：**任何以平均流量或常態流量為基準推算出來的防護規格，都會在那少數幾次裡失效。** 而防護只要失效一次，服務中斷就已經發生，前面11個月的穩定不會被客戶或主管機關拿來抵銷。

第二，高強度攻擊不是罕見事件。

12 個月裡有 10 個月的月度峰值超過 150 Gbps，其中 4 個月突破 1 Tbps，單次最高達 2.4 Tbps。

如果內部評估還停留在「我們大概不會遇到超過 10 Gbps 的攻擊」，這個假設需要更新。同期業界統計顯示，逾 96% 的攻擊規模低於 10 Gbps，但這個分布描述的是所有攻擊的平均狀況；一旦成為特定攻擊方的目標，企業面對的就是分布最極端的那一端，而不是中位數。

第三，處置窗口比人工流程的反應時間更短。

業界統計顯示 2025 年約九成的攻擊持續時間低於 10 分鐘。我們觀測到的年度最大事件（2.4 Tbps）發生在當地時間晚上 20 時 45 分，由預先部署的自動化規則完成緩解，全程無人工介入。

十分鐘這個數字，是後面幾項判斷標準的共同前提。「偵測 → 通報 → 判斷 → 處置」這條流程，如果任何一個環節需要人，總時間就會超過事件本身的長度。

一、承載容量的計算基準，比最大值重要

規格表上的最大承載值意義有限，因為那通常是廠商全網的加總，不代表分配到你身上的可用容量。

該問的不是「你們最大擋過多少」，而是以下三個問題：

• 這個承載值是全網加總，還是單一清洗節點的容量？

• 攻擊集中在單一節點時，超過該節點容量的流量會怎麼處理？

• 是否有分攤機制，也就是同時有多個客戶被攻擊時的資源配置邏輯？

為什麼要問到這個層次？因為 Tbps 級攻擊的特性是短時間、單點集中。全網 100 Tbps 的容量，如果最靠近你的節點只有 2 Tbps，那實際能承接的就是 2 Tbps。

規格上的合理基準：以你所在區域可用節點的容量為準，且至少要能覆蓋近 12 個月同類型組織所觀測到的月度最高值，而不是平均值。

二、常態在線，還是按需啟動

這一項是所有判斷標準裡最容易被忽略、影響卻最直接的一個。

DDoS 防護的部署模式大致分兩種：

• 常態在線（Always-on）：所有流量平時就經過清洗設施，攻擊發生時直接在既有路徑上緩解。

• 按需啟動（On-demand）：平時流量走原本路徑，偵測到攻擊後才把流量導引到清洗中心。

按需啟動的價格通常較低，這是它存在的理由。但它有一個結構性的時間成本：偵測、決策、路由變更（BGP 宣告或 DNS 切換）、路由收斂，全部完成通常需要數分鐘到數十分鐘。

把這個時間放回前面的數據：九成攻擊在十分鐘內結束。這意味著在相當比例的事件裡，流量導引完成的時候，攻擊已經結束了——服務中斷已經發生，清洗機制才剛就位。

我們觀測到的集中型攻擊（1、3、5、7 月）正是這種型態。以 5 月為例，全月只有 5 月 7 日一次事件達到 1,200 Gbps，其餘事件都低於 40 Gbps。這種單次極端事件要求的是「隨時到位的防禦」，任何需要人工啟動、流量導引或跨系統協調的機制，反應時間都可能長於事件本身。

該問清楚的：如果是按需模式，從偵測到清洗生效的實測時間是多少？這個數字要寫進合約或 SLA，而不是口頭說「很快」。

三、自動化緩解的實際範圍與人工介入門檻

「我們有自動化防護」這句話，不同廠商指的可能是完全不同的東西。有的是全自動判斷與處置，有的是自動偵測加人工確認，有的只是自動發告警。

建議問的三個問題：

• 哪些攻擊類型可以完全自動緩解，哪些需要人工確認？

• 自動緩解的規則是通用型還是客製型？兩者的觸發條件分別是什麼？

• 需要人工介入的情況，值班的實際覆蓋時間與回應時限是多久？

第二個問題值得多說明。我們 7 月那起 2.4 Tbps 事件，是由通用型高流量 UDP 特徵規則觸發緩解的，不是針對特定來源的客製規則。這說明該次攻擊沒有使用足以規避通用特徵的混淆手法；但同時也指出一個限制——如果攻擊方採用更接近正常流量特徵的向量，通用規則的有效性會下降。

因此完整的答案應該包含兩層：通用規則覆蓋的範圍，以及當通用規則不夠時，客製規則的建立需要多久。後者才是遇到針對性攻擊時的真實反應能力。

至於值班時間，這一項要對照攻擊的實際發生時段。我們的年度最大事件發生在晚上八點四十五分。攻擊方選擇非上班時段不是巧合，而是常見選擇——值班人力最薄弱的時段，恰好是最容易取得成效的時段。「上班時間內回應」這種條件，實際上排除了最可能發生問題的那段時間。

四、網路層與應用層是否分別配置

流量型攻擊（L4）和應用層攻擊（L7、CC）需要的技術完全不同，前者靠承載與清洗容量，後者靠行為分析與請求識別。有些方案只做前者，有些把後者當附加功能。

一個常見但錯誤的規劃順序是：先處理流量型攻擊，應用層之後再說。

這個順序的問題在於，它假設攻擊方會依序來。但我們的觀測資料不支持這個假設。以季度平均檢視，網路層在第三季暴增 122%、第四季下滑 83%，同期應用層則是逐季單向走低，兩者的走勢沒有對應關。本觀測期間未發現兩層之間存在明確的調度關聯。

更具體的是雙層併發的紀錄：上半年六個月中，有四個月的兩層峰值落在同一天。也就是說，在那四個月裡，流量型攻擊與應用層攻擊是同日發生的。

採購上的意涵：兩層需要分別配置，不是二選一，也不是有先後。如果方案只涵蓋一層，實際的防護覆蓋率就不是廠商聲稱的那個數字。

該問清楚的：應用層防護是同一套方案內建，還是需要另外購買？兩者的計費是否分開？同時發生時，資源會不會互相排擠？

五、告警聚合與事件分級跟攔截容量一樣重要

這一項幾乎不會出現在任何規格表上，但它決定你的團隊能不能撐過一個高密度攻擊的月份。

2025 年 10 月，我們觀測到全年最高的事件密度：約 40 起事件、幾乎每日發生，強度集中在 150 至 380 Gbps 區間，沒有單一事件特別突出。

這種型態的傷害不在技術面，而在營運面。40 起事件全部都需要判斷、記錄、追蹤，但每一起單獨看都達不到升級處置的標準。累積效應是告警疲勞，而告警疲勞的實際後果是：當真正重大的事件發生時，它會在雜訊裡被忽略。

值得注意的是，這個月的強度區間高度集中，比較不符合多個獨立攻擊來源的隨機分布特徵，而較接近單一資源進行長期成本試探的行為模式，其目的可能在於測定不觸發防禦升級的最高持續強度。換句話說，這種型態可能是刻意設計的。

該問清楚的：

• 平台是否提供告警聚合，也就是把同一波攻擊的多筆告警合併為一起事件？

• 是否有事件分級，讓低強度事件不觸發跟重大事件相同的通報流程？

• 告警的通報對象與層級是否可以自訂？

如果每一起事件都以同等層級處置，維運量能可能在數週內耗竭。這不是假設，而是一個 40 起事件的月份會直接驗證的事。

六、計費與合約條件：三個容易被忽略的地方

攻擊次數或流量上限：
部分方案對清洗次數、清洗時數或攻擊流量設有年度上限，超過另計。以我們的觀測資料估算，一個 40 起事件的月份足以在單月耗掉不少方案的年度額度。簽約前應該用近 12 個月的實際事件密度去試算，而不是用廠商的建議值。

超額計費的計算方式：
若有超額費用，是按攻擊流量、清洗時數還是事件次數計算？這三種算法在 Tbps 級事件下的金額差距可能很大。

合約期間內的規格調整彈性：
這一項的重要性來自外部趨勢。2025 年一年之內，公開揭露的最大單次攻擊從 7.3 Tbps 一路上升到 31.4 Tbps；依 Cloudflare 的年度報告，超大流量型攻擊的規模相較 2024 年底成長超過 700%。這代表以歷史觀測值為基礎配置的容量，有效期間正在縮短。三年合約如果沒有中途調整規格的機制，第二年就可能不夠用。

該問清楚的：
合約期間內若需要提升規格，是重新議價還是有既定的加購條件？

七、事件報告與稽核文件

這一項對政府、金融、醫療等受法規約束的單位特別重要，但常常在採購階段被漏掉，等到需要提交資料時才發現拿不到。

該確認的：

• 攻擊事件是否提供正式的事件報告，內容包含偵測時間、攻擊類型、峰值、緩解動作與處置結果？

• 報告的產出時間與交付方式是什麼？

• 平台是否提供可自行匯出的原始紀錄，供內部稽核或主管機關查核使用？

具體來說，一份可用的事件報告至少要能呈現這種層級的資訊：偵測時間（含時區）、攻擊類型、最大速率（bps 與 pps 皆需）、緩解動作、觸發的規則類別、是否有人工介入。前述 7 月事件的處置紀錄就是這種格式。沒有這個層級的紀錄，事後的檢討與對外說明都缺乏依據。

此外，如果你所屬的單位適用資通安全管理法，或需要依資安署的資安事件應變處理行動指引進行通報，事件報告的取得時效會直接影響通報作業能否如期完成。

詢價前的問題清單

把前面七項整理成可以直接拿去問的版本：

關於容量

• 這個承載值是全網加總還是單節點容量？我所在區域的可用節點容量是多少？

• 攻擊集中在單一節點且超過容量時，超出的流量如何處理？

關於部署與反應

• 是常態在線還是按需啟動？若為按需，從偵測到清洗生效的實測時間是多少？

• 哪些攻擊類型可以完全自動緩解？哪些需要人工確認？

• 值班的實際覆蓋時段與回應時限？非上班時段的處理方式是否相同？

• 客製規則從需求提出到生效需要多久？

關於覆蓋範圍

• 應用層防護是內建還是另購？計費是否分開？

• 兩層同時遭受攻擊時，資源是否互相排擠？

關於營運

• 是否提供告警聚合與事件分級？通報層級可否自訂？

關於合約

• 清洗次數、時數或流量是否有上限？超額如何計費？

• 合約期間內提升規格的條件是什麼？

關於稽核

• 事件報告的內容、產出時效與交付方式？

• 原始紀錄是否可自行匯出？

三個常見的規劃錯誤

一、用平均值推算容量：
平均 712、中位數 390 的分布已經說明，年度風險集中在少數幾次。容量基準應該是月度最高值。

二、只用歷史最高值推算容量：
這會導致另一種失誤——資源配置在錯誤的防護層級。合理的做法是同時追蹤「月度最高值」與「事件次數」兩項指標，並定期檢視兩者的相對變化，而不是只盯單一數字。

三、依當期活動量調整配置：
2025 年的 6 月與 11 月是全年唯二峰值低於 150 Gbps 的月份，而這兩次低點都緊接在高強度期間之後：6 月接在前五個月的持續高壓之後，11 月接在 7 至 10 月的多樣化攻勢之後。11 月的低點過後，12 月又回升到 173 Gbps。

在時序上，這兩段靜默期比較接近攻擊方投入後進行成效評估與資源重整的階段，而不是威脅解除。也就是說，看起來最適合調降配置的時間點，很可能正是對方準備下一輪的時間點。

常見問題

小結

規格表能回答「這個方案最多能擋多少」，但決定實際成效的是另外幾件事：防禦有沒有在攻擊發生前就在線上、緩解需不需要人來啟動、應用層有沒有分開配置、告警機制撐不撐得住一個 40 起事件的月份、合約有沒有留下調整空間。

這七項判斷標準都不是抽象的最佳實務，而是從 12 個月的實際觀測反推出來的。如果你正在進行 DDoS 防護方案的評估或續約，歡迎與我們聯繫，我們可以協助你用實際的攻擊數據來檢視現有配置。