DoS攻击的原理以及监测与防御初探
第一部分 SYN Flood的基本原理
SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一,这是一种利用TCP协议缺陷,发送大量伪造的TCP连接请求,从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式。
要明白这种攻击的基本原理,还是要从TCP连接建立的过程开始说起:
大家都知道,TCP与UDP不同,它是基于连接的,也就是说:为了在服务端和客户端之间传送TCP数据,必须先建立一个虚拟电路,也就是TCP连接,建立TCP连接的标准过程是这样的:
首先,请求端(客户端)发送一个包含SYN标志的TCP报文,SYN即同步(Synchronize),同步报文会指明客户端使用的端口以及TCP连接的初始序号;
第二步,服务器在收到客户端的SYN报文后,将返回一个SYN+ACK的报文,表示客户端的请求被接受,同时TCP序号被加一,ACK即确认(Acknowledgement)。
第三步,客户端也返回一个确认报文ACK给服务器端,同样TCP序列号被加一,到此一个TCP连接完成。
以上的连接过程在TCP协议中被称为三次握手(Three-way Handshake)。
问题就出在TCP连接的三次握手中,假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小),此时从正常客户的角度看来,服务器失去响应,这种情况我们称作:服务器端受到了SYN Flood攻击(SYN洪水攻击)。
从防御角度来说,有几种简单的解决方法,第一种是缩短SYN Timeout时间,由于SYN Flood攻击的效果取决于服务器上保持的SYN半连接数,这个值=SYN攻击的频度 x SYN Timeout,所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃改连接的时间,例如设置为20秒以下(过低的SYN Timeout设置可能会影响客户的正常访问),可以成倍的降低服务器的负荷。
第二种方法是设置SYN Cookie,就是给每一个请求连接的IP地址分配一个Cookie,如果短时间内连续受到某个IP的重复SYN报文,就认定是受到了攻击,以后从这个IP地址来的包会被一概丢弃。
可是上述的两种方法只能对付比较原始的SYN Flood攻击,缩短SYN Timeout时间仅在对方攻击频度不高的情况下生效,SYN Cookie更依赖于对方使用真实的IP地址,如果攻击者以数万/秒的速度发送SYN报文,同时利用SOCK_RAW随机改写IP报文中的源地址,以上的方法将毫无用武之地。
第二部分 SYN Flood攻击的监测与防御初探
对于SYN Flood攻击,目前尚没有很好的监测和防御方法,不过如果系统管理员熟悉攻击方法和系统架构,通过一系列的设定,也能从一定程度上降低被攻击系统的负荷,减轻负面的影响。(这正是我撰写本文的主要目的)
一般来说,如果一个系统(或主机)负荷突然升高甚至失去响应,使用Netstat 命令能看到大量SYN_RCVD的半连接(数量>500或占总连接数的10%以上),可以认定,这个系统(或主机)遭到了SYN Flood攻击。
遭到SYN Flood攻击后,首先要做的是取证,通过Netstat –n –p tcp >resault.txt记录目前所有TCP连接状态是必要的,如果有嗅探器,或者TcpDump之类的工具,记录TCP SYN报文的所有细节也有助于以后追查和防御,需要记录的字段有:源地址、IP首部中的标识、TCP首部中的序列号、TTL值等,这些信息虽然很可能是攻击者伪造的,但是用来分析攻击者的心理状态和攻击程序也不无帮助。特别是TTL值,如果大量的攻击包似乎来自不同的IP但是TTL值却相同,我们往往能推断出攻击者与我们之间的路由器距离,至少也可以通过过滤特定TTL值的报文降低被攻击系统的负荷(在这种情况下TTL值与攻击报文不同的用户就可以恢复正常访问)
前面曾经提到可以通过缩短SYN Timeout时间和设置SYN Cookie来进行SYN攻击保护,对于Win2000系统,还可以通过修改注册表降低SYN Flood的危害,在注册表中作如下改动:
首先,打开regedit,找到HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
增加一个SynAttackProtect的键值,类型为REG_DWORD,取值范围是0-2,这个值决定了系统受到SYN攻击时采取的保护措施,包括减少系统SYN+ACK的重试的次数等,默认值是0(没有任何保护措施),推荐设置是2;
增加一个TcpMaxHalfOpen的键值,类型为REG_DWORD,取值范围是100-0xFFFF,这个值是系统允许同时打开的半连接,默认情况下WIN2K PRO和SERVER是100,ADVANCED SERVER是500,这个值很难确定,取决于服务器TCP负荷的状况和可能受到的攻击强度,具体的值需要经过试验才能决定。
增加一个TcpMaxHalfOpenRetried的键值,类型为REG_DWORD,取值范围是80-0xFFFF,默认情况下WIN2K PRO和SERVER是80,ADVANCED SERVER是400,这个值决定了在什么情况下系统会打开SYN攻击保护。
我们来分析一下Win2000的SYN攻击保护机制:正常情况下,Win2K对TCP连接的三次握手有一个常规的设置,包括SYN Timeout时间、SYN-ACK的重试次数和SYN报文从路由器到系统再到Winsock的延时等,这个常规设置是针对系统性能进行优化的(安全和性能往往相互矛盾)所以可以给用户提供方便快捷的服务;一旦服务器受到攻击,SYN半连接的数量超过TcpMaxHalfOpenRetried的设置,系统会认为自己受到了SYN Flood攻击,此时设置在SynAttackProtect键值中的选项开始作用,SYN Timeout时间被减短,SYN-ACK的重试次数减少,系统也会自动对缓冲区中的报文进行延时,避免对TCP/IP堆栈造成过大的冲击,力图将攻击危害减到最低;如果攻击强度不断增大,超过了TcpMaxHalfOpen值,此时系统已经不能提供正常的服务了,更重要的是保证系统不会崩溃,所以系统将会丢弃任何超出TcpMaxHalfOpen值范围的SYN报文(应该是使用随机丢包策略),保证系统的稳定性。
所以,对于需要进行SYN攻击保护的系统,我们可以测试/预测一下访问峰值时期的半连接打开量,以其作为参考设定TcpMaxHalfOpenRetried的值(保留一定的余量),然后再以TcpMaxHalfOpenRetried的1.25倍作为TcpMaxHalfOpen值,这样可以最大限度地发挥WIN2K自身的SYN攻击保护机制。
通过设置注册表防御SYN Flood攻击,采用的是“挨打”的策略,无论系统如何强大,始终不能光靠挨打支撑下去,除了挨打之外,“退让”也是一种比较有效的方法。
退让策略是基于SYN Flood攻击代码的一个缺陷,我们重新来分析一下SYN Flood攻击者的流程:SYN Flood程序有两种攻击方式,基于IP的和基于域名的,前者是攻击者自己进行域名解析并将IP地址传递给攻击程序,后者是攻击程序自动进行域名解析,但是它们有一点是相同的,就是一旦攻击开始,将不会再进行域名解析,我们的切入点正是这里:假设一台服务器在受到SYN Flood攻击后迅速更换自己的IP地址,那么攻击者仍在不断攻击的只是一个空的IP地址,并没有任何主机,而防御方只要将DNS解析更改到新的IP地址就能在很短的时间内(取决于DNS的刷新时间)恢复用户通过域名进行的正常访问。为了迷惑攻击者,我们甚至可以放置一台“牺牲”服务器让攻击者满足于攻击的“效果”(由于DNS缓冲的原因,只要攻击者的浏览器不重起,他访问的仍然是原先的IP地址)。
同样的原因,在众多的负载均衡架构中,基于DNS解析的负载均衡本身就拥有对SYN Flood的免疫力,基于DNS解析的负载均衡能将用户的请求分配到不同IP的服务器主机上,攻击者攻击的永远只是其中一台服务器,虽然说攻击者也能不断去进行DNS请求从而打破这种“退让”策略,但是一来这样增加了攻击者的成本,二来过多的DNS请求可以帮助我们追查攻击者的真正踪迹(DNS请求不同于SYN攻击,是需要返回数据的,所以很难进行IP伪装)。
对于防火墙来说,防御SYN Flood攻击的方法取决于防火墙工作的基本原理,一般说来,防火墙可以工作在TCP层之上或IP层之下,工作在TCP层之上的防火墙称为网关型防火墙,网关型防火墙与服务器、客户机之间的关系如下图所示:
外部TCP连接 内部TCP连接
[客户机] =================>[防火墙] =================>[服务器]
如上图所示,客户机与服务器之间并没有真正的TCP连接,客户机与服务器之间的所有数据交换都是通过防火墙代理的,外部的DNS解析也同样指向防火墙,所以如果网站被攻击,真正受到攻击的是防火墙,这种防火墙的优点是稳定性好,抗打击能力强,但是因为所有的TCP报文都需要经过防火墙转发,所以效率比较低由于客户机并不直接与服务器建立连接,在TCP连接没有完成时防火墙不会去向后台的服务器建立新的TCP连接,所以攻击者无法越过防火墙直接攻击后台服务器,只要防火墙本身做的足够强壮,这种架构可以抵抗相当强度的SYN Flood攻击。但是由于防火墙实际建立的TCP连接数为用户连接数的两倍(防火墙两端都需要建立TCP连接),同时又代理了所有的来自客户端的TCP请求和数据传送,在系统访问量较大时,防火墙自身的负荷会比较高,所以这种架构并不能适用于大型网站。(我感觉,对于这样的防火墙架构,使用TCP_STATE攻击估计会相当有效:)
工作在IP层或IP层之下的防火墙(路由型防火墙)工作原理有所不同,它与服务器、客户机的关系如下图所示:
[防火墙] 数据包修改转发
[客户机]========|=======================>[服务器]
TCP连接
客户机直接与服务器进行TCP连接,防火墙起的是路由器的作用,它截获所有通过的包并进行过滤,通过过滤的包被转发给服务器,外部的DNS解析也直接指向服务器,这种防火墙的优点是效率高,可以适应100Mbps-1Gbps的流量,但是这种防火墙如果配置不当,不仅可以让攻击者越过防火墙直接攻击内部服务器,甚至有可能放大攻击的强度,导致整个系统崩溃。
在这两种基本模型之外,有一种新的防火墙模型,我个人认为还是比较巧妙的,它集中了两种防火墙的优势,这种防火墙的工作原理如下所示:
第一阶段,客户机请求与防火墙建立连接:
SYN SYN+ACK ACK
[客户机]---- >[防火墙] => [防火墙]-------- >[客户机] => [客户机]--- >[防火墙]
第二阶段,防火墙伪装成客户机与后台的服务器建立连接
[防火墙]< =========== >[服务器]
TCP连接
第三阶段,之后所有从客户机来的TCP报文防火墙都直接转发给后台的服务器
防火墙转发
[客户机]< ======|======= >[服务器]
TCP连接
这种结构吸取了上两种防火墙的优点,既能完全控制所有的SYN报文,又不需要对所有的TCP数据报文进行代理,是一种两全其美的方法。
近来,国外和国内的一些防火墙厂商开始研究带宽控制技术,如果能真正做到严格控制、分配带宽,就能很大程度上防御绝大多数的拒绝服务攻击,我们还是拭目以待吧。 | |
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=33781
阅读(1277) | 评论(0) | 转发(0) |