DDoS 攻擊如何防禦：分層防護方案與被打時的處置步驟

DDoS 攻擊如何防禦，取決於攻擊規模落在哪一層：沒有超過伺服器接入頻寬的小規模攻擊（SYN 泛洪、連線數耗盡），主機上的核心引數和防火牆就能頂住；一旦流量超過伺服器的接入頻寬，主機上做什麼都沒用，只能靠機房的流量清洗或黑洞；再大的規模就要把業務放到高防 IP 或高防 CDN 後面，由它們的清洗中心吸收。應用層的 HTTP 泛洪則要靠限速、WAF 和人機驗證。本文先給分層方案表，再給被打時的處置順序。

分層防護方案：每一層能擋多大

層次	手段	能擋什麼	大致上限	誰來做
主機	核心引數、iptables/nftables、關閉無用服務	SYN 泛洪、小規模連線耗盡、少量源的掃描	接入頻寬與 CPU 決定，1 Gbps 連接埠被 2 Gbps 流量打滿時全部失效	伺服器管理員
機房	上聯頻寬冗餘、旁路清洗裝置、黑洞路由	UDP 泛洪、反射放大、SYN 泛洪等流量型攻擊	以合同標稱的清洗能力為準，通常為數十到數百 Gbps 量級；超過閾值走黑洞	機房/IDC 服務商
高防 IP / CDN	把攻擊引到服務商的清洗中心，源站隱藏	大規模流量型攻擊，部分產品也過濾應用層	以服務商標稱的防護頻寬為準，通常遠高於單個機房的清洗能力	業務方購買並接入
應用層	Nginx 限速、WAF、驗證碼、快取	HTTP 泛洪（CC）、慢速攻擊、介面濫用	取決於後端處理能力，與頻寬無關	應用/維運

這張表的重點是：下面一層擋不住的，上面一層才需要出手，而且每一層的上限都很硬。買了高防頻寬不等於應用層安全，主機調優也替代不了機房清洗。下面按機房、高防、主機、應用四塊分別說明該做什麼。

機房側：頻寬冗餘與流量清洗

機房側的防護通常由三部分組成：

1. 頻寬冗餘：上聯頻寬留有餘量，攻擊流量不至於立刻堵死整個機房出口；
2. 流量清洗：透過 NetFlow/sFlow 檢測異常，把被攻擊 IP 的路由牽引到旁路清洗裝置，過濾後再回注給伺服器；
3. 黑洞路由：攻擊超過清洗能力或合同閾值時，上游把該 IP 路由到空介面，犧牲一個 IP 保住整個機房。

簽約前要問清楚這幾個數字：清洗觸發閾值、黑洞閾值、黑洞後多久解封、清洗是否額外收費、被打時能否臨時更換 IP。這些條款直接決定被攻擊時你還有哪些選項。

高防 IP 與 CDN：把源站藏起來

高防 IP 的原理是讓所有流量先經過服務商的清洗節點，再轉發給源站。接入步驟：

1. 在高防控制檯新增轉發規則：四層業務填連接埠轉發（例如 TCP 443 → 源站 IP:443），七層業務填域名並上傳證書；
2. 把源站防火牆改成只允許高防回源 IP 段存取業務連接埠，其他來源一律丟棄；
3. DNS 解析改到高防 IP，TTL 提前縮短到 300 秒以內，方便後續切換；
4. 更換源站 IP：舊 IP 已經暴露，不換等於白做；
5. 排查洩露渠道：歷史 DNS 記錄、郵件頭裡的發件伺服器位址、未接入高防的子域名（證書透明度日誌裡能查到你簽發過證書的所有域名）。

CDN 隱藏源站的思路相同，靜態內容還能直接由邊緣節點回應。無論哪種，源站防火牆那一條是關鍵，否則攻擊者繞過高防直接打源站 IP。

主機側：防火牆與核心引數

主機層只對小規模、未超過接入頻寬的攻擊有效，但它是零成本、馬上能做的部分。以 Linux 為例，先調核心引數：

cat >> /etc/sysctl.conf <<'CONF'
# SYN Cookie：半連線佇列滿時仍能建立連線
net.ipv4.tcp_syncookies = 1
# 半連線與全連線佇列長度
net.ipv4.tcp_max_syn_backlog = 65536
net.core.somaxconn = 65535
# 減少 SYN+ACK 重傳次數，半連線更快超時
net.ipv4.tcp_synack_retries = 2
# 網路卡收包佇列
net.core.netdev_max_backlog = 262144
CONF
sysctl -p

再用 iptables 限制單個源的連線數和新建連線速率：

