SYN攻击原理 accpet()函数调用时机

TCP 建立连接

SYN 攻击原理

我们都知道三次握手的第一步是客户端向服务器发送连接请求，第二步是服务器回应客户端的请求，第三步是客户端确认连接。从上图可以看出，前两个报文的 SYN 都置为1，说明它们是同步报文段，同步报文段比较特殊，即使它并没有携带任何应用程序数据，它也要占用一个序号值。其实这个问题的答案就在第二步。在第二次握手时，服务器的TCP收到连接请求报文段后，如若同意建立连接，就向客户端发送确认，并在 OS 内核中为该 TCP 连接分配 TCP 缓存和变量。在确认报文段中，SYN 和 ACK 位都被置为1，确认号字段的值为 x+1(表示希望收到的下一个字节的序号为x+1)，并且服务器随机产生起始序号 seq = y (确认报文不携带数据，但也要消耗掉一个序号)。在计算机里的资源就是两个东西——时间和空间（时间是指处理机的时间，而空间就是硬盘，内存等空间）。这个分配资源的时间很好理解，如若是在第三次握手时才分配资源，那对客户端请求响应肯定会变慢。了解了这个分配资源的问题后，假如，一个黑客想攻击一台服务器，他可以怎么做？首先他伪造地址对服务器发起 SYN 请求，服务器回应 (SYN+ACK) 包，而真正的 IP 并没有做出相应的请求，当然不会回应。服务器没有收到回应，这样的话，服务器会认为(SYN+ACK)丢了，默认情况下会重试 5 次。在这种状态下，服务器会一直维护刚才所分配的资源，可是这些资源并不能被真正的用户所利用。在这个过程中，黑客只需要做到浪费服务器的资源，使得服务器无法响应多数客户端的请求，就能达到攻击服务器的目的了。这就是 SYN flood 攻击的原理。

三次握手过程中产生序列号的算法

我上网查阅了相关资料，就针对 SYN 防御的措施，可以通过以下方式：

(1)无效连接监视释放：这种方法不停的监视系统中半开连接和不活动的连接，当达到一定阈值时就释放这些连接，从而回收系统的资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉。

(2)延缓TCB分配方法：SYN Flood 关键是利用了SYN数据报文一到，服务器立即分配 TCB 资源，从而占用了服务器资源。可以用两种技术来解决这一问题。① Syn Cache 技术：它的思想是在收到 SYN 时不急着去分配 TCB，而是先回应一个 ACK 报文，并在一个专用的 HASH 表中（Cache）中保存这种半开连接，直到收到正确的 ACK 报文再去分配 TCB。②Syn Cookie 技术：完全不使用任何存储资源，它使用一种特殊的算法生成 Sequence Number，这种算法考虑到了对方的IP、端口、己方 IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如 MSS、时间等，在收到对方的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源。

(3)使用SYN Proxy防火墙：其原理是对试图穿越的 SYN 请求进行验证之后才放行。

补充内容：

(1) SYN Flood 攻击

SYN 攻击就是 Client 在短时间内伪造大量不存在的 IP 地址，并向 Server 不断地发送 SYN 包，Server 则回复确认包，并等待 Client 确认，由于源地址不存在，因此 Server 需要不断重发（默认重发5次）直至超时，这些伪造的 SYN 包将长时间占用未连接队列和消耗CPU 时间和内存，导致正常的 SYN 请求无法被响应，从而引起网络拥塞甚至系统瘫痪。

解决方法：只有当 SYN + ACK 报文段本身被确认后(并且已返回初始序列号)才会分配真正的内存。

(2) Land 攻击

向一个目标主机发送一个用于建立请求连接的 TCP SYN 报文而实现对目标主机的攻击。与正常的 TCP SYN 报文不同的是：LAND 攻击报文的源 IP 地址和目的 IP 地址是相同的，都是目标主机的 IP 地址。由于目的 IP 地址和源 IP 地址是相同的，都是目标主机的 IP 地址，因此这个 ACK 报文就发给了目标主机本身。这样如果攻击者发送了足够多的 SYN 报文，则目标计算机的 TCB 可能会耗尽，最终不能正常服务。

(3) connection flood 攻击

利用真实的 IP 地址向服务器发起大量的连接，并且建立连接之后很长时间不释放并定时发送垃圾数据包给服务器使连接得以长时间保持，占用服务器的资源，无法响应其他客户所发起的连接。

解决方法：限制每个源 IP 的连接数；对恶意连接的IP进行封禁；主动清除残余连接。

accpet()函数调用的时间

还有一个问题就是 accept 函数是在那个阶段调用的，这个问题好像是腾讯的一道面试题。之前我一直以为是第二次握手的时候就完成这项工作了。可是没想到啊，最近查看资料后发现自己是大错特错。因为服务器在创建socket、bind、listen之后就要接收客户端的连接请求。而且，服务器就是用 accept() 函数返回的 socket 文件描述符与客户端通信。所以自然而然的认为 accept 函数是在服务器分配资源的时候完成的。其实 accept() 从监听队列中接受的连接已经完成了 TCP 三次握手。下面的代码用于查看调用 accept() 函数之前连接所处的状态，所以就没有添加 accept() 函数。

测试代码：

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <signal.h>
#include <unistd.h>
#include <stdlib.h>
#include <assert.h>
#include <stdio.h>
#include <string.h>static bool stop = false;static void handle_term( int sig )
{stop = true;
}int main( int argc, char *argv[] )     //输入IP，端口和监听队列的长度
{signal( SIGTERM, handle_term );if( argc <= 3 ){printf( "usage:%s ip_address port_number backlog\n", basename(argv[0]) );return 1;}const char * ip = argv[1];int port = atoi( argv[2] );int backlog = atoi( argv[3] );int sock = socket( PF_INET, SOCK_STREAM, 0 );assert( sock >= 0 );struct sockaddr_in address;bzero( &address, sizeof(address) );address.sin_family = AF_INET;inet_pton( AF_INET, ip, &address.sin_addr );address.sin_port = htons( port );int ret = bind( sock, (struct sockaddr*)&address, sizeof(address) );assert( ret != -1 );ret = listen( sock, backlog );assert( ret != -1 );while(!stop)   //循环等待连接，直到有SIGTERM信号将它中断{sleep(1);}close( sock );return 0;
}

在 Linux 系统下运行上述代码，再使用 telnet 命令来连接该服务器程序。同时，每使用 telnet 命令建立一个连接，就执行一次 netstat 命令来查看服务器上连接的状态。具体流程如下：

$ ./asd 192.168.1.10 12345 5
$ telnet 192.168.1.10 12345 5
$ netstat -nt | grep 12345
多次执行2，3步结果是处于ESTABLISHED状态的连接有6个(backlog+1),其他的连接都处于SYN_RCVD状态。

上述实验表明，再 accept() 函数被调用前，三次握手就建立了。

工作流程图如下：