让子弹多飞一会 | 论如何优化DDoS

假设1枚炮弹击中目标的伤害为10,而4枚炮弹同时击中目标的伤害为200。现在我方只有一门火炮,4枚炮弹。此火炮每次只能发射一枚炮弹。问如何操作可以使其伤害达到200?

答案是”让子弹多飞一会儿”,不过这个回答不是来自姜文的电影,而是源于美军在二战中提出的 MRSI (Multiple Rounds Simultaneous Impact)技术,粗糙的翻译一下就是“发射多次却同时命中”。

我们知道炮弹飞行的时间取决于开炮时的发射仰角,比如仰角大于45度时,炮弹的飞行的长度和时间比仰角小于45度要长。那么我们就可以采用MRSI 技术,以从大到小的发射仰角,连续发射4次。

这样第一次发射的炮弹飞行时间最长,最后一次发射的飞行时间最短。只要我们精确的计算好角度和发射的时间间隔,就有可能让4枚炮弹同时击中目标,从而造成200的伤害。

简而言之,就是利用炮弹的飞行时间差来弥补发射的间隔时间。

Ryan Rasti在Temporal Lensing and its Application in Pulsing Denial-of-Service Attacks一文中提出了一种利用网络延迟来增强DDoS攻击效果的方法。以DNS放大攻击为例。

假设攻击者选择了两个DNS 服务器(A和B)来攻击目标, 已知A到目标的网络延迟为110毫秒,B到目标的网络延迟为40毫秒。而攻击者到A和B的延迟忽略不计。那么攻击者可以先给A发一个假冒的DNS请求,让A反射目标。

略等70毫秒以后(110-40=70毫秒),攻击者再发给B请求,让B反射目标。这样,虽然攻击者的两个DNS请求不是同时发出的,但是反射出来的攻击消息却可以同时击中目标。如下图所示:

这么做的好处是什么呢?当然是提高了DDoS的效率,攻击者的发报率是1包/70毫秒,而在某个时间点却有2个反射包击中目标。

这相当于巧妙的利用了网络延迟而把所有的攻击包汇聚在某一个特定的时间点上。例子中只用到了2个DNS服务器,但是在实际攻击中,可以扩展到n个。

攻击方式也不仅限于DNS放大攻击,用http 代理的CC攻击也可以。

优化过的DDoS步骤是

1.假设有n条线路(取决于具体的攻击方法,可能有n个DNS服务器,n个http代理等等),攻击者先测量出每条攻击路线的延迟, 对应记为 (L1,L2,…,Ln)。 2.从(L1,L2,…,Ln)中找出最大延迟,记为Lmax 3. 对于路线i(1≤ i ≤n),攻击者在发送前须等待 Lmax-Li

普通的DDoS是拼命打,有多少打多少。这样的结果是数据包击中最终目标的时间是平均分布的,如下图所示:

而优化过的DDoS应该是这样的:

然而为了成功的优化DDoS,我们还必须得解决一个首要问题,如何测量网络延迟。 对于HTTP CC类攻击来说比较简单,攻击者配制好代理,对攻击目标发一个http请求,接收http响应,就可以得到请求往返时间,然后用这个请求往返时间来估算网络延迟。

当然,在实际情况中,网络延迟取决于很多因素,还需要用不同的方法降低噪音带来的影响,比如多次测量取平均值等等。

对于DNS放大攻击,一般用King测量法。

比如攻击者(A)打算用DNS服务器D来攻击目标T。然而,直接测量 A经过D到T的网络延迟 (LADT)是很难的。但是,我们可以利用DNS递归查询的特性,测量出 A经过D到T的DNS服务器 的网络延迟(LADT(DNS))。

方法是让A对D发一个关于T域的DNS查询,在这种情况下D会向T的DNS服务器递归查询。从而该攻击者可以用此DNS请求往返时间来估算LAT(DNS)。一般来说, DNS服务器都在离其他服务器很近的地方,延迟差别可以忽略不计,因此LAT ≈ LAT(DNS) 。

比如攻击者打算利用google DNS (8.8.8.8)来攻击test.com的web 服务器。为了优化,攻击者需要先知道他到8.8.8.8再到test.com web服务器的延迟。