# 單個源 IP 到 80/443 的併發連線超過 50 即丟棄
iptables -A INPUT -p tcp -m multiport --dports 80,443 \
  -m connlimit --connlimit-above 50 --connlimit-mask 32 -j DROP
# 單個源 IP 每秒新建連線超過 30（突發 60）即丟棄
iptables -A INPUT -p tcp --syn -m hashlimit --hashlimit-name syn \
  --hashlimit-mode srcip --hashlimit-above 30/second --hashlimit-burst 60 -j DROP
# 丟棄連線狀態無效的包
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

同時檢查伺服器有沒有對外開放可被利用的反射源：DNS 遞迴、NTP 的 monlist、SSDP、memcached 的 11211 連接埠。這些服務開著，你的伺服器就會成為別人攻擊的放大器，機房也可能因此把你的連接埠關掉。

應用層：限速與人機驗證

流量不大、頻寬不滿、但網站打不開，問題多半在應用層。Nginx 裡按來源 IP 限制請求速率和併發連線：

http {
    limit_req_zone  $binary_remote_addr zone=req_per_ip:10m rate=20r/s;
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;

    server {
        location / {
            limit_req  zone=req_per_ip burst=40 nodelay;
            limit_conn conn_per_ip 30;
        }
    }
}

閾值按業務調：靜態站可以嚴一些，API 介面要考慮同一出口 NAT 後面的大量使用者。再往上是 WAF 的規則過濾、對可疑來源彈 JavaScript 驗證或驗證碼，以及把能快取的頁面快取起來，讓攻擊請求打不到資料庫。

伺服器被 DDoS 攻擊怎麼辦：處置順序

被打時不要先改配置，先按順序做下面幾步。

1. 判斷是不是攻擊、是哪一種

看三個指標就能分清：

# 連線狀態彙總：SYN-RECV 數量異常高說明是 SYN 泛洪
ss -s
ss -ant state syn-recv | wc -l
# 已建立連線按來源統計：少數 IP 佔大頭說明是連線型或應用層攻擊
ss -ant state established | awk 'NR>1{split($4,a,":");print a[1]}' | sort | uniq -c | sort -rn | head

• 監控圖上入向頻寬打滿、包速率暴漲 → 流量型攻擊（UDP 泛洪、反射放大），主機上無解，直接進入第 2 步；
• 頻寬不高、半連線數暴漲 → SYN 泛洪，主機側的核心引數能頂一陣；
• 頻寬正常、請求數和後端 CPU 暴漲 → 應用層攻擊，按應用層的限速與人機驗證處理。

2. 流量型攻擊：聯絡機房，切高防

• 立刻聯絡機房值班，確認 IP 是否已進黑洞、清洗是否已觸發、什麼時候能解封；
• 如果已有高防 IP 或 CDN，把 DNS 切過去；提前把 TTL 縮短過的話，切換隻需幾分鐘；
• 如果沒有高防，考慮臨時申請一個新 IP 承接核心業務，同時把舊 IP 留在黑洞裡；
• 主機層能做的只有關閉非必要連接埠、臨時縮緊連線數，不要指望封 IP 見效，因為源位址大多是偽造的。

3. 通知相關方

給受影響的客戶發公告，說明影響範圍和預計恢復時間；涉及多個客戶的 IDC 要同步通知銷售和客服，避免工單堆積在一線。

4. 取證

攻擊期間儲存證據，事後才談得上追責或報案：

# 抓取 1 萬個包留樣，不要長時間抓包拖垮伺服器
tcpdump -i eth0 -c 10000 -w /tmp/ddos-$(date +%F-%H%M).pcap

再加上監控系統的流量圖截圖、機房或高防服務商出具的攻擊報告、勒索郵件或聊天記錄。

5. 事後覆盤

• 換掉暴露的源站 IP，並確認新 IP 只對高防回源段開放；
• 檢查監控告警閾值，攻擊開始到有人知道的時間差就是要縮短的目標；
• 評估這次攻擊規模與現有防護上限的差距，決定是否升級機房清洗套餐或購買高防；
• 把 DNS TTL、高防轉發規則、機房聯絡方式寫成一頁應急手冊，下次不用現找。

IDC 運營方：不讓一台機器拖垮一排

對 IDC 來說，一台伺服器被攻擊往往連帶同一交換器、同一上聯線路上的其他客戶。Toplink DCIM 的頻寬自動限速按最近一段時間的平均頻寬判斷，超過閾值就自動把交換器連接埠限到設定速率，流量回落並持續穩定後再恢復，把影響圈在一個連接埠以內。客戶也可以在自助端檢視自己伺服器的流量與被攻擊事件記錄，不必等維運回覆才知道發生了什麼。