网络 ACK 攻击是什么?

作者: 来源: 日期:2008-9-2

个人理解是利用TCP连接的三次握手机制,但发起攻击端只来一、两次的握手,而被攻击端就一直在试图完成TCP连接,造成资源不足之类的。

一、SYN / ACK 攻击原理:

SYN工作的原理就是利用两个互联网程序间协议握手的过程进行的攻击。协议握手的过程如下,其中一个应用程序向另一个程序发送一个TCP SYN(同步)数据包。然后目标程序向第一个程序发送一个TCP-ACK应答数据包作为回答;第一个程序最后用一个ACK应答数据包确认已经收到。一旦这两个程序握手成功,它们就准备一起运行了。 SYN攻击用一堆TCP SYN数据包来淹没它的受害者。每个SYN数据包迫使目标服务器产生一个SYN-ACK应答数据包然后等待对应的ACK应答。这很快就导致过量的SYN-ACK一个接一个的堆积在缓存队列里。当缓存队列满了以后,系统就会停止应答到来的SYN请求。如果SYN攻击中包括了拥有错误IP源地址的SYN数据包,情况很快就会变得更糟。在这种情况下,当SYN-ACK被送出的时候,ACK应答就永远不会被收到。飞快充满的缓存队列使得合法程序的SYN请求无法再通过。更加厉害的是,与之相似的Land攻击手段使用欺骗性的SYN数据包,它带有一个伪装的IP地址,使得它看起来像是来自你自己的网络。现在,SYN攻击就像是来自于你防火墙的内部,这使得问题更加严重。 大多数时新的操作系统和防火墙可以阻止SYN攻击。另一个简单的阻止SYN攻击的方法是阻塞掉所有带有已知的错误的IP源地址的数据包。这些数据包应该包括带有错误的为内部保留的IP地址的外部数据包。

二、检测SYN攻击

检测SYN攻击非常的方便,当你在服务器上看到大量的半连接状态时,特别是源IP地址是随机的,基本上可以断定这是一次SYN攻击。我们使用系统自带的netstat 工具来检测SYN攻击:

  # netstat -n -p TCP
  tcp 0  0 10.11.11.11:23  124.173.152.8:25882  SYN_RECV -
  tcp 0  0 10.11.11.11:23  236.15.133.204:2577  SYN_RECV -
  tcp 0  0 10.11.11.11:23  127.160.6.129:51748  SYN_RECV -
  tcp 0  0 10.11.11.11:23  222.220.13.25:47393  SYN_RECV -
  tcp 0  0 10.11.11.11:23  212.200.204.182:60427 SYN_RECV -
  tcp 0  0 10.11.11.11:23  232.115.18.38:278   SYN_RECV -
  tcp 0  0 10.11.11.11:23  239.116.95.96:5122  SYN_RECV -
  tcp 0  0 10.11.11.11:23  236.219.139.207:49162 SYN_RECV -
  ...

上面是在LINUX系统中看到的,很多连接处于SYN_RECV状态(在WINDOWS系统中是SYN_RECEIVED状态),源IP地址都是随机的,表明这是一种带有IP欺骗的SYN攻击。

我们也可以通过下面的命令直接查看在LINUX环境下某个端囗的未连接队列的条目数:

#netstat -n -p TCP | grep SYN_RECV | grep :22 | wc -l
324

显示TCP端囗22的未连接数有324个,虽然还远达不到系统极限,但应该引起管理员的注意。

三、SYN攻击防范技术

关于SYN攻击防范技术,人们研究得比较早。归纳起来,主要有两大类,一类是通过防火墙、路由器等过滤网关防护,另一类是通过加固TCP/IP协议栈防范.但必须清楚的是,SYN攻击不能完全被阻止,我们所做的是尽可能的减轻SYN攻击的危害,除非将TCP协议重新设计。

1、过滤网关防护

这里,过滤网关主要指明防火墙,当然路由器也能成为过滤网关。防火墙部署在不同网络之间,防范外来非法攻击和防止保密信息外泄,它处于客户端和服务器之间,利用它来防护SYN攻击能起到很好的效果。过滤网关防护主要包括超时设置,SYN网关和SYN代理三种。

