Redis masterauth防未授权同步

Redis作为高性能缓存与消息中间件，一旦暴露在公网且未设置访问密码，攻击者可能在几分钟内完成入侵。很多人只关注requirepass设置登录密码，却忽略了masterauth在哨兵和集群模式下的致命缺口。masterauth配置不当，攻击者无需破解你的应用服务器，直接通过伪造主从同步就能窃取全量数据，甚至写入恶意键值对。这不是理论推演，而是每天都在发生的真实攻击链。

Redis主从复制建立在一条基本信任之上：从节点向主节点发送SYNC或PSYNC命令，主节点就会把内存快照和增量命令流全量推送过去。这个设计在封闭内网里没问题，但一旦端口对外开放，任何能连通你Redis实例的客户端都可以冒充从节点发起同步请求。masterauth的作用就是在这条信任链上增加一道验证：从节点连接主节点时，必须提供正确的密码才能完成身份认证，否则主节点拒绝复制请求。

技术细节上，masterauth并不是独立的认证模块，它和requirepass共用Redis的AUTH命令体系。当你在从节点配置文件中写入masterauth，从节点会在建立复制连接后自动发送AUTH命令，参数就是masterauth的值。主节点收到AUTH后，与自身requirepass进行比对，匹配成功才允许后续同步。如果主节点没有设置requirepass，masterauth配置就形同虚设，因为主节点根本不要求任何认证。

第一种是直接端口扫描加SYNC命令。攻击者使用Masscan或Zmap扫描全网6379端口，对存活的Redis实例发送SYNC命令。如果主节点未设置requirepass，攻击者瞬间就能拿到RDB文件，里面包含所有键值对。这种攻击成本极低，一条命令就能完成，市面上甚至有自动化利用工具，从扫描到拖库全程不超过30秒。

第二种是SLAVEOF劫持。攻击者先连接目标Redis，执行SLAVEOF命令将自己的恶意服务器设为主节点，目标Redis就会主动连接攻击者服务器并同步数据。如果目标Redis配置了masterauth但攻击者控制的“假主节点”不要求认证，同步依然会成功，数据照样流出。更危险的是，攻击者可以在假主节点上写入恶意键值，反向同步回目标Redis，实现数据篡改。

第三种是哨兵模式下的伪造故障转移。攻击者向哨兵发送虚假的主节点下线报告，诱导哨兵发起故障转移，将一个恶意Redis提升为新主节点。如果哨兵配置中未正确设置sentinel auth-pass，或者所有节点的masterauth一致且已被攻击者获取，整个集群的数据流向就会被劫持。这种攻击隐蔽性极强，运维人员可能很久都不会发现主节点已经被替换。

单机主从模式下，主节点redis.conf必须设置requirepass，从节点redis.conf必须设置masterauth，且两者密码必须一致。配置示例如下：

# 主节点 redis.conf
requirepass your_strong_password_here

# 从节点 redis.conf
masterauth your_strong_password_here
replicaof 主节点IP 6379

哨兵模式下，每个哨兵节点的sentinel.conf都需要配置sentinel auth-pass，确保哨兵在监控和故障转移时能够认证主从节点。配置示例：

# sentinel.conf
sentinel monitor mymaster 主节点IP 6379 2
sentinel auth-pass mymaster your_strong_password_here
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000

集群模式下，所有节点的redis.conf都需要设置相同的requirepass和masterauth。集群总线通信同样依赖AUTH认证，任何一个节点缺失配置都会成为攻击入口。集群配置示例：

# 每个集群节点的 redis.conf
requirepass your_strong_password_here
masterauth your_strong_password_here
cluster-enabled yes
cluster-config-file nodes.conf

密码强度方面，建议使用32位以上的随机字符串，包含大小写字母、数字和特殊字符。避免使用弱密码或默认密码，攻击者手里有大量常见密码字典，foobar123这类密码在暴力破解面前不堪一击。可以使用openssl命令生成强密码：

openssl rand -base64 32

