# SYN Cookie 簡單理解


## TCP 簡單回顧

先簡單回顧一下 TCP 跑起來的時候，seq and ack number 的變化

這邊關注 Seq/Ack number (32-bit, 超出從 0 開始)，可以看一些 TCP 例子

[TCP協定的執行可劃分為三個階段：連接建立(connection establishment)、資料傳送（data transfer）和連接終止（connection termination）](https://zh.wikipedia.org/zh-tw/%E4%BC%A0%E8%BE%93%E6%8E%A7%E5%88%B6%E5%8D%8F%E8%AE%AE)

![alt text](image.png)

如上，在建立連線的過程，主機自己都會有一個 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：

1. 如果對方也有資料要傳 → 就 piggyback 在 ACK 上，一併送出。
2. 如果對方的資料或控制 flag (SYN/FIN/RST) 被 ACK 到 → 這次的 ACK 就是必要的。

對於每個 TCP 連線 (四元組: src IP, src port, dst IP, dst port)，核心會維護一個 TCB (Transmission Control Block)，裡面包含：

1. SND.UNA: 已經送出但還沒被 ACK 的最小序號。
2. SND.NXT: 下一個要送的序號。
3. SND.WND: 對方通告的可用 window 大小。
4. RCV.NXT: 預期收到的下一個序號（用來檢查封包是否按序）。
5. RCV.WND: 本端的接收 window 大小。

可以參考 [传输控制块TCB - Backend-Development - GitBook](https://mqjyl2012.gitbook.io/backend-development/network-communication-and-programming/linux-network-source/transmission-control-block)。

針對 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 可能的問題：

1. Fake src IP Syn Flood
2. Linux 實作問題？

## 2024 年比較新的 SYN Cookie

[SmartCookie: Blocking Large-Scale SYN Floods with a Split-Proxy Defense on Programmable Data Planes](https://www.usenix.org/system/files/usenixsecurity24-yoo.pdf)

## Reference

* [SYN cookies 機制下連接的建立](https://medium.com/r?url=https%3A%2F%2Fchunchaichang.blogspot.com%2F2018%2F09%2Fsyn-cookies.html)
* [Linux TCP -SYN cookies的一个问题分析](https://zhuanlan.zhihu.com/p/640934692)