Redis 默认配置下如果直接暴露在公网，攻击者通过 6379 端口就能在几分钟内完成入侵。常见的攻击路径并不是什么高深漏洞，而是利用未授权访问直接执行 FLUSHALL 清库、通过 CONFIG SET 写入计划任务、写入 SSH 公钥或者植入挖矿脚本。真正需要优先解决的是网络暴露面、认证缺失和高危命令未禁用这三件事。
网络层隔离是第一步
Redis 本身不适合直接面对公网，最有效的防护是把 Redis 绑定在内网网卡上。修改 redis.conf 中的 bind 参数，只监听业务服务器所在的私网地址，而不是 0.0.0.0。如果业务架构确实需要跨主机访问，应当通过安全组或防火墙限制来源 IP，只允许应用服务器访问 6379 端口。云环境下不要依赖 Redis 自带的安全机制去对抗公网扫描，安全组规则要精确到具体 IP 或网段，拒绝任何陌生来源。
同时关闭默认端口对外映射。很多入侵事件并不是针对 Redis 漏洞，而是公网扫描发现 6379 开放后直接尝试未授权连接。改端口只能降低扫描命中率，不能作为主要防线，但配合 IP 白名单可以显著减少噪音攻击。
强制开启认证并设置高强度密码
Redis 的 requirepass 参数必须开启。未设置密码时，任何能连上端口的人都可以执行全部命令。设置密码时不要使用常见弱口令，因为 Redis 的认证是明文传输，密码强度直接决定暴力破解成本。建议使用 32 位以上的随机字符串，并定期轮换。需要注意，requirepass 只提供单层密码认证，不支持用户分级，因此密码泄露等同于完全失陷。
在配置密码后，客户端连接需要通过 AUTH 命令认证。应用程序连接池要统一配置密码，避免硬编码在代码仓库中。可以使用环境变量或配置中心注入，防止源码泄露导致密码外泄。对于主从复制架构，masterauth 也要设置，否则从节点无法在带密码的主节点上完成复制。
重命名或禁用高危命令
Redis 中有一批命令可以直接改写持久化文件、修改配置或清空数据，属于高危操作。CONFIG、FLUSHALL、FLUSHDB、SHUTDOWN、DEBUG、KEYS 等命令在生产环境中应当按需处理。通过 rename-command 可以将命令重命名为只有运维知道的随机字符串，或者直接禁用为空字符串。
rename-command CONFIG "CONFIG_9f2b7c1e" rename-command FLUSHALL "" rename-command FLUSHDB "" rename-command SHUTDOWN "" rename-command DEBUG ""
重命名 CONFIG 后，攻击者即使拿到认证也无法通过 CONFIG SET 修改持久化路径写入恶意文件。禁用 FLUSHALL 和 FLUSHDB 可以防止数据被一键清空。KEYS 命令在生产环境会造成阻塞，也建议重命名或禁用，改用 SCAN 做遍历。需要注意的是，重命名命令后，运维脚本和监控工具也要同步调整，否则会影响正常运维。
限制 Redis 运行权限与文件系统隔离
Redis 进程不应当以 root 用户运行。创建独立的 redis 用户，限制其家目录和文件写入权限。即使攻击者通过 Redis 写入文件，也只能在 redis 用户权限范围内操作，无法直接写入 /etc/crontab 或 /root/.ssh/authorized_keys。同时将 Redis 的工作目录设置为独立挂载的分区或受限目录，避免攻击者通过 CONFIG SET dir 切换到敏感目录。
在 systemd 或 supervisor 中配置 Redis 服务时，可以加入 NoNewPrivileges、PrivateTmp、ProtectSystem 等安全加固参数，进一步限制进程能力。容器化部署时不要使用 privileged 模式，只挂载必要的数据卷，并设置只读根文件系统。
开启保护模式与最小化配置
Redis 默认开启 protected-mode，当没有设置密码且没有绑定具体 IP 时，Redis 只允许本地回环连接。但很多运维在配置时关闭了保护模式，或者设置了 bind 0.0.0.0 后忘记设置密码，导致保护模式失效。正确的做法是始终显式配置 bind、requirepass 和 protected-mode，三者配合使用，避免依赖单一配置项。
另外要精简 Redis 的配置项，关闭不用的功能。例如不需要持久化时不要开启 RDB 和 AOF，减少文件写入面。不需要主从复制时不要开放 replicaof 相关配置。关闭 Lua 脚本的全局变量污染风险，限制脚本执行时间，防止通过 EVAL 执行死循环拖垮实例。
数据持久化文件的安全防护
RDB 和 AOF 文件包含完整数据内容，一旦泄露等同于数据库被拖走。持久化文件要存放在权限严格的目录中，仅 redis 用户可读写。定期备份时，备份文件要加密存储，传输过程使用内网通道或加密协议。对于云环境，快照和对象存储桶要设置私有访问权限，避免公开读取。
攻击者常利用 CONFIG SET dir 和 CONFIG SET dbfilename 将 RDB 文件写入 Web 目录或计划任务目录，实现 getshell。禁用 CONFIG 命令后，这条攻击链基本被切断。如果业务必须保留 CONFIG 命令，可以通过 ACL 限制只有特定管理连接才能执行，而不是所有客户端都能调用。
使用 ACL 实现细粒度权限控制
Redis 6.0 以上版本支持 ACL 用户体系，可以创建多个用户并分配不同权限。生产环境应禁用默认用户，为应用程序创建只具备必要命令权限的用户，为运维创建具备管理权限的独立用户。ACL 可以精确到命令级别和键模式级别，例如只允许应用用户对特定前缀的键执行读写操作。
user default off user appuser on >app_password ~cache:* +get +set +del +expire user opsuser on >ops_password allcommands allkeys
这样即使应用服务器被入侵，攻击者拿到的 appuser 账号也无法执行 CONFIG、FLUSHALL 等管理命令，只能操作 cache 前缀的键。ACL 规则可以通过文件持久化，并在运行时通过 ACL SETUSER 动态调整。对于多租户共用一个 Redis 实例的场景，ACL 是必须启用的隔离手段。
传输加密与客户端连接安全
Redis 原生协议是明文传输，密码和数据在网络上可以被抓包获取。如果 Redis 与客户端之间跨公网或跨安全域通信，应当使用 TLS 加密。Redis 6.0 以上版本原生支持 TLS，可以在配置中指定证书和私钥。对于旧版本，可以通过 stunnel 或 Spiped 等工具建立加密隧道。
内网环境下如果抓包风险较低，可以暂不启用 TLS，但至少要保证网络隔离到位。云上跨可用区通信建议开启 TLS 或使用云厂商的私有网络加密能力。客户端连接池要配置连接超时、空闲超时和最大连接数，防止连接泄漏和资源耗尽。
实时监控与入侵检测
安全防护不能只靠配置，还需要持续的监控和告警。对 Redis 的关键指标进行监控，包括连接数、命令执行频率、内存使用率、持久化文件大小变化等。异常的命令模式，如短时间内大量 FLUSHALL、CONFIG SET、EVAL 调用，应当触发告警。可以通过 Redis 的 MONITOR 命令采集命令日志，但生产环境 MONITOR 性能开销较大，建议使用审计插件或代理层记录。
日志方面，Redis 默认日志级别为 notice，可以调整为 warning 或更高级别，减少噪音。同时将日志输出到集中式日志平台，便于关联分析。对于主从复制异常、认证失败、RDB 保存失败等事件要重点监控。认证失败次数突增通常意味着暴力破解正在进行。
定期更新与漏洞响应
Redis 官方会定期发布安全更新，修复已知漏洞。例如整数溢出、Lua 沙箱逃逸、主从复制协议缺陷等问题都曾出现在历史版本中。生产环境应保持 Redis 版本在官方支持范围内，并及时应用安全补丁。升级前在测试环境验证兼容性，尤其是主从复制和持久化格式的兼容。
建立漏洞响应流程，一旦发现 Redis 相关漏洞公告，立即评估自身暴露面和受影响版本。对于无法立即升级的场景，通过配置调整、命令禁用或网络隔离进行临时缓解。安全团队要定期对 Redis 实例进行配置核查和渗透测试，验证防护措施是否真正生效。
备份恢复与业务连续性
安全防护的最后一环是备份和恢复能力。即使发生数据被清空或加密勒索，只要有可靠的备份就能快速恢复。RDB 快照和 AOF 日志要定期备份到独立存储，备份保留周期至少覆盖业务可接受的数据丢失窗口。定期进行恢复演练，确认备份文件可用、恢复流程顺畅。
备份文件本身要加密并限制访问权限，防止备份泄露成为另一个攻击入口。对于关键业务，可以考虑异地容灾和实时同步，将 RPO 和 RTO 控制在分钟级。主从复制虽然能提供数据冗余，但不能替代备份，因为主节点的删除操作会同步到从节点。
Redis 的安全防护本质上是一个纵深防御体系，从网络隔离、认证授权、命令管控到监控审计和备份恢复，每一层都不能缺失。单独开启密码或单独改端口都无法抵御有目的的攻击。只有把 Redis 当作一个需要持续加固和监控的生产系统来对待，才能真正降低缓存层被入侵的风险。
