TCP SYNCookie机制

本篇文章在于浅尝辄止的分析TCP的SYNCookie机制

一个连接的建立需要进行TCP三次握手，如下图所示

简单来说，服务端收到客户端的SYN包之后，将连接放到半连接队列中， 当服务端再次收到客户端的ACK包之后，会将连接从半连接队列移到全连接队列中， 这样服务端的程序调用accept()方法的时候，就可以从全连接队列中获取到连接了.

这里要提到SYN Flood， 如果一个客户端在短时间内发送大量的SYN包给服务端，而且不发送ACK包给服务端， 这样会导致服务端的半连接队列很快就被填满了， 间接导致其他客户端无法与服务端完成三次握手.

接下来，通过实验模拟这样的场景，以及如何解决它.

【实验】
一台ubuntu-20.04机器作为服务端(IP=192.168.0.103)， 一台Kali机器作为客户端(IP=192.168.0.102)

首先，需要修改一个服务端的配置文件(/etc/sysctl.conf)，修改的文件内容如下

如果sysctl.conf文件中没有对应的属性值则自己手动添加

属性值的含义如下
net.ipv4.tcp_syncookies = 0 表示不开启SYNCookie机制
net.ipv4.tcp_max_syn_backlog = 5 设置半连接队列大小
net.core.somaxconn = 5 设置全连接队列大小

这里只是将半连接队列和全连接队列设置的小了一些, 除此之外没有其他特殊原因

接下来，在服务端，使用Python语言搭建一个简单的Server程序，代码如下

import socket
server=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
server.bind(('192.168.0.103',8082))
server.listen(5)

程序监听在8082端口

然后在客户端机器上，通过netwox命令，向服务端持续发送SYN包，模拟SYN Flood

以上命令会向192.168.0.103机器的8082端口发送SYN包

通过 apt install netwox 安装netwox命令

接下来， 我们看一下服务端的一些现象

在服务端执行 netstat -s | grep LISTEN 命令，可以查看半连接队列的情况

可以发现，被丢弃的SYN包的数量一直在增长. 因为客户端一直在向服务端发送SYN包， 当半连接队列满了之后，后面的SYN包只能被丢弃

在服务端执行 sudo tcpdump -nn -i enp0s8 port 8082 命令，如下图

192.168.0.103属于enp0s8网卡

可以发现， 客户端一直发送SYN包给服务端

而且通过查看系统日志，比如使用 dmesg 命令或者查看 /var/log/kern.log 文件，能够发现如下一行信息

TCP: request_sock_TCP: Possible SYN flooding on port 8082. Dropping request.

大概意思是，在8082端口可能发生了SYN Flood攻击， 请求被丢弃了.

假如我们有另外一个客户端，向服务端正常的发送三次握手，比如执行 telnet 192.168.0.103 8082 命令

它会一直处于连接中，直到超时失败.

【总结】 由于半连接队列满了，导致客户端无法与服务端建立连接

针对上面的情况，TCP给出了一个解决思路，修改服务端的配置文件(/etc/sysctl.conf)，将 net.ipv4.tcp_syncookies = 1 ，表示开启SYNCookie机制， 其他的无需修改， 继续上面的实验

通过 netstat -s | grep LISTEN 命令，可以发现SYN包没有再被丢弃 (被丢弃的数量没有发生变化)

再次通过dmesg命令查看系统日志，发现如下一行信息

TCP: request_sock_TCP: Possible SYN flooding on port 8082. Sending cookies.
大概意思是，在8082端口可能发生了SYN Flood攻击， 发送了cookies.

是因为在服务端开启了SYNCookie机制， 即便半连接队列满了， 通过Cookie机制，依然可以保证让客户端连接到服务端.

这个时候通过另外一个客户端执行 telnet 192.168.0.103 8082 命令，是可以正常连接到服务端的，如下图

【总结】开启TCP的SYN Cookie机制，即便半连接队列满了，客户端也可以成功与服务端建立连接