Memcrashed

原文地址：https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
原文标题：Memcrashed - Major amplification attacks from UDP port 11211
原文作者：Marek Majkowski
原文写于：2018/2/27 GMT+8 下午10:38:35

译者：驱蚊器喵#ΦωΦ
翻译水平有限，有不通顺的语句，请见谅。

在过去几天，我们发现了一种隐蔽的放大攻击途径 - 使用 memcached 协议, 来自于 UDP的11211端口。

3829936641_f112ed1665_b
CC BY-SA 2.0 image by David Trawin

以前, 我们就讨论过很多网上的放大攻击. 我们最近的两篇有关这个话题的博客是:

超过 100Gbps 的 SSDP 放大攻击. 有趣的是，那之后我们成为了一次196Gbps流量SSDP攻击的目标.
我们看到的各种放大攻击的统计.

所有放大攻击的基本思路都是一样的. 一个可以伪造IP的攻击者将伪造的请求发送给有缺陷的 UDP 服务器. 这个 UDP 服务器, 不知道请求是伪造的, 礼貌的回应请求.问题发生在大量的回应包发送到毫无戒心的服务器, 耗尽了他的资源 - 尤其是网络资源.

spoofing-1

放大攻击是威力很大的，因为响应的数据包通常比请求数据包大得多。精心准备的攻击手法可以让攻击者的有限带宽 (比如1Gbps) 打出规模巨大的攻击流量(达到100s Gbps)，从而”放大”攻击者的带宽。

隐蔽的放大攻击一直在发生. 我们经常看到 “chargen” 或者 “call of duty” 数据包攻击我们的服务器.

但是这种新型的放大攻击，效果很出色的很少。这种新的 memcached UDP DDoS 就是这类。

奇虎360的DDosMon 会监控ddos攻击，下面的图表显示了最近的 memcached/11211攻击:

memcached-ddosmon

memcached 的攻击相对平缓，直到几天前突然开始增加.我们的图表也证实了这点, 下面是最近4天的攻击(每秒发送的数据包数量):

memcached-pps

虽然每秒的数据包不是很多, 但是造成的宽带却很大:

memcached-gpb

我们可以看到入站UDP memcached流量的速度高达 260Gbps. 对于一种新型放大攻击来说，这个放大倍数很大. 数据不会说谎. 这是由于所有反射回来的数据包都非常大. 这是在tcpdump中看到的:

$ tcpdump -n -t -r memcrashed.pcap udp and port 11211 -c 10
IP 87.98.205.10.11211 > 104.28.1.1.1635: UDP, length 13
IP 87.98.244.20.11211 > 104.28.1.1.41281: UDP, length 1400
IP 87.98.244.20.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 188.138.125.254.11211 > 104.28.1.1.41281: UDP, length 1400
IP 5.196.85.159.11211 > 104.28.1.1.1635: UDP, length 1400
IP 46.31.44.199.11211 > 104.28.1.1.6358: UDP, length 13

大部分数据包的大小是1400 字节. 做一下算术题， 23Mpps x 1400 bytes 造成了 257Gbps 流量, 正如图表所示.

Memcached 使用的是 UDP?

在了解到 memcached 使用的是 UDP 协议后，我很吃惊! 在协议规范中表明这是用于放大攻击中最好的协议之一! 在UDP协议中，没有任何校验，然后数据就以超快的速度返回给客户端! 此外, 请求可以很小，但是响应很大 (最多到 1MB).

发动这样的攻击很简单. 首先攻击者注入一个巨大的攻击载荷到暴露在外网的 memcached 服务器. 然后, 攻击者伪造一个从目标来源 IP 发起的 “get” 请求.

Tcpdump 的运行显示了这些流量:

$ sudo tcpdump -ni eth0 port 11211 -t
IP 172.16.170.135.39396 > 192.168.2.1.11211: UDP, length 15
IP 192.168.2.1.11211 > 172.16.170.135.39396: UDP, length 1400
IP 192.168.2.1.11211 > 172.16.170.135.39396: UDP, length 1400
...(重复几百次)...

15 B的请求能够触发 134 KB 的请求. 放大倍数是 10,000x! 测试中，我们能看到的是， 15 B的请求造成了 750kB 的回应 (这里是 51,200x 倍放大).

Source IPs

存在缺陷的 memcached 服务器遍布全球, 北美和欧洲的服务器居多. 以下是我们在120多个检测点中得到的源IP地图:

memcached-map2

有趣的是，我们在 EWR, HAM 和 HKG 的数据中心，看到了大量的不成比例的攻击 IP. 这是因为大量的存在缺陷的服务器位于主要的托管提供商中. 我们看到的这些IP的 AS 号码如下:

