在过去的几天里，我们看到一个模糊的放大攻击向量有了很大的增加——使用memcached协议，来自UDP端口11211。大卫·特拉温的CC BY-SA 2.0图像在过去，我们谈论了很多关于互联网上发生的放大攻击。我们最近的两篇关于这个主题的博客文章是：跨100Gbps的SSDP放大。有趣的是，从那时起我们就成了196Gbps SSDP攻击的目标。我们看到的各种放大攻击的一般统计数据。所有放大攻击背后的基本思想都是一样的。具有IP欺骗能力的攻击者向易受攻击的UDP服务器发送伪造请求。UDP服务器不知道请求是伪造的，礼貌地准备响应。当成千上万的响应被传递到一个毫无防备的目标主机上时，问题就发生了，它的资源被压倒了——最典型的就是网络本身。放大攻击是有效的，因为响应包通常比请求包大得多。精心准备的技术允许IP欺骗容量有限（如1Gbps）的攻击者发起非常大的攻击（达到100s Gbps）"放大"攻击者的带宽。内存崩溃模糊的放大攻击总是发生。我们经常看到"chargen"或"使命召唤"数据包撞击我们的服务器。然而，一个新的放大载体的发现，允许非常大的放大，很少发生。这种新的memcached UDP DDoS绝对属于这一类。奇虎360的DDosMon监控放大攻击向量，此图显示最近的memcached/11211攻击：memcached攻击的数量相对平稳，直到几天前才开始激增。我们的图表也证实了这一点，以下是过去四天中以每秒包为单位的攻击：虽然每秒的数据包计数并不令人印象深刻，但产生的带宽是：在峰值时，我们看到了260Gbps的入站UDP memcached流量。这对于一个新的放大向量来说是巨大的。但数字不会说谎。这是可能的，因为所有反射的包都非常大。这是tcpdump中的外观：$tcpdump-n-t-r内存崩溃.pcapudp和端口11211-c 10IP 87.98.205.10.11211>104.28.1.1.1635:UDP，长度13IP 87.98.244.20.11211>104.28.1.1.41281:UDP，长度1400IP 87.98.244.20.11211>104.28.1.1.41281:UDP，长度1400IP 188.138.125.254.11211>104.28.1.1.41281:UDP，长度1400IP 188.138.125.254.11211>104.28.1.1.41281:UDP，长度1400IP 188.138.125.254.11211>104.28.1.1.41281:UDP，长度1400IP 188.138.125.254.11211>104.28.1.1.41281:UDP，长度1400IP 188.138.125.254.11211>104.28.1.1.41281:UDP，长度1400IP 5.196.85.159.11211>104.28.1.1.1635:UDP，长度1400IP 46.31.44.199.11211>104.28.1.1.6358:UDP，长度13大多数数据包的大小为1400字节。计算一下23Mpps x 1400字节，就可以得到257Gbps的带宽，正如图表所示。Memcached做UDP？我很惊讶地得知memcached做UDP，但你去吧！协议规范表明它是有史以来用于放大的最佳协议之一！绝对零检查，数据将以极快的速度传递给客户！此外，请求可以很小，响应可以很大（高达1MB）。发动这样的攻击很容易。首先，攻击者在暴露的memcached服务器上植入一个大负载。然后，攻击者利用目标源IP欺骗"get"请求消息。Tcpdump的合成运行显示流量：$sudo tcpdump-ni eth0端口11211-tIP 172.16.170.135.39396>192.168.2.1.11211:UDP，长度15IP 192.168.2.1.11211>172.16.170.135.39396:UDP，长度1400IP 192.168.2.1.11211>172.16.170.135.39396:UDP，长度1400…（重复了几百次）。。。15个字节的请求触发了134KB的响应。这是10000倍的放大倍数！在实践中，我们看到了一个15字节的请求结果是750kB的响应（这是51200x的放大倍数）。源IP易受攻击的memcached服务器遍布全球，集中在北美和欧洲。以下是我们在120多个存在点中看到的源IP的地图：有趣的是，我们在EWR、HAM和HKG的数据中心看到了不成比例的大量攻击IP。这是因为大多数易受攻击的服务器位于主要的托管提供商中。我们看到的IP的AS编号：———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————│578│AS16276│OVH││468│AS14061│数字海洋-ASN-数字海洋有限责任公司││231│AS7684│SAKURA-A SAKURA互联网公司││199│AS9370│樱花B樱花互联网公司││165│AS12876│AS12876││119│AS9371│SAKURA-C SAKURA互联网公司││104│AS16509│亚马逊02-亚马逊网站，公司││102│AS24940│赫茨纳-AS││81│AS26496│AS-26496-GO-DADDY-COM-LLC-GoDaddy.com网站，有限责任公司││74│AS36351│软层-软层技术公司││65│AS20473│AS-CHOOPA-CHOOPA有限责任公司││49│AS49981│世界流││48│AS51167│康塔博││48│AS33070│RMH-14-机架空间托管││45│AS19994│机架空间-机架空间托管││44│AS60781│LEASEWEB-NL-AMS-01荷兰││42│AS45899│VNPT-AS-VNPT公司││41│AS2510│INFOWEB富士通有限公司││40│AS7506│INTERQ GMO互联网公司││35│AS62567│数字海洋-ASN-NY2-数字海洋有限责任公司││31│AS8100│ASN-QUADRANET-GLOBAL-QUADRANET公司││30│AS14618│亚马逊AES-亚马逊网站，公司││30│AS31034│阿鲁巴ASN│└─────┴─────────┴──────────────────────────────────────────────┘我们看到的大多数memcached服务器来自AS16276-OVH、AS14061-Digital-Ocean和AS7684-Sakura。我们总共只看到了5729个memcached服务器的唯一源IP。我们预计未来会出现更大规模的攻击，Shodan报告了88000个开放式memcached服务器：让我们把它修好有必要解决这个问题，防止进一步的攻击。这是一份应该做的事情的清单。Memcached用户如果您正在使用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\x01\x00\x00stats\r\n"| nc-q1-u 127.0.0.11211统计pid 21357统计正常运行时间41557034静态时间1519734962...如果您看到非空响应（如上面的响应），则服务器易受攻击。管理员组请确保你的memcached服务器是从互联网防火墙！为了测试是否可以使用UDP访问它们，我推荐上面的nc示例，要验证TCP是否关闭，请运行nmap：$nmap TARGET-p12111-sU-sS—编写memcached信息脚本启动Nmap 7.30（https://nmap.org)在2018-02-27 12:44 UTCxxxx的Nmap扫描报告主机启动（0.011s延迟）。港口国服务11211/tcp打开内存缓存|memcached信息：|进程ID 21357|正常运行时间41557524秒|服务器时间2018-02-27T12:44:12|体系结构64位|已用CPU（用户）36235.480390|已用CPU（系统）285883.194512|电流连接11|总连接数107986559|最大连接数1024|TCP端口11211|UDP端口11211|_认证号11211/udp open |过滤memcache互联网服务提供商为了在将来击败这些攻击，我们需要修复易受攻击的协议和IP欺骗。只要互联网上允许IP欺骗，我们就有麻烦了。帮助我们追踪谁是这些袭击的幕后黑手。我们不必知道谁有问题的memcached服务器，而是谁首先向它们发送查询。没有你的帮助我们做不到！开发商请停止使用UDP。如果必须，请不要在默认情况下启用它。如果你不知道什么是放大攻击，我在此禁止你在你的编辑器中输入SOCK_gram。我们已经在这条路上走了很多次了。DNS、NTP、Chargen、SSDP和现在的memcached。如果使用UDP，则必须始终以比请求更小的数据包大小来响应。否则你的协议就会被滥用。还要记住，人们确实忘记了设置防火墙。做一个好公民。不要发明一个没有任何身份验证的基于UDP的协议。这就是全部在清理易受攻击的服务器之前，任何人都不知道memcached攻击会有多大。在过去的几天里已经有了0.5Tbps扩增的传闻，而这仅仅是一个开始。最后，如果您是Cloudflare的客户，您就可以了。Cloudflare的Anycast架构可以很好地在发生大规模放大攻击时分配负载，除非您的原始IP暴露在外，否则您在Cloudflare后面是安全的。开场白下面的一条评论指出，在2017年的一次演示中讨论了将memcached用于DDoS的可能性。更新我们从Digital Ocean、OVH、Linode和Amazon那里得到消息，他们解决了memcached问题，他们的网络不应该成为未来攻击的载体。万岁！处理DDoS攻击听起来很有趣？加入我们在伦敦、奥斯汀、圣弗朗西斯的世界著名团队