深入浅出TCP中的SYN-Cookies

图片描述

本文渐进地介绍TCP中的syn-cookie技术,包括其由来、原理、实例测试。

SYN Flood 攻击

TCP连接建立时,客户端通过发送SYN报文发起向处于监听状态的服务器发起连接,服务器为该连接分配一定的资源,并发送SYN+ACK报文。对服务器来说,此时该连接的状态称为半连接(Half-Open),而当其之后收到客户端回复的ACK报文后,连接才算建立完成。在这个过程中,如果服务器一直没有收到ACK报文(比如在链路中丢失了),服务器会在超时后重传SYN+ACK
图片描述
如果经过多次超时重传后,还没有收到, 那么服务器会回收资源并关闭半连接,仿佛之前最初的SYN报文从来没到过一样!

图片描述

这看上一切正常,但是如果有坏人故意大量不断发送伪造的SYN报文,那么服务器就会分配大量注定无用的资源,并且从backlog的意义 中可知,服务器能保存的半连接的数量是有限的!所以当服务器受到大量攻击报文时,它就不能再接收正常的连接了。换句话说,它的服务不再可用了!这就是SYN Flood攻击的原理,它是一种典型的DDoS攻击。

连接请求的关键信息

Syn-Flood攻击成立的关键在于服务器资源是有限的,而服务器收到请求会分配资源。通常来说,服务器用这些资源保存此次请求的关键信息,包括请求的来源和目(五元组),以及TCP选项,如最大报文段长度MSS、时间戳timestamp、选择应答使能Sack、窗口缩放因子Wscale等等。当后续的ACK报文到达,三次握手完成,新的连接创建,这些信息可以会被复制到连接结构中,用来指导后续的报文收发。

那么现在的问题就是服务器如何在不分配资源的情况下

  1. 验证之后可能到达的ACK的有效性,保证这是一次完整的握手
  2. 获得SYN报文中携带的TCP选项信息

SYN cookies 算法

SYN Cookies算法wiki可以解决上面的第1个问题以及第2个问题的一部分

我们知道,TCP连接建立时,双方的起始报文序号是可以任意的。SYN cookies利用这一点,按照以下规则构造初始序列号:

  • t为一个缓慢增长的时间戳(典型实现是每64s递增一次)
  • m为客户端发送的SYN报文中的MSS选项值
  • s是连接的元组信息(源IP,目的IP,源端口,目的端口)和t经过密码学运算后的Hash值,即s = hash(sip,dip,sport,dport,t)s的结果取低 24

则初始序列号n为:

  • 5 位为t mod 32
  • 接下来3位为m的编码值
  • 24 位为s

当客户端收到此SYN+ACK报文后,根据TCP标准,它会回复ACK报文,且报文中ack = n + 1,那么在服务器收到它时,将ack - 1就可以拿回当初发送的SYN+ACK报文中的序号了!服务器巧妙地通过这种方式间接保存了一部分SYN报文的信息。

接下来,服务器需要对ack - 1这个序号进行检查:

  • 将高 5 位表示的t与当前之间比较,看其到达地时间是否能接受。
  • 根据t和连接元组重新计算s,看是否和低 24 一致,若不一致,说明这个报文是被伪造的。
  • 解码序号中隐藏的mss信息

到此,连接就可以顺利建立了。

SYN Cookies 缺点

既然SYN Cookies可以减小资源分配环节,那为什么没有被纳入TCP标准呢?原因是SYN Cookies也是有代价的:

  1. MSS的编码只有3位,因此最多只能使用 8MSS
  2. 服务器必须拒绝客户端SYN报文中的其他只在SYNSYN+ACK中协商的选项,原因是服务器没有地方可以保存这些选项,比如WscaleSACK
  3. 增加了密码学运算

Linux 中的 SYN Cookies

Linux上的SYN Cookies实现与wiki中描述的算法在序号生成上有一些区别,其SYN+ACK的序号通过下面的公式进行计算:

内核编译需要打开 CONFIG_SYN_COOKIES
seq = hash(saddr, daddr, sport, dport, 0, 0) + req.th.seq + t << 24 + (hash(saddr, daddr, sport, dport, t, 1) + mss_ind) & 0x00FFFFFF

其中,req.th.seq表示客户端的SYN报文中的序号,mss_ind是客户端通告的MSS值得编码,它的取值在比较新的内核中有 4 种(老的内核有 8 种), 分别对应以下 4 种值

static __u16 const msstab[] = {
    536,
    1300,
    1440,    /* 1440, 1452: PPPoE */
    1460,
};

感兴趣的可以顺着以下轨迹浏览调用顺序

tcp_conn_request
  |-- cookie_init_sequence
     |-- cookie_v4_init_sequence
        |-- __cookie_v4_init_sequence
           |-- secure_tcp_syn_cookie

SYN Cookies 与时间戳

如果服务器和客户端打开了时间戳选项,那么服务器可以将客户端在SYN报文中携带了TCP选项的使能情况暂时保存在时间戳中。当前使用了低 6 位,分别保存WscaleSACKECN

图片描述

客户端会在ACKTSecr字段,把这些值带回来。

实验

Linux中的/proc/sys/net/ipv4/tcp_syncookies是内核中的SYN Cookies开关,0表示关闭SYN Cookies1表示在新连接压力比较大时启用SYN Cookies,2表示始终使用SYN Cookies

本实验是在4.4.0内核运行的,服务端监听50001端口,backlog参数为3(该参数意义)。同时,模拟不同的客户端注入SYN报文。

测试代码

不开启 SYN Cookies

echo 0 > /proc/sys/net/ipv4/tcp_syncookies

可以看到,在收到3SYN报文后,服务器不再响应新的连接请求了,这也就是SYN-Flood的攻击方式。
图片描述

有条件使用 SYN Cookies

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

图片描述

由于服务器的backlog参数为3,因此图中的从第4SYN+ACK(#8报文)开始使用SYN Cookies

从时间戳可以看出,#8报文(44167748)比 #6号报文(44167796)还要小。

44167748 = 0x2A1F244 ,最后低6位是 0b000100 ,与SYN报文中 wscale = 4 是相符的

小结

SYN Cookie技术可以让服务器在收到客户端的SYN报文时,不分配资源保存客户端信息,而是将这些信息保存在SYN+ACK的初始序号和时间戳中。对正常的连接,这些信息会随着ACK报文被带回来。

REF

SYN Flood Attack
Improving syncookies

阅读 4.2k

推荐阅读
187J3X1
用户专栏

793 人关注
48 篇文章
专栏主页