0x00 关于DRDOS反射***

作为DDOS，也有各种流派，有大力出奇迹的DDOS远控集群，有以巧取胜的反射放大，也有精巧的LOT僵尸网路。这里我们只讨论udp反射DRDOS.

DRDOS靠的是发送大量带有被害者IP地址的UDP数据包给放大器主机，然后放大器主机对伪造的IP地址源做出大量回应，形成分布式拒绝服务***。 ***往往会选择那些响应包远大于请求包的udp服务，这样就可以四两拨千斤。

***流程

要完成一次反射放大***：可以简化成下面三个环节。

作为***者，需要伪造IP。发送海量伪造来源的请求。未采取BCP38的机房。(firewall rules and uRPF)

作为反射服务器：需要满足2个条件，第一上面运行着容易放大的udp协议，指的就是那些使用不当或设计不当的udp服务，能够满足特定条件下，响应包远远大于请求包。第二个条件就是，该协议或服务在互联网上有一定的使用量，比如dns，ntp等基础服务。

受害者，由于ddos的意图，受害者一般是金融，游戏，政治等目标。不过也有单纯搞破坏或炫技的。

常见协议

上图是近三个月来，打反射ddos比较流行的协议，数据来源于360网络安全研究院。 可以看到，NTP，DNS等古老的协议，依然占据反射ddos的半壁江山。 这里比较新颖的是9.29号时，cldap的***数量暴涨，且大部分***的来源端口都是26383。所以有可能是地下***的一次实战测试，或是地下市场的ldap***工具开始流传.

***强度

上图是近年来比较大型的DRDOS***数据，可以看到放大的流量是越来越大，现在是动辄上百G，而放大的协议有DNS,NTP等古老的协议，也有比较新型的SSDP,CLDAP,MSSQL等。

但***强度是怎么计算的呢？决定因素又是什么？

一般是用pps和bps这2个指标来比表示DDOS的***强度。

pps: packets per second (每秒的数据包个数，主要是消耗服务器，网关，路由等设备的CPU性能)

bps: bits per second (每秒的带宽量，单位是小b，主要是消耗带宽，通常约定按bps表示强度)

比如阿里云被D，发现有邮件告诉你遭到了5G的混合DDOS，已友情将你的ip黑洞。 而腾讯云被D，有时候会短信告诉你遭到了100wPPS的DDOS，已友情将你的服务器进行清退。

而对DRDOS的***强度，主要是由放大器数量和放大强度决定的。

$$BPS = Amplifiers * Amplification Factor ( 1 )$$

我们这里有个不严谨的公式，就是Spoof带宽不受限制时，单一DRDOS的***强度和放大器数量乘以平均放大倍数成正相关的。

放大系数(Amplification Factor)

根据我们上面的公式，***流量是由放大倍数和放大器的数量决定的。 我们先看一看常见协议放大倍数。 NTP，557倍，CHARGEN 358倍，DNS和LDAP都是50倍左右，ssdp是30倍。 但这些放大倍数，是怎么得出的呢？下面我们简单分析下背后的原理：

1. ntp是123端口校对时间的服务。放大参数是monlist，主要用于监控 NTP 服务器，可以同步的最后 600 个客户端的 IP，响应包是请求包的500多倍。所以放大倍数就是响应包大小／请求包大小。(也有另外一种计算方法，传输层的大小也计算进去)

2. 而Ldap是未授权的用户，可执行一些基本的请求，如查询组织机构，最后造成了55倍的放大效果。

放大器数量(Amplifiers)

上图是全网不同类型的的放大器数量。数据来源于某机构，扫描时间是今年10月。 放大器千万级的有sip，百万级的有dns.ntp,rpc,ssdp等。

结合之前实际***比例可以发现，ntp和dns由于海量的分布，所以***占比非常高。 而分布较少的ldap，mssql等，由于出色的放大倍数和优良的网络，实际***也有不错的效果，

***策略和条件

结合前面的数据，我们可以发现，实际***要么是利用放大倍数高的协议，要么是用分布广泛的基础服务。通过监控放大器数量和更新放大倍数(比如新型协议支持,DNS的edns)，我们就可以得到大概的***强度.

为了提高反射放大的流量。我们可以采取以下策略。

我们可以研究那些通用的UDP协议，这样就可以获取海量的放大器。

然后就是挖掘放大倍数高的协议，这样就可以以最小的成本获得最好的反射效果。

当放大器和放大倍数都到达瓶颈后，我们就需要更高的带宽来发送伪造请求包，这里可以全球分散部署这些服务器。

0x01 关于Memcache

定义

Memcached它是基于一个存储键/值对的内存对象缓存系统，常用于动态Web应用以减轻数据库负载。性能优越，在互联网上使用量巨大。

