網站被DDoS攻擊了嗎?中小企業3步驟自救教學,檢測清單、應變流程與法律責任一次看懂
「DDoS攻擊」每個月在 Google 被搜尋 27,100 次,多數人不是想學怎麼發動網路攻擊——是自己的網站正在打不開,慌張地查這四個字母代表什麼。網站連不上、流量圖出現詭異的垂直線、客戶在 LINE 群裡問「你們家是不是掛了」,這時候該先做什麼?本文只談中小企業站主能做的事:DDoS攻擊與駭客攻擊的差別、3 分鐘自我檢測清單、被打掛當下的應變步驟、事前的三道低成本防線,以及法律責任歸屬。
DDoS攻擊是什麼?跟駭客入侵網站有什麼不同
多數人第一次接觸這個詞是在新聞標題上——某某銀行官網被打掛、某某政府單位服務中斷,配圖永遠是戴著兜帽的剪影。這個畫面誤導很多中小企業主,讓人以為 DDoS攻擊是「有人潛進我的系統」——不是的。
DDoS攻擊的基本原理:殭屍網路怎麼運作
DDoS 的全名是 Distributed Denial of Service,中文譯作分散式阻斷服務攻擊。原理粗暴:攻擊方調動成千上萬台裝置,同一時間對同一個網站發出請求,把伺服器的頻寬、連線數或運算資源塞爆,讓真正的客戶連不進來。
關鍵在「分散式」三個字。這些裝置絕大多數不屬於攻擊者本人,而是被惡意軟體感染、遠端統一操控的第三方設備——家用路由器、網路攝影機、數位錄影機、智慧家電——集合起來就是俗稱的殭屍網路(Botnet)。裝置主人通常毫無知覺,攻擊流量對單一裝置只是一點點頻寬。
規模失控到什麼程度?Cloudflare 威脅報告指出,2025 年全球緩解的 DDoS 攻擊總數突破 4,710 萬次,較前一年成長 121%;同年 12 月,名為 Aisuru(Kimwolf)的殭屍網路創下單次 31.4 Tbps 歷史紀錄。這個紀錄不是一次跳上去的——同年稍早的 4 月,Cloudflare 才緩解過一波峰值 6.5 Tbps 的攻擊,之後陸續被 7.3 Tbps、11.5 Tbps、22.2 Tbps、29.7 Tbps 等多波攻擊逐次刷新,短短八個月天花板拉高將近五倍。發動一次攻擊的成本,已低到攻擊者不需要挑對象。

DDoS 與 DoS 的差異:一台電腦堵門,還是一群人湧入大門
DoS(Denial of Service)是單一來源發動的攻擊,封鎖來源 IP 就結束了,今天幾乎已失去威脅性。DDoS 難處理,難在它沒有「那個 IP」——流量來自幾萬個分散各國的真實裝置,每個都像正常訪客,封鎖單一 IP 沒意義,封鎖整國又可能連真客戶一起擋掉。中小企業幾乎不可能靠主機硬扛,問題不在防禦技術,在頻寬總量的懸殊。

常見的三種DDoS攻擊類型:流量型、協定型、應用層
美國網路安全暨基礎設施安全局(CISA)把 DDoS 攻擊分成三大類,依據是打在網路架構的哪一層,對站主有實際用途——不同類型的徵兆不一樣。
| 攻擊類型 | 鎖定目標 | 常見手法 | 典型徵兆 |
|---|---|---|---|
| 流量型 Volumetric | 對外頻寬 | UDP Flood、DNS 放大攻擊、NTP 放大攻擊 | 頻寬瞬間打滿,整站連不上,連 ping 都不通 |
| 協定型 Protocol | 伺服器連線資源 | SYN Flood、Ping of Death、Smurf 攻擊 | 連線數異常暴增,伺服器 CPU 正常但無法建立新連線 |
| 應用層 Application | 網站程式本身 | HTTP Flood、對搜尋頁或登入頁的高頻請求 | 流量看起來不大,但網站極慢、資料庫負載飆高 |

