原文地址:https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
翻译水平有限,有不通顺的语句,请见谅。
原作者:Marek Majkowski
写于 27 Feb 2018

译者:驱蚊器喵#ΦωΦ


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

3829936641_f112ed1665_b
3829936641_f112ed1665_b

CC BY-SA 2.0 image by David Trawin

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

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

spoofing-1
spoofing-1

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

Memcrashed

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

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

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

memcached-ddosmon
memcached-ddosmon

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

memcached-pps
memcached-pps

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

memcached-gpb
memcached-gpb

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

1
2
3
4
5
6
7
8
9
10
11
$ 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 的运行显示了这些流量:

1
2
3
4
5
$ 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
memcached-map2

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
┌─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-shodan

解决

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

Memcached 用户

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

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

1
2
3
4
5
$ 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端口是否关闭:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ 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
memcached-reflector

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

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

开发者

请拜托你们: 停止使用 UDP. 如果你必须要用, 请不要默认开启. 我在此严禁你们把 SOCK_DGRAM 写入到你的编辑器中,尽管你可能不知道放大攻击是什么.

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

结束语

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

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

序言

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

更新

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