SYN Flood攻击,防御?无解!

SYN Flood攻击,防御?无解!

本文档的Copyleft归yfydz所有，使用GPL发布，可以自由拷贝、转载，转载时请保持文档的完整性，严禁用于任何商业用途。
msn:
来源: http://yfydz.cublog.cn

1.TCP连接基本原理
TCP协议是一个标准的面向连接协议，在真正的通信前，必须按一定协议先建立连接，连接建立好后才能通信，通信结束后释放连接。连接建立过程称为三次握手，发起方先发送带有只SYN标志的数据包到目的方，目的方如果端口是打开允许连接的，就会回应一个带SYN和ACK标志的数据包到发起方，发起方收到后再发送一个只带ACK标志的数据包到目地方，目的方收到后就可认为连接已经正确建立。服务器只收到SYN包时称为半连接状态，收到ACK包成为全连接，半连接和全连接服务器端都要分配一定的资源来处理。

2.SYN Flood攻击
SYN Flood攻击就是根据TCP服务器不验证连接对方，一收到SYN就要回应的特点进行的DOS攻击，攻击方发送大量的伪造SYN包到服务器，使服务器建立大量的半连接，使自己的连接队列被填满，这样真正的请求就无法响应，造成服务无法提供。

只要攻击方构造攻击包的代价小于服务器的处理代价，SYN攻击就可以起效。

3.syn cookie和syn proxy防御
syn cookie方法是在收到SYN包后，服务器根据一定的方法，以数据包的源地址、端口等信息为参数计算出一个cookie值作为自己的SYNACK包的序列号，回复SYNACK包后服务器并不分配资源进行处理，等收到发起方的ACK包后，重新根据数据包的源地址、端口计算该包中的确认序列号是否正确，如果正确则建立连接，否则丢弃该包。该方法可以在服务器上自己使用，确实能缓解SYN Flood攻击，但如果不用SYN而用ACK攻击，DOS就会很有效。即使是这样，就算只有SYN包，由于计算cookie值并不很简单，也需要消耗资源，因此流量大时也会形成DOS的。

syn proxy方法一般不在服务器本身使用，而是在服务器前端的防火墙上使用，防火墙上收到SYN包，自己就回复一个SYNACK包给发起方，在自己内部建立连接，等发起方将ACK包返回后，再重新构造SYN包发到服务器，建立真正的TCP连接，这个过程中防火墙要给发起方发送SYNACK一个包，给服务器发送SYN和ACK两个包，通信的后续包防火墙都应该注意修改序列号或确认号，因为防火墙回复发起方的SYNACK包的序列号基本不可能等于服务器发送的 SYNACK包的序列号，所以要进行调整。syn proxy的方法可以保证到达服务器的连接都是合法的连接，有攻击时服务器并不会受到冲击，都是由防火墙来承受了，本质上也不能真正防御SYN Flood。

4. 根据SYN包异常来判断
对于构造出来的SYN攻击，源地址、源端口等值都可能是随机的，不能确定是否真是攻击包，但攻击程序一般并不是真正完善，还是可以通过一定特点检测出来，以下是一些判断依据：
1) 是否带TCP选项，一般的TCP SYN包中都要带选项，只是要告诉对方自己的MSS是多少，完全不带选项的SYN包理论上虽然合法，但伪造的可能性更大；
2) tcp window值，window值表示当前机器所能接收的数据缓冲大小，作为连接发起方，该值太小是说不过去的，伪造成分居多；
3) IP TTL值，对于固定的服务器，可以事先探测出到其他地址的TTL值，如果发现该TTL和理论值差异太大，伪造成分居多；
4) IP ID, TCP window, TCP序列号等值在不同SYN包中相同的可能性很小，如果连续的SYN包这些值都相同，基本就是伪造包
当然，对于完善的SYN攻击器，是可以避免上述缺点的。

5. 首包丢弃法
对于真正的TCP连接，如果第一个包没有响应，发起方会再次发送SYN包，而攻击程序大都不会重发，因此防火墙上可以对首次出现的SYN包进行丢弃，只接收后面的，也会缓解SYN Flood攻击。但如果攻击程序确实会重复发包，该方式无效。

6. 总结
由于一般情况下TCP发起方消耗的资源都要小于服务方，所以SYN攻击是TCP协议的死结，根子是出在协议上，所以真正的SYN Flood是无法防御的，所有措施都只能在某些情况下起效，真正从根本上进行防御是不可能的，如果有号称能真正防御SYN攻击的设备，只能说是用来测试的 SYN攻击器功能不完善，真正完善的SYN攻击器没有任何设备能防御。