zoukankan html css js c++ java

SYN FLOOD学习理解

SYN FLOOD是一种比较常见的DoS攻击手段，它的特点就是防不胜防。SYN攻击属于DOS攻击的一种，它利用TCP协议缺陷，通过发送大量的半连接请求，耗费CPU和内存资源。SYN攻击除了能影响主机外，还可以危害路由器、防火墙等网络系统，事实上SYN攻击并不管目标是什么系统，只要这些系统打开TCP服务就可以实施。

TCP连接基本原理

Syn Flood利用了TCP/IP协议的固有漏洞。面向连接的TCP三次握手是Syn Flood存在的基础。

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

2.SYN Flood攻击

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

假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率非常之小），此时从正常客户的角度看来，服务器失去响应，这种情况我们称做：服务器端受到了SYN Flood攻击（SYN洪水攻击）。

3.SYN Flood攻击检测技术

根据统计对象的不同特征，SYN Flood攻击检测可分为两种类型：半开连接数检测、新建连接速率检测。

3.1 半开连接数检测

1. 原理介绍

当恶意客户端向目标服务器发起SYN Flood 攻击时，如果恶意客户端采用了仿冒的源IP，那么在目标服务器上会存在大量半开连接。

这类半开连接与正常的半开连接的区别在于，正常半开连接会随着客户端和服务器端握手报文的交互完成而转变成全连接，而仿冒源IP的半开连接永远不会完成握手报文的交互。

为有效区分仿冒半开连接和正常半开连接，就需要实时记录所有客户端向服务器发起的所有半开连接数和完成了握手交互且转变为全连接的半开连接数，二者之差（即未完成的半连接数）在服务器未受到攻击时会保持在一个相对恒定的范围内。如果未完成的半连接数突然增多，甚至接近服务器的资源分配上限时就可以怀疑此时服务器正受到异常流量的攻击。

半开连接数检测示意图

如上图所示，管理员可以根据被保护服务器的处理能力设置半开连接数阈值。如果服务器无法处理客户端所有连接请求，就会导致未完成的半开连接数（即客户端向服务器发起的所有半开连接数和完成了握手交互变成全连接的半开连接数之差）超过指定阈值，此时可以判定服务器正在遭受SYN Flood 攻击。

3.2 新建连接速率检测

1. 原理介绍

当恶意客户端向目标服务器发起SYN Flood攻击时，不管恶意客户端采用仿冒源IP手段还是使用真实的客户端，其呈现的结果就是发往服务器的报文会在短时间内大量增加。

恶意客户端发向服务器的报文中，一部分是新建连接的报文，一部分是已建立连接的后续数据报文。通过记录每秒新建连接的数量，并与设定的阈值进行比较来判断向目标服务器发起SYN Flood攻击行为是否发生，若达到或超过，则认为攻击行为发生。

新建连接速率检测示意图

如上图所示，在对被保护服务器进行监测时，防火墙在一秒的时间间隔内统计客户端向服务器发起的新建连接请求数量，作为当前的新建请求速率。当新建连接请求速率超过指定阈值时，可以认为服务器可能遭受了SYN Flood攻击。

4.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。

5. 根据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攻击器，是可以避免上述缺点的。

6. 首包丢弃法

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

7. 总结

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

实例演示：

这一个局域网环境，只有一台攻击机（PIII667/128/mandrake），被攻击的是一台Solaris 8.0 (spark)的主机，网络设备是Cisco的百兆交换机。这是在攻击并未进行之前，在Solaris上进行snoop的记录，snoop与tcpdump等网络监听工具一样，也是一个很好的网络抓包与分析的工具。可以看到攻击之前，目标主机上接到的基本上都是一些普通的网络包。

…