客户支持 >> 测试杂志下载
测试杂志内容精选

[ 网络安全测试 ] 第13期 2010年02月

黑客张大民之大民治水-DDOS反击方法浅论(2)

 

正常与异常网络流量建模

如果需要在几秒钟内作出反应,不但要预警,还要对DDOS进行反击,任何有人工参与的过程都是不可能的了。张大民想。整个过程需要自动化。需要能自动探测到被保护的网站是否受到了DDOS攻击。需要但能自动化的对DDOS进行反击。而整个过程要在几秒钟的范围内完成。

作为一个网络安全工程师,张大民也知道任何问题都需要把它分解成几个模块,然后每个模块各个击破。那首先就看看如何能自动探测到DDOS的攻击吧,张大民想。

很快,张大民就意识到,自动探测DDOS攻击的本质就是对正常与异常网络流量的建模过程。如果系统能够对正常的网络流量建立模型,找到平均值。那么如何高过这个平均值的网络流量都可以认为是异常网络流量。当然,到底高过多高才算作是异常的网络流量,那就要看每个网站管理员的定义了。但如果一个网站日常访问的网络流量是每秒钟100次,突然上升到了每秒钟一万次,那基本上肯定就是拒绝服务的攻击了。

而且张大民还意识到,这种探测方式对分布式拒绝服务攻击还是原始的拒绝服务攻击都是适用的。因为对不管是那种攻击,所有的网络流量最终都要汇总到网站本身。如果能够对正常网络流量进行建模,然后一直监视随后的网络流量,那么如果发现异常,就能够实现自动预警了。张大民想。但这个建模的过程也应该是一个很费时间的过程,至少需要几个星期的时间吧。而且还要保证这几个星期内不受到DOS的攻击,否则建立的模型就不会精确的反应网站正常的访问流量。

对于网站访问流量进行建模的方法应该有很多种,这里面应该也有很多学问可以做,也包涵了一些数学问题。统计学,概率论和神经网络什么的。从这里面出来一个博士论文也不会稀奇。张大民想。但作为工程师的他来说,张大民觉得并不需要对网站的访问流量进行精确的建模,因为据他所知,所有的DDOS洪水攻击的网络流量都差不多是正常网站访问流量的十几倍,甚至几十倍。探测起来并不是很困难。

DDOS网络流量源地址校验

而真正困难的是,当探测到了DDOS的洪水攻击后该怎么办呢?张大民也开始挠脑袋了。因为当有了分布式的洪水攻击后,网站的网络流量内容就变得非常复杂。张大民想了一下,大概包涵一下几种网络流量:

1、 正常的客户来访问网站的访问流量

2、 DDOS网络流量,IP源地址是真实IP地址

3、 DDOS网络流量,IP源地址是伪装(假冒)IP公有地址

4、 DDOS网络流量,IP源地址是假冒的IP私有地址

对于DDOS正确的反击应该是让正常的客户来访问网站的访问流量还能正常访问网站,而让DDOS网络流量2,3,4在到达网站之前就被拒绝掉。张大民想。但说的容易,到底如何才能实现呢?问题是这样的,虽然大家都是在讲网络流量,但每一个到达网站的其实都是离散的报文。通过分析这些离散报文的内容,是无法知道这个报文是是来自DDOS的源头,还是由正常访问网站的客户发过来的。必须要把离散的报文集合成网络流量。但是如果为每一个源地址都建立一个网络流量的概念,那就要使用很多系统的内存资源来跟踪这些状态,那实际上就很网站处理TCP连接的方法一样了,根本不能应付大流量的DDOS攻击。而且根据网络流量来分析,不能解决的问题是,如果真的是一个网站很流行,象一个时装网站要网络实时直播泳装模特的表演,而几百万人同时登录网站,网站的流量还是很大,几乎可以和DDOS时的网络流量相比,但这些访问都是正常的访问。根据网络流量的分析如何能把它们和DDOS的网络流量区别开来?但到底怎么样才能自动区分正常的网站访问流量和DDOS的网络流量,而同时又不根据IP源地址保存网络流量的状态呢?张大民知道思考到现在,他已经几乎抓到了问题的本质,但就是找不到解决的方法。

“他奶奶的,老子想不出来解决方法,今天就不睡觉了!”,张大民的狠劲儿上来了。但作为工程师的他同时也知道,对一个问题,如果没有解决方法,是因为对这个问题的本质还是没有一个清晰的认识,没有找到问题的根本原因,而被围绕在问题外部的一些表象所迷惑。

“不要想网络流量,也不要想什么DDOS的”,张大民强迫自己,   “应该想一下一个正常的网站访问过程和一个异常的网站访问过程的不同之处”。毕竟,DDOS的网络流量不是要实现一个正常的网页访问过程,而只是要占用服务器的资源。

 “那我先分析一下一个正常网站访问的过程”,张大民想。

