Redis权限漏洞到底有多严重，访问控制还差多少才能放心用

关于Redis权限漏洞的严重性以及访问控制现状的问题,我们需要结合其历史设计、常见的使用场景以及近年来的改进来综合判断，在过去，Redis的权限漏洞问题极其严重，甚至可以被称为系统安全的“隐形炸弹”，但经过多个版本的迭代，其安全性已经有了显著提升，不过若配置不当，依然存在不小的风险。

Redis权限漏洞曾经有多严重？

Redis权限漏洞的严重性根植于其最初的设计哲学,Redis的开发者Salvatore Sanfilippo（别名antirez）在早期曾明确表示，他更倾向于将Redis设计为一个被信任环境内部使用的、高性能的数据结构服务器，而非一个直接暴露在公网、需要应对复杂攻击的数据库，这种设计思路直接导致了Redis在很长一段时间内，其安全模型非常简陋，甚至可以说“默认不安全”，具体体现在以下几个方面，这些内容在众多安全研究文章和漏洞报告中都有提及，例如在知名安全社区如FreeBuf、安全客以及CNVD（国家信息安全漏洞共享平台）收录的相关漏洞中均有体现：

1. 默认无密码验证（空密码）：这是最核心也是最危险的一点，在Redis 3.2版本之前，默认配置下，Redis服务启动后是完全没有密码保护的，任何能够通过网络连接到Redis服务器端口的客户端，都可以直接执行任意命令，拥有完全的读写权限，这相当于把自家保险柜的大门敞开，放在人来人往的街道上。

2. 默认绑定所有网络接口（0.0.0.0）：早期版本中，Redis默认监听0.0.0地址，这意味着它不仅接受本地连接，也接受来自网络上任何其他主机的连接，当“空密码”和“绑定所有接口”这两个默认设置组合在一起时，灾难就发生了，一旦管理员疏忽，将带有这种默认配置的Redis服务器部署在具有公网IP的机器上，它就会瞬间成为全球黑客扫描器眼中的“肉鸡”。

3. 利用CRON任务实现权限提升：这是Redis早期一个非常经典且危害极大的攻击手法，攻击者一旦能够连接到未授权访问的Redis，就可以利用Redis的CONFIG命令修改数据库的持久化文件路径和文件名，例如将其设置为/var/spool/cron/crontabs/root（Linux系统的root用户定时任务文件），再通过SET命令将一条恶意命令（如反弹shell的指令）写入数据库，最后通过SAVE命令强制Redis将内存数据持久化到磁盘，由于Redis进程通常以root或较高权限运行，它有权覆盖crontab文件，这样，攻击者就能成功在目标服务器上植入一个定时任务，从而获得服务器的最高控制权，根据2015年左右广泛传播的安全预警文章《Redis未授权访问漏洞》中的描述，这种攻击方式成功率极高，危害巨大。

4. 写入SSH公钥：与上述方法类似，攻击者可以将Redis的持久化文件路径设置为root用户的SSH公钥文件（/root/.ssh/authorized_keys），然后将自己生成的SSH公钥内容写入Redis，并持久化到该文件，这样，攻击者就可以直接使用对应的私钥通过SSH无密码登录到服务器。

在Redis的“蛮荒时代”，一个未授权访问漏洞足以导致整个服务器沦陷，其严重性等同于系统最高权限的漏洞，乌云漏洞平台（已关闭）等历史安全平台上曾披露过大量因此导致的真实案例。

访问控制还差多少才能放心用？

经过多年的发展和安全事件的警示,Redis开发团队在访问控制方面做出了重要改进，现在距离“放心用”还有多远？答案是：只要正确配置，已经可以相当放心地用于多数场景，但“默认安全”仍有距离，人为失误的风险依然存在。

近年来Redis引入的关键改进包括：

1. 引入保护模式（Protected Mode）：从Redis 3.2版本开始，Redis引入了一个至关重要的安全特性——保护模式，当Redis没有设置密码（requirepass），并且默认绑定所有接口（bind 0.0.0.0）时，它会自动进入保护模式，在此模式下，Redis只会接受来自本地回环地址（127.0.0.1）和Unix Socket的连接，拒绝来自其他外部IP的请求，这极大地降低了因管理员忘记设置密码而直接暴露在公网的风险，这可以说是Redis迈向“默认更安全”的一大步。

2. 更安全的默认绑定：在新版本的安装包或官方Docker镜像中，有时会默认将bind配置为0.0.1或::1（IPv6回环地址），仅允许本地访问，进一步收紧了口子。

3. 认证机制的强化：密码认证（AUTH命令）一直是可用的，但现在文档和社区都强烈推荐必须设置一个强密码，Redis 6.0引入了ACL（访问控制列表）功能，这是一个里程碑式的改进，在ACL之前，Redis的权限是“一刀切”的：要么有密码，拥有所有权限（读写执行所有命令）；要么没密码，什么都做不了，而ACL允许管理员创建多个用户，并为每个用户精细地分配权限，

   • 可以创建只能读取特定键前缀的只读用户。
   • 可以禁止用户执行危险的命令,如FLUSHALL（清空所有数据）、CONFIG（修改配置）等。
   • 可以实现更细粒度的访问控制,满足多租户等复杂场景的安全需求。

“还差多少”？

主要的差距已经不在于Redis软件本身的功能,而在于使用者和使用方式：

• 配置的复杂性：ACL功能虽然强大，但也增加了配置的复杂性，对于简单的应用，管理员可能仍然倾向于只使用一个密码，而不是去配置一套复杂的ACL规则，如何平衡安全性与易用性，是对管理员的考验。
• 人为失误仍是最大风险：即使有了保护模式，如果管理员主动在配置文件里设置了bind 0.0.0.0并且设置了一个弱密码甚至空密码（虽然不推荐），保护模式就会失效，服务依然会暴露在风险中，将Redis错误地部署在公网环境，或者网络防火墙规则设置不当，都是常见的安全隐患。
• 对危险命令的依赖：某些应用程序可能确实需要用到FLUSHDB、CONFIG等危险命令，在ACL中禁用这些命令可能会影响应用功能，不禁用则增加风险，这需要开发者和运维人员共同协商，找到安全的替代方案。
• 网络层面的安全：Redis协议是明文的（尽管Redis 6.0支持了TLS加密，但需要额外配置），在内网环境中可能问题不大，但在跨公网或不信任网络中使用时，必须配合SSL/TLS加密来防止数据窃听和中间人攻击。

结论是,Redis已经提供了足够强大的工具（保护模式、ACL、TLS）来构建一个安全的访问控制体系，一个按照安全最佳实践（强密码、限制绑定IP、使用ACL最小权限原则、网络隔离、启用TLS等）配置的Redis实例，在今天是可以“放心用”的，它还没有达到像一些现代数据库那样“开箱即用”就具备高度安全性的程度，最终的安全水位，取决于使用它的人对安全的理解和重视程度，在宣称“放心”之前，我们必须确保已经正确地实施了这些安全措施。