作为一个酷爱钻研网络技术黑客，张大民在遇到了技术难题时，最喜欢的办法就是要闭关，要排除一切干扰，一天24小时什么也不想，就是要把难题解决出来。有点象一休要挠脑袋打坐一样。
这次张大民也不例外，他上网订了一个酒店房间，要在这个周末全心全意考虑这个问题。入住酒店后，张大民关掉手机，切断电话，只叫服务生来送饭，开自己对于DDOS的思考。
正常与异常网络流量建模
如果需要在几秒钟内作出反应，不但要预警，还要对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的近一步分析，在天色蒙蒙亮的时候，张大民终于拿出了第一个验证远程客户端有效性的方案。
图 3
首先，一个保护层需要放在客户端和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服务器发布新的TCPSYN链接。
转截请注明:文章来自 pc捍卫者 http://www.pchwz.com
本站发布此文为传递更多信息之目的,不表明pc捍卫者赞同其观点
