利用HTTP进行拒绝服务攻击的一些构思

ZDNet软件频道 时间:2009-11-04 作者: | 中国IT实验室 我要评论()
本文关键词:入侵 攻击防范 拒绝服务攻击 Windows
由于HTTP协议是基于请求/响应范式的(相当于客户机/服务器)。一个客户机与服务器建立连接后,发送一个请求给服务器,请求方式的格式为:统一资源标识符(URL)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后,给予相应的响应信息,其格式为一个状态行,包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息包括服务器信息、实体信息和可能的内容。

  由于HTTP协议是基于请求/响应范式的(相当于客户机/服务器)。一个客户机与服务器建立连接后,发送一个请求给服务器,请求方式的格式为:统一资源标识符(URL)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后,给予相应的响应信息,其格式为一个状态行,包括信息的协议版本号、一个成功或错误的代码,后边是MIME信息包括服务器信息、实体信息和可能的内容。

  留意这行文字:“服务器接到请求后,给予相应的响应信息,其格式为一个状态行”,这是HTTP协议的一个重要特性,我们可以做个实验:

  用TELNET或任何一个能建立HTTP连接的程序连接到某服务器的80端口,手工输入:

  GET /index.htm HTTP/1.0(必须确保这个工具能自动产生两个换行符,否则服务器会认为你没有输入完全!)

  如果index.htm存在,你会看到类似以下的报文:

  HTTP/1.1 200 OK

  Server: Microsoft-IIS/5.0

  Content-Location: http://www.******.com/index.htm

  Date: Sat, 20 Jul 2002 23:32:03 GMT

  Content-Type: text/html

  Accept-Ranges: bytes

  Last-Modified: Wed, 03 Jul 2002 09:50:05 GMT

  ETag: "8e2ba27722c21:850"

  Content-Length: 3292

  这是正常的访问方法,但是如果我们胡乱输入请求呢?看:

  HTTP/1.1 400 Bad Request

  Server: Microsoft-IIS/5.0

  Date: Sat, 20 Jul 2002 23:37:59 GMT

  Content-Type: text/html

  Content-Length: 87

  The parameter is incorrect.

  呵呵,HTTP 400 - 错误请求,其实就是HTTP语法错误,服务器老老实实给我们返回了。

  可以得出结论:无论你输入了什么,服务器根据HTTP协议,总会返回信息

  通常用得最多的DOS方法主要有SYN、Smurf、Land、TearDrop等,其中SYN的资料如下(抄来的资料~~呵呵)

  假设一个用户向服务器发送了SYN报文后突然死机或掉线,那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成),这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接,这段时间的长度我们称为SYN Timeout,一般来说这个时间是分钟的数量级(大约为30秒-2分钟);一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题,但如果有一个恶意的攻击者大量模拟这种情况,服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源----数以万计的半连接,即使是简单的保存并遍历也会消耗非常多的CPU时间和内存,何况还要不断对这个列表中的IP进行SYN+ACK的重试。实际上如果服务器的TCP/IP栈不够强大,最后的结果往往是堆栈溢出崩溃---即使服务器端的系统足够强大,服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求(毕竟客户端的正常请求比率非常之小),此时从正常客户的角度看来,服务器失去响应,这种情况我们称作:服务器端受到了SYN Flood攻击(SYN洪水攻击)。

  而Smurf、TearDrop等是利用ICMP报文来Flood和IP碎片攻击的。

  但是以上的DOS方法的目的无非都是让服务器大量消耗资源和超时连接,那么除了超时连接,能不能用“正常连接”的方法来产生拒绝服务攻击呢?

  再来看看19端口的定义:

  字符产生器协议(Character Generator Protocol)

  字符产生器服务器一个有用的调试工具。无论接收到的是什么,它都返回特定的数据。

  基于TCP的字符产生器服务

  此服务可以是一个基于TCP的服务,TCP端口19是用于此服务的。一旦连接建立,服务器会传送一个字符流。接收到的信息会被抛弃。字符流会在用户请求下中止。用户可能会非正常中止一个连接,因此此服务必须准备处理这种情况。传输的速度会由TCP流控制机制负责,用户不必关心数据太快,而用户来不及处理。

  19端口在早期已经有人用来做Chargen攻击了,即Chargen_Denial_of_Service,但是!他们用的方法是在两台Chargen服务器之间产生UDP连接,让服务器处理过多信息而DOWN掉,那么,干掉一台WEB服务器的条件就必须有2个:1.有Chargen服务 2.有HTTP服务

  实际上,现在是无法找到这么多同时开放两个这两个服务的服务器的。

  看看开头的HTTP协议特性,和Chargen比较一下,你发现了什么?哈哈~~~没错!一个是无论接收到什么报文都会回应,一个是一旦连接建立就会发送报文,看看示意图:

  发送请求------------------------------------->

  客户端----------------------------------------------------------服务器

  <-------------------------------------------回应

  如果把客户端改为Chargen,就是以下情况:

  字符流--------------------------------------->

  Chargen----------------------------------------------------------服务器

  <-----------------------------------400 Bad Request

  也就是说,这两者会产生利害冲突,可以这样比喻:两个人吵架,你骂一句,他还一句,这就是循环过程,除非有一方停止或第三者干涉,否则这将是个Do...Loop循环!

  搬到HTTP和Chargen来说,就是因为这两者的特性正好天生一对,那好,就从这里下手:

  攻击者伪造源IP给N台Chargen发送连接请求(Connect),如有必要还可以发送(Send)个“Fuck you”报文过去,Chargen接收到连接后就会返回每秒72字节的字符流(实际上根据网络实际情况,这个速度更快)给服务器,HTTP协议处理这个报文时当然会识别为400 Bad Request而返回一条错误说明给它,接下来的情况嘛………………自己发挥想像力,别问我。

  我用自己的机器(640 kbps ADSL)+VB Winsock程序做测试,只用了3秒钟,程序就因为内存溢出而崩溃了(主要是TextBox的问题,它接受文本的最大范围为64KB),就是说,3秒钟内Chargen就发送了大于64KB的字符流!如果用大于10台的Chargen一起发起攻击,其速度足以大量消耗服务器资源和带宽。

