内容简介：我们在之前的文章中已经提及，Memcache DRDoS 自从被360 0kee team首次公开批露以来，在过去的9个月中在网络上都不活跃。但是最近十天以来，Memcache DRDoS 在现网中的攻击越来越频繁，所制造的攻击流量也在不断刷...
我们在之前的文章中已经提及，Memcache DRDoS 自从被360 0kee team首次公开批露以来，在过去的9个月中在网络上都不活跃。但是最近十天以来，Memcache DRDoS 在现网中的攻击越来越频繁，所制造的攻击流量也在不断刷新，当前最新的公开记录已经到了 1.7Tbps 。
关于这种攻击方式，目前还有很多问题等待回答。例如，到底已经有多少受害者、攻击中所使用的反射点到底有多少、实际发生的反射放大倍数是多少，等等。通过回答这些问题，我们可以充分描述当前总体态势，有助于安全社区理解这种新的DDoS攻击方式。
为此我们在 Memcache DRDoS 在 DDoSMon 上建立了一个 实时页面 ，展示我们看到的相关DDoS攻击情况，供安全社区参考。
总体趋势
上面两图展示了每天中发生的攻击事件次数。可以看出，从2018-02-24开始，这种攻击在几天内快速发展。我们暂且将时间划分为下面这些阶段：
~ 2018-02-24 之前，每日平均小于 50 起攻击事件
第一阶段：02-24 ~ 02-28，每日平均 372 起攻击事件
第二阶段：03-01 ~ 03-07，每日平均 1758起攻击事件
03-06，今天已经发生 721 起攻击事件，还有12个小时结束，后续发展还有待观察
上图是每日活跃（即实际参与了攻击的）的反射点数量。从2018-02-24 快速增长以后，每日活跃的反射点数量一直稳定。
我们还挑选了 03-07 当天的15k个活跃反射点进行了实际测试。其中 15% 的反射点回应了我们用来探测的stats命令，确实拥有参与实际攻击的能力。15% 这个比例看起来比例较低，考虑到可能当前这些服务器的带宽已经接近耗尽或者接近ISP设定上限，也许需要多次测量来确认实际情况。
受害者案例
在过去这些天中，已经有一些主要的网站成为这种攻击方式的受害者。例如，github 在 2018-02-28 17:20 GMT附近，遭遇了一次DDoS攻击，其流量峰值达到 1.3Tbps，或者126.9mpps（百万包/秒）。 akamai 和 github 均发布了文档描述此事件。
在 DDoSMon 上，我们能看到 www.github.com 这个域名在2018-03-01 和 2018-03-02 遭受了两次攻击，前者就是上文提到的那次攻击：
受攻击IP：192.30.252.113
发生时间：分别是 IP在 2018-03-01 14:26:22 和 2018-03-02 01:13:44 （GMT +8）
来源端口：流量集中在 UDP 11211 源端口上
攻击类型：被 ddosmon 标注为udp@attack@amp_flood_target-MEMCACHE
实际攻击中使用到的 memcache stats 指令并不能制造 50k 的放大倍数
我们为这种攻击方式搭建了服务蜜罐，并采集到了超过 37k 次攻击指令（请求包）。
如下表所示，99% 的攻击指令都是基于 memcache stats 指令。
我们在上一篇文章中提到，我们对实际环境中的实际放大倍数做了测试。在那个测试中，我们利用 stats 指令能获得的放大倍数在几十倍左右。
受害者列表
这7天中，我们的DDoSMon平台记录了：
10k 次攻击事件
7131 个受害者IP地址
为了使得结果更加可读，我们使用了PDNS 数据把受害者IP映射回他们的域名。这些IP中，有 981(13%) 个最近一周内有过域名解析，有1.5k(22%) 个历史上有过域名解析。
我们将这些有DNS域名解析的受害者，分别选择位于Alexa和float排名前1百万的，制作了两个列表。
下面是位于 Alexa 排名前1百万的受害者。需要指出我们只保留了SLD而非全部FQDN，所以表格中虽然列出了 a.com ，但实际上受攻击的可能是 xyz.a.com。
target_ip rank belongs to sld 59.37.97.93 9 qq.com 182.254.79.46 9 qq.com 36.110.213.82 21 360.cn 216.18.168.16 32 pornhub.com 192.30.255.113 74 github.com 192.30.253.125 74 github.com 192.30.253.113 74 github.com 192.30.253.112 74 github.com 151.101.128.84 80 pinterest.com 104.155.208.139 112 googleusercontent.com
下面是位于 float 排名前1百万的受害者。float 是我们内部的一个工具，主要使用中国大陆地区访问数据评估域名流行度。使用float排名时的一个好处是该排名基于FQDN，这样我们就不需要再次映射到 SLD，这样比较方便。
target_ip rank fqdn 115.239.211.112 12 www.a.shifen.com 182.254.79.46 21 mp.weixin.qq.com 59.37.97.93 464 pingma.qq.com 114.80.223.177 587 interface.hdslb.net 47.91.19.168 587 interface.hdslb.net 222.186.35.81 587 interface.hdslb.net 114.80.223.172 587 interface.hdslb.net 140.205.32.8 867 sh.wagbridge.aliyun.com.gds.alibabadns.com 114.80.223.177 1052 bilibili.hdslb.net 47.91.19.168 1052 bilibili.hdslb.net
观察这个列表可以看到一些有意思的受害者，例如：
有些大网站本身就经常被攻击，例如 360, amazon, google, qq, 等等
有些网站是游戏行业的，例如 minecraft.net, playstation.net, rockstargames.com ，等等
有些网站是色情行业的，例如 homepornbay.com, pornhub.com
有些网站是安全行业的，例如 360.cn, avast.com, kaspersky-labs.com
一些政府相关网站，例如 epochtimes.com, nra.org, nrafoundation.org ,racarryguard.com
还有那个总是可以看到最新攻击的:) krebsonsecurity.com
下面是受害者的地理分布：
以及ASN 分布：
总体而言，当前的受害者主要集中在美国、中国（含中国香港）、韩国、巴西、法国、德国、英国、加拿大、荷兰。
这些攻击事件中涉及的反射点/memcache 服务器
在继续分析这些攻击事件中涉及的反射点之前，我们必须指出：
这里所涉及的反射点，均“已经”在真实攻击中被使用，而非“可能”存在被利用的隐患
由于我们数据来源的地缘性限制，我们会看到中国区相关的数据较多，世界其他区域的数据相对较少
通过对所有反射点的分析，我们发现共有 62k 个反射点已经参与真实攻击事件。其中前20 的ASN 列表如下：
这些排名最靠前的20个ASN也仅能覆盖大约 53% 的活跃反射点，还有大约29k(47%)的反射点分布在其他 2.8k 个ASN中，如下表所示：
因此：
尽管前期有若干主要电信运营商已经在 UDP 11211 上做端口限速，为后续所有动作争取了时间
但是 memcache 服务器的分布较广，很难想象全部 4.8k 个ASN 均采取限制措施。
仍然需要memcache 服务的开发者、发行者、使用者做工作，才能关闭掉这些反射点。
在文章的结尾，我们很高兴的注意到 memcached 的服务的开发者已经在 3月3日，提交 代码 缺省关闭了 memcache 的UDP监听端口。
原文：netlab
【声明】文章转载自：开源中国社区 [http://www.oschina.net]
以上所述就是小编给大家介绍的《Memcache UDP 反射放大攻击 II: 最近的数据分析》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- Go语言反射之反射调用
- Go语言反射之类型反射
- Go语言反射之值反射
- 模块讲解----反射 (基于web路由的反射)
- 装饰器与元数据反射（4）元数据反射
- .NET/C# 反射的的性能数据，以及高性能开发建议（反射获取 Attribute 和反射调用方法）
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Spring
Bruce Tate、Justin Gehtland / O'Reilly Media, Inc. / 2005-04-12 / USD 29.95
Since development first began on Spring in 2003, there's been a constant buzz about it in Java development publications and corporate IT departments. The reason is clear: Spring is a lightweight Java......一起来看看 《Spring》 这本书的介绍吧!
