SYN Cookie 簡單理解
TCP 簡單回顧
先簡單回顧一下 TCP 跑起來的時候，seq and ack number 的變化
這邊關注 Seq/Ack number (32-bit, 超出從 0 開始)，可以看一些 TCP 例子
TCP協定的執行可劃分為三個階段：連接建立(connection establishment)、資料傳送（data transfer）和連接終止（connection termination）
如上，在建立連線的過程，主機自己都會有一個 ISN seq number，之後傳資料就是繼續沿用三項交握的數字繼續。
注意傳資料不一定要有 PSH flag，傳資料就是看 TCP payload 的 length 就知道有沒有資料，但都會有 ACK flag 來讓收到訊息的人要送一個 ack 封包。
一旦連線建立（完成三次握手），雙方就都有初始序號（SND/RCV），之後發出的段都會帶上有效的 acknowledgement number 以回應對方已收到的序號 - - 因此 ACK 位幾乎總是被設為 1。
這種封包通常叫 純 ACK (pure ACK)，裡面沒有資料，只有 TCP header + ACK 標誌。
Client 收到 Server 的資料，就會回一個 純 ACK，確認 seq 或者 TCP window probe、keep-alive 之類的情況。
但有幾個例子會讓對方「順便」回一個 ACK：
- 如果對方也有資料要傳 → 就 piggyback 在 ACK 上，一併送出。
- 如果對方的資料或控制 flag (SYN/FIN/RST) 被 ACK 到 → 這次的 ACK 就是必要的。
對於每個 TCP 連線 (四元組: src IP, src port, dst IP, dst port)，核心會維護一個 TCB (Transmission Control Block)，裡面包含：
- SND.UNA: 已經送出但還沒被 ACK 的最小序號。
- SND.NXT: 下一個要送的序號。
- SND.WND: 對方通告的可用 window 大小。
- RCV.NXT: 預期收到的下一個序號（用來檢查封包是否按序）。
- RCV.WND: 本端的接收 window 大小。
可以參考 传输控制块TCB - Backend-Development - GitBook。
針對 seq ISN number，早期 (RFC 793) ISN 會根據一個 全域計數器產生，這個計數器大約每 4 μs 加 1。這樣可以確保不同時間建立的連線，不會用到相同序號 → 避免舊連線的封包被誤認成新連線的。
現代系統 (RFC 6528)，因為 安全性問題（如果攻擊者能預測 ISN，就可以偽造 TCP 連線，稱為 TCP sequence prediction attack），現在的 OS 都改成：
- 隨機化 ISN：在一定範圍內 pseudo-random 產生。
- 還要考慮「時間」與「連線四元組 (src IP, src port, dst IP, dst port)」混合進去。
SYN Flood 簡單介紹
簡單說一個 socket listen 會以兩個 queue，半連接 queue and 全連接 queue，所以 syn flood 就是塞滿半連接 queue。 傳統的 TCP 實作從發送 SYN-ACK 封包的那一刻起就維持連線狀態。此狀態包括客戶端的 IP 位址、連接埠號碼、初始序號和 TCP 選項。 SYN Cookie 消除了這種狀態儲存需求。伺服器將必要的資訊編碼到 ISN 欄位中，並丟棄其他所有訊息，直到客戶端完成握手。
SYN Cookie
許多系統僅在偵測到潛在攻擊時才會啟動 SYN Cookie。常規操作使用傳統的狀態連線追蹤來獲得更好的效能和完整的 TCP 選項支援
- 優點
- 協定相容性：此機制可與任何相容的 TCP 用戶端相容，無需修改或特殊配置。客戶端無法區分正常的 SYN-ACK 封包和包含 SYN Cookie 的封包。
- 選擇性啟動：系統僅在受到攻擊時啟用 SYN cookie，在不存在威脅時保留正常功能。
- 缺點
- TCP 的 extension options 會沒辦法使用。雖然 syn cookie 作者強調的是：如果沒有 SYN cookie，連線會因為 SYN flood 而被丟棄，也就無法使用 TCP options。 所以他認為「SYN cookies 不會額外破壞 TCP extensions」，這是從「連線能否成功建立」的角度來看的 - SYN cookies
- 在初始化 ISN 的時候可能會用到加密，加密計算會為伺服器帶來額外的處理需求。在高強度攻擊期間，這種開銷可能會變得非常大，並可能影響整體系統效能。
SYN Cookie 可能的問題：
- Fake src IP Syn Flood
- Linux 實作問題？
2024 年比較新的 SYN Cookie
SmartCookie: Blocking Large-Scale SYN Floods with a Split-Proxy Defense on Programmable Data Planes