Redis缓存数据库安全加固指导（一）
背景
在众多开源缓存技术中，Redis无疑是目前功能最为强大，应用最多的缓存技术之一，参考2018年国外数据库技术权威网站DB-Engines关于key-value数据库流行度排名，Redis暂列第一位，但是原生Redis版本在安全方面非常薄弱，很多地方不满足安全要求，如果暴露在公网上，极易受到恶意攻击，导致数据泄露和丢失。
本文主要是在原生开源软件Redis3.0基础上，系统的在安全特性方面进行的增强,很多增强点涉及了开源代码的修改，后续章节阐述的Redis缓存数据库的安全规范, 理论上适用于所有应用Redis的产品。
本系列共连载三篇，分九个章节，本文从合法监听接口，未公开接口，访问通道控制三个章节阐述了Redis缓存数据库加固措施
1、合法监听接口
1.1 端口使用非默认端口
安全问题：Redis Server监听的端口默认为6379,容易被扫描攻击。
解决方案：修改为非默认端口，并在端口矩阵中说明。
1.2 监听地址不允许包括*
安全问题：Redis支持监听0.0.0.0。
解决方案：因为如果有多网卡，应该将监听地址设置为只有数据库客户端需要连接的网卡地址。如果只允许本机访问，应该只监听127.0.0.1。
1.3 隐蔽的RedisCluster端口
安全问题：官方RedisCluster方案缺省会增加一个集群端口，且是在客户端端口偏移10000，这个问题非常隐蔽。
解决方案：在端口矩阵中对额外的这个集群端口有说明。修改源码,新增一个redis.conf偏移量配置项cluster-port-increment，缺省配置+1，这样可以做到端口范围可控，避免冲突。
2、未公开接口
2.1 账号管理(重要)
安全问题：Redis只有一个超户，权限过大。
解决方案：权限最小化原则，增加配置项，角色区分超户，普通用户和只读用户三种。
|
角色 |
redis.conf对应配置项 |
权限说明 |
|
超户 |
requirepass |
所有功能。 |
|
普通用户 |
requireuserpass |
不能进行管理类命令，如shutdown等 |
|
只读用户 |
requirereaduserpass |
在普通用户基础上，进一步限制只能进行读操作。没有script命令权限。 |
普通用户不能进行的操作有：
|
命令 |
解释 |
|
save |
SAVE 命令执行一个同步保存操作，将当前Redis 实例的所有数据快照(snapshot) 以RDB 文件的形式保存到硬盘。 |
|
bgsave |
在后台异步(Asynchronously) 保存当前数据库的数据到磁盘。 |
|
bgrewriteaof |
执行一个AOF 文件重写操作。重写会创建一个当前AOF 文件的体积优化版本。即使BGREWRITEAOF 执行失败，也不会有任何数据丢失，因为旧的AOF 文件在BGREWRITEAOF 成功之前不会被修改。 |
|
shutdown |
停止所有客户端 如果有至少一个保存点在等待，执行SAVE 命令 如果AOF 选项被打开，更新AOF 文件 关闭redis 服务器(server) |
|
sync |
用于复制功能(replication) 的内部命令。 |
|
psync |
用于复制功能(replication) 的内部命令。 |
|
replconf |
暂无用处 |
|
monitor |
实时打印出Redis 服务器接收到的命令，调试用。 |
|
slaveof |
SLAVEOF 命令用于在Redis 运行时动态地修改复制(replication) 功能的行为。 |
|
debug |
调试命令 |
|
config |
配置参数 |
|
restore |
反序列化给定的序列化值，并将它和给定的key 关联。 |
|
migrate |
将key 原子性地从当前实例传送到目标实例的指定数据库上，一旦传送成功，key 保证会出现在目标实例上，而当前实例上的key 会被删除。 |
|
dump |
序列化给定key ，并返回被序列化的值，使用RESTORE 命令可以将这个值反序列化为Redis 键 |
2.2 Redis-cli隐藏密码
安全问题：通过在redis-cli指定-a参数，密码会被ps出来，属于敏感信息。
解决方案：修改Redis源码,在main进入后，立即隐藏掉密码，避免被ps出来。(可参考开源Mysql代码)
2.3 Redis-cli工具使用说明
对于需在现网维护阶段使用的命令/参数、端口等接入方式（包括但不限于产品的生产、调测、维护用途），需通过产品资料等向客户或监管机构公开或受限公开。
2.4 禁止在脚本中通过sudo方式切换用户执行redis-cli
安全问题： redis-cli访问参数带密码敏感信息,会被ps出来,也容易被系统记录操作日志。
解决方案：改为通过API方式(Python可以使用redis-py)来安全访问,禁止通过sudo方式切换到dbuser账号使用redis-cli。
重现条件：可以通过iptables禁掉redis端口来模拟重现。
3、访问通道控制
3.1 预共享秘钥认证(重要)
安全问题：Redis原生认证存在重放攻击:只是简单的交互一次auth xxx
解决方案：采用预共享秘钥(对称加密算法+随机数的双向认证)，同时在方案设计上做到最大限度兼容，让客户端改造成本最小，目前平台配套目前支持客户端有:Java，Python，C，Lua。
方案设计如下:
Redis认证协议变更,其中auth命令区分两种功能,通过首字母区分：
|
auth命令含义 |
区分 |
|
认证第一阶段:客户端传递随机数 |
请求:auth <RAND_C 响应:-ERR >TokenBA |
|
认证第二阶段 |
auth >TokenAB |
预共享秘钥认证时序图
说明：Redis为文本协议, 安全随机数长度固定为32字节的可显示字符串，连接2个随机数的分隔符为”@”。
主要认证流程：
1.客户端向服务端执行命令: auth <RAND_C
1) 首字母<表示是认证第一阶段。(便于服务端从协议层区分)
2) RAND_C表示客户端生成安全随机数。
2.服务端产生响应错误回复
1) 获取RAND_C,并生成RAND_S
2) 产生TokenBA=AES128(RAND_S@RAND_C)
3) 响应错误回复:-ERR >TokenBA
说明:错误描述为服务端生成的安全随机数。
3.客户端验证
1) 验证TokenBA是否合法
解密出RAND_S@RAND_C，看看RAND_C是否是自己生成的随机数
2) 客户端产生TokenAB=AES128(RAND_C@RAND_S@dbname@ossdbuser@pwd)
3) 调用认证接口: auth >TokenAB
4.服务端认证
1) 验证TokenAB是否合法
解密出RAND_C@RAND_S，看看RAND_S是否是自己生成的随机数
2) 验证用户和密码合法性: dbname@ossdbuser@pwd
3.2 认证时加上库名
安全问题：Redis没有库名,系统如果只通过用户名+密码，容易猜测和攻击。
解决方案：通过认证时带上库名, 因为每个服务的库名都配置不同，增加攻击复杂度, 认证格式以dbname@dbuser@pwd区分。
3.3 端口矩阵
安全问题：Redis也是一种数据库服务，一般一个进程占用一个端口，集群还会额外多占用一个端口。
解决方案：在端口矩阵写明系统申请的Redis端口范围。
3.4 客户端认证超时时间
安全问题：原生Redis没有限制客户端认证超时时间,存在慢攻击。
解决方案：修改源码,限制在60秒内认证成功，否则服务器将主动断开连接。
说明: 控制完成客户端认证的时间上限。这可以防止无效客户端长时间占用连接通道。
3.5 支持SSL通信
安全问题：增加SSL通信可以提高数据传输的安全。
解决方案：
1．不改动官方源码,通过在客户端和服务端部署SSL Proxy，类似stunnel。
2．支持SSL可配置,涉及开源代码修改。
说明:因为Redis属于交互密集型,每秒处理几万次请求,支持SSL后性能会有比较大损失。
3.6 支持ACL控制
安全问题：目前Redis没有ACL控制。
解决方案：
1． 目前基于平台共享秘钥，其中秘钥是随机生成，每套系统不一样，间接也做到了IP范围控制。
2． 通过iptables控制进一步限制接入IP范围。
3． 如果要具体控制到用户+IP级别，类似Mysql认证。作者antirez已经意识到这个问题，有望在未来版本提供，链接如下：Multi users AUTH and ACLs for Redis
3.7 Jedis客户端相关
安全问题：官方推荐Java客户端Jedis集群最新版还不支持认证。
解决方案：增加认证参数，与服务端共享秘钥认证保持一致。
安全问题：Jedis认证接口密码为参数string。
解决方案：Jedis客户端认证新增一套char[]接口。
3.8 集群认证相关
1. RedisCluster多主多从,内部高度自制，因此Redis的认证masterauth需要加密保存到配置文件。
2.配置集群关系时,基于Gossip协议，Cluster meet需要有认证保护。
