一次真实的 Redis 入侵：我的服务器是怎么被打进来的，以及我是怎么修的

症状：网站中间空白，刷新也没用#

最先发现的是用户反馈：AI 应用平台打开后只有头尾、中间一片空白，刷新也不行。

“刷新不好使”这个细节很关键——它排除了最常见的”静态资源缓存问题”（那种刷新就好了）。我用无头浏览器渲染页面并对照 nginx 访问日志，发现真正的异常是：

1
GET /api/user/get/login  →  500

前端是”先查登录状态、再渲染主界面”的模式，接口 500，页面就停在空白。

顺着 500 往下挖#

应用日志里的报错很反常：

1
READONLY You can't write against a read only replica.

一台独立部署的 Redis，怎么会是”只读副本”？查复制状态：

1
role:slave
2
master_host:175.24.232.83
3
master_link_status:down

我的 Redis 被人配置成了另一个 IP 的从库——而且那个主库根本连不上。应用往 Redis 写 session 被拒绝，于是接口 500。

SLOWLOG：攻击者留下了完整作案记录#

Redis 的慢日志记下了精确到秒的时间线，两个攻击者，两次入侵：

第二次那两条命令组合是标准的数据外带手法：把被控 Redis 设成攻击者的从库，主库会把全量数据同步过去，等于打包偷走。配套的 stop-writes-on-bgsave-error no 是为了保证 RDB 快照能顺利生成。

回头看，9 月 16 日的 FLUSHDB 其实已经是响亮的警报——那天所有用户都被登出过，只是没人把它和”入侵”联系起来。

入口：一个 2016 年就有的老洞#

弱密码 root，加上 6379 对公网开放。十年前的入侵套路，2026 年照样打得穿。

这里有个很多人栽过的坑：我服务器上 ufw 明明是”默认拒绝”、放行列表里根本没有 6379，为什么外网还是连得上？——Docker 会绕过 ufw。容器把端口发布到 0.0.0.0 时，Docker 直接往 iptables 里插规则，优先级高于 ufw。所以 ufw 界面看着滴水不漏，实际上数据库端口全网裸奔。

取证：先确认失陷范围，再动手修#

确认入侵后我没有急着删删改改，而是先做取证——清了就没了。逐项排查：

• MODULE LIST → 空（无后门模块）
• CONFIG GET dir / dbfilename → 正常值（没被改成写 SSH key / 计划任务的目标路径）
• 挖矿进程、UID=0 异常用户、对外连接（C2/矿池）→ 全部干净
• SSH 七天内无密码登录成功记录，authorized_keys 只有合法密钥
• 计划任务只有腾讯官方组件和证书续期
• Redis 容器非特权模式、独立网络栈 → 没有逃逸到宿主机

结论：失陷范围仅限 Redis。泄露的内容是约 45 个键，几乎全部是 spring:session:*——全部用户的会话令牌，攻击者可以冒充任何已登录用户。而 jar 包里的模型 API Key、对象存储密钥没有经由这条路径泄露。

修复：顺序很重要#

我的处置顺序是止血 → 取证 → 轮换凭据 → 收口网络 → 作废赃物 → 加固入口：

1. 止血：REPLICAOF NO ONE 断开外带通道。一条命令同时止住数据外带和业务中断
2. 凭据轮换：Redis 密码换成 48 位随机值，旧密码实测被拒
3. 收口网络：把 Redis 和 MySQL 的 Docker 端口映射从 0.0.0.0 改绑 127.0.0.1（釜底抽薪，不跟 ufw 缠斗），外网实测两个端口关闭
4. 改应用配置：数据库连接从公网 IP 改为 127.0.0.1——顺便说一句，配置里那个公网 IP 是”服务器连自己”，流量本来就不出机器，改成本地地址是等价且更清晰的
5. 作废赃物：FLUSHDB 清空全部会话。这步最容易被漏掉——不作物废，攻击者偷走的令牌在修复后依然有效
6. 加固入口：SSH 关闭密码登录（只留密钥）、管理面板换随机安全入口 + 开防爆破

修复后全量回归：网站、评论区、AI 平台全部恢复正常。

复盘：三个教训#

1. “看着关了”不等于”关了”。 ufw 显示没放行、外网却能连——Docker 绕过 ufw 是部署期就该知道的坑。端口安全要从外网实测，不能只看防火墙界面。

2. 告警的缺失让事件拖了两天。 9 月 16 日的 FLUSHDB 让所有用户掉线，那本该是发现入侵的时刻，实际却拖到 18 日业务挂掉。键数一夜清零、role 从 master 变 slave、日志出现 READONLY——任何一条接上告警，事件当天就能被处理。

3. 处置顺序决定二次伤害。 先取证再清理（证据不能再生）；先改密码再关端口（单改一样都会留下窗口）；修复完必须作废被窃的凭证（尤其是会话令牌这种”看不见的赃物”）。

给你的清单#

如果你也有公网服务器，花两分钟自查：

1
# 端口从外网实测（不是看防火墙界面）
2
nc -z -w 5 你的服务器IP 6379
3

4
# Redis 弱密码 + 复制状态
5
redis-cli -a 你的密码 INFO replication | grep -E "^role|master"
6

7
# 有没有奇怪的慢日志
8
redis-cli -a 你的密码 SLOWLOG GET 10

数据库端口绑 127.0.0.1、强密码、关 SSH 密码登录——这三件事做完，这类攻击的入口就基本堵死了。

本文细节已做脱敏处理（隐去服务器地址与管理入口）。攻击者 IP 保留原文，作为事件证据。