入侵

攻击防范

拒绝服务攻击

Windows

用户评论
用户名
评论内容
发表时间
ZDNet网友
2011-03-18 14:57:01
ZDNet网友
2010-05-21 00:49:14
ZDNet网友
2010-05-21 00:48:00
ZDNet网友
微软应该对自己的用户负责,如果用户完全使用xp升级微软win7,为什么要付出这样麻烦的代价?都是微软出品软件,且都是利用该软件获取信息以及处理文字、多媒体功能,微软应该尽可能方便用户!虽然有时候这样的请求也许跟不上时代技术发展的脚步,但是微软不要以此为借口,认为一切都理所应当,就不可以方便用户。还是要尽力,所谓拿人手短吃人嘴软,商业不正是讲求有商道吗!至少做人需诚实守信,尽可能帮助用户顺利、安全转换操作系统、各种必须软件功能尽可能兼容以及信息尽可能的少丢失!虽然这很大程度仅仅取决于微软等计算机专家、工程师的自我自律约束,我们普通用户恐怕很难知道微软究竟仅了多大力量为用户考虑,但是我相信真相会有被发现的一天,无论多久远。 微软从某种意义上来说,就是一个类似“掌握魔方”操作特别出神入化的公司。几乎奠定了电脑主要的“规则”,但是,我却相信不久将来我们会发现,电脑依然是非常有限的一个小系统而已!随着我们新的关键材料认知突破,电脑系统会真正被另一个革命性新电脑系统所取代,不要以为我这样的说法是无稽之谈不可实现,我却认为很有可能,只看这样的情况发生究竟是快还是慢,是早还是迟!变成历史的小玩具之后的电脑系统,微软会留下良好的历史声名吗?我们拭目以待! 网友::我爱佛祖
2010-02-03 13:52:55
- 发表评论 -
匿名
注册用户

百度大联盟认证黄金会员Copyright© 1997- CNET Networks 版权所有。 ZDNet 是CNET Networks公司注册服务商标。
中华人民共和国电信与信息服务业务经营许可证编号:京ICP证010391号 京ICP备09041801号-159
京公网安备:1101082134