最近在学习TCP方面的基础知识，对于古老的SYN Flood也有了更多认识。SYN Flood利用的是TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。
SYN Flood的原理简单，实现也不复杂，而且网上有许多现成的程序。
我在两台虚拟机上(虚拟机C攻击虚拟机S)做测试，S上跑了apache监听80端口，用C对S的80端口发送SYN Flood，在无任何防护的情况下攻击效果显著。用netstat可以看见80端口存在大量的半连接状态(SYN_RECV)，用tcpdump抓包可以看见大量伪造IP发来的SYN连接，S也不断回复SYN+ACK给对方，可惜对方并不存在(如果存在则S会收到RST这样就失去效果了)，所以会超时重传。
这个时候如果有正常客户A请求S的80端口，它的SYN包就被S丢弃了，因为半连接队列已经满了，达到攻击目的。
对于SYN Flood的防御一般会提到修改 net.ipv4.tcp_synack_retries, net.ipv4.tcp_syncookies, net.ipv4.tcp_max_syn_backlog
目的就是减小SYN+ACK重传次数，增加半连接队列长度，启用syn cookie。
当S开启syn cookie的时候情况会缓解，一旦半连接队列满了系统就会启用syn cookie功能，同时在/var/log/messages记录kernel: possible SYN flooding on port 80. Sending cookies.
但也不是可以完全防御的，如果说攻击瞬间并发量足够大，毕竟S的CPU内存有限，一般大公司都有专业的防火墙设备来应对。
其中对于net.ipv4.tcp_max_syn_backlog的描述一般都称为半连接队列的长度，但在我实际测试的过程中却发现SYN_RECV状态的数量与net.ipv4.tcp_max_syn_backlog设置的值相差甚远。
S系统配置如下：
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_syn_backlog = 4096
但SYN_RECV状态的数量却只有256
于是就开始相关资料，首先想到的是TCP/IP详解卷1中提到的backlog，man 2 listen:
int listen(int sockfd, int backlog);
The backlog parameter defines the maximum length the queue of pending connections may grow to. If a connection request arrives with
the queue full the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmis-
sion, the request may be ignored so that retries succeed.
NOTES
The behaviour of the backlog parameter on TCP sockets changed with Linux 2.2. Now it specifies the queue length for completely estab-
lished sockets waiting to be accepted, instead of the number of incomplete connection requests. The maximum length of the queue for
incomplete sockets can be set using the tcp_max_syn_backlog sysctl. When syncookies are enabled there is no logical maximum length
and this sysctl setting is ignored. See tcp(7) for more information.
可见backlog在Linux 2.2之后表示的是已完成三次握手但还未被应用程序accept的队列长度。
man 7 tcp:
tcp_max_syn_backlog (integer; default: see below)
The maximum number of queued connection requests which have still not received an acknowledgement from the connecting client.
If this number is exceeded, the kernel will begin dropping requests. The default value of 256 is increased to 1024 when the
memory present in the system is adequate or greater (>= 128Mb), and reduced to 128 for those systems with very low memory (<=
32Mb). It is recommended that if this needs to be increased above 1024, TCP_SYNQ_HSIZE in include/net/tcp.h be modified to
keep TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog, and the kernel be recompiled.
可见tcp_max_syn_backlog确实是半连接队列的长度，那为何会不准呢？
这时候正好让同事也在两台机器上测试了一下，得到的数据居然与tcp_max_syn_backlog完全一致。
开始怀疑是系统哪个地方配置有问题，又发现一个可疑的配置 net.core.somaxconn 它是listen的第二个参数int backlog的上限值，如果程序里的backlog大于
net.core.somaxconn的话就会取net.core.somaxconn的值。S系统的net.core.somaxconn = 128
//file:net/socket.c
SYSCALL_DEFINE2(listen, int, fd, int, backlog)
{
struct socket *sock;
int err, fput_needed;
int somaxconn;
sock = sockfd_lookup_light(fd, &err, &fput_needed);
if (sock) {
somaxconn = sock_net(sock->sk)->core.sysctl_somaxconn;
//上限不超过somaxconn
if ((unsigned)backlog > somaxconn)
backlog = somaxconn;
err = security_socket_listen(sock, backlog);
if (!err)
err = sock->ops->listen(sock, backlog);
fput_light(sock->file, fput_needed);
}
return err;
}
查了apache文档关于ListenBackLog 指令的说明，默认值是511. 可见最终全连接队列(backlog)应该是net.core.somaxconn = 128
证实这点比较容易，用 慢连接攻击 测试观察到虚拟机S的80端口ESTABLISHED状态最大数量384
正好等于256(apache prefork模式MaxClients即apache可以响应的最大并发连接数) + 128(backlog即已完成三次握手等待apache accept的最大连接数)。说明全连接队列长度等于min(backlog,somaxconn);
转载请注明：爱开源 » linux诡异的半连接(SYN_RECV)队列长度(一)