Redis 安全配置怎么做？生产环境加固 checklist 与漏洞防范
核心回答
Redis 安全配置要从网络隔离、认证授权、数据保护和运行加固四个层面入手。生产环境最低要求三条：绑定内网 IP + 开启密码认证 + 禁用危险命令。做不到这三条，Redis 基本等于裸奔。
2015 年爆发的 Redis 未授权访问漏洞（CVE-2015-4335）让大量服务器被植入挖矿脚本和 SSH 公钥，根源就是默认配置下 Redis 无密码监听所有网卡。这个漏洞至今仍在被批量扫描利用，绝不是历史问题。每次安全加固的第一步，就是确保这三条底线全部到位。
网络层隔离
绑定监听地址
Redis 默认绑定 0.0.0.0，所有网卡都能连，这是最常见的安全隐患。修改 redis.conf：
bind 127.0.0.1 10.0.0.1 protected-mode yes
protected-mode 是 Redis 3.2 引入的保护机制，当 Redis 绑定了非回环地址且没有设置密码时，会拒绝外部连接。这个开关一定要保持开启。
生产环境建议只绑定内网 IP，绝不要直接暴露到公网。如果必须远程访问，走 VPN 或 SSH 隧道。很多 Redis 被入侵的案例就是因为公网暴露了 6379 端口，被扫描器批量发现后利用。
防火墙规则
即使绑定了内网 IP，也要用防火墙做二次防护，这是纵深防御的基本思路：
# iptables 方式 iptables -A INPUT -p tcp --dport 6379 -s 10.0.0.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP # firewalld 方式 firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/24" port protocol="tcp" port="6379" accept' firewall-cmd --reload
云上环境用安全组实现同样的效果，原则是端口最少放开。AWS、阿里云的安全组规则中，Redis 端口只对应用服务器所在子网开放。
TLS 加密传输
Redis 6.0 开始原生支持 TLS，这是生产环境安全加固的重要一环。如果数据经过不可信网络（跨机房、公网），必须开启：
# 生成证书 openssl genrsa -out redis.key 2048 openssl req -new -key redis.key -out redis.csr openssl x509 -req -days 365 -in redis.csr -signkey redis.key -out redis.crt # redis.conf 配置 tls-port 6380 port 0 tls-cert-file /path/to/redis.crt tls-key-file /path/to/redis.key tls-ca-cert-file /path/to/ca.crt
设置 port 0 关闭明文端口，强制所有连接走 TLS。集群模式下还需要配置 tls-cluster yes 和 tls-replication yes。Redis 7.0 进一步增强了 TLS 支持，集群总线通信也可以走加密通道。
认证与授权
密码认证
最基本的安全措施，也是 Redis 安全加固 checklist 的第一条：
# redis.conf requirepass your_strong_password # 运行时设置（重启失效） CONFIG SET requirepass your_strong_password # 连接时指定密码 redis-cli -a your_strong_password
注意：-a 参数会触发警告，密码可能出现在进程列表和日志中。建议用 REDISCLI_AUTH 环境变量代替：
export REDISCLI_AUTH=your_strong_password redis-cli
密码强度要求：至少 16 位，混合大小写字母、数字和特殊字符。requirepass 的密码以明文存储在配置文件中，所以配置文件权限也要收紧。
ACL 精细权限控制
Redis 6.0 引入 ACL（Access Control List），替代了之前只有一个全局密码的模式，是实现 Redis 安全最小权限原则的关键：
# 创建只读用户，只能访问 user: 开头的 key ACL SETUSER readonly on >password1 ~user:* +@read # 创建业务用户，只能操作特定前缀的 key ACL SETUSER app_user on >app_password ~order:* +@read +@write +@string +@hash # 创建管理员 ACL SETUSER admin on >admin_password ~* +@all # 查看所有用户 ACL LIST # 删除用户 ACL DELUSER readonly
ACL 的权限粒度可以精确到命令组和 key 模式。+@read 表示所有读命令，+@write 表示所有写命令，+@all 表示全部命令。用 ACL CAT 查看所有命令组。
实际部署中，为每个业务应用创建独立的 ACL 用户，遵循最小权限原则。一个只做缓存的业务不需要 FLUSHALL 权限。Redis 7.0 还支持 ACL 规则持久化到文件，通过 aclfile 配置项指定，比每次重启都重新配置更可靠。
禁用和重命名危险命令
这是防止 Redis 被攻击者利用的关键配置：
# redis.conf rename-command FLUSHALL "" rename-command FLUSHDB "" rename-command CONFIG "" rename-command SHUTDOWN "" rename-command DEBUG "" # 或者重命名为难猜的名字 rename-command FLUSHALL "a9b8c7d6e5_FLUSHALL"
禁用比重命名更安全。如果用重命名，新的命令名不要出现在代码和日志中。CONFIG 命令尤其危险，攻击者可以通过它修改 requirepass 实现持久化后门——先把密码改成自己知道的值，再修改 dir 指向 /root/.ssh/，dbfilename 设为 authorized_keys，执行 BGSAVE 写入 SSH 公钥。这就是 CVE-2015-4335 的经典攻击链。
数据安全
持久化策略
# RDB 快照 save 900 1 save 300 10 save 60 10000 # AOF 日志 appendonly yes appendfsync everysec
RDB 适合做备份，AOF 适合做数据安全。生产环境建议两者都开，AOF 保证最多丢 1 秒数据，RDB 做快速恢复的兜底。
注意：AOF 文件可能包含敏感数据（如密码明文），需要控制文件访问权限。
加密持久化文件
Redis 本身不提供数据加密，需要在文件系统层面解决：
# 限制文件权限 chmod 700 /var/lib/redis chmod 600 /var/lib/redis/dump.rdb chmod 600 /var/lib/redis/appendonly.aof # 文件系统加密（Linux） # 使用 LUKS 或 eCryptfs 加密 Redis 数据目录
如果数据敏感性高（如用户信息、Token），在写入 Redis 前做应用层加密。读取时解密，Redis 只存密文。这样即使持久化文件被窃取，也无法直接获取明文数据。
备份与恢复
# 定时备份 RDB 0 2 * * * cp /var/lib/redis/dump.rdb /backup/dump_$(date +\%Y\%m\%d).rdb # 备份到远程 rsync -avz /backup/ user@remote:/backup/
备份文件也要控制权限，最好加密后传输。恢复时注意检查 RDB 文件完整性，避免被篡改的备份文件引入恶意数据。用 redis-check-rdb 工具校验 RDB 文件，用 redis-check-aof 校验 AOF 文件。
运行时加固
最小权限运行
# 创建专用用户 useradd -r -s /bin/false redis # 设置文件归属 chown -R redis:redis /var/lib/redis chown redis:redis /etc/redis/redis.conf # 用非 root 用户启动 sudo -u redis redis-server /etc/redis/redis.conf
Redis 不需要 root 权限。用 root 运行 Redis 一旦被攻破，攻击者可以直接拿到服务器控制权，这就是为什么 Redis 安全加固必须包含权限降级。
文件权限收紧
chmod 600 /etc/redis/redis.conf chmod 700 /var/lib/redis chmod 600 /var/log/redis/redis.log
配置文件包含密码等敏感信息，必须限制读写权限。日志文件可能包含查询内容，也要保护。
系统级隔离
用 systemd 的安全选项加强隔离：
[Service] User=redis Group=redis ExecStart=/usr/bin/redis-server /etc/redis/redis.conf ProtectSystem=full ReadWritePaths=/var/lib/redis NoNewPrivileges=true PrivateTmp=true
NoNewPrivileges=true 防止子进程提权，PrivateTmp=true 隔离临时目录。Docker 部署时同理，不要用 --privileged 参数，用 --user 指定非 root 用户，用 --cap-drop=ALL 去掉不必要的 Linux capabilities。
监控与审计
慢查询监控
# redis.conf slowlog-log-slower-than 10000 slowlog-max-len 128 # 查看慢查询 SLOWLOG GET 10
慢查询日志可以帮助发现异常操作。突然出现的慢查询可能是攻击者在执行大量 KEYS * 扫描或 DEL 删除。
Prometheus + Grafana 监控
# prometheus.yml scrape_configs: - job_name: 'redis' static_configs: - targets: ['localhost:9121'] # 告警规则 groups: - name: redis_alerts rules: - alert: RedisTooManyConnections expr: redis_connected_clients > 100 for: 1m labels: severity: warning - alert: RedisSuspiciousCommands expr: rate(redis_commands_processed_total[5m]) > 10000 for: 2m labels: severity: critical
关键监控指标：连接数突增、内存使用异常、命令执行频率异常、主从切换。连接数异常暴增可能是在做端口扫描或暴力破解密码，命令频率异常可能是攻击者在批量导出数据。
操作审计
Redis 本身的审计能力有限，建议在以下层面补充：
- 网络层：记录所有连接来源 IP，排查可疑来源
- 应用层：在业务代码中记录关键操作，特别是写入和删除操作
- 系统层：用 auditd 监控 redis.conf 文件变更，防止配置被篡改
如果合规要求严格，可以考虑 Redis 企业版的审计日志功能，或用第三方审计代理。
集群安全
主从复制认证
# 主节点配置 masterauth your_master_password requirepass your_master_password # 从节点配置 requirepass your_slave_password masterauth your_master_password
主从之间必须设置认证。没有认证的复制关系，攻击者可以伪装成从节点拉取全量数据，这相当于直接把数据库内容交给了攻击者。
哨兵模式安全
# sentinel.conf sentinel auth-pass mymaster your_master_password
哨兵也需要配置认证密码，否则攻击者可以操控哨兵触发故障转移，把主节点切换到自己控制的服务器，实现中间人攻击。
集群模式安全
Redis 7.0 开始支持集群 TLS，集群总线通信也走加密通道：
cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 tls-cluster yes tls-replication yes
集群模式下的安全比单机更复杂，因为节点间通信也需要保护。Redis 7.2+ 还支持集群总线端口的 TLS 认证，确保集群内部通信不被窃听。
安全加固优先级
按紧迫程度排序，这份 Redis 安全加固 checklist 可以直接参考：
- 立即做：绑定内网 IP + 开启密码认证 + 禁用危险命令。不做这三条就是在等被入侵
- 尽快做：配置防火墙 + 使用非 root 用户 + 收紧文件权限。降低被攻破后的影响范围
- 逐步做：开启 TLS + 配置 ACL + 部署监控告警。提升整体安全水位
- 持续做：更新版本修复 CVE + 审计日志 + 定期安全扫描。保持安全性不退化
已知安全漏洞
Redis 历史上几个重要的安全漏洞，面试和实战都会遇到：
- CVE-2015-4335：未授权访问写入 SSH 公钥和 cron 任务，这是最经典也最常被利用的 Redis 安全漏洞。攻击条件极其简单：Redis 暴露公网 + 无密码
- CVE-2022-0543：Debian/Ubuntu 打包的 Lua 沙箱逃逸，可以在 Redis 中执行任意代码。影响范围广，因为大部分 Linux 发行版都用系统包管理器安装 Redis
- CVE-2023-41053：Lua 脚本库堆栈溢出，可导致拒绝服务
- CVE-2025-32023：Redis 7.4.x 之前的 Lua 脚本 eval 逃逸漏洞，最新一轮安全修复
面试中被问到 Redis 安全，提到 CVE-2015-4335 说明你理解问题的根源：默认配置不安全。提到 ACL 说明你跟进 Redis 6.0+ 新版本特性。提到加固优先级说明你有生产环境实战经验。
应急响应
发现 Redis 被入侵时的处理步骤：
- 立即断网：
iptables -A INPUT -p tcp --dport 6379 -j DROP，先止血 - 保留现场：
SLOWLOG GET 100、CLIENT LIST、INFO记录当前状态，为后续分析保留证据 - 检查后门：查 crontab、SSH authorized_keys、.bashrc 是否被篡改，这是 Redis 被入侵后最常见的持久化手段
- 分析入侵路径：检查
CONFIG GET dir和CONFIG GET dbfilename是否被改过，确认数据文件是否被指向了系统敏感目录 - 清除恢复：在确保后门清除后，修改密码重启 Redis，从备份恢复数据
- 加固复盘：按上面的安全加固 checklist 逐项检查，堵住入侵路径
大多数 Redis 被入侵事件的根因都是：公网暴露 + 无密码 + CONFIG 命令可用。攻击者通过 CONFIG SET dir /root/.ssh/ CONFIG SET dbfilename authorized_keys 写入 SSH 公钥实现持久化控制。理解这个攻击链，就知道为什么禁用 CONFIG 命令是 Redis 安全加固的核心措施。