SYN Cookie原理及在Linux内核中的实现 （3）

这个isn被赋予返回的TCP SYN+ACK包中，作为其中的ISN值。这就是cookie 的产生过程。在这个过程中，没有在本地为这个连接请求分配任何存储空间。

在TCP服务器收到TCP ACK包时，相应的要进行SYN Cookie的检查。这个检查过程在函数tcp_v4_hnd_req中的cookie_v4_check函数开始。cookie_v4_check调用cookie_check函数，cookie_check函数调用check_tcp_syn_cookie函数。

check_tcp_syn_cookie函数在random.c中定义，是与前面介绍的secure_tcp_syn_cookie函数对应的函数，检查从TCP ACK中提取出的ISN值。

在check_tcp_syn_cookie中假定ISN的值如下:

isn := A+sseq + (count2<<COOKIEBITS) + (B+data2)&COOKIEMASK
　　　　

这里的A、B都是根据当前这个skb中的地址信息和syncookie_secret算出来的；sseq是根据这个skb中的seq值算出的。

有了上面这些值，TCP服务器就可以反算出count2和data2。理论上来说，只要这个isn是原来那个isn，应该有:

count2 == count1　
　　data2 == data1

但是这种结论仅仅是一个理论情况。因为在TCP服务器端并没有保存原来的count1和data1，因此不能直接进行比较。TCP服务器采取的方法是：

1）计算出当前的分钟值

count3 := jiffies/(HZ*60)用count3与count2比较，如果差值超过COUNTER_TRIES（4）分钟，则认为这 个ACK包不合法。

2）看data2是不是一个合法的msstab的索引，也就是说是不是小于NUM_MSS， 即(sizeo(msstab)/sizeof(msstab[0]) - 1)。如果小于，则认为这个ACK 合法，否则认为非法。

上面介绍的就是Linux内核Linux2.4.20中对SYN Cookie的实现方式。下面讨论一下它的合理性。希望得到的结论是这种方案可以有效的实现一般TCP的连接，同时可以防止SYN Flood攻击。

从上面的介绍来说，合法的TCP连接请求一定可以通过SYN Cookie流程。 另一方面我们看SYN Cookie在系统受到各种SYN Flood攻击时会采取的行为。 最一般的SYN Flood攻击方式是攻击者作为TCP客户机发送大量TCP SYN包而不再发送其他的包。这时SYN Cookie会为每个SYN包计算出相应的ISN值，并返回SYN+ACK包，而在本地将不分配任何存储空间，因此不会被成功攻击。

根据SYN Cookie的原理，攻击者有可能直接发送大量ACK包。这时SYN Cookie提取出每个包的isn值，并假定它有下面的格式:

isn := A+sseq + (count<<COOKIEBITS) + (B+data)&COOKIEMASK

反算出count和data。因为攻击者并不知道这里的A和B，因此经过反算出的count和data几乎不可能都合理，因此TCP服务器也几乎不可能为这些ACK包分配存储空间，这也就说明了SYN Cookie达到起到了抵挡SYN Flood攻击的作用。

四 SYN Cookie Firewall

从上面的介绍可以看到，Linux内核中的SYN Cookie机制主要的功能是防止本机遭受SYN Flood攻击的，但是在很多情况下，仅仅实现这样的SYN Cookie机制是不够的。如果我们要考虑的是一个网关模式的防火墙，它不仅要保护本机免受各种网络攻击，还要保护它后面的所有对外有开放TCP端口的主机免受这些攻击。比如一个局域网中有个服务器开放了FTP服务给外界，这个服务器主机就有可能遭受到来自互联网上的SYN Flood攻击。而这时的防火墙会将所有的攻击SYN包转发给受害主机。