TCP 全队列和半队列介绍和SYN Flood

2015-01-09 0 By admin

一、TCP 维护队列

TCP协议在数据传输过程中会维护两个队列:半连接队列(SYN queue)和全连接队列(accept queue)。

1.1、半连接队列(SYN Queue)

服务器端监听TCP端口后,会创建一个request_sock结构,用于存储半连接队列。
在TCP三次握手中,当服务器接受到客户端的SYN包后,就将此连接保存到SYN Queue中,并向客户端发送SYN-ACK包;等待客户端发送ACK包。
此时服务器端记录此链接状态为SYN_RECV。
SYN Queue的存储数量max(64,/proc/sys/net/ipv4/tcp_max_syn_backlog)。

1.2、全连接队列Accept Queue

客户端收到服务器端的syn-ack包后,就会发出ACK包。服务器端收到ACK包,会将此链接从SYN Queue中删除,添加到Accept Queue。
此时服务器端记录此链接状态为Established。
accept queue的存储数量min(backlog,somaxconn)。默认somaxconn为128,即接受129个。

二、SYN Queue队列满(tcp_abort_on_overflow)|SYN Flood攻击

当服务器维护的SYN Queue队列满了,默认(tcp_abort_on_overflow=0)情况会发送重置此连接;客户端会重新发送SYN包,尝试多次得不到响应后返回(time out)错误。
SYN Flood 是DDoS(分布式拒绝服务攻击)的方式之一,这是一种利用TCP协议缺陷,发送大量伪造的TCP连接请求,从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式。

2.1、实例场景

场景1、当Client发送SYN包后就宕机了,这样Server服务发送的SYN-ACK数据包一直得不到确认;会持续一段时间在SYN_RCV状态并维护此链接在SYN Queue队列中。
场景2、黑客伪造大量的TCP连接请求,服务器端产生大量的SYN_RCV状态链接和SYN Queue队列被填满。

2.2、tcp_abort_on_overflow参数

默认0:当系统无法处理新连接,则内核重置此连接;尝试之后恢复此连接。
启动1:如确定新连接请求无法处理,开启此参数,直接拒绝接受连接。启用此选项可能会损害服务器的客户端。

2.3、SYN_RCV多久关闭

目前,Linux下默认会进行5次重发SYN-ACK包,重试的间隔时间从1s开始,下次的重试间隔时间是前一次的双倍,5次的重试时间间隔为1s, 2s, 4s, 8s, 16s,总共31s,第5次发出后还要等32s都知道第5次也超时了,所以,总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s,TCP才会把断开这个连接。
当收到SYN Flood攻击时,从影响时间上考虑,我们应该减小SYN_RCV状态的关闭时间。
net.ipv4.tcp_synack_retries #内核放弃连接之前,发送SYN+ACK包的次数
net.ipv4.tcp_syn_retries #内核放弃建立连接之前,发送SYN包的次数

2.4、判断Client的真伪

Linux 的SYNcookie的机制,默认不开启,通过net.ipv4.tcp_syncookies控制,设置为1表示开启。当服务器端开启了syncookie机制,tcp_max_syn_backlog值就失去了意义。
SYNcookie机制就是将连接信息(就是cookie)编码在ISN(initialsequencenumber)中返回给客户端;而服务器端不需要将半连接(syn connection)保存在SYN Queue队列中,而是利用客户端随后发来的ACK包中带回的ISN还原连接信息;以完成连接的建立。用于验证客户端是否为攻击,避免了半连接队列被攻击SYN包填满。
请注意,请先千万别用tcp_syncookies来处理正常的大负载的连接的情况。因为,synccookies是妥协版的TCP协议,并不严谨。

2.5、增加SYN Queue

增加tcp_max_syn_backlog值,增大SYN Queue队列维护的连接数。当开启了syncookie机制,tcp_max_syn_backlog值就失去了意义。

三、Accept Queue队列满

当Accept Queue队列满了之后,即使client继续向server发送ACK的包,也会不被响应。