SYN Flood攻击及其防御

本文档的Copyleft归yfydz所有，使用GPL发布，可以自由拷贝、转载，转载时请保持文档的完整性，

严禁用于任何商业用途。
msn: [email protected]
来源：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攻击器没有任何设备能防御。