DDoS 攻擊來了怎麼辦：緊急處理與長期防護

網站或伺服器突然連不上、流量暴增時，先確認是不是 DDoS，接著立刻聯絡主機商或機房、記錄時間與流量、啟用 CDN 或防護服務的攻擊因應設定，並暫停吃資源的非必要功能。若同時收到勒索信，原則是不付款、保留證據並通報。狀況穩定後，再用 CDN、WAF、速率限制、隱藏源站 IP 與備援降低下一次的衝擊。

美國 CISA（網路安全暨基礎設施安全局）提醒，網站變慢或連不上，也可能只是一般技術問題或排定的維護，不能只看症狀就斷定是攻擊。比較可靠的做法是同時看三件事：流量從哪裡來、連線數有沒有異常、出現的是哪一類錯誤。

IT 人員可以從主機商控制台的流量圖、網站存取紀錄（access log）與系統連線狀態著手：看請求最多的 IP 與網址、連線數和平常差多少、CPU 與頻寬是否同時吃滿。CISA 也提到，DNS、防火牆等其他服務一起出問題，或防護服務主動發出警示，都是攻擊徵兆。

DDoS（分散式阻斷服務攻擊）是攻擊者控制大量遭入侵的電腦或物聯網裝置（俗稱殭屍網路），同時對你送出流量，讓正常客人進不來，就像高速公路被大量車輛塞住。依照攻擊打的位置，常見分成三類：

• 網路層（流量型）：把水管塞爆。用大量資料把主機對外的頻寬塞滿，常利用 DNS 等協定的「放大」手法，讓攻擊者送出小請求、你收到大回應。線路在流量到達主機前就滿了，主機本身調整擋不住，要靠主機商、機房或上游清洗。
• 傳輸層（協定型）：把櫃台號碼牌拿光。例如 SYN Flood 大量發出建立連線的請求卻不完成，讓伺服器一直保留連線位置等回覆；UDP Flood 則用大量封包逼伺服器逐一檢查、回應。目標是耗盡伺服器、防火牆或負載平衡設備能處理的連線數。
• 應用層（HTTP 請求型）：假客人擠爆店面。對網頁、登入、搜尋或 API 送出大量看似正常的請求。每個請求都可能觸發資料庫查詢，不需大頻寬就能拖垮網站，也最難和真實訪客分辨，通常靠 WAF 規則、速率限制與驗證挑戰篩選。

實際攻擊常混用多種手法。跟主機商溝通時，說清楚是「整台連不上」還是「主機還活著但某些頁面被狂打」，對方比較能判斷從哪一層處理。

1. 聯絡主機商或機房。提供受影響的網域、IP、開始時間與症狀，詢問對方是否偵測到攻擊、是否已啟動流量清洗。CISA 也建議第一時間通知網路服務商或主機商，他們可能有現成的緩解措施或能改變流量路徑。攻擊太大時，上游可能把打向你 IP 的流量整個丟棄（黑洞路由），網站會暫時完全斷線，要和對方確認解除條件。
2. 記錄時間與流量。寫下發現時間與每個處理動作的時間點，保存流量圖截圖、主要來源 IP、被打的網址或連接埠、錯誤訊息與系統紀錄，之後通報、報案與檢討都用得到。
3. 啟用 CDN 或防護服務的攻擊因應設定。已經使用 CDN 或雲端防護的，把防護敏感度調高，開啟服務提供的「受攻擊模式」或瀏覽器驗證挑戰，對被集中攻擊的網址加上速率限制。還沒有使用的，可以評估緊急導入，但要知道 DNS 切換需要時間生效，而且源站 IP 若早已公開，攻擊者仍可能繞過 CDN 直接打主機。
4. 暫時限制非必要功能。站內搜尋、複雜篩選、報表匯出、免登入的 API 都很耗資源，可以先關閉或改成需要登入。首頁與活動頁盡量讓 CDN 快取，必要時換成靜態公告頁，先保住結帳、登入等核心流程。
5. 對內對外說明狀況。在社群或不受影響的管道公告服務異常，讓客服說法一致。
6. 留意其他系統。CISA 提醒，阻斷服務攻擊有時是掩護其他入侵的煙霧彈，攻擊期間要多看後台登入紀錄與管理帳號是否有異狀。

不建議做的事：不斷重開主機（攻擊不會因此停止），或自行換 IP 後又直接把新 IP 寫進公開的 DNS 紀錄，攻擊者很快就能找到新位置。

勒索型 DDoS 通常是一封信，聲稱已經或即將發動攻擊，要求在期限內支付加密貨幣，有時會先打一小波「示範攻擊」。處理原則如下：

