怎样防止ACK攻击

拒绝服务攻击（Denial of Service，DoS）是目前比较有效而又非常难于防御的一种网络攻击方式，它的目的就是使服务器不能够为正常访问的用户提供服务。所以，DoS对一些紧密依靠互联网开展业务的企业和组织带来了致命的威胁。

SYN Flood是最为有效和流行的一种DoS攻击形式。它利用TCP三次握手协议的缺陷，向目标主机发送大量的伪造源地址的SYN连接请求，消耗目标主机的资源，从而不能够为正常用户提供服务。

1.1 TCP连接建立的过程

要掌握SYN Flood攻击的基本原理，必须先介绍TCP的三次握手机制。

TCP三次握手过程如下：

1)客户端向服务器端发送一个SYN置位的TCP报文，包含客户端使用的端口号和初始序列号x；

2)服务器端收到客户端发送来的SYN报文后，向客户端发送一个SYN和ACK都置位的TCP报文，包含确认号为x＋1和服务器的初始序列号y；

3）

TCP客户端

客户端端口

（1024－65535）

TCP服务器端

服务器端口

（1－1023）

SYN

SYN/ACK

ACK

客户端收到服务器返回的SYN＋ACK报文后，向服务器返回一个确认号为y＋1序号为x＋1的ACK报文，一个标准的TCP连接完成。如图1所示：

1.2 攻击原理

在SYN Flood攻击中，黑客机器向受害主机发送大量伪造源地址的TCP SYN报文，受害主机分配必要的资源，然后向源地址返回SYN＋ACK包，并等待源端返回ACK包，如图2所示。由于源地址是伪造的，所以源端永远都不会返回ACK报文，受害主机继续发送SYN＋ACK包，并将半连接放入端口的积压队列中，虽然一般的主机都有超时机制和默认的重传次数，但是由于端口的半连接队列的长度是有限的，如果不断的向受害主机发送大量的TCP SYN报文，半连接队列就会很快填满，服务器拒绝新的连接，将导致该端口无法响应其他机器进行的连接请求，最终使受害主机的资源耗尽。

TCP客户端

客户端端口

（1024－65535）

TCP服务器端

服务器端口

（1－1023）

SYN

SYN/ACK

伪造源地址

2 几种防御技术

SYN Flood攻击给互联网造成重大影响后，针对如何防御SYN Flood攻击出现了几种比较有效的技术。

2.1 SYN－cookie技术

一般情况下，当服务器收到一个TCP SYN报文后，马上为该连接请求分配缓冲区，然后返回一个SYN＋ACK报文，这时形成一个半连接。SYN Flood正是利用了这一点，发送大量的伪造源地址的SYN连接请求，而不完成连接。这样就大量的消耗的服务器的资源。

SYN－cookie技术针对标准TCP连接建立过程资源分配上的这一缺陷，改变了资源分配的策略。当服务器收到一个SYN报文后，不立即分配缓冲区，而是利用连接的信息生成一个cookie，并将这个cookie作为将要返回的SYN＋ACK报文的初始序列号。当客户端返回一个ACK报文时，根据包头信息计算cookie，与返回的确认序列号（初始的序列号＋1）的前24位进行对比，如果相同，则是一个正常连接，然后，分配资源，建立连接。

该技术的巧妙之点在于避免了在连接信息未完全到达前进行资源分配，使SYN Flood攻击的资源消耗失效。实现的关键之处在于cookie的计算。cookie的计算应该做到包含本次连接的状态信息，使攻击者不能伪造cookie。cookie的计算过程如下：

1）服务器收到一个SYN包后，计算一个消息摘要mac：

mac = MAC（A，k）；

MAC是密码学中的一个消息认证码函数，也就是满足某种安全性质的带密钥的hash函数，它能够提供cookie计算中需要的安全性。

A为客户和服务器双方的IP地址和端口号以及参数t的串联组合：

A = SOURCE_IP || SOURCE_PORT || DST_IP || DST_PORT || t

K为服务器独有的密钥；

时间参数t为32比特长的时间计数器，每64秒加1；

2）生成cookie：

cookie = mac（0:24）：表示取mac值的第0到24比特位；

3）设置将要返回的SYN+ACK报文的初始序列号，设置过程如下：

i. 高24位用cookie代替；

ii. 接下来的3比特位用客户要求的最大报文长度MMS代替；

iii. 最后5比特位为t mod 32。

客户端收到来自服务器SYN+ACK报文后，返回一个ACK报文，这个ACK报文将带一个cookie（确认号为服务器发送过来的SYN ACK报文的初始序列号加1，所以不影响高24位），在服务器端重新计算cookie，与确认号的前24位比较，如果相同，则说明未被修改，连接合法，然后，服务器完成连接的建立过程。

