Redis 安全

Redis中的安全模型和特性

本文档从Redis的角度介绍了安全主题。它涵盖了Redis提供的访问控制、代码安全问题、通过选择恶意输入从外部触发的攻击以及其他类似主题。您可以通过参加Redis大学安全课程了解更多关于访问控制、数据保护和加密、安全的Redis架构以及安全部署技术的信息。

对于与安全相关的联系人，请在GitHub上提出问题，或者当您认为确实需要保护通信安全时，请使用本文档末尾的GPG密钥。

安全模型

Redis 设计为由受信任环境中的受信任客户端访问。这意味着通常不建议将 Redis 实例直接暴露在互联网上，或者一般来说，暴露在不受信任的客户端可以直接访问 Redis TCP 端口或 UNIX 套接字的环境中。

例如，在使用Redis作为数据库、缓存或消息系统的Web应用程序的常见上下文中，应用程序前端（Web端）的客户端将查询Redis以生成页面或执行由Web应用程序用户请求或触发的操作。

在这种情况下，Web应用程序在Redis和不受信任的客户端（访问Web应用程序的用户浏览器）之间进行访问中介。

通常，对Redis的不可信访问应始终通过实现访问控制列表（ACLs）的层进行中介，该层负责验证用户输入，并决定对Redis实例执行哪些操作。

网络安全

除了网络中的受信任客户端外，应拒绝所有人访问Redis端口，因此运行Redis的服务器应仅允许使用Redis实现应用程序的计算机直接访问。

在单个计算机直接暴露在互联网上的常见情况下，例如虚拟化的Linux实例（Linode、EC2等），Redis端口应该被防火墙保护，以防止外部访问。客户端仍然可以通过回环接口访问Redis。

请注意，可以通过在redis.conf文件中添加如下行来将Redis绑定到单个接口：

bind 127.0.0.1

由于Redis的特性，未能保护Redis端口免受外部访问可能会带来重大的安全影响。例如，外部攻击者可以使用单个FLUSHALL命令删除整个数据集。

保护模式

不幸的是，许多用户未能保护Redis实例免受外部网络的访问。许多实例只是简单地暴露在互联网上，使用公共IP。自版本3.2.0以来，当Redis以默认配置（绑定所有接口）执行且没有任何密码时，它会进入一种称为保护模式的特殊模式。在这种模式下，Redis只响应来自回环接口的查询，并向从其他地址连接的客户端返回一个错误，解释问题以及如何正确配置Redis。

我们预计保护模式将显著减少由于未经适当管理执行的无保护Redis实例引起的安全问题。然而，系统管理员仍然可以忽略Redis给出的错误，并禁用保护模式或手动绑定所有接口。

认证

Redis 提供了两种方式来验证客户端。推荐的身份验证方法是在 Redis 6 中引入的，通过访问控制列表（Access Control Lists），允许创建命名用户并分配细粒度的权限。了解更多关于访问控制列表的信息，请点击这里。

通过编辑redis.conf文件并设置requirepass来启用旧版认证方法。然后所有客户端都将使用此密码。

当启用requirepass设置时，Redis将拒绝任何未经认证的客户端的查询。客户端可以通过发送AUTH命令后跟密码来进行认证。

密码由系统管理员在redis.conf文件中以明文形式设置。它应该足够长，以防止暴力攻击，原因有两个：

Redis 在服务查询方面非常快速。外部客户端每秒可以测试许多密码。
Redis密码存储在redis.conf文件和客户端配置中。由于系统管理员不需要记住它，密码可以非常长。

认证层的目标是可选地提供一层冗余。如果防火墙或任何其他用于保护Redis免受外部攻击者攻击的系统失效，外部客户端仍然无法在不知道认证密码的情况下访问Redis实例。

由于AUTH命令，像其他Redis命令一样，是以未加密的方式发送的，它无法防止具有足够网络访问权限的攻击者进行窃听。

TLS 支持

Redis 支持在所有通信通道上使用 TLS，包括客户端连接、复制链接和 Redis 集群总线协议。

禁止特定命令

可以在Redis中禁止命令或将它们重命名为不可猜测的名称，以便普通客户端仅限于一组指定的命令。

例如，虚拟化服务器提供商可能会提供托管的Redis实例服务。在这种情况下，普通用户可能不应该能够调用Redis的CONFIG命令来更改实例的配置，但提供和删除实例的系统应该能够这样做。

在这种情况下，可以重命名或完全遮蔽命令表中的命令。此功能可作为语句使用，可以在redis.conf配置文件中使用。例如：

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

在上面的例子中，CONFIG 命令被重命名为一个不可猜测的名称。也可以通过将其重命名为空字符串来完全禁止它（或任何其他命令），如下例所示：

rename-command CONFIG ""

由外部客户端的恶意输入触发的攻击

存在一类攻击，攻击者即使没有外部访问实例的权限，也可以从外部触发。例如，攻击者可能会向Redis插入数据，这些数据会触发Redis内部实现的数据结构上的病态（最坏情况）算法复杂度。

攻击者可以通过网页表单提供一组已知会在哈希表中哈希到同一桶的字符串，从而将预期的O(1)时间（平均时间）转变为最坏情况的O(N)时间。这可能会消耗比预期更多的CPU资源，并最终导致服务拒绝。

为了防止这种特定的攻击，Redis 使用了每次执行的伪随机种子来生成哈希函数。

Redis 使用 qsort 算法实现 SORT 命令。目前，该算法不是随机的，因此通过精心选择正确的输入集，可能会触发二次最坏情况行为。

字符串转义和NoSQL注入

Redis协议没有字符串转义的概念，因此在正常情况下使用普通的客户端库是不可能进行注入的。该协议使用前缀长度字符串，并且完全二进制安全。

由于由EVAL和EVALSHA命令执行的Lua脚本遵循相同的规则，这些命令也是安全的。

虽然这将是一个奇怪的用例，应用程序应避免从未受信任的来源获取的字符串组成Lua脚本的主体。

代码安全

在经典的Redis设置中，客户端被允许完全访问命令集，但访问实例不应导致能够控制运行Redis的系统。

在内部，Redis 使用了所有众所周知的安全编码实践来防止缓冲区溢出、格式错误和其他内存损坏问题。然而，使用 CONFIG 命令控制服务器配置的能力允许客户端更改程序的工作目录和转储文件的名称。这使得客户端可以将 RDB Redis 文件写入随机路径。这是一个安全问题，可能会导致系统被攻破和/或以与 Redis 运行相同的用户身份运行不受信任的代码。

Redis 不需要 root 权限即可运行。建议将其作为仅用于此目的的无特权 redis 用户运行。

GPG 密钥