最容易被誤判的是應用層攻擊:流量數字不誇張,主機商監控可能不會亮紅燈,站主看到的只是「網站怎麼今天特別慢」——這類攻擊模仿真實使用者行為,專打站內搜尋、商品篩選、登入驗證這類最耗資源的頁面。
DDoS攻擊的目的是癱瘓服務,不是竊取資料——這件事必須講清楚。入侵是找漏洞進系統拿東西,DDoS 連門都沒進,只是把門口堵死。但實務上 DDoS 有時被當成掩護,趁資安人員忙著處理流量時進行真正的入侵,攻擊結束後日誌還是要調出來看,不能因為服務恢復就當沒事。
延伸閱讀:「弱點掃描:中小企業不用花錢的網站體檢清單」(上稿後補)讀完攻擊原理後,下一步是確認網站體質,那篇有免費檢測工具的操作說明。
網站被DDoS攻擊了嗎?3 分鐘自我檢測清單
網站打不開的原因有很多種,被攻擊只是其中一種,而且不是最常見的那種。我看過太多站主第一時間就下結論說「一定是被駭了」,結果真正原因是主機商機房在維護、或外掛更新後撞版本。誤判的代價不只是虛驚一場,是把處理時間花在錯的方向。這份清單用意在快速收斂範圍,不是診斷書。
4 個常見徵兆:從流量、來源、速度到完全斷線
第一,流量在分鐘等級暴增:不是今天比昨天多三成,是十分鐘內衝到平常同時段的十倍、二十倍,曲線垂直上去、平台式維持,不像正常流量有起伏。
第二,請求來源異常集中:翻主機或 CDN 的存取日誌,若大量請求集中在少數幾個 IP 網段、或集中來自平常沒有生意的國家,這是明顯訊號。來源極度分散但每個 IP 只打一兩次,也可能是大型殭屍網路,比較難判斷。
第三,回應時間變慢或間歇性逾時:應用層攻擊最典型的樣子。網站還在,但每次載入要等十幾秒,重新整理有時成功有時失敗,搜尋頁、商品列表頁比靜態頁面明顯更慢。
第四,完全無法連線,或反覆出現 502、503 錯誤:伺服器已經沒有餘力回應任何請求,前台顯示的是主機商或 CDN 產生的錯誤頁,不是網站自己的畫面。
整理成可逐條打勾的清單:
- 網站流量在分鐘等級內暴增,遠超平常同時段水準
- 後台或主機監控看到大量請求集中在少數幾個 IP 或同一網段
- 頁面載入時間明顯變慢,甚至間歇性逾時
- 網站完全無法連線,或反覆出現 502/503 錯誤畫面
- 這段時間沒有促銷活動、媒體曝光或其他能解釋流量暴增的正常原因
- 主機商或 CDN 服務商後台出現異常流量警示通知
勾到三項以上,建議依下一章應變步驟處理並同步聯繫主機商;勾到一到兩項,先往設定異常或資源不足的方向查。

