投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
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上有很多ssrf攻击的案例。另外由于支持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或者添加安全组。
为预防机器扫描和ssrf等攻击，可以将memcache的监听端口随机改为其他的。
鼓励用户升级到最新版本的memcache，并且使用SASL设置密码来进行权限控制。
网络层防御
网络管理员应确保监控和防御来自UDP端口11211的入站流量。
打击攻击源：互联网服务提供商不应该允许在他们的网络上执行IP欺骗。IP欺骗DRDOS的根本原因。具体措施可以参考BCP38。
ISP(互联网服务提供商) 应允许他们的客户使用BGP flowspec来限制入站UDP11211的流量，以减轻大型DRDOS攻击期间的拥塞。
开发者
开发人员不应该在没有仔细考虑UDP放大问题的情况下，推出自己的UDP协议。
0x05 关于我们
最后介绍一下我们，我们是0kee team，来自于奇虎360的信息安全部，团队成员专注于WEB安全相关研究，在攻防领域拥有丰富的经验。更多关于我们的信息可以上我们的主页 0kee.360.cn了解。