Memcache UDP 反射放大攻击技术分析

周其
 周其
发布于 2018年03月12日
收藏 9

本篇技术blog,由360信息安全部0kee Team、360网络安全研究院、360-CERT共同发布。

Memcache UDP 反射放大攻击(以下简称 Memcache DRDoS)在最近的一周里吸引了安全社区的较多注意。以下介绍我们对该类型攻击观察到的情况。

在PoC 2017 会议上的原始报告

Memcache DRDoS,由360信息安全部0kee Team在2017-06 附近首先发现,并于 2017-11 在 PoC 2017 会议上做了公开报告。会议报告在 这里,其中详细介绍了攻击的原理和潜在危害。

在这份文档中,作者指出这种攻击的特点:

  • memcache 放大倍数超高,至少可以超过50k;

  • memcache 服务器(案例中的反射点)数量较多,2017-11时估算全球约有 60k 服务器可以被利用,并且这些服务器往往拥有较高的带宽资源。

基于以上特点,作者认为该攻击方式可以被利用来发起大规模的DDoS攻击,某些小型攻击团队也可能因此获得原先没有的大流量攻击能力。

在 DDoSMon 上观察到的现网趋势

自批露以来,我们就一直利用 DDoSMon 的统计页面 持续监控Memcache DRDoS在实际现网中的情况。在过去的几个月中,这种类型攻击的频率和单次破坏性都不大,但是自2018-02-24开始,这种情况发生了较大变化。

近期,Memcache DRDoS 的攻击频率上升到了平时的10+倍,从每天小于50件,上升到每天300~400件,直到今天的1484件(实际上,离今天结束还有1个小时),如下图所示。

需要指出,当前 Memcache DRDoS 仍然还不是DDoS的主流。即使在反射类DDoS中,也只占 1% 以下(按攻击事件计),排在 DNS、CLDAP、NTP、SSDP、CharGen、L2TP、BitTorrent、Portmap、SNMP的后面。

我们在现网中对 Memcache DRDoS 攻击方式的测试结果

我们对现网实际环境做了测试,结合分析我们捕获的实际攻击载荷,有以下内容值得关注:

  • 这种反射攻击的放大比率,在理想的测试环境中,可以稳定的测得 1k~60k之间的放大倍数;

  • 在现网实际环境中, 60k 的放大倍数,也是可以稳定的测得的;

  • 上述实测结果,与最初报告者0kee team的估计、US-CERT安全通告中的提法,基本是一致的;

  • 此外我们分析了现网实际发生的攻击负载。到目前为止,部分负载的构造是有问题,可能会导致memcache服务崩溃,并不能稳定的打出最大放大倍数。但是这里涉及的技术改进并不困难,攻击者容易做出响应调整。

另外,我们对将放大倍数调整到 60k 以上做了一些初步分析。我们怀疑这个比例是可以继续显著提高的,但具体技术细节不会在这里讨论。

当前已知 Memcache DRDoS 攻击的案例

2月27日,Qrator Labs 在 medium.com 上 批露 了一次DDoS攻击。按照文章的说法,这次攻击确信就是 UDP 11211 端口上的 memcache DRDoS,攻击流量峰值达到 480Gbps。

除了这个案例以外,我们确认有更大的攻击已经实际发生,但并未被公开报道。

当前已知各国运营商、安全社区的应对措施

目前已经有多个相关安全通告,部分列出如下:

  • 通告类:多个主要设备厂商、安全厂商、CERT已经发布通告,例如 CloudFlareQrator LabsArbor NetworksUS-CERT,等等

  • 预防和防御类:包括 NTT 在内的多个ISP 已经对 UDP 11211 采取限速措施。

应对建议方面,ISP、网络管理员、企业用户可以从很多渠道获得应对建议,例如 这里 。我们建议:

  • 各运营商 ISP、云服务厂商,考虑在自己的网络内对UDP 11211 采取限速措施

  • 各开发者和 memcache 管理者,考虑自查 memcache 设定ACL

总体而言,一方面,我们开始担忧1Tbps以上的DDoS攻击案例今后会比较频繁的出现,DDoS攻击开始从 G 时代进入 T 时代(Gbps vs Tbps);另一方面,我们必须指出至少在当前 Memcache DRDoS 还不是DDoS 攻击的主流,比例还在 1% 以下(按次数统计)。

来自:netlab

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Memcache UDP 反射放大攻击技术分析
加载中

精彩评论

ddatsh
ddatsh
还以为是POC分析。。 啥也没有啊
clouddyy
clouddyy
都是些什么二逼运维开放memcache

最新评论(8

clouddyy
clouddyy

引用来自“clouddyy”的评论

都是些什么二逼运维开放memcache

引用来自“gaolongquan”的评论

更多的都是开发没有安全意识导致的

引用来自“clouddyy”的评论

我们的业务系统上线之前,运维人员都会做二次安全检查的

引用来自“gaolongquan”的评论

很多个人开发者都是直接跑脚本上去的,并没有运维人员参与,就连YUM安装的MEMCACHE都是监听所有端口的。
嗯,活该被刚~
gaolongquan
gaolongquan

引用来自“clouddyy”的评论

都是些什么二逼运维开放memcache

引用来自“gaolongquan”的评论

更多的都是开发没有安全意识导致的

引用来自“clouddyy”的评论

我们的业务系统上线之前,运维人员都会做二次安全检查的
很多个人开发者都是直接跑脚本上去的,并没有运维人员参与,就连YUM安装的MEMCACHE都是监听所有端口的。
clouddyy
clouddyy

引用来自“clouddyy”的评论

都是些什么二逼运维开放memcache

引用来自“gaolongquan”的评论

更多的都是开发没有安全意识导致的
我们的业务系统上线之前,运维人员都会做二次安全检查的
gaolongquan
gaolongquan

引用来自“clouddyy”的评论

都是些什么二逼运维开放memcache
更多的都是开发没有安全意识导致的
eechen
eechen

引用来自“ddatsh”的评论

还以为是POC分析。。 啥也没有啊
连事后诸葛亮都不如
ddatsh
ddatsh
还以为是POC分析。。 啥也没有啊
宇润
宇润
监听0.0.0.0也是666
clouddyy
clouddyy
都是些什么二逼运维开放memcache
返回顶部
顶部