怎麼分辨是DDoS攻擊,還是主機資源不足或正常流量暴增
DDoS攻擊、主機資源不足、正常流量暴增這三種狀況的前台症狀高度重疊,分辨關鍵在三個維度:持續時間形狀、流量來源組成、有沒有可解釋的外部原因。
| 狀況 | 持續時間特徵 | 流量來源特徵 | 可採取的動作 |
|---|---|---|---|
| DDoS攻擊 | 突然開始、突然結束,中間維持在高原期,可能反覆多波 | 來源國家與平常客群不符,或集中在少數網段,跳出率接近 100%、停留時間趨近 0 | 聯繫主機商與 CDN 服務商,啟動防護模式並保留日誌 |
| 主機資源不足 | 使用量上升後逐漸惡化,離峰時段自動恢復 | 來源正常,是真實客戶,行為數據看起來合理 | 檢視主機規格與資料庫查詢效率,考慮升級方案 |
| 正常流量暴增 | 與某個外部事件同時開始,之後緩慢衰減 | 來自社群平台、新聞網站或搜尋引擎的推薦流量,有明確 referrer | 確認事件來源,臨時擴充資源,把握流量做轉換 |
最快的驗證方法是看流量的「行為品質」:真人會停留、會點下一頁;攻擊流量的停留時間趨近於零,跳出率貼近 100%。打開 GA 即時報表,看的不是人數,是這群人在做什麼。另一個線索:促銷帶來的流量暴增通常有預兆,社群觸及、開信率會先動——柱子憑空冒出來,多半不是生意。
網站被DDoS攻擊當下,中小企業能做的 3 個應變動作
先講一句掃興的話:網站已被打掛的當下,站主自己能做的事情其實不多。真正的處置能力在主機商和 CDN 服務商手上,攔截流量必須發生在流量進到伺服器之前。站主的角色是判斷、通報、配合、記錄,價值在於速度——二十分鐘內完成通報和三小時後才發現,中斷時間差了一個量級。
本文的應變步驟與防禦建議為一般性參考,不保證能完全防禦或阻止 DDoS攻擊;發生疑似攻擊時建議同時聯繫主機商或專業資安服務商協助處理。
STEP 1–4:從確認狀況到事後復盤
STEP 1 確認狀況:輸入:流量監控畫面、錯誤截圖、檢測清單勾選結果。動作:排除誤判,先從外部確認網站是否真的無法存取(用手機行動網路開一次,避開自家網路或快取干擾),再看主機後台資源曲線。輸出:初步結論——是、不確定、否,控制在五分鐘內,不確定也是有效結論。
STEP 2 聯繫主機商或 CDN 服務商:輸入:網域名稱、異常開始的時間點(精確到分鐘)、流量截圖。用對方的緊急聯絡管道,開票直接寫「疑似遭遇 DDoS 攻擊,請協助確認流量來源並啟動防護」,會被分派到正確隊列。輸出:工單編號,留著它,後面復盤和求償都用得到。
STEP 3 暫時限流或啟動防護模式:輸入:CDN 或 WAF 的後台權限。Cloudflare 這類服務多半提供緊急模式(如 Under Attack Mode),啟用後對每個訪客做瀏覽器驗證,代價是真實客戶也要多等五秒;也可臨時封鎖非目標市場流量、關閉站內搜尋等耗資源功能。輸出:啟用紀錄,攻擊結束後記得關掉——留著不關會傷轉換率。
STEP 4 事後復盤:輸入:攻擊期間的伺服器日誌與服務商報告。問三個問題:打的是哪一層、防護哪個環節失效、下次多久才能發現。輸出:復盤紀錄和調整清單,銜接下一章三道防線。日誌要盡快調閱,多數主機商保留期只有七到三十天。復盤同時建議把損失量化成一個數字,方便後續跟主機商求償或跟老闆報告。算法很簡單:攻擊持續時數乘以平常同時段的平均每小時營收,再加上這段期間流失的訂單數乘以客單價,得出的區間就是這次事件的損失估算——比單純寫「網站掛了幾小時」有說服力得多。

沒有專職 IT 團隊時,第一時間該找誰求助
順序有講究。第一通打給主機商或 CDN 服務商,只有他們能在網路層動手;第二通給建置廠商或維護接案者,檢查應用層設定與日誌。不能反過來——建置廠商通常無法處理頻寬層級的攻擊,先找他們只是浪費時間。若攻擊持續、規模超出主機商能力,或已造成營運損失,可向 TWCERT/CC 通報,並視情節向警政單位報案。
台灣不缺真實案例。2025 年 10 月,親俄駭客組織對台灣多家上市公司與政府機構發動集體攻擊,半導體 IC 設計公司世芯-KY 公開證實遭遇 DDoS 攻擊,網站一度受影響,公司當晚完成應變並恢復正常運作。這個案例值得看的地方,不在它被攻擊,在節奏——確認、公告、應變、恢復全在同一工作日內走完。上市公司有資安團隊、有應變流程,所以動作快;中小企業沒有團隊,但可以有一份清單:緊急電話、後台帳號、誰有權限,寫在紙上貼在能立刻找到的地方。真正拖慢應變的往往不是技術,是「密碼在誰那裡」。