怎么计算延迟呢? 攻击者可以给8.8.8.8发送一个DNS查询:[随机子域].test.com 。由于8.8.8.8 并不负责test.com子域名,它只能递归询问test.com的DNS服务器。test.com的DNS服务器收到该询问以后,会进行本地记录查询。

因为该子域是随机产生的,所以肯定会返回找不到啦,8.8.8.8收到回答以后,会再把这一回答继续转发给攻击者。

这样攻击者就可以计算出他到8.8.8.8再到test.com DNS服务器的延迟。由于一般DNS服务器都在离WEB服务器很近的地方,因此可以推算出到8.8.8.8再到test.com web服务器的延迟。

为什么查询的时候要使用随机子域呢?是为了防止查询结果被cache缓存。如果查询结果被缓存了,那么DNS服务器就不递归查询了,从而导致测量结果不准确。

参考资料

1.Ryan Rasti et al., Temporal Lensing and its Application in Pulsing Denial-of-Service Attacks, IEEE S&P 2015

2.GUMMADI, K. P., SAROIU, S., AND GRIBBLE, S. D. King: Estimating Latency Between Arbitrary Internet End Hosts. In Proc. ACM Internet Measurment Workshop (2002)

* 作者:nickchang,本文属FreeBuf原创奖励计划文章,未经许可禁止转载

本文分享自微信公众号 - FreeBuf(freebuf)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-06-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

DNS迭代穷举脚本

在普通的DNS穷举中,如果使用字典进行穷举,会发现没有哪个字典能穷举完所有的域名,国外安全研究者在常年累月的DNS记录收集中发现,很多域名有大量的短主机名,并且...

30590
来自专栏IT技术精选文摘

负载均衡详解

面对大量用户访问、高并发请求,海量数据,可以使用高性能的服务器、大型数据库,存储设备,高性能Web服务器,采用高效率的编程语言比如(Go,Scala)等,当单机...

79190
来自专栏张善友的专栏

C#实现DNS解析服务和智能DNS服务

C#实现DNS解析服务有一个开源项目ARSoft.Tools.Net, ARSoft.Tools.Net是一个非常强大的开源DNS控件库,包含.Net SPF ...

31250
来自专栏FreeBuf

“DNS隧道”盗号木马分析

盗号木马相信大家都不陌生。随着网络越来越普及,网上的账号密码越来越重要,盗号木马的生命力也就越发的顽强了。 随着与杀毒软件的对抗,盗号木马也在不断的更新换代。Q...

287100
来自专栏向治洪

xmpp即时通讯三

6.1 概述       XMPP包含一个认证流的方法,此方法依靠一个简单认证与安全层(SASL)协议[SASL]的XMPP-specific profile...

27170
来自专栏FreeBuf

集齐7把钥匙,掌控全球互联网DNS

很少有人知道,庞大的互联网系统背后隐藏着一个神秘的组织,这个神秘组织的成员是来自世界各地的网络安全专家,他们手中的钥匙可以组合成控制DNS系统的主钥匙,可以影响...

26350
来自专栏F-Stack的专栏

F-Stack与Seastar对比

本文是将知乎网友的提问 《如何评价腾讯开源的基于 DPDK 和 BSD 协议栈的网络框架 f-stack?》,将回答讨论内容和我们的一些想法进行了整理。 项目背...

71490
来自专栏FreeBuf

DNS污染事件跟踪:为什么.cn和.org域名逃过一劫

关于中国境内用户访问.com 和.net 域名被解析到65.49.2.178 一事我又有新发现,我发现了为什么.cn 和.org 的域名没有受到影响指向65.4...

94360
来自专栏前端黑板报

(1)当你输入URL到页面显示经历了什么--URL到IP地址

这是一个经典的问题,能区分知识的广度与深度,从回答的侧重点上甚至能区分出工种(前端、后端、运维等)。开发人员基本上都能说出几点,而牛人更可在自己...

238100
来自专栏FreeBuf

黑暗搜索引擎Shodan Chrome插件

今天小编为各位推荐的是Shodan Chrome插件,它可以自动探测网站所属的国家、城市,谁是这个网站IP的主人以及其开放的服务和端口,包括FTP、DNS、SS...

373100

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励