配置完成后必须验证主从同步是否正常工作。在主节点执行INFO replication命令，查看connected_slaves数量是否与预期一致，以及每个从节点的状态是否为online。在从节点同样执行INFO replication，确认master_link_status为up，说明认证通过且同步正常。

常见错误之一是masterauth和requirepass密码不一致。从节点日志会出现NOAUTH Authentication required错误，此时检查两端密码是否完全匹配，包括前后空格和不可见字符。另一个常见错误是修改配置文件后只执行了CONFIG REWRITE，没有重启Redis服务。masterauth参数不支持运行时动态修改，必须通过配置文件加载，所以修改后需要重启从节点。

哨兵模式下，如果忘记配置sentinel auth-pass，哨兵在故障转移时无法认证新主节点，导致切换失败。日志中会出现ERR invalid password错误，集群将陷入无主状态。所以每次增加节点或修改密码后，务必同步更新所有哨兵配置并重启哨兵进程。

仅仅配置masterauth还不够，必须配合多层防护才能有效抵御未授权同步攻击。第一层是网络隔离，Redis端口不应直接暴露在公网，使用iptables或安全组规则限制访问来源IP，只允许应用服务器和运维跳板机连接。第二层是rename-command，将危险命令重命名或禁用。至少应该禁用或重命名以下命令：CONFIG、SLAVEOF、REPLICAOF、DEBUG、FLUSHALL、FLUSHDB、SHUTDOWN。配置示例：

# redis.conf 命令重命名
rename-command CONFIG b840fc02d52404542994
rename-command SLAVEOF ""
rename-command REPLICAOF ""
rename-command DEBUG ""
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command SHUTDOWN ""

第三层是定期审计。使用redis-cli连接每个节点，执行CONFIG GET requirepass和CONFIG GET masterauth确认密码设置是否生效。编写自动化脚本定期检查所有Redis实例的认证状态，发现异常立即告警。第四层是开启protected-mode，Redis 3.2及以上版本默认开启此模式，当Redis绑定在0.0.0.0且未设置密码时，只接受本地连接。虽然这不是安全功能的完全替代，但能防止新手误操作导致的直接暴露。

在Kubernetes环境中部署Redis，很多人习惯用ConfigMap挂载配置文件，但密码以明文存储在ConfigMap中会带来新的风险。建议使用Kubernetes Secret存储密码，然后在Pod启动脚本中读取Secret并写入配置文件。Docker容器启动时，可以通过环境变量传递密码，但要注意环境变量也可能被其他容器或进程读取，生产环境建议使用Docker Secret或Vault这类密钥管理服务。

云厂商托管的Redis服务通常默认开启了认证，但用户自定义参数组时可能意外关闭。修改参数组前务必确认requirepass和masterauth相关参数的状态，有些云平台将这两个参数合并为一个统一的密码参数，修改时注意文档说明。跨可用区部署时，主从节点之间的网络延迟增加，但认证过程不会影响同步性能，AUTH命令只在连接建立时执行一次，后续数据流不受影响。

如果怀疑Redis已被未授权同步攻击，首先立即断开可疑从节点的网络连接，在主节点执行CLIENT LIST查看所有连接的客户端信息，重点关注cmd字段为sync或psync的连接。执行CONFIG SET requirepass临时修改密码，切断攻击者的持续访问。然后从安全的备份中恢复数据，不要直接使用被攻击实例的RDB文件，因为攻击者可能已经写入了持久化的恶意键值。

溯源时检查Redis日志文件，搜索SYNC、PSYNC、SLAVEOF等关键字，定位攻击时间点和来源IP。如果开启了慢查询日志，查看攻击者执行过的命令序列，评估数据泄露范围和篡改程度。同步检查应用服务器的访问日志，因为攻击者获取Redis数据后，很可能进一步渗透应用系统。

预防永远比补救成本低。masterauth配置只需几行文本，却能挡住绝大多数自动化攻击。在安全这件事上，没有过度防护一说，每多一层验证，攻击者的成本就呈指数级上升。你的Redis集群可能运行着千万级QPS的业务，花十分钟检查一下所有节点的masterauth配置，这笔时间投资绝对值得。