技術處置之外,還有一件同樣緊迫的事:客服信箱和 LINE 已經被塞爆,要不要跟客戶說什麼。原則很簡單——誠實承認網站異常、給一個保守的預估恢復時間、避免在還沒查清楚前臆測是被攻擊還是系統問題。一句「網站目前異常,工程團隊正在處理,預計 O 小時內恢復,造成不便敬請見諒」比完全沉默或事後才發公告,更能保住客戶對品牌的信任——技術恢復得再快,這段沉默期留下的印象通常比停機時間本身更久。
延伸閱讀:「502 bad gateway 是什麼?五種網站錯誤代碼的排查對照」(上稿後補)網站被打掛時最常見的錯誤畫面之一,那篇整理了各代碼代表哪個環節出問題。
事前該有的 3 道低成本防線
多數中小企業的資安預算是零,這不是不負責任,是現實。第一、二道防線用免費或月費數百元的方案就能起步,第三道甚至不用花錢,只需改變一個習慣。必須誠實說明:這三道防線降低的是受攻擊時的影響程度與復原時間,不能保證絕對防禦。
第一道防線:CDN 與流量清洗,把攻擊擋在主機外面
CDN(內容傳遞網路)原本用途是加速,把靜態內容分散到全球節點。副作用是天然具備防禦能力:訪客連的是 CDN 節點,不是主機真實 IP,攻擊流量先打在 CDN 頻寬上,大型 CDN 業者的頻寬總量是任何單一主機比不上的。Cloudflare、Fastly 這類服務都有免費或低價方案,一般中小企業流量規模在免費層級就夠用,設定成本主要是把 DNS 指向服務商。
常被忽略的細節:啟用 CDN 後,主機真實 IP 必須確實隱藏。若 IP 曾公開過(舊 DNS 紀錄、郵件標頭、憑證透明度日誌都可能洩漏),攻擊方可繞過 CDN 直接打主機,前面部署等於白做,防火牆記得只接受 CDN 節點連線。

第二道防線:WAF 與防火牆規則,過濾異常請求
WAF(網頁應用程式防火牆)處理的是 CDN 擋不掉的那一半——應用層攻擊,檢查每個 HTTP 請求:同一 IP 一分鐘內請求超過幾次、User-Agent 是否為已知惡意工具、有沒有嘗試存取後台路徑。
對沒有 IT 人員的站主來說,實務做法是啟用服務商的預設規則集,不要自己寫規則——誤判率經過大量調校,比自訂規則安全得多。真正需要自訂的只有兩種:登入頁與表單頁的速率限制、非目標市場的地區封鎖。TWCERT/CC 的基本防護建議還包含幾件不用花錢的事:避免用預設密碼、限制不必要的對外開放埠、善用 CDN 與負載平衡分散流量——共同點是都需要有人真的去做。
選服務商有三個檢查點:免費方案防護額度上限、是否提供 24 小時緊急支援、後台能否自行啟用緊急模式而不必開票等人處理——第三點在攻擊當下影響最大。

