NOSQL之【redis的安全策略】

原文：http://redis.io/topics/security

1.Redis的安全模式

       可信环境下的可信用户才可访问redis。这意味着，将redis服务器直接暴露在Internet或者不可信用户可直接访问Redis的tcp端口或Unix套接字的环境，是不安全的。

使用redis的web应用程序的常用场景是将redis作为数据库，缓存，消息系统，应用程序的前端用户查询redis来产生页面，或者运行需要的操作，被web应用程序用户所触发。这样的话，web应用程序需要对不可信用户(用户浏览器)访问redis进行处理。

对redis的非法访问经常通过使用ACL,验证用户输入和决定redis的哪些操作是禁止的等等措施来控制。

总的来说，redis着重于高性能和简单易用，在安全方面做得并不好。

2.网络安全

        除了可信用户之外，任何人都不能访问redis端口。用redis实现的应用程序才可直接访问服务器上运行的redis.

        通常情况下，一台直接暴露在Internet的计算机，例如一个虚拟化Linux实例（Linode,EC2,…）,防火墙应防止外部用户访问它的redis端口。

用户仍可以通过本地接口来访问redis.

        在redis.conf配置文件增加下面这一行配置，即可把redis绑定在单个接口上。

                  bind 127.0.0.1

         如果不禁止外部访问redis的话，将会产生非常严重的后果。例如，外部的非法用户的一个FLUSHALL操作就可以删除redis的所有数据。

（我们也可以禁止掉Redis 禁用FLUSHALL FLUSHDB KEYS 命令等操作）

FLUSHALL FLUSHDB 命令会清空数据，而且从不失败，对于线上集群非常危险。

KEYS * 命令，当数据规模较大时使用，会严重影响Redis性能，也非常危险。

如果从根本上规避这些风险呢？

Redis提供了非常简单且有效的方法，直接在配置文件中设置禁用这些命令。设置非常简单，如下

 

需要注意的一点是，rename-command命名无法直接对线上集群生效。如果需要使用rename-command，必须重启集群。

所以建议一开始，就将该配置配置好。

rename-command FLUSHALL ""

rename-command FLUSHDB ""

rename-command KEYS ""

3.认证

        虽然redis没有实现访问控制这个功能，但是它提供了一个轻量级的认证方式，可以编辑redis.conf配置来启用认证。

　　　　当授权方式启用时，redis将会拒绝来自非认证用户的任何查询。用户可以通过发送AUTH命令并带上密码给redis服务器来给自己授权。

　　　　系统管理员在redis.conf文件里以明文方式设置密码。而且密码必须足够长来抵御暴力破解密码方式的攻击，这样设置密码做有两个原因：

（1）redis的查询速度是非常快的，外部用户一秒内可以尝试许多个密码。

（2）redis密码存储在redis服务器上的redis.conf文件以及用户的配置文件里，系统管理员没有必要记住密码，因为密码可以非常长的。

       认证层的目标是提供多一层的保护。如果防火墙或者用来保护redis的系统防御外部攻击失败的话，外部用户如果没有通过密码认证还是无法访问redis的。

       AUTH命令跟其他redis命令一样，是没有加密的，所以阻止不了攻击者在网络上窃取你的密码。

4.数据加密

Redis并不支持加密。为了能让在Internet或者不可信网络的用户访问redis，需要实现新增的保护层，例如SSL代理。

5.禁用指定的命令

在redis你可以禁用某些命令或者将命令重命名成难以猜测的名字，这样一般的用户就只能使用部分命令了。
例如，虚拟服务器提供商提供管理redis实例的服务，这样的话，普通用户就不能调用CONFIG命令来修改配置了，但能新增，删除redis实例的系统必须能修改配置。你可以重命名命令，也可以完全禁用该命令。Redis.conf文件支持这样的这样配置。
例如：
　　rename-command CONFIGb840fc02d524045429941cc15f59e41cb7be6c52

在上面这个例子里，CONFIG命令重命名成一个毫无意义的名字。把命令重命名成空字符串即可将命令完全禁用，例如下面这个例子：

rename-command CONFIG “”

6.外部用户精心构造的输入所触发的攻击

有一类攻击是攻击者即便没有访问redis权限也可以通过外部来触发的。这种攻击的一个方式是向redis插入数据，使得对redis内部实现的数据结构的操作达到一个变态的算法复杂度。
例如，攻击者通过表单提交若干哈希值相同的字符串到哈希表里，使O(1)的平均算法复杂度变成最差的O(n),redis服务器要花费比预期更多的cpu，最终导致无法提供服务。

    为了防范这类特殊的攻击，redis的哈希函数使用per-excution的伪随机种子。Redis用qsort算法来实现SORT命令。目前这个算法还不是随机的，所以通过有意构造输入可能引发二次达到最糟糕情况的行为。

7.字符串转义和NoSQL注入

Redis的协议里并没有字符串转义的概念，在一般的情况下使用普通客户端库是无法实现NoSQL注入的。协议使用的是二进制安全的前缀长度字符串。通过EVAL,EVALSHA命令执行Lua脚本同样是安全的。应用程序应避免使用不明来源的字符串来写Lua脚本。

8.代码安全

典型版本的redis中，客户端是可以使用全部命令的，但是访问redis实例时是没有能力

控制运行着redis的系统的。

Redis使用好的编程方法来写代码，防止出现缓存溢出，格式错误和其他内存损坏问题。可是，使用CONFIG命令修改服务器配置的能力使得用户可以改变程序的工作目录和备份文件的名字。这也使得用户将RDB文件写在任意位置。这个安全问题容易引起不安全的代码的运行。

Redis并不需要root权限来运行。建议使用非特权用户运行redis.redis的作者正在调查给CONFIG命令增加一个新参数来防止CONFIG SET/GET dir和其他类似的运行时配置指令的可能性。这可以防止用户强制服务器在任意位置写备份文件。