redis集群总线端口16379不校验密码，requirepass仅作用于客户端端口6379；其安全依赖绑定内网ip、显式配置cluster-announce-ip/port及防火墙严格限制访问源。

Redis集群总线端口（16379）不认密码，别指望requirepass拦住扫描

requirepass只校验客户端端口（6379），对集群总线端口（16379）完全无效。攻击者直连16379就能执行CLUSTER NODES、伪造心跳、触发故障转移——哪怕你所有节点都配了强密码，也拦不住。

常见错误现象：安全扫描工具扫出16379端口开放，返回完整节点列表；或日志里出现大量来自陌生IP的cluster meet请求。

• requirepass必须写在配置文件中，且前后不能加引号；含$、@、#等字符时，命令行启动会截断，实际生效密码可能不对
• 某节点漏配或配错requirepass，CLUSTER NODES会显示noauth，导致槽分配失败甚至集群不可用
• 集群模式下protected-mode yes默认失效——只要配了bind或requirepass，它就自动退出，不拦截任何连接

真正起作用的三道硬防线：绑定 + 广播地址 + 防火墙

集群安全不是靠“设个密码”糊弄过去，得从网络层卡死入口。缺一不可。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 所有节点redis.conf必须显式写bind 10.0.1.50（内网IP），绝不能留空、不能写bind 0.0.0.0或bind ::
• 必须显式配置cluster-announce-ip 10.0.1.50和cluster-announce-port 6379，否则节点可能广播公网地址，把攻击面重新暴露出去
• 防火墙规则要同时放行6379和16379端口，且仅允可信内网IP访问；云环境优先用安全组，物理机用iptables或nftables

为什么代理层或bind 127.0.0.1挡不住集群攻击

把Redis绑到127.0.0.1再套一层反向代理，看似安全，实则失效——代理转发后源IP变成127.0.0.1，防火墙白名单形同虚设；而bind本身只控制TCP连接入口，不区分已连接客户端能发什么命令。

• 集群节点间通信依赖真实内网IP，bind 127.0.0.1会导致节点无法互相发现，集群启动失败
• 即使你用HAProxy解析Redis协议做订阅级拦截，PSUBSCRIBE因通配符特性极难稳定识别，且纯文本协议无固定包头，解析易出错
• 试图用CLIENT LIST定时CLIENT KILL清理恶意连接，属于事后补救——连接已建立，输出缓冲区可能已被拖垮

升级到Redis 8.2.3并禁用高危命令

Redis 8.2.3修复了CVE-2025-62507（远程代码执行漏洞），必须升级。同时，rename-command要用于禁用真正危险的操作。

• 在配置文件中写rename-command FLUSHALL ""和rename-command CONFIG ""，避免攻击者通过CONFIG SET dir写入webshell
• maxclients需按业务实际设上限（如maxclients 500），防止连接数耗尽导致拒绝服务
• 别忽略mem_fragmentation_ratio监控——RSS内存可能比used_memory高30%~50%，maxmemory预留buffer不足会直接触发OOM Killer

最常被忽略的一点：集群总线端口（16379）明文通信、无认证、无加密，它天生就不该暴露——所有防护动作必须围绕“让它只能被内网可信节点访问”展开，而不是幻想它能像6379那样靠密码守门。