Redis 企业版是否容易受到 RedisWannaMine 的攻击？

3 月 8 日，Imperva 发布了一篇博客文章关于一种新的利用 Redis 的加密劫持攻击。从工程的角度来看，这种攻击与其说是奇迹，不如说是复杂的鲁布·戈德堡机器，它恰好将 Redis 作为其中一个齿轮。好消息是：

• 如果您遵循了最基本的配置和安全最佳实践，那么您将不会受到影响。
• Redis 企业版 对此攻击完全免疫。

Imperva 的博客文章很好地解释了此漏洞，因此我不会在这里“重新造轮子”，但我会简要概述 Redis 如何参与其中。

1. 在之前能够进行远程代码执行的被利用机器上，一个简单的扫描器会探测默认端口 6379 上的 Redis 服务器。
2. 一旦它找到一台对这台被利用的原始机器可用的开放（没有 AUTH）Redis 服务器，该漏洞就会执行以下操作：
   1. 将一些键设置为 crontab 配置行
   2. 使用 CONFIG SET 将 *dir* / *dbfilename* 指令的位置更改为执行 crontab 的各个路径
   3. 使用 SAVE 对数据集执行同步保存

经验丰富的 Redis 极客现在可能在尖叫。让我们回顾一下为了使此漏洞成为可能而需要做出的所有与 Redis 相关的糟糕决定。

1. 您需要在开放的互联网上运行 Redis。Redis 的安全模型是分层的——Redis 永远不应该是一个完全开放给外界的服务。即使是简单的防火墙也足以阻止这种攻击。事实上，Redis 会尝试通过 redis.conf 文件阻止您执行此操作——您必须手动更改绑定到所有网络接口。
2. Redis 服务器上没有密码。始终设置密码并在发送命令之前使用 AUTH。即使是一个字符的密码（这是一个糟糕的主意）也足以阻止这种攻击。受保护模式默认情况下处于启用状态，这将阻止普遍的网络接口绑定实例没有密码。所以再次说明，有人必须手动更改配置以关闭受保护模式。
3. Redis 在端口 6379 上运行。虽然这并不是世界上最糟糕的罪行，但更改任何服务的端口号使其远离默认端口是一种抵御此类攻击的廉价防御措施。即使这种小小的变化也足以阻止这种攻击。

简而言之，此攻击针对的是那些手动更改设置以执行危险操作的人。

另一方面，Redis 企业版通过在管理/管理平面和数据路径平面之间提供纯粹的分离，从一开始就免受这些类型的攻击。例如，所有标准 Redis API 的 CONFIG 命令都被禁用。此外，Redis 企业版带有一个内置的多层安全控制，包括访问控制层、身份验证层、授权、取证层、加密层和可用性保护层。所有这些功能的详细描述可以在 Redis 企业版安全技术 页面上找到。

所以，事情就是这样——这个漏洞的核心是一个非常不合理的配置。不要为了让您的开源 Redis 服务器不那么安全而跳过各种障碍……或者直接使用 Redis 企业版，您就安全了。