正常网站访问过程

.客户:TCP SYN

.服务器:TCP SYNACK

.客户:TCP ACK

.客户:HTTP GET/POST网站网页

.服务器:HTTP网页

那么异常网站的访问过程呢?在通常情况的TCP SYN洪水攻击时,过程如下:

.客户:TCP SYN

.服务器:TCP SYNACK

.服务器:TCP SYNACK

.服务器:TCP SYNACK

.服务器:TCP SYNACK

.服务器:TCP RST

而且张大民注意到,在大多数的DDOS攻击,攻击服务器主机都是被OWN的肉鸡。攻击的工具在这些肉鸡上并不建立一个有效的TCP状态,它们只是拼命向服务器发送TCP SYN的单一报文。所以当服务器发过来TCP SYN ACK时,这些肉鸡上根本没有相应的TCP连接来接收这个服务器发回来的报文,并根据这个报文找到相应的TCP连接状态而发任何有效的报文回去。

“有点意思”,张大民想,张大民敏锐的意识到对TCP状态的理解对于确定是否是有效的TCP链接的重要性。他开始后悔当初在学校读书是没有把TCP的状态图好好理解透彻。

张大民赶紧下载了TCP的状态表。而且在下载过程中,  他又发现了一个非常有效的技术,来保存TCP的状态信息在TCP的系列号(SEQUENC NUMBER)中,叫TCP COOKIE。TCP COOKIE是一个特别的TCP序列号。服务器通过这个序列号,可以恢复这个TCP链接的整个状态信息。这这个发现让张大民有点大喜过望了。这正是他所要的。一个可以判断TCP是否是有效的链接,但又不必保存TCP的状态信息。这样,  一个系统可以验证一个TCP链接是否是有效的链接,但同时又不保存任何TCP的状态信息,等系统验证这个TCP链接是有效的,它可以把这个COOKIE转发给WEB服务器,让WEB服务器从这个COOKIE里面构建原始的TCP状态信息,完成有效的TCP链接。  “而且也可以用某种方法让客户端从新建立一个新的TCP链接,如果客户端肯建立的话,那就说明客户端是一个有效的TCP链接,遵循TCP或者HTTP的协议。而不是一个被OWN的主机,拼命向一台WEB服务器发送TCP SYN报文而不保存任何状态”,张大民思考到这里,感觉到他已经离一个解决方案不远了。通过对TCP和HTTP的近一步分析,在天色蒙蒙亮的时候,张大民终于拿出了第一个验证远程客户端有效性的方案。

首先,一个保护层需要放在客户端和WEB服务器之间,来拦截所有的从客户端发来的TCP SYN报文。在接到TCP SYN报文后,这个保护层要发一个TCP SYNACK回去,TCP的序列好是计算好的TCPSYN COOKIE,根据这个COOKIE,一个完整的TCP状态可以恢复出来。注意这时这个保护层并不保存任何TCP的状态,它在等着客户端是否能送一个TCPACK回来。如果回来,就证明远程客户是一个有效的客户,因为远程客户也和WEB服务器一样,在保存这个TCP的状态。

而且通过对HTTP的分析,张大民在此基础上又加了一道防御。保护层会送回一个HTTP重定向的TCP报文。根据HTTP的RFC的规定,当一个HTTP收到HTTP重定向报文后,它应该中断HTTP和TCP的链接。根据HTTP重定向报文中的内容重新建立新的TCP链接。这样,保护层也验证了HTTP是否是一个有效的HTTP,如果是,就应该遵守HTTP的规定,中断TCP链接,并重新向WEB服务器发布新的TCP SYN链接。

当一台肉鸡向WEB服务器发布TCP SYN洪水工具时,它是不会送任何TCP ACK回来的。如果保护层没有收到这个TCP ACK,就发现了这个源地址来的报文不是正常的报文,以后也不会让这个源地址来的报文通过了。从而达到了过滤DDOS网络流量的目的。

尝到了胜利的喜悦后,张大民也顾不上睡觉,又好好分析了TCP的状态装换图。这次,他主要是找有什么报文能使客户端自动终止一个TCP链接,然后在自动重试的。他发现,大部分应用层的协议,当一个TCP链接出现异常后,通常情况下都要进行重试,在建立新的TCP链接,直到三到四次。这样,当服务生敲门送上早饭的时候,黑客张大民又有了另一个TCP客户有效性验证方案:

这次,当保护层拦截到客户端发布来的TCP SYN报文后,保护层送一个TCP ACK,  而不是TCP SYNACK回去。根据TCP的状态转换图,当客户端接收到这个TCP ACK报文时,客户端认为TCP的链接出了问题,会向服务器端发一个TCP RST的报文来中断目前的TCP链接。而使用TCP的应用层协议,如HTTP通常情况下会重试。如果是一个有效的HTTP客户,而不是一个发送DDOS网络流量的肉鸡,这个客户会重试。保护层会让这个重试的报文通过,而到达正常的WEB服务器。

