Redis缓存数据库安全加固指导（一）

背景

在众多开源缓存技术中，Redis无疑是目前功能最为强大，应用最多的缓存技术之一，参考2018年国外数据库技术权威网站DB-Engines关于key-value数据库流行度排名，Redis暂列第一位，可是原生Redis版本在安全方面很是薄弱，不少地方不知足安全要求，若是暴露在公网上，极易受到恶意攻击，致使数据泄露和丢失。

本文主要是在原生开源软件Redis3.0基础上，系统的在安全特性方面进行的加强,不少加强点涉及了开源代码的修改，后续章节阐述的Redis缓存数据库的安全规范, 理论上适用于全部应用Redis的产品。

本系列共连载三篇，分九个章节，本文从合法监听接口，未公开接口，访问通道控制三个章节阐述了Redis缓存数据库加固措施

一、合法监听接口

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.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.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须要有认证保护。