常见***面

从协议看，memcache同时监听tcp和udp。且数据接口容错性强，tcp上有很多***f***的案例。另外由于支持udp，天然满足了反射ddos***条件。

另外我们注意到：memcache大部分是作为企业应用的组件，常常具有很高的上传带宽。

而最重要的是memcache不需要认证就可以随意交互。

而很多用户编译安装时，错误的监听了0.0.0.0,且未设置iptables或云安全组。

放大系数

在我们的调试之下，memcache的放大倍数可以稳定在5w倍以上，最高达到50w倍。

***链

扫描端口和服务

抓取指纹，获取未认证的memcache

过滤出可以反射回来的udp memcache

0x02 实战***

全网memcache放大器预估

shodan搜索查看  从tcp协议上看，Memcache全网开放的主要分布在中美，其次是香港，法国，日本，印度等。开放的数量为116534，在10w级别左右。

exploit

进行一系列的操作后，获取可以成功放大的memcache主机ip。

***强度和演示

我们随机选择了一台可利用的主机(digital ocean)，进行ddos放大测试，ddos目标为我们的aws ec2(扛D)，发现反射流量最大达到了700m/s,稳定在500m/s. 而全网可以利用的主机数量在5w以上。 而仅仅是memcache这样一个协议，就可以造成很可观的放大效果，像这样的协议其实还有很多。

最大***效果计算：

100M(企业服务器的平均上传流量，主要为国外) * 5w <= 5T (上1T应该是没问题的)

0x03 影响范围

Top 20 ASN 信息

从asn信息上看，可简单分为下面四类：

– ec2: aliyun,tencent,aws,azure,google cloud

– vps: digital ocean,linode,vultr,godaddy

– dedicated server: ovh,online

– idc: 一些idc。

从市场份额上看：

– 同属于云服务器的亚马逊和阿里云差别很大。亚马逊市场份额全球第一，阿里云全球第三，而阿里云的受影响主机数目是aws的15倍。我们分析主要有2个原因：1. aws的vpc做的非常方便，且默认存在，形成了一个安全的私有云网络组，进行了网络隔离，只开放有限的端口。而阿里云在vpc的研发过程中，经典网络作为一种过渡，在引导用户的过程中，可能有些许不当，很多用户往往会选择`0.0.0.0`完全开放，在主机上也不会设置iptables等。当然也可能是由于租户的的安全习惯，会觉得网络安全组很麻烦，安全意识也比较低，所以有了这后面的风险。针对云服务，应该还是要遵循租户完全隔离，最小权限2个基本原则。

– 针对ec2和vps对比可以看到，vps是受影响的重灾区，因为其架构了就没有一个完整或方便的vpc和网络安全组，即使有，如vultr等，为了用户的方便，也不是默认要求，会设置成作为可选的高级选项。所以网络隔离对安全事件的防御使尤为重要的。这点上亚马逊的lightsail同为vps，却做的非常好，默认有vpc,且可以很方便的与ec2,rdp等服务合并或分离vpc。

– 针对独立服务器(dedicated server),不管是硬件还是软件上，做安全组都是很不方便的，所以基本无安全组，数据上看ovh和online都是份额很低，但是可利用的主机却排在前列。

– idc这一块，国内idc在数据上比较突出，可以反映出国内厂商的安全架构和意识，还有企业的acl策略等，都亟待提高。

TOP 20 地理分布

从国家分布上看:

中美都是名列前茅，因为其体量和基数都是比较全世界份额比较高的，

Shodan tcp 开放主机数量上，美国第一，中国第二，但受影响的数量上却是相反的，说明美国对udp的一些服务还是有防御的，可以看出我们安全体系和架构，还有运维能力和意识上，都有不少的差距。

0x04 缓解措施和总结

Memcache 使用者

memcache的用户建议将服务放置于可信域内，有外网时不要监听0.0.0.0,有特殊需求可以设置acl或者添加安全组。

为预防机器扫描和***f等***，可以将memcache的监听端口随机改为其他的。

鼓励用户升级到最新版本的memcache，并且使用SASL设置密码来进行权限控制。

网络层防御

网络管理员应确保监控和防御来自UDP端口11211的入站流量。

打击***源：互联网服务提供商不应该允许在他们的网络上执行IP欺骗。IP欺骗DRDOS的根本原因。具体措施可以参考BCP38。

ISP(互联网服务提供商) 应允许他们的客户使用BGP flowspec来限制入站UDP11211的流量，以减轻大型DRDOS***期间的拥塞。

开发者

开发人员不应该在没有仔细考虑UDP放大问题的情况下，推出自己的UDP协议。