张大民已经有点崇拜自己了。这个想法就更天才了。这个办法只是拦截TCP SYN,然后送一个TCP ACK回去,如果收不到客户端发回来的TCP RST,那么客户端就肯定是发送DDOS网络流量的肉鸡。如果不是,客户端自己会重新建立另一个TCP链接。而保护层在收到这个客户发来的TCP RST后,会让这个客户的新的TCP链接通过。保持肉鸡的网络流量被掐断,也保证了有效的客户可以正常访问网站。

如果我是做市场的,我就把这个中间层叫作“智能Anti—DDOS防火墙”张大民沾沾自喜的想。

DDOS防护方案的系统实现思路

这个系统设计最核心的思想就是保护层不保留任何TCP的状态信息。正是因为这样,保护层才能比一般的WEB服务器接收流量大的多的TCP网络流量。而且保护层也做到了对正常的网络流量和DDOS的网络流量的区分,保证让正常的网络流量通过,而拒绝DDOS的网络流量到达WEB服务器,从而保证了WEB服务器的资源只服务于正常访问网站的客户。

张大民一边想,一边理顺着自己的思路那么在一个实际运行的网站中,这个系统应该放在哪里呢?最直接的想法就是把这个保护层放在网站服务器的前面,就像一般的企业网把防火墙放在企业网的前面一样。这样,当没有DDOS攻击网站服务器时,保护层就让正常访问网站的网络流量通过。当有DDOS攻击网站服务器时,保护层就启动反击装置,把DDOS的网络流量过滤掉。这样的设计应该是可行的。张大民想。但问题是,在打多数情况下网站都不会遭到DDOS的攻击,把这个保护层一直放在网站服务器前面,接收网络流量,是否有点太浪费了?最好的方法是,通过路由来指导网络流量,当没有DDOS网络流量攻击网站服务器时,让所有的网络流量都不经过保护层,直接到达网站服务器。一旦遭到攻击,就通过路由把所有的网络流量都现转到保护层,让保护层看一下,把DDOS的网络流量过滤掉。

这样的设计应该是比较优化的。张大民在想张大民知道,通过路由自动转移网络流量的方向不是什么困难的技术问题。当网络流量的建模和预警装置发现DDOS网络流量时,象网络中自动插入静态路由或者BGP路由来指导网络流量的方向,这些在现代网络中已经是很常用的技术了。

在这个方案中,保护层首先要对网站的流量进行统计建模。然后保护层一直监视着网络的流量状况,当流量出现异常时,保护层进入反击状态,首先改变访问网站服务器的网络流量的方向,让这些网络流量都首先都经过保护层。保护层就用源地址验证的方法对这些访问流量进行过滤,过滤掉DDOS的网络流量,让正常的网络流量传过保护层,正常访问网站服务器。

看着自己的设计方案,张大民突然想起了雷锋同志日记里的话。 “对待同志要像春天般的温暖,对待工作要像夏天一样火热,对待个人主义要像秋风扫落叶一样,对待敌人要像严冬一样严酷无情。”

这也正是DDOS反击系统设计的准则之一啊,张大民不禁笑出声来:

“对待正常的网络访问流量要像春天般的温暖,对待访问网站的客户要像夏天一样火热,对待被利用的肉鸡要像秋风扫落叶一样,对待真正的DDOS网络流量要像严冬一样严酷无情。”

而且雷锋同志的这些可都是要手工去实现的。DDOS反击的方法必须是全自动化。

结束语

张大民站起身来,  心中充满了工作的喜悦。这也正是他为什么热爱网络安全工作的原因之一。网络安全领域充满了挑战性。魔高一尺,道高一丈。亦或道高一尺,魔高一丈。攻防之间此消彼长,永远是在动态之中在寻找平衡。

张大民正高兴着,突然间一个想法又击中了自己。自己光顾考虑TCP了,那么哪些基于UDP的应用,如果遭到了DDOS的攻击该怎么办呢?张大民又开始挠脑袋了。因为他知道,同TCP不同,UDP是没有状态的,就和IP一样。UDP和IP唯一的区别就是UDP提供了应用层的端口。而他这两天冥思苦想出来的解决方案完全不适合UDP,因为自己的解决方案是以TCP的状态图为根据的。这个就更难了。难道自己又要闭关一次不成?但张大民心里已经有了些准备。因为通过这两天的思考,他知道,验证一个客户主机是正常的主机,还是被OWN的肉鸡被用来发动攻击,关键就是看远程的客户主机是否遵循RFC的协议来运作。如果是,那就基本上是正常的主机。否则,就很有可能是被OWN的肉鸡。应该还是有办法的,张大民暗想。

 

黑客张大民之大民治水-DDOS反击方法浅论(1)

 

下载本期杂志

<< 返回测试杂志首页