SYN Flood 是最經典、至今仍極具威脅的拒絕服務攻擊手法之一。它利用 TCP 三向交握機制的固有缺陷，以極低成本耗盡伺服器連接隊列資源，導致正常服務不可用。本文從協定層面剖析攻擊原理，並提供從核心參數調整、協定擴展到架構層面的系統性緩解方案。

TCP 三向交握與攻擊根源

1. Client → Server：發送 SYN=1, seq=x (主動開啟)
2. Server → Client：回應 SYN=1, ACK=1, seq=y, ack=x+1 (SYN-ACK)，將連接放入半連接隊列 (SYN Queue / Incomplete Connection Queue)，等待最終 ACK。
3. Client → Server：發送 ACK=1, seq=x+1, ack=y+1，連接移入全連接隊列 (Accept Queue / Completed Connection Queue)，應用層 accept() 取走。

攻擊利用點：攻擊者大量發送偽造來源 IP 的 SYN 封包，Server 回應 SYN-ACK 後無法收到 ACK，導致半連接隊列填滿。隊列滿時，新的合法 SYN 被丟棄，服務癱瘓。隊列長度受 net.ipv4.tcp_max_syn_backlog (Linux) 或 TcpNumConnections (Windows) 限制，通常僅數百至數千條。

基本緩解措施 (作業系統/協定棧層面)

措施	原理	Linux 關鍵參數	優缺點
縮短 SYN-ACK 重試次數與超時	加速半連接回收，降低佔用時間	net.ipv4.tcp_synack_retries = 2~3 (預設 5) net.ipv4.tcp_syn_retries (主動端)	簡單有效，但高延遲網路可能誤判合法連接
啟用 SYN Cookies	不分配半連接資源，將狀態編碼在 SYN-ACK 的序列號中，驗證 ACK 後才建立完整連接	net.ipv4.tcp_syncookies = 1	犧牲部分 TCP 選項 (窗口縮放、SACK、時間戳)；僅作為隊列滿時的備援機制
擴大半連接隊列	增加佇列容量吸收突發	net.ipv4.tcp_max_syn_backlog = 4096~65535 net.core.somaxconn = 65535 (需應用層 listen backlog 配合)	消耗記憶體，治標不治本，大規模攻擊仍會填滿
啟用 TCP Fast Open (TFO)	允許在 SYN 中攜帶資料，減少 RTT，間接降低半連接佔用時間	net.ipv4.tcp_fastopen = 3 (Client+Server)	需客戶端支援，且有重放攻擊風險，需配合 Cookie 保護

進階緩解：SYN Proxy / TCP Intercept (網路設備層面)

在流量進入伺服器前，由防火牆、負載平衡器 (L4/L7) 或專用 DDoS 清洗設備代理三向交握：

1. 設備代表 Server 回應 SYN-ACK (可啟用 SYN Cookies)。
2. 驗證 Client 回傳 ACK 合法性 (序列號、時間窗)。
3. 僅合法連接才向後端真實 Server 發起新的三向交握 (或直接轉發已驗證連接)。

優勢：後端 Server 完全免受 SYN Flood 影響，半連接狀態由高效能 ASIC/FPGA 或專用軟體在邊緣處理。典型廠商：F5 (SYN Check/TCP Proxy)、Radware、Arbor、Cloudflare、AWS Shield、阿里云 Anti-DDoS。

原始碼層面視角：攻擊工具構造 (僅供防禦理解)

攻擊者通常使用原始套接字 (SOCK_RAW) 手工構造 TCP 標頭，關鍵欄位：

• Source Port：隨機高埠 (1024-65535)
• Destination Port：目標服務埠 (80, 443, 22...)
• Sequence Number：隨機初始序列號 (ISN)
• Flags：SYN=1，其餘 0
• Window Size：常設較大值 (如 65535) 顯示接收能力
• Checksum：需正確計算偽首部 + TCP 首部 + 選項
• Options：通常包含 MSS、Window Scale、SACK Permitted、Timestamps 以模擬真實客戶端

為繞過 SYN Cookies，進階工具會嘗試破解 Cookie 演算法 (Linux 使用 SHA-1 摘要：hash(src_ip, src_port, dst_ip, dst_port, secret, time_counter)) 或利用旁路洩漏。但現代實作 (Linux 4.4+、BSD、Windows) 已加強 Cookie 熵與時間窗管理，破解難度極高。

綜合防禦架構建議

SYN Flood 雖老但不退場，隨著反射放大、Tsunami SYN Flood (低速慢攻)、加密流量 (TLS over TCP) 等變體出現，單一修補參數已不足以應對。企業應建立「假設會被攻擊」的韌性架構，將緩解能力前移至邊緣與雲端，主機層面專注於參數優化與可觀測性，並在平時透過模擬攻擊 (如 hping3、scapy、商用壓測平台) 持續驗證防禦有效性。