SYN cookie
此條目需要精通或熟悉相關主題的編者參與及協助編輯。 (2014年12月7日) |
SYN cookie 是一種用於阻止 SYN flood 攻擊的技術。這項技術的主要發明人 Daniel J. Bernstein 將 SYN cookies 定義為「TCP 服務器進行的對開始TCP數據包序列數字的特定選擇」。舉例來說，SYN Cookies 的應用允許服務器當 SYN 隊列被填滿時避免丟棄連接。相反，服務器會表現得像 SYN 隊列擴大了一樣。服務器會返回適當的 SYN+ACK 響應，但會丟棄 SYN 隊列條目。如果服務器接收到客戶端隨後的ACK響應，服務器能夠使用編碼在 TCP 序號內的信息重構 SYN 隊列條目。
實現
編輯發起一個 TCP 連接時，客戶端將一個 TCP SYN 包發送給服務器。作為響應，服務器將 TCP SYN + ACK 包返回給客戶端。此數據包中有一個序號（sequence number，TCP頭中的第二個32 bit），它被 TCP 用來重新組裝數據流。根據 TCP 規範，由端點發送的第一個序號可以是由該端點決定的任何值。SYN Cookies 是根據以下規則構造的初始序號：
- 令 t 為一個緩慢遞增的時間戳（通常為
time() >> 6，提供 64 秒的解析度）； - 令 m 為服務器會在 SYN 隊列條目中存儲的最大分段大小（maximum segment size，簡稱為 MSS）；
- 令 s 為一個加密散列函數對服務器和客戶端各自的 IP 地址和端口號以及 t 進行運算的結果。返回得到的數值 s 必須是一個24位值。
初始 TCP 序號，也就是所謂的 SYN cookie，按照如下算法得到：
- 頭五位：t mod 32；
- 中三位：m 編碼後的數值；
- 末24位：s 本身；
註：由於 m 必須用 3 位進行編碼，服務器在啟用了 SYN Cookie 時只能為 m 發送八種不同的數值。
根據 TCP 規範，當客戶端發回 TCP ACK 包給服務器以響應服務器的 SYN + ACK 包時，客戶端必須使用由服務器發送的初始序號加1作為數據包中的確認號。服務器接着從確認號中減去 1 以便還原向客戶端發送的原始 SYN Cookie。
接下來服務器進行以下檢查：
- 根據當前的時間以及 t 來檢查連接是否過期。
- 重新計算 s 來確認這是不是一個有效的 SYN Cookie。
- 從 3 位編碼中解碼 m，以便之後用來重建 SYN 隊列條目。在此之後，連接照常進行。
缺陷
編輯SYN Cookies 的使用不與任何協議定義衝突，照理來說它該和所有的 TCP 實現兼容。然而，當 SYN Cookies 使用的時候，會發生兩種值得注意的變化：首先，服務器只能編碼八種 MSS 數值，因為只有 3 位二進制空間可用。其次，這個服務器必須拒絕所有的 TCP 選用項，例如大型窗口和時間戳，因為服務器會在信息被用其他方式存儲時丟棄 SYN 隊列條目。 [1]
儘管這些限制將不可避免地導致一個不如最佳的體驗，它們的效果很少被客戶端注意到——這些改變只在被攻擊時值得注意。在這樣的情況下，犧牲 TCP 選項來保護連接一般被認為是合乎情理的。
Linux內核 從 2.6.26 版本開始為 TCP 選用項加入了有限的支持，通過把它們編碼在時間戳內實現。[2]
較新的 TCP Cookie 傳輸（TCPCT）標準被設計用來克服 SYN Cookies 的這些問題，並且在各種方面改進這套機制。不像 SYN Cookies，TCPCT 是一個 TCP 拓展並且要求兩端點都支持 TCPCT。
安全考量
編輯被設置為允許所有出站連接但對入站連接有限制（例如在 Web 服務器上只允許 80 端口）的簡單防火牆一般是這樣實現的：只阻斷不必要端口的 SYN 請求。如果 SYN Cookies 被啟動了，應當小心以保證攻擊者不能使用偽造 ACK、嘗試隨機序列號的方式來繞過這樣的防火牆。因此 SYN cookies 應該按照每個端口單獨處理的方式來調節開關，這樣的話一個公共端口上的 SYN Cookies 並不會在一個私有端口上被認可。[3]
歷史
編輯Daniel J. Bernstein 和 Eric Schenk 於 1996 年九月創造了這個技術。Jeff Weisberg 在一個月後發布了最早的實現（在 SunOS 上），Eric Schenk 隨後在 1997 年二月發布了他的 Linux 實現（目前的實現使用，例如 net.ipv4.tcp_syncookies（頁面存檔備份，存於網際網路檔案館））。