Redis安全

Redis通用安全模型

Redis被设计为可由可信环境中的可信客户端访问。 这意味着，通常不应该将Redis实例直接暴露到internet上，或者在一般情况下，不要暴露到不受信任的客户端可以直接访问Redis TCP端口或UNIX套接字的环境中。

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

在本例中，web应用程序在Redis和不受信任的客户端(访问web应用程序的用户浏览器)之间充当访问中介。

通常，对于Redis的不受信任访问应该始终由实现了ACLs、决定对Redis实例执行什么操作和用户输入验证的中间层来协调。 一般来说，Redis的优化不是为了最大的安全性，而是为了最大的性能和简单性。

网络安全

除了网络中的可信客户端外，所有其它的Redis端口都应该拒绝访问，因此运行Redis的服务器只能由使用Redis实现应用程序的计算机直接访问。

在单个计算机直接暴露于internet的常见情况下，例如一个虚拟化的Linux实例(Linode, EC2，…)，应该对Redis端口设置防火墙，以防止来自外部的访问。 客户端仍然能够使用环回接口访问Redis。

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

bind 127.0.0.1

由于Redis的性质，无法从外部保护Redis端口可能会造成很大的安全影响。

例如，外部攻击者可以使用一个FLUSHALL命令删除整个数据集。

保护模式

不幸的是，许多用户无法保护Redis实例不被外部网络访问。 许多实例通过公共ip暴露在internet上。 由于这个原因，从3.2.0版开始，当执行Redis时使用默认配置(绑定所有接口)，并且没有任何密码来访问它，它就进入一种称为保护模式的特殊模式。 在这种模式下，Redis只回复来自环回接口的查询，来自其他地址的其他客户端只回复error，解释发生了什么以及如何正确配置Redis。

我们希望受保护模式能够在没有适当管理的情况下，减少不受保护的Redis实例执行所带来的安全问题，但是系统管理员仍然可以忽略Redis给出的错误，禁用受保护模式或手动绑定所有接口。

身份验证功能

虽然Redis不尝试实现访问控制，但它提供了一个很小的身份验证层，可以在编辑Redis .conf文件时选择打开这个层。 当启用授权层时，Redis将拒绝未经身份验证的客户端的任何查询。 客户端可以通过发送AUTH命令和密码对自己进行身份验证。

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

• Redis在查询方面非常快。 外部客户端每秒可以测试多个密码。
• Redis密码存储在Redis .conf文件和客户端配置中，因此系统管理员不需要记住它，因此它可以是非常长。

身份验证层的目标是可选地提供冗余层。 如果防火墙或任何其他用于保护Redis免受外部攻击的系统失败，外部客户端在不知道身份验证密码的情况下仍然无法访问Redis实例。 与其他所有Redis命令一样，AUTH命令发送时是不加密的，因此它不能防止攻击者对网络进行足够的访问来执行窃听。

禁用特定命令

可以禁用Redis中的命令，或者将它们重命名为不可猜测的名称，这样普通客户端就只能使用一组指定的命令。

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

在这种情况下，可以从命令表重命名或完全隐藏命令。如下的特性语句是可用的，可以在redis.conf配置文件中使用：

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

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

rename-command CONFIG ""

由外部客户端精心选择的输入触发的攻击

攻击者可以从外部触发一类攻击，即使没有对实例的外部访问权限。 此类攻击的一个例子是将数据插入Redis，这将对Redis内部实现的数据结构触发病态算法复杂度(最坏情况)。

例如，攻击者可以通过web表单提供一组已知的字符串，将这些字符串hash到一个hash表中，以便将O（1）的预期时间（平均时间）变为O（n）的最坏情况，消耗比预期更多的CPU，并最终导致拒绝服务。

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

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

字符串转义和NoSQL注入

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

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

虽然这将是一个非常奇怪的用例，但是应用程序应该避免使用从不可信源获得的字符串组合Lua脚本的主体。

 

转载于:https://my.oschina.net/jennerlo/blog/3075208