高性能Redis数据库安全手册(1)
Redis是一个高性能的key-value数据库，这两年可谓火的不行。而Redis的流行也带来一系列安全问题，不少攻击者都通过Redis发起攻击。本文将讲解这方面的内容，包括Redis提供的访问控制和代码安全问题，以及可以由恶意输入和其他类似的手段触发的攻击。
Redis通用安全模块
Redis被设计成只能由可信环境的可信机器访问。这意味着将它直接暴露在互联网或者其他可以由不可信机器通过TCP或者UNIX SCOKET直接连接的环境中。
例如，在通常的WEB应用程序使用Redis作为数据库，cache,或者消息系统。WEB应用程序的客户端将查询Redis生成页面或执行请求或由用户触发。在这个例子中，WEB应用链接了Redis和不可信的客户端。
这是一个特定的例子，但是一般来说，不授信的Redis链接应该被监控，验证用户输入，再决定执行什么样的操作。因为，Redis追求的不是最大的安全性，而是简洁与高效。
网络安全
Redis链接应该对每个受信的客户端开放。所以，服务器运行的Redis应该只被使用Redis应用的计算机连接。在大多数直接暴露在互联网的单个计算机，例如，虚拟化的LINUX实例(LINODE，EC2，…..)
Redis端口应该被防火墙阻止来自外部的访问。客户端应该仍然能通过服务器的本地回环接口访问Redis。注意，通过在Redis.CONF添加下面一句就可以绑定本地回环，阻止外网访问了。
bind 127.0.0.1
因为Redis的特性，没有对外网访问进行限制会是一个很重大的安全问题。例如一条简单的FLUSHALL命令就能被攻击者用来删除整个数据设置。
身份验证机制
如果你们不想使用访问限制的话，Redis提供了一个身份验证功能，可以通过编辑Redis.CONF文件来实现它。
如果开启了身份验证功能，Redis将拒绝所有的未身份验证的客户端的所有操作。客户端可以发送AUTH命令+密码来验证自己。
密码是由系统管理员在Redis。CONFIG文件中设置的明文密码，为了防止暴力破解攻击他应该足够长。原因有两个：
Redis的执行效率非常快，外部设备每秒可以测试相当数量的密码
Redis的密码是存储在Redis.conf文件和内部客户端的配置中的，因此不需要管理员记住。所以可以使用相当长的密码。
身份验证的目标是提供第二层的安全保障。这样当防火墙或者其他第一层的系统安全设置失效的话，一个外部设备在没有密码的情况下仍然不能访问redia。
AUTH命令像其他的redia命令一样是不加密传输的，所以他不能阻止攻击者在内网的窃听。