■网关超时设置:防火墙设置SYN转发超时参数(状态检测的防火墙可在状态表里面设置),该参数远小于服务器的timeout时间。当客户端发送完SYN包,服务端发送确认包后(SYN+ACK),防火墙如果在计数器到期时还未收到客户端的确认包(ACK),则往服务器发送RST包,以使服务器从队列中删去该半连接。值得注意的是,网关超时参数设置不宜过小也不宜过大,超时参数设置过小会影响正常的通讯,设置太大,又会影响防范SYN攻击的效果,必须根据所处的网络应用环境来设置此参数。

■SYN网关:SYN网关收到客户端的SYN包时,直接转发给服务器;SYN网关收到服务器的SYN/ACK包后,将该包转发给客户端,同时以客户端的名义给服务器发ACK确认包。此时服务器由半连接状态进入连接状态。当客户端确认包到达时,如果有数据则转发,否则丢弃。事实上,服务器除了维持半连接队列外,还要有一个连接队列,如果发生SYN攻击时,将使连接队列数目增加,但一般服务器所能承受的连接数量比半连接数量大得多,所以这种方法能有效地减轻对服务器的攻击。

■SYN代理:当客户端SYN包到达过滤网关时,SYN代理并不转发SYN包,而是以服务器的名义主动回复SYN/ACK包给客户,如果收到客户的ACK包,表明这是正常的访问,此时防火墙向服务器发送ACK包并完成三次握手。SYN代理事实上代替了服务器去处理SYN攻击,此时要求过滤网关自身具有很强的防范SYN攻击能力。
 
2、加固tcp/ip协议栈

防范SYN攻击的另一项主要技术是调整tcp/ip协议栈,修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等。tcp/ip协议栈的调整可能会引起某些功能的受限,管理员应该在进行充分了解和测试的前提下进行此项工作。

■SynAttackProtect机制

为防范SYN攻击,win2000系统的tcp/ip协议栈内嵌了SynAttackProtect机制,Win2003系统也采用此机制。SynAttackProtect机制是通过关闭某些socket选项,增加额外的连接指示和减少超时时间,使系统能处理更多的SYN连接,以达到防范SYN攻击的目的。默认情况下,Win2000操作系统并不支持SynAttackProtect保护机制,需要在注册表以下位置增加SynAttackProtect键值:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

当SynAttackProtect值(如无特别说明,本文提到的注册表键值都为十六进制)为0或不设置时,系统不受SynAttackProtect保护。

当SynAttackProtect值为1时,系统通过减少重传次数和延迟未连接时路由缓冲项(route cache entry)防范SYN攻击。

当SynAttackProtect值为2时(Microsoft推荐使用此值),系统不仅使用backlog队列,还使用附加的半连接指示,以此来处理更多的SYN连接,使用此键值时,tcp/ip的TCPInitialRTT、window size和可滑动窗囗将被禁止。

我们应该知道,平时,系统是不启用SynAttackProtect机制的,仅在检测到SYN攻击时,才启用,并调整tcp/ip协议栈。那么系统是如何检测SYN攻击发生的呢?事实上,系统根据TcpMaxHalfOpen,TcpMaxHalfOpenRetried 和TcpMaxPortsExhausted三个参数判断是否遭受SYN攻击。

TcpMaxHalfOpen 表示能同时处理的最大半连接数,如果超过此值,系统认为正处于SYN攻击中。Win2000 server默认值为100,Win2000 Advanced server为500。

TcpMaxHalfOpenRetried定义了保存在backlog队列且重传过的半连接数,如果超过此值,系统自动启动SynAttackProtect机制。Win2000 server默认值为80,Win2000 Advanced server为400。

TcpMaxPortsExhausted 是指系统拒绝的SYN请求包的数量,默认是5。

如果想调整以上参数的默认值,可以在注册表里修改(位置与SynAttackProtect相同)

■ 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推荐该值为20。

MaximumDynamicBacklog是当前活动的半连接和空闲连接的和,当此和超过某个临界值时,系统拒绝SYN包,Microsoft推荐MaximumDynamicBacklog值不得超过2000。

DynamicBacklogGrowthDelta值是指扩展的空闲连接数,此连接数并不计算在MaximumDynamicBacklog内,当半连接队列为某个TCP端囗分配的空闲连接小于MinimumDynamicBacklog时,系统自动分配DynamicBacklogGrowthDelta所定义的空闲连接空间,以使该TCP端囗能处理更多的半连接。Microsoft推荐该值为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命令修改这些默认值。

==================================================

拒绝服务攻击(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

下载:

你前面那位网友看了:C# 的 char

▲▲▲嘿,欢迎转载传播本站原创文章,尽量保留来源噢。▲▲▲

文章评论
标题:必填
内容: