Redis密码泄露应急处理，重置权限清空缓存

知识分享

2026-09-23 12:40

38 阅读

发现Redis密码可能泄露时，第一反应不应是直接重启服务，而是按顺序完成三件事：切断外部访问、重置认证密码、清理可能被污染的数据。
本文面向零基础运维人员，给出可直接执行的命令和配置片段，帮你把风险降到最低。

先判断泄露范围与当前风险

在动手修改之前，先确认Redis是否暴露在公网以及是否已开启密码认证。
登录服务器，执行以下命令查看监听端口和绑定地址：

ss -tlnp | grep redis

如果输出显示 0.0.0.0:6379 或 *:6379，说明Redis正在监听所有网络接口，风险较高。
接着检查配置文件中的认证设置：

redis-cli -h 127.0.0.1 -p 6379 ping

如果返回 PONG 且未提示需要认证，说明当前没有设置密码，任何能访问到端口的人都能操作数据。
此时应立即进入下一步。

修改密码需要编辑Redis配置文件，通常路径为 /etc/redis/redis.conf 或 /etc/redis/6379.conf。
用编辑器打开后找到 requirepass 行，如果没有则手动添加：

requirepass 你的新密码

新密码建议使用16位以上随机字符串，避免使用纯数字或常见词汇。
同时将 bind 指令改为仅监听本机或内网地址：

bind 127.0.0.1

如果业务需要远程连接，至少限制为内网IP段，并配合防火墙规则。
保存文件后重启Redis服务：

systemctl restart redis

重启后验证密码是否生效：

redis-cli -h 127.0.0.1 -p 6379 ping

此时应返回 NOAUTH Authentication required.，说明密码已启用。

密码泄露期间，攻击者可能写入恶意键或利用Redis的持久化功能写入文件。
先列出所有键，评估数据量：

redis-cli -a 你的新密码 keys '*'

如果数据量不大且业务允许，直接清空当前数据库：

redis-cli -a 你的新密码 flushall

注意 flushall 会删除所有数据库的数据，执行前确认没有关键业务数据仅存于Redis中。
如果只想清空当前库，使用 flushdb。

接着检查持久化文件是否被篡改。
查看Redis配置中的 dir 路径，默认可能是 /var/lib/redis 或 /data。
列出该目录下的 dump.rdb 和 appendonly.aof 文件，确认修改时间是否异常。
必要时可备份后删除，让Redis重新生成：

mv /var/lib/redis/dump.rdb /var/lib/redis/dump.rdb.bak

密码重置和缓存清理只是应急，长期安全还需要做几件事。
禁用危险命令，在配置文件中添加：

rename-command FLUSHALL ""
rename-command CONFIG ""

这样即使密码再次泄露，攻击者也无法直接清空数据或修改配置。
同时确保Redis以非root用户运行，检查服务启动用户：

ps aux | grep redis

验证加固效果时，从外部网络尝试连接，应出现连接超时或被拒绝。
最后查看Redis日志，确认没有异常登录记录：

tail -n 50 /var/log/redis/redis-server.log

如果日志中出现大量来自陌生IP的 AUTH 失败记录，说明之前确实被扫描过，建议进一步排查服务器上是否有其他后门。

关键提醒：完成上述步骤后，务必通知相关应用更新连接密码，否则业务会因认证失败而中断。
测试应用连接正常后，再观察一段时间Redis的CPU和内存使用情况，确认没有残留的异常任务。

修改密码后需要重启Redis吗？
通过配置文件修改 requirepass 必须重启服务才能生效。如果使用 CONFIG SET requirepass 命令动态修改，则无需重启，但重启后会丢失，因此建议以配置文件为准。

清空缓存后业务变慢怎么办？
缓存清空后，所有请求会直接落到数据库，可能导致数据库压力骤增。建议在低峰期操作，或提前做好数据库慢查询优化。如果Redis承载的是会话数据，清空会导致用户掉线，需提前公告。

如何确认密码是否真的泄露了？
检查Redis日志中的 AUTH 失败记录和连接来源IP。如果存在大量来自非业务IP的尝试，基本可以判定被扫描。另外查看 keys * 是否有陌生键名，如 backup、crack 等。

还需要做端口防护吗？
即使设置了强密码，也建议用防火墙限制6379端口的访问来源。例如使用 iptables 只允许特定内网IP访问：

iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

完成以上操作后，Redis密码泄露的应急处理基本结束。
核心原则是：先隔离、再改密、后清理，每一步都要验证结果，避免遗漏导致二次风险。