redis裸奔公网未设密码,被入侵写入挖矿任务案例复盘
Redis 裸奔在公网且未设置访问密码,是目前云服务器被植入挖矿任务最常见的入口之一。
攻击者扫描到开放的 6379 端口后,通过未授权访问直接写入 crontab 定时任务,拉取挖矿程序运行。
本文用一个典型入侵场景复盘完整过程,并给出零基础用户也能照做的排查、清理和加固步骤。
这次入侵是怎么发生的
很多 Redis 教程只教 redis-server 启动服务,却没有强调默认配置下 Redis 会监听所有网卡,并且不需要密码。
攻击者使用扫描脚本批量检测公网 IP 的 6379 端口,发现开放端口后,执行类似下面的命令写入定时任务:
redis-cli -h 受害IP -p 6379
set mykey "\n* * * * * /tmp/kinsing\n"
config set dir /var/spool/cron/
config set dbfilename root
save
定时任务被写入后,服务器每分钟都会去下载并执行挖矿程序。
这里要明确一句结论:Redis 允许任意来源 IP 未授权访问,一旦暴露到公网,就等于把服务器控制权间接交给了攻击者。
先别急着杀进程,把痕迹查清楚
遇到服务器 CPU 飙升,第一件事不是直接 kill,而是先确认入侵面。
登录服务器后,按顺序执行以下检查:
# 查看 CPU 占用靠前的进程
top -c
# 查看当前用户的定时任务
crontab -l
# 查看系统级定时任务
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /var/spool/cron/
挖矿进程通常伪装成 kdevtmpfsi、kinsing、xmrig 等名字,注意观察 /tmp、/var/tmp 下是否有最近生成的二进制文件:
ls -la /tmp /var/tmp
同时用 netstat -lnpt 检查 Redis 是否真的在监听 0.0.0.0:6379。
这一步属于“取证”,目的是确认恶意定时任务来自哪个文件,避免清理不干净导致进程反复复活。
清理挖矿进程和定时任务
确认异常进程和定时任务后,按顺序执行清理。
先杀掉进程,再删除定时任务文件,顺序不能反过来:
# 找到挖矿进程 PID,例如 2345
kill -9 2345
# 删除当前用户 crontab 中的恶意行
crontab -e
如果恶意任务写在 /var/spool/cron/root,可以直接编辑对应文件删除恶意行。
对于攻击者留下的二进制文件,建议先复制文件路径再删除:
rm -f /tmp/kinsing /tmp/kdevtmpfsi
挖矿任务多数通过写入 crontab 实现持久化,
不清理定时任务,
进程杀掉后会马上复活。 因此清理后要再次执行 crontab -l 确认没有遗留条目,
也可以通过 cat /var/spool/cron/root 复查。
Redis 加固:三条配置细节堵住入口
清理现场只是第一步,不修复 Redis 配置,服务器很快会被再次入侵。
找到 Redis 配置文件,常见路径为 /etc/redis/redis.conf 或宝塔面板的 /www/server/redis/redis.conf,修改以下三项:
# 只监听本机或内网 IP,不要监听 0.0.0.0
bind 127.0.0.1
# 开启保护模式
protected-mode yes
# 设置强密码,长度至少 16 位
requirepass 你的复杂密码
修改后重启 Redis 服务:
systemctl restart redis
这里有一个高频坑:修改配置后不重启,或者重启后仍监听公网 IP,加固都不会生效。 重启后必须用下面的命令验证:
netstat -lnpt | grep 6379
redis-cli -h 127.0.0.1 -a 你的密码 ping
期望输出是 Redis 只监听 127.0.0.1,并且 PONG。
如果 Redis 需要被其他服务器访问,可以绑定内网 IP,而不是暴露到公网;
同时通过云安全组或防火墙限制 6379 端口只允许指定来源 IP 访问。
复查节点:哪些指标代表服务器已恢复正常
清理和加固完成后,建议观察 30 分钟以上,重点复查如下指标:
top中已无异常进程,CPU 使用率回落到正常水平。crontab -l和/var/spool/cron/中无恶意任务。- Redis 端口不再对外监听,外部扫描不到 6379。
- 服务器访问异常、流量异常的情况消失。
另外,入侵后要尽快修改服务器 root 密码和 Redis 密码,并检查是否有其他未授权服务,比如 MongoDB、Elasticsearch 等。
新手最容易忽略的几个细节
有人会问:为什么我设置了 requirepass,公网还是能连接?
大概率是 protected-mode yes 没有开启,或者 bind 仍配置成 0.0.0.0。
也有人清理完定时任务但不改 Redis 密码,结果几小时后挖矿进程又出现。安全修复必须“清理 + 加固 + 验证”一起完成,缺少任何一环都可能再次被入侵。
如果你今天刚发现 Redis 被入侵,先按本文步骤切断攻击入口,再逐步排查其他可疑文件。
处理完以后,建议定期查看 auth.log 或 secure 日志,养成关注服务器端口开放情况的好习惯。