第三道防線:持續監控——你多久才會知道自己被打掛?
這是最容易被跳過、卻最影響損失金額的一道。前兩道防線處理「攻擊來了怎麼辦」,第三道處理更前面的問題:攻擊來了,你什麼時候會知道?多數站主的答案說出來有點尷尬——是客戶告訴他的,LINE 訊息、客服信箱、社群留言。如果攻擊發生在半夜,就是隔天早上開電腦才發現。
有位經營品牌官網的客戶,某次促銷檔期流量圖出現異常尖峰,客服同時收到一批「網站打不開」的訊息。他當下反應是「活動太成功、伺服器擠爆了」,還挺高興。隔天調數據才確認那晚有很大一部分流量根本不是人,是一場規模不大的攻擊——真實客戶被擠在門外,剛好是檔期黃金時段。讓我在意的是他後來說的話:「如果那天晚上有人跟我講一聲,我至少可以先把活動延後兩小時。」問題不是他不會處理,是不知道要處理。

第三道防線很單純:讓網站狀態有一個不依賴客戶通報的來源——主機商的告警通知(多數方案內建,只是預設沒開)、CDN 後台的流量提醒,或任何定時檢查網站回應的機制都行。重點在於這條資訊管道是主動推給你的,不是等你想起來才去看。檢查一件事就好:網站掛掉會不會有訊息主動通知到你手機?答案若是不會,這道防線目前是空的。
三道防線談的都是技術面的損害控制,但還有一個常被忽略的財務工具:確認現有的產物保險或營業中斷保險,是否涵蓋網路攻擊造成的營收損失,或另外評估投保網路資安保險。多數中小企業從沒想過這件事在保單裡有沒有涵蓋,直到真的求償才發現保單完全沒提到網路攻擊——這跟前三道防線一樣,都是平常沒事時最容易被跳過的準備動作。
如果你想確認自己的網站現在到底處在哪一種狀態,老闆文學院的電子報固定會整理這類中小企業自己就能上手的資安與維運筆記,不推銷任何資安產品,訂閱最新一期還送價值千元的 AI 工具箱。
DDoS攻擊的法律責任:被害人與加害人分別要注意什麼
這一章是諮詢時最常被問、答案卻最模糊的部分:對方要負什麼責任、萬一自己的設備被利用了會不會有事。
以下為法律條文白話說明,不構成法律意見,個案是否構成犯罪或需負民事賠償責任,須由執業律師依事證判斷。
台灣刑法第 360 條白話解讀:對方觸犯了什麼罪
中華民國刑法第 360 條規定:無故以電腦程式或其他電磁方式干擾他人電腦或其相關設備,致生損害於公眾或他人者,處三年以下有期徒刑、拘役或科或併科三十萬元以下罰金。
構成要件有三個:無故(沒有正當理由,壓力測試事先取得授權就不算)、干擾電腦或相關設備(DDoS 灌爆伺服器屬典型干擾行為)、致生損害(實際造成損害才成立,營業損失、緊急處理費用都算,留存證據很重要)。第 360 條跟第 358 條無故入侵電腦、第 359 條取得或刪除電磁紀錄不同。DDoS 通常只落在第 360 條,因為攻擊方沒進到系統拿東西;若伴隨資料外洩,適用條文會不一樣。
實務上還有一層現實:跨境攻擊追訴難度很高。流量來源分散多國、經過多層跳板,追查得先透過司法互助程序向對方國家調證據,光是這道程序常常就要拖上數月。加上多數跳板裝置的真實主人自己也不知情、無從問起,即使報案能追到人的比例也不樂觀。這不是勸人不要報案——保留報案紀錄對保險理賠、客戶說明、主機商求償都有用——只是要讓期待值符合現實。
如果你的網站被當成攻擊別人的跳板,你需要負責嗎
主機被植入惡意程式成為殭屍網路一員對外發動攻擊,或伺服器開放設定不當的服務(可被利用做放大攻擊的 DNS、NTP)被拿來當放大器——這種情境比多數人想的更常見,站主什麼都沒做,設備卻參與了攻擊。刑事責任核心在「故意」,不知情狀況下被利用通常難以認定;但民事責任是另一回事——若能證明主機管理有明顯疏失(長期未更新、用預設密碼、忽略多次警告),受害方主張賠償時會被拿出來討論,個案仍須由律師依事證判斷。
| 情境 | 需要做的事 | 是否需要負責 | 可求助窗口 |
|---|---|---|---|
| 自己的網站遭受攻擊 | 保留日誌與服務商報告、記錄中斷時間與營業損失、必要時報案 | 不需負責,屬被害人 | 主機商/CDN 服務商、TWCERT/CC、警政單位報案窗口 |
| 主機被入侵當成跳板 | 立即斷開對外連線、重建主機、更換所有憑證與密碼、通報主機商 | 刑責通常不成立;民事責任視管理疏失程度而定 | 主機商、資安服務廠商、TWCERT/CC |
| 攻擊伴隨個資外洩疑慮 | 依法定程序評估通報義務、通知受影響當事人 | 依個資法規範另行認定 | 主管機關、法律專業人士 |
| 誤把壓力測試打到別人主機 | 立即停止、主動聯繫對方說明 | 未取得授權可能構成無故干擾 | 執業律師 |
若懷疑已造成大規模個資外洩或金流異常,應優先依法定通報程序處理,本文不涵蓋重大資安事故的完整應變流程。
延伸閱讀:「個資法:網站端該做到的合規清單」(上稿後補)若攻擊過程伴隨資料外洩疑慮,那篇整理了網站端可自行檢查的合規項目與通報窗口。
常見問題(FAQ)
DDoS攻擊不是能不能避免的問題,而是多快能發現、多快能應變
我想收回一個常見的說法:中小企業不用擔心 DDoS攻擊,因為駭客沒興趣打小網站。這句話十年前也許成立,現在不成立了——攻擊已自動化、服務化、廉價化,發動者不需要認識你,也不需要理由。
但這不代表要恐慌式地投入預算。三道防線裡真正需要花錢的部分其實不多——CDN 有免費方案、WAF 用預設規則集就有基本效果、監控多半是把服務商內建功能打開而已。真正的門檻不在費用,在於有沒有人在事情發生之前坐下來花一個下午設定完。
坦白說,這件事很難有動力去做。它跟做廣告、拍商品照不一樣,做完不會有看得見的成果,最好的結果是「什麼事都沒發生」。我看過的中小企業裡,願意在平安無事時處理這件事的是少數,多數人是被打掛過一次之後才回頭補起來。
留一個問題給讀者:假設今天半夜三點,你的網站無法連線,你會在幾點知道這件事?答案如果是「隔天早上」,那不是資安問題,是資訊落差的問題——而這個落差,是三道防線裡最便宜、也最少人補的一道。
三道防線的清單你已經看完了,真正決定生死的是有沒有人在半夜三點還醒著。如果你不想每次都靠客戶的 LINE 訊息才知道網站掛了,現在就訂閱老闆文學院電子報——訂閱馬上送價值千元的 AI 工具箱,之後每一期都會有像這樣能直接照做的中小企業維運筆記。
如果你覺得這篇對你有幫助,歡迎訂閱我的電子報。我每雙週寄一封到你信箱,談的都是這種會真正影響你決策的東西。👉 訂閱連結在這
也歡迎你轉給身邊需要的朋友。也許只是你的舉手之勞,就改變了另一個人的思維和習慣。
延伸閱讀:網站出現 502 Bad Gateway 怎麼辦?5 個常見錯誤碼排查步驟
參考資料
- Cloudflare, "DDoS Threat Report"
- CISA(美國網路安全暨基礎設施安全局), "Understanding and Responding to Distributed Denial-of-Service Attacks"
- NIST(美國國家標準與技術研究院), "Advanced DDoS Mitigation Techniques"
- 法務部全國法規資料庫,中華民國刑法第 360 條
- TWCERT/CC 台灣電腦網路危機處理暨協調中心
- iThome,〈台塑化、緯創、聯電、世芯與多個公家單位遭 DDoS 攻擊〉
- iThome,〈Cloudflare 第一季緩解了 6.5 Tbps 的史上最大 DDoS 攻擊〉