1. 背景介紹
為了防范SYN Flood攻擊，
Daniel J. Bernstein等人提出了SYN Cookie機制，主要思想就是收到SYN報文時，在服務器端不保存任何信息，構造特殊的序列號后回復SYN-ACK報文，減少這種拒絕服務攻擊對服務器的壓力。收到ACK報文后，通過序列號解析判斷其是否合法，決定連接是否建立。關于SYN Cookie的詳細資料，請參考wikipedia的說明[1]。
本文主要描述IPV4協(xié)議棧收到SYN包后回復SYN-ACK報文、收到ACK包時檢驗其合法性時，計算與校驗Cookie值的方法。參考源碼為Linux 2.6.28的net/ipv4/syncookies.c。
2. 實現分析
目前的cookie是一個__u32的值，相關的算法實現主要包括兩部分：
計算Cookie值做為回復SYN-ACK的序列號，在處理SYN報文的tcp_v4_conn_request()中調用，入口為cookie_v4_init_sequence ()；
檢驗Cookie值是否合法，在tcp_v4_hnd_req ()中調用cookie_v4_check()->cookie_check()檢查cookie值是否合法；
此外，在初始化時，需要調用init_syncookies()初始化數組__u32 syncookie_secret[2][16-4+SHA_DIGEST_WORDS]，以備計算cookie時使用，通過調用random.c的get_random_bytes()實現，此處不再綴述。
2.1 Cookie的計算
函數調用關系主要為：
cookie_v4_init_sequence()=>secure_tcp_syn_cookie()=>cookie_hash()
根據secure_tcp_syn_cookie ()中的代碼，我們可以得出，Cookie主要是由一些信息及其hash值相加得到的。代碼內容如下：
|
return (cookie_hash(saddr, daddr, sport, dport, 0, 0) +
sseq + (count << COOKIEBITS) +
((cookie_hash(saddr, daddr, sport, dport, count, 1) + data)
& COOKIEMASK));
|
其中，COOKIEBITS為24，COOKIEMASK為低24位的掩碼，即((__u32)1 << COOKIEBITS) - 1。而cookie_hash()的前四個參數為地址、端口信息，第五個參數count是系統(tǒng)的分鐘數，用jiffies/(HZ*60)計算得到，第六個參數為0或1，指明使用syncookie_secret[0]還是syncookie_secret[1]來計算hash值。
Cookie的組成由圖1所示：
圖1 Cookie的組成
如圖1說明，Cookie一共由三部分加和而成：
以源/目的地址和端口、0以及syncookie_secret[0]為輸入的hash值
sseq序列號
高八位為當前分鐘數，即jiffies/(60*HZ)，低24位為hash值+data后的24位，其中，hash值以源/目的地址和端口、當前分鐘數和syncookie_secret[1]為輸入。
在cookie中加入的data只包括了低24位信息，在當前版本(8-3-0-3)的BVS中，data其實只保存了協(xié)商后的MSS值在msstab中的索引值。
2.2 Cookie的計算
如圖1所示，三部分加和中，第一和三部分所用的hash算法相同。同時，顯然可以得出，收到ACK報文時，第一個hash值是不變的，sseq是很容易求出的(ntohl(ack_th->ack_seq) - 1)即可)。而count值可以取出，但不是現在的系統(tǒng)分鐘數。設發(fā)送SYNACK時時間jiffies，系統(tǒng)分鐘數為count，收到ACK時時間為jiffies，系統(tǒng)分鐘數為count，即
count = 向下取整(jiffies/(60*HZ)),count = 向下取整(jiffies/(60*HZ))
那么，分鐘數的差值diff=count-count <!--[if !vml]--><!--[endif]-->
據此，我們可以進行cookie的第一步校驗——檢查時間值，代碼與分析如下：
|
//首先，去掉cookie三部分加和中的前兩部分
cookie -= cookie_hash(saddr, daddr, sport, dport, 0, 0) + sseq;
//接下來，取出cookie的高八位，即發(fā)送SYN-ACK時編碼進去的當時的系統(tǒng)分鐘數，用
//當前分鐘數去減，即為前后時間的差值，精確到分鐘。
diff = (count - (cookie >> COOKIEBITS)) & ((__u32) - 1 >> COOKIEBITS);
//如果diff值過大，則認定cookie非法
if (diff >= maxdiff)
return (__u32)-1;
|
如果diff值合理，則進一步解出data的低24位：
|
return (cookie -
cookie_hash(saddr, daddr, sport, dport, count - diff, 1))
& COOKIEMASK; /* Leaving the data behind */
|
接下來，判斷data的低24位是否合法，即判斷data的低24位是否屬于msstab的合法索引，如果合法，則通過校驗，否則，校驗失敗，判斷ACK報文非法。
|
return mssind < NUM_MSS ? msstab[mssind] + 1 : 0;
|
從上面的分析可以看出，cookie將一段數據編碼進序列號，然后通過拆解ACK報文的序列號，確定tcp協(xié)商的選項MSS的協(xié)商結果。data可用的位一共24位，全部用來存儲mssind以便解析檢驗。
2.3 其他TCP選項的處理
Linux 2.6.26中的syncookie機制實現了對MSS外的一些TCP選項的支持，但并未像MSS一樣編碼進cookie，即序列號，而是在支持timestamp的情況下，放入了timestamp的低9位。
收到SYN，在構造序列號完成后回復SYNACK時，調用如下函數處理其他TCP選項支持的問題：
__tcp_v4_send_synack()
＝>__tcp_v4_send_synack()
＝>tcp_make_synack()
＝>cookie_init_timestamp()
在cookie_init_timestamp()中，將TCP選項支持寫入了timestamp的低九位。
在校驗時的調用cookie_v4_check()校驗完MSS后，調用cookie_check_timestamp()從timestamp中拆出TCP選項。參考[2]中給出了當年這個實現的patch。
3. 參考資料
4.主要函數