• 不要付款。付款不保證攻擊會停止，願意付錢的企業反而會成為更好的下手對象；勒索信也可能只是虛張聲勢。
• 不要回信、不要和對方談判。美國 FBI 網路犯罪投訴中心（IC3）針對 DDoS 勒索信的公告，建議不要與寄件者聯繫，並在報案時提供含完整郵件標頭的勒索信。
• 保留證據。完整保存勒索信（不要只截圖內文）、對方指定的付款地址，以及攻擊期間的流量與紀錄。
• 通報與報案。台灣一般企業可透過 TWCERT/CC（台灣電腦網路危機處理暨協調中心）官網的「一般資安通報」線上服務，或其企業資安事件通報信箱通報；勒索屬於刑事案件，也可以帶著證據向警察機關報案。上市櫃公司或特定產業如有自己的通報規定，請一併依規定辦理。
• 照樣做好防護。不論威脅是否屬實，都依前一段的步驟加強防護，並先和主機商確認處理流程。

沒有單一工具能保證擋下所有攻擊，實際的目標是「被打時保住核心服務，而且恢復得快」：

• CDN 與快取：把靜態檔案與可快取的頁面交給分散在各地的節點回應，減少直接打到主機的請求，也能分散大流量。
• WAF（網站應用程式防火牆）：依規則過濾 HTTP 流量，攻擊發生時可以快速調整規則、針對特定網址或特徵阻擋。WAF 主要防應用層，不能取代網路層的頻寬清洗。
• 速率限制：限制同一來源在一段時間內能送出的請求數，特別適合登入、搜尋、表單與 API。規則要依平常的使用量設定，避免誤擋真實客人。
• 隱藏源站 IP：網站流量都經過 CDN 或防護服務後，主機防火牆只允許服務商的 IP 連入；檢查 DNS 的 TXT、SPF 等紀錄有沒有洩漏主機 IP；郵件系統不要和網站放在同一台主機，因為退信會暴露 IP。導入防護前用過的 IP 可能留在歷史 DNS 紀錄裡，必要時請主機商換一組新 IP。
• 備援與負載分散：重要服務分散到多台主機或多個機房並設定故障切換，定期備份。CISA 也建議事先擬好應變計畫：誰聯絡主機商、誰對外公告、防護服務的緊急聯絡方式。
• 平常就監控流量：建立正常流量的基準，設定異常警示，才不會等客人抱怨才發現。

如果營收高度依賴線上服務，也要檢視主機架構：共用主機彈性有限，VPS 雲端主機或專屬伺服器可以自行設定防火牆與連線限制，再搭配上游的 DDoS 防護。不確定該從哪一層開始，可以請我們協助評估目前的架構與風險。

遊戲伺服器的防護邏輯和一般網站不太一樣，主要有兩個原因：

• 大量使用 UDP。UDP 不需要先建立連線，傳輸快，很適合即時連線的線上遊戲，但這個特性也常被拿來發動 UDP Flood 與放大攻擊。攻擊量大到塞滿上游線路或防火牆時，必須在流量到達機器之前過濾。
• 玩家直接連源站。網站用的 CDN 代理的是 HTTP／HTTPS 流量，遊戲連線通常走自訂的 TCP 或 UDP 連接埠，不會經過網站 CDN。玩家用戶端拿得到伺服器 IP，攻擊者也拿得到，所以「網站有掛 CDN」並不代表遊戲伺服器受到保護。

實務上可以這樣規劃：

1. 向主機商或機房確認是否提供針對 UDP 與非 HTTP 流量的上游清洗，以及遊戲連接埠被攻擊時的處理方式。
2. 評估支援 TCP／UDP 代理的防護服務，讓玩家先連到代理節點，不直接接觸源站 IP。
3. 官網、會員登入、儲值金流與遊戲伺服器分開主機，避免遊戲服被打時連帶整個服務停擺。
4. 只開放遊戲真正需要的連接埠，關閉用不到的服務與協定；導入代理後，不要再把源站 IP 放在公開的 DNS 紀錄或網頁上。
5. 反射型攻擊的來源多半是被利用的正常公開伺服器，逐一封鎖 IP 效果有限。CISA 建議可以把攻擊來源 IP 提供給網路服務商，並請對方評估依連接埠與封包大小過濾。

• 網站被駭怎麼辦：清除惡意程式與通報步驟
• DDoS 防護：了解網路層、傳輸層與應用層攻擊的緩解方式與洽詢管道。
• VPS 雲端主機：可自行設定防火牆與連線限制，適合需要更多控制權的網站。
• 專屬伺服器：遊戲伺服器或高流量服務獨立運作，資源不與他人共用。
• 聯絡我們：說明目前的架構與遇到的狀況，協助評估適合的防護方式。