SYN-cookie技术由于在连接建立过程中不需要在服务器端保存任何信息，实现了无状态的三次握手，从而有效的防御了SYN Flood攻击。但是该方法也存在一些弱点。由于cookie的计算只涉及了包头的部分信心，在连接建立过程中不在服务器端保存任何信息，所以失去了协议的许多功能，比如，超时重传。此外，由于计算cookie有一定的运算量，增加了连接建立的延迟时间，因此，SYN-cookie技术不能作为高性能服务器的防御手段。通常采用动态资源分配机制，当分配了一定的资源后再采用cookie技术，Linux就是这样实现的。还有一个问题是，当我们避免了SYN Flood攻击的同时，同时也提供了另一种拒绝服务攻击方式，攻击者发送大量的ACK报文，使服务器忙于计算验证。尽管如此，在预防SYN Flood攻击方面，SYN-cookie技术仍然是一种有效的技术。

2.2 地址状态监控的解决方法

地址状态监控的解决方法是利用监控工具对网络中的有关TCP连接的数据包进行监控，并对监听到的数据包进行处理。处理的主要依据是连接请求的源地址。

每个源地址都有一个状态与之对应，总共有四种状态：

初态：任何源地址刚开始的状态；

NEW状态：第一次出现或出现多次也不能断定存在的源地址的状态；

GOOD状态：断定存在的源地址所处的状态；

BAD状态：源地址不存在或不可达时所处的状态。

具体的动作和状态转换根据TCP头中的位码值决定：

1）监听到SYN包，如果源地址是第一次出现，则置该源地址的状态为NEW状态；如果是NEW状态或BAD状态；则将该包的RST位置1然后重新发出去，如果是GOOD状态不作任何处理。

2）监听到ACK或RST包，如果源地址的状态为NEW状态，则转为GOOD状态；如果是GOOD状态则不变；如果是BAD状态则转为NEW状态；如果是BAD状态则转为NEW状态。

3）监听到从服务器来的SYN ACK报文（目的地址为addr），表明服务器已经为从addr发来的连接请求建立了一个半连接，为防止建立的半连接过多，向服务器发送一个ACK包，建立连接，同时，开始计时，如果超时，还未收到ACK报文，证明addr不可达，如果此时addr的状态为GOOD则转为NEW状态；如果addr的状态为NEW状态则转为BAD状态；如果为addr的状态为BAD状态则不变。

状态的转换图如图3所示：

初态

GOOD

NEW

BAD

ACK/RST

SYN

ACK/RST

ACK包确认超时

ACK/RST

ACK包确认超时

下面分析一下基于地址状态监控的方法如何能够防御SYN Flood攻击。

1）对于一个伪造源地址的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，当监听到服务器的SYN+ACK报文，表明服务器已经为该源地址的连接请求建立了半连接。此时，监控程序代源地址发送一个ACK报文完成连接。这样，半连接队列中的半连接数不是很多。计时器开始计时，由于源地址是伪造的，所以不会收到ACK报文，超时后，监控程序发送RST数据包，服务器释放该连接，该源地址的状态转为BAD状态。之后，对于每一个来自该源地址的SYN报文，监控程序都会主动发送一个RST报文。

2）对于一个合法的SYN报文，若源地址第一次出现，则源地址的状态为NEW状态，服务器响应请求，发送SYN＋ACK报文，监控程序发送ACK报文，连接建立完毕。之后，来自客户端的ACK很快会到达，该源地址的状态转为GOOD状态。服务器可以很好的处理重复到达的ACK包。

从以上分析可以看出，基于监控的方法可以很好的防御SYN Flood攻击，而不影响正常用户的连接。

3 小结

本文介绍了SYN Flood攻击的基本原理，然后详细描述了两种比较有效和方便实施的防御方法：SYN-cookie技术和基于监控的源地址状态技术。SYN-cookie技术实现了无状态的握手，避免了SYN Flood的资源消耗。基于监控的源地址状态技术能够对每一个连接服务器的IP地址的状态进行监控，主动采取措施避免SYN Flood攻击的影响。这两种技术是目前所有的防御SYN Flood攻击的最为成熟和可行的技术。

参考文献

1． 颜学雄，王清贤，李梅林. SYN Flood攻击原理与预防方法. 计算机应用，2000

2． 孙 曦，朱晓妍，王育林. DDoS下的TCP洪流攻击及对策. 网络安全技术与应用，2004

3． 李 磊，赵永祥，陈常嘉. TCP SYN Flooding原理及其应对策略. 网络与应用，2003

4． 陈 波. SYN Flood攻击的原理、实现与防范. 计算机应用与研究，2003

【转自世纪安全网 http://www.21safe.com】

