Redis 安全性

Redis 中的安全模型和功能

Redis 堆栈	Redis 社区版

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

对于与安全相关的联系人，请在 GitHub 上提出问题，或者在您感觉到问题时提出问题对于维护通信的安全性非常重要，请使用 GPG 密钥。

安全模型

Redis 旨在供可信环境中的可信客户端访问。这意味着通常公开 Redis 实例不是一个好主意直接传输到 Internet，或者通常传输到不受信任的环境客户端可以直接访问 Redis TCP 端口或 UNIX 套接字。

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

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

通常，对 Redis 的不受信任的访问应该始终由实现 ACL 的层进行中介，验证用户输入，以及决定要对 Redis 实例执行哪些作。

网络安全

应拒绝除受信任的客户端以外的所有人访问 Redis 端口，因此应该可以直接访问运行 Redis 的服务器只能由使用 Redis 实现应用程序的计算机提供。

在单台计算机直接暴露在 Internet 上的常见情况下，例如作为虚拟化 Linux 实例（Linode、EC2 等），Redis 端口应为防火墙以防止来自外部的访问。客户仍然可以使用 loopback 接口访问 Redis。

请注意，可以通过添加一行 Redis 将 Redis 绑定到单个接口类似于 redis.conf 文件：

bind 127.0.0.1

未能从外部保护 Redis 端口可能会产生很大的安全性影响，因为 Redis 的性质。例如，单个FLUSHALL命令可被外部攻击者用来删除整个数据集。

保护模式

遗憾的是，许多用户无法保护 Redis 实例不被访问来自外部网络。许多实例只是暴露在具有公共 IP 的 Internet。从 3.2.0 版本开始，Redis 进入一种称为保护模式的特殊模式，当它使用默认配置执行（绑定所有接口）和无需任何密码即可访问它。在此模式下，Redis 仅回复来自 loopback 接口，并回复从其他地址 - 包含解释问题和如何配置的错误的地址正确地进行 Redis。

我们预计保护模式将大大减少导致的安全问题由未受保护的 Redis 实例执行，而没有适当的管理。然而系统管理员仍然可以忽略 Redis 和关闭保护模式或手动绑定所有接口。

认证

Redis 提供了两种对客户端进行身份验证的方法。 Redis 6 中引入的推荐身份验证方法是通过访问控制列表，允许创建命名用户并为其分配精细权限。在此处阅读有关访问控制列表的更多信息。

旧式身份验证方法是通过编辑 redis.conf 文件，并使用requirepass设置。然后，所有客户端都将使用此密码。

当requirepass设置，Redis 将拒绝任何查询未经身份验证的客户端。客户端可以通过发送 AUTH 命令后跟密码来验证自身。

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

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

身份验证层的目标是选择性地提供一个冗余。如果实施了防火墙或任何其他系统来保护 Redis from external attackers fail 时，外部客户端仍然无法在不知道身份验证密码的情况下访问 Redis 实例。

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

TLS 支持

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

禁止使用特定命令

可以在 Redis 中禁止命令或将其重命名为 unguessable name，以便将普通客户端限制为一组指定的命令。

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

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

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

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

rename-command CONFIG ""

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

有一类攻击，攻击者甚至可以从外部触发无需对实例进行外部访问。例如，攻击者可能会将数据插入 Redis 中，从而触发病态（最坏情况）在 Redis 内部实现的数据结构的算法复杂性。

攻击者可以通过 Web 表单提供一组字符串，这些字符串已知会对哈希表中的同一存储桶进行哈希处理，以便将 O（1）达到 O（N）最坏情况的预期时间（平均时间）。这可能会消耗更多 CPU 超出预期，并最终导致拒绝服务。

为了防止这种特定的攻击，Redis 使用每次执行的伪随机 seed 添加到 hash 函数中。

Redis 使用 qsort 算法实现 SORT 命令。现在该算法不是随机的，因此可以触发二次最坏情况的行为。

字符串转义和 NoSQL 注入

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

由于 Lua 脚本由EVAL和EVALSHA命令跟在相同的规则，这些命令也是安全的。

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

代码安全性

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

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

Redis 不需要 root 权限即可运行。建议以仅用于此目的的非特权 Redis 用户身份运行它。

GPG 密钥