┌─ips─┬─srcASN──┬─ASName───────────────────────────────────────┐
│ 578 │ AS16276 │ OVH                                          │
│ 468 │ AS14061 │ DIGITALOCEAN-ASN - DigitalOcean, LLC         │
│ 231 │ AS7684  │ SAKURA-A SAKURA Internet Inc.                │
│ 199 │ AS9370  │ SAKURA-B SAKURA Internet Inc.                │
│ 165 │ AS12876 │ AS12876                                      │
│ 119 │ AS9371  │ SAKURA-C SAKURA Internet Inc.                │
│ 104 │ AS16509 │ AMAZON-02 - Amazon.com, Inc.                 │
│ 102 │ AS24940 │ HETZNER-AS                                   │
│  81 │ AS26496 │ AS-26496-GO-DADDY-COM-LLC - GoDaddy.com, LLC │
│  74 │ AS36351 │ SOFTLAYER - SoftLayer Technologies Inc.      │
│  65 │ AS20473 │ AS-CHOOPA - Choopa, LLC                      │
│  49 │ AS49981 │ WORLDSTREAM                                  │
│  48 │ AS51167 │ CONTABO                                      │
│  48 │ AS33070 │ RMH-14 - Rackspace Hosting                   │
│  45 │ AS19994 │ RACKSPACE - Rackspace Hosting                │
│  44 │ AS60781 │ LEASEWEB-NL-AMS-01 Netherlands               │
│  42 │ AS45899 │ VNPT-AS-VN VNPT Corp                         │
│  41 │ AS2510  │ INFOWEB FUJITSU LIMITED                      │
│  40 │ AS7506  │ INTERQ GMO Internet,Inc                      │
│  35 │ AS62567 │ DIGITALOCEAN-ASN-NY2 - DigitalOcean, LLC     │
│  31 │ AS8100  │ ASN-QUADRANET-GLOBAL - QuadraNet, Inc        │
│  30 │ AS14618 │ AMAZON-AES - Amazon.com, Inc.                │
│  30 │ AS31034 │ ARUBA-ASN                                    │
└─────┴─────────┴──────────────────────────────────────────────┘

我们看到，大多数的 memcached 服务器来自 AS16276 - OVH, AS14061 - Digital Ocean 和 AS7684 - Sakura.

所有我们能够看到的 memcached 服务器的唯一来源 IP 只有 5,729 个. 我们期待以后会看到威力更大的攻击，因为，据 Shodan 的报告，有 88,000 个开放的 memcached 服务器:

memcached-shodan

解决

解决这个问题来阻止更多的攻击是有必要的. 以下列出了一些应该做的事.

Memcached 用户

如果你正在使用, 如果你没有用到UDP功能，请关闭它. 在 memcached 启动的时候，你可以指定--listen 127.0.0.1参数，让它只监听本地的localhost，指定-U 0 参数来完全关闭UDP . 默认情况下 memcached 监听入站的外网端口 INADDR_ANY ，并且运行是开启了UDP支持. 文档见:

https://github.com/memcached/memcached/wiki/ConfiguringServer#udp

你可以通过运行以下的命令来简单的测试你的服务器是否有漏洞:

$ echo -en "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n" | nc -q1 -u 127.0.0.1 11211
STAT pid 21357
STAT uptime 41557034
STAT time 1519734962
...

如果你看到有内容的回复(就像上面这个), 说明你的服务器是有漏洞的.

系统管理员

请确认你的 memcached 服务器是在互联网的防火墙之后! 我建议使用nc来测试其他人是否能够通过UDP访问, 运行nmap验证TCP端口是否关闭:

$ nmap TARGET -p 11211 -sU -sS --script memcached-info
Starting Nmap 7.30 ( https://nmap.org ) at 2018-02-27 12:44 UTC
Nmap scan report for xxxx
Host is up (0.011s latency).
PORT      STATE         SERVICE
11211/tcp open          memcache
| memcached-info:
|   Process ID           21357
|   Uptime               41557524 seconds
|   Server time          2018-02-27T12:44:12
|   Architecture         64 bit
|   Used CPU (user)      36235.480390
|   Used CPU (system)    285883.194512
|   Current connections  11
|   Total connections    107986559
|   Maximum connections  1024
|   TCP Port             11211
|   UDP Port             11211
|_  Authentication       no
11211/udp open|filtered memcache

网络服务提供商(ISP)

memcached-reflector

为了杜绝以后的这类攻击, 我们需要修复存在缺陷的协议，以及 IP 欺骗. 只要有 IP 欺骗的存在, 我们就会陷入麻烦之中.

通过追踪攻击的幕后黑手来帮助我们. 我们不仅需要知道谁有存在问题的 memcached 服务器, 还需要知道是谁发送了请求到这些服务器上. 没有你们的帮助，我们无法完成!

开发者

请拜托你们: 停止使用 UDP. 如果你必须要用, 请不要默认开启. 我在此呼吁，严禁 SOCK_DGRAM（译者注：SOCK_DGRAM是基于UDP的socket）写入你们的代码中，尽管你可能不知道放大攻击是什么.

这条路，我们已经走了很多次. 从 DNS, NTP, Chargen, SSDP 到现在的 memcached. 如果你使用 UDP, 你必须以比请求数据还小的响应回复. 否则你的UDP协议将会被滥用. 还要记得设置人们通常忘记的防火墙. 做个好公民. 不要创造任何基于UDP的缺乏身份校验的协议.

结束语

在我们清理完缺陷服务器之前，每个人都在猜测 memcached 攻击能达到多大. 前几天有传言是 0.5Tbps 放大攻击, 这只是个开始.

最后, 如果你是Cloudflare的客户，那就没有什么问题. Cloudflare 的 Anycast 架构可以很好的分布负载，以防大量的放大攻击，如果你的源站 IP 没有泄漏，那你在 Cloudflare 的保护下会非常安全.

序言

一个评论 (文章后) 指出了在一篇 2017年的演示文稿中讨论了使用 memcached 进行 DDoS 的可行性 .

更新

我们收到了Digital Ocean，OVH，Linode和亚马逊的来信，他们解决了memcached的问题，他们的网络以后将不会成为攻击的载体。太棒了！