Redis 缓存数据库安全加固指导(一)

阅读数:63 2019 年 10 月 21 日 23:47

Redis缓存数据库安全加固指导(一)

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

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

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

一、合法监听接口

01 端口使用非默认端口

安全问题:Redis Server 监听的端口默认为 6379, 容易被扫描攻击。

解决方案:修改为非默认端口,并在端口矩阵中说明。

02 监听地址不允许包括 *

安全问题:Redis 支持监听 0.0.0.0。

解决方案:因为如果有多网卡,应该将监听地址设置为只有数据库客户端需要连接的网卡地址。如果只允许本机访问,应该只监听 127.0.0.1。

03 隐蔽的 RedisCluster 端口

安全问题:官方 RedisCluster 方案缺省会增加一个集群端口,且是在客户端端口偏移 10000,这个问题非常隐蔽。

解决方案:在端口矩阵中对额外的这个集群端口有说明。修改源码, 新增一个 redis.conf 偏移量配置项 cluster-port-increment,缺省配置 +1,这样可以做到端口范围可控,避免冲突。

二、未公开接口

01 账号管理(重要)

安全问题:Redis 只有一个超户,权限过大。

解决方案:权限最小化原则,增加配置项,角色区分超户,普通用户和只读用户三种。

Redis缓存数据库安全加固指导(一)

普通用户不能进行的操作有:

Redis缓存数据库安全加固指导(一)

02 Redis-cli 隐藏密码

安全问题:通过在 redis-cli 指定 -a 参数,密码会被 ps 出来,属于敏感信息。

解决方案:修改 Redis 源码, 在 main 进入后,立即隐藏掉密码,避免被 ps 出来。(可参考开源 Mysql 代码)

03 Redis-cli 工具使用说明

对于需在现网维护阶段使用的命令 / 参数、端口等接入方式(包括但不限于产品的生产、调测、维护用途),需通过产品资料等向客户或监管机构公开或受限公开。

04 禁止在脚本中通过 sudo 方式切换用户执行 redis-cli

安全问题: redis-cli 访问参数带密码敏感信息, 会被 ps 出来, 也容易被系统记录操作日志。

解决方案:改为通过 API 方式 (Python 可以使用 redis-py) 来安全访问, 禁止通过 sudo 方式切换到 dbuser 账号使用 redis-cli。

重现条件:可以通过 iptables 禁掉 redis 端口来模拟重现。

三、访问通道控制

01 预共享秘钥认证(重要)

安全问题:Redis 原生认证存在重放攻击: 只是简单的交互一次 auth xxx

解决方案:采用预共享秘钥 (对称加密算法 + 随机数的双向认证),同时在方案设计上做到最大限度兼容,让客户端改造成本最小,目前平台配套目前支持客户端有:Java,Python,C,Lua。

方案设计如下:

1 Redis 认证协议变更, 其中 auth 命令区分两种功能, 通过首字母区分:

Redis缓存数据库安全加固指导(一)

2 预共享秘钥认证时序图:

Redis缓存数据库安全加固指导(一)

说明: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

02 认证时加上库名

安全问题:Redis 没有库名, 系统如果只通过用户名 + 密码,容易猜测和攻击。

解决方案:通过认证时带上库名, 因为每个服务的库名都配置不同,增加攻击复杂度, 认证格式以 dbname@dbuser@pwd 区分。

03 端口矩阵

安全问题:Redis 也是一种数据库服务,一般一个进程占用一个端口,集群还会额外多占用一个端口。

解决方案:在端口矩阵写明系统申请的 Redis 端口范围。

04 客户端认证超时时间

安全问题:原生 Redis 没有限制客户端认证超时时间, 存在慢攻击。

解决方案:修改源码, 限制在 60 秒内认证成功,否则服务器将主动断开连接。

说明:控制完成客户端认证的时间上限。这可以防止无效客户端长时间占用连接通道。

05 支持 SSL 通信

安全问题:增加 SSL 通信可以提高数据传输的安全。

解决方案:

1 不改动官方源码, 通过在客户端和服务端部署 SSL Proxy,类似 stunnel。

2 支持 SSL 可配置, 涉及开源代码修改。说明: 因为 Redis 属于交互密集型, 每秒处理几万次请求, 支持 SSL 后性能会有比较大损失。

06 支持 ACL 控制

安全问题:目前 Redis 没有 ACL 控制。

解决方案:

1 目前基于平台共享秘钥,其中秘钥是随机生成,每套系统不一样,间接也做到了 IP 范围控制。

2 通过 iptables 控制进一步限制接入 IP 范围。

3 如果要具体控制到用户 +IP 级别,类似 Mysql 认证。作者 antirez 已经意识到这个问题,有望在未来版本提供,链接如下:Multi users AUTH and ACLs for Redis( https://github.com/redis/redis-rcp/blob/master/RCP1.md)

07 Jedis 客户端相关

对于需在现网维护阶段使用的命令 / 参数、端口等接入方式(包括但不限于产品的生产、调测、维护用途),需通过产品资料等向客户或监管机构公开或受限公开。

08 集群认证相关

1 RedisCluster 多主多从, 内部高度自制,因此 Redis 的认证 masterauth 需要加密保存到配置文件。

2 配置集群关系时, 基于 Gossip 协议,Cluster meet 需要有认证保护。

本文转载自公众号中间件小哥(ID:huawei_kevin)。

原文链接:

https://mp.weixin.qq.com/s/Jqoi3JfJGJicFxR7aNYTZQ

评论

发布