Redis Enterprise 是否容易受到 RedisWannaMine 攻击？

3月8日，Imperva 发表了一篇博文，介绍了一种利用 Redis 的新型加密劫持攻击。从工程角度来看，这次攻击与其说是一种奇迹，不如说是一台复杂的鲁布·戈德堡机械，而 Redis 恰好是其中的一个齿轮。但有个好消息：

• 如果您遵循了哪怕是最基本的配置和安全最佳实践，这将不会影响您。
• Redis Enterprise 完全不受此攻击的影响。

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 进行验证。即使是一个单字符密码（这是个糟糕的主意）也足以阻止这次攻击。受保护模式（protected mode）默认是开启的，这会阻止一个绑定到所有网络接口的实例没有密码。所以再次强调，必须有人手动修改配置来关闭受保护模式。
3. Redis 位于端口 6379。虽然这不是世界上最严重的错误，但更改任何服务的默认端口号是一种廉价的防御此类攻击的方法。即使是这一小小的改变也足以阻止这次攻击。

简而言之，这次攻击针对的是那些手动修改设置以执行危险操作的用户。

另一方面，Redis Enterprise 通过提供管理/管理平面与数据平面之间的纯粹分离，可以开箱即用地防范这些类型的攻击。例如，标准 Redis API 的所有 CONFIG 命令都被禁用。此外，Redis Enterprise 内置了多层安全控制，包括访问控制层、身份验证层、授权、取证层、加密层以及可用的保护层。所有这些功能的详细说明可以在Redis Enterprise 安全技术页面上找到。

所以，这就是真相——一次非常不明智的配置是这次攻击的核心。不要费尽周折让您的开源 Redis 服务器变得不安全……或者直接使用 Redis Enterprise，一切就迎刃而解了。