■ SYN cookies技术 我们知道，TCP协议开辟了一个比较大的内存空间backlog队列来存储半连接条目，当SYN请求不断增加，并这个空间，致使系统丢弃SYN连接。为使半连接队列被塞满的情况下，服务器仍能处理新到的SYN请求，SYN cookies技术被设计出来。 SYN cookies应用于linux、FreeBSD等操作系统，当半连接队列满时，SYN cookies并不丢弃SYN请求，而是通过加密技术来标识半连接状态。 在TCP实现中，当收到客户端的SYN请求时，服务器需要回复SYN＋ACK包给客户端，客户端也要发送确认包给服务器。通常，服务器的初始序列号由服务器按照一定的规律计算得到或采用随机数，但在SYN cookies中，服务器的初始序列号是通过对客户端IP地址、客户端端囗、服务器IP地址和服务器端囗以及其他一些安全数值等要素进行hash运算，加密得到的，称之为cookie。当服务器遭受SYN攻击使得backlog队列满时，服务器并不拒绝新的SYN请求，而是回复cookie（回复包的SYN序列号）给客户端， 如果收到客户端的ACK包，服务器将客户端的ACK序列号减去1得到cookie比较值，并将上述要素进行一次hash运算，看看是否等于此cookie。如果相等，直接完成三次握手（注意：此时并不用查看此连接是否属于backlog队列）。 在RedHat linux中，启用SYN cookies是通过在启动环境中设置以下命令来完成： # echo 1 >/proc/sys/net/ipv4/tcp_syncookies ■ 增加最大半连接数 大量的SYN请求导致未连接队列被塞满，使正常的TCP连接无法顺利完成三次握手，通过增大未连接队列空间可以缓解这种压力。当然backlog队列需要占用大量的内存资源，不能被无限的扩大。 WIN2000：除了上面介绍的TcpMaxHalfOpen, TcpMaxHalfOpenRetried参数外，WIN2000操作系统可以通过设置动态backlog(dynamic backlog)来增大系统所能容纳的最大半连接数，配置动态backlog由AFD.SYS驱动完成，AFD.SYS是一种内核级的驱动，用于支持基于window socket的应用程序，比如ftp、telnet等。AFD.SYS在注册表的位置：HKLM\\System\\CurrentControlSet\\Services\\AFD\\ParametersEnableDynamicBacklog值为1时，表示启用动态backlog，可以修改最大半连接数。 MinimumDynamicBacklog表示半连接队列为单个TCP端囗分配的最小空闲连接数，当该TCP端囗在backlog队列的空闲连接小于此临界值时，系统为此端囗自动启用扩展的空闲连接（DynamicBacklogGrowthDelta），Microsoft[s:148]该值为20。 MaximumDynamicBacklog是当前活动的半连接和空闲连接的和，当此和超过某个临界值时，系统拒绝SYN包，Microsoft[s:148]MaximumDynamicBacklog值不得超过2000。 DynamicBacklogGrowthDelta值是指扩展的空闲连接数，此连接数并不计算在MaximumDynamicBacklog内，当半连接队列为某个TCP端囗分配的空闲连接小于MinimumDynamicBacklog时，系统自动分配DynamicBacklogGrowthDelta所定义的空闲连接空间，以使该TCP端囗能处理更多的半连接。Microsoft[s:148]该值为10。 LINUX：Linux用变量tcp_max_syn_backlog定义backlog队列容纳的最大半连接数。在Redhat 7.3中，该变量的值默认为256，这个值是远远不够的，一次强度不大的SYN攻击就能使半连接队列占满。我们可以通过以下命令修改此变量的值： # sysctl -w net.ipv4.tcp_max_syn_backlog=\"2048\" Sun Solaris Sun Solaris用变量tcp_conn_req_max_q0来定义最大半连接数，在Sun Solaris 8中，该值默认为1024，可以通过add命令改变这个值： # ndd -set /dev/tcp tcp_conn_req_max_q0 2048 HP-UX：HP-UX用变量tcp_syn_rcvd_max来定义最大半连接数，在HP-UX 11.00中，该值默认为500，可以通过ndd命令改变默认值： ＃ndd -set /dev/tcp tcp_syn_rcvd_max 2048 ■缩短超时时间 上文提到，通过增大backlog队列能防范SYN攻击；另外减少超时时间也使系统能处理更多的SYN请求。我们知道，timeout超时时间，也即半连接存活时间，是系统所有重传次数等待的超时时间总和，这个值越大，半连接数占用backlog队列的时间就越长，系统能处理的SYN请求就越少。为缩短超时时间，可以通过缩短重传超时时间（一般是第一次重传超时时间）和减少重传次数来实现。 Win2000第一次重传之前等待时间默认为3秒，为改变此默认值，可以通过修改网络接囗在注册表里的TcpInitialRtt注册值来完成。重传次数由TcpMaxConnectResponseRetransmissions 来定义，注册表的位置是：HKLM\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters registry key。 当然我们也可以把重传次数设置为0次，这样服务器如果在3秒内还未收到ack确认包就自动从backlog队列中删除该连接条目。 LINUX：Redhat使用变量tcp_synack_retries定义重传次数，其默认值是5次，总超时时间需要3分钟。 Sun Solaris Solaris 默认的重传次数是3次，总超时时间为3分钟，可以通过ndd命令修改这些默认值。

---