共计 986 个字符,预计需要花费 3 分钟才能阅读完成。
昨天有台测试服务器被告知服务异样,进服务器之后才发现是因为 docker 异样退出了。
将 docker 运行起来之后,发现有个不意识的过程 kdevtmpfsi
占用 CPU 异样的多,Google 一下才晓得,好家伙,服务器被当成矿机了。
间接 kill 并不能将其完结掉,它还有守护过程及可能存在的定时工作。
1. 首先查找文件
$ find / -name kinsing // 守护过程
$ find / -name kdevtmpfsi // 挖矿过程
如果 Redis 是运行在本地,下面两个文件通常是在 /tmp/
目录下。
如果 Redis 是以容器的形式运行,则通常是在/var/lib/docker/overlay2/
(容器的 /tmp/
目录)下。
2. 将其删除
$ rm -f kinsing kdevtmpfsi
这里被感化的容器也不肯定是 Redis,比方我的则是 PHP,所以须要进入到被感化的容器内能力找到。
3. 干掉过程
$ ps -aux | grep kinsing
$ ps -aux | grep kdevtmpfsi
$ kill -9 pid
4. 查看定时工作
$ crontab -l
存在定时工作的不肯定是以后用户,能够应用以下命令查找其余用户是否存在工作:
$ for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done
定时工作还可能存在于以下中央:
/etc/crontab
/var/spool/cron/
/var/spool/cron/crontabs/
至此就实现了病毒的清理,网上千篇一律的全是这种解决形式,但这个形式并不适宜我,我尝试了很屡次,无论我怎么删除,病毒还是存在。
因为病毒是依赖于容器生存的,于是我便将容器进行掉,通过docker logs
实时查看容器最初 10 条日志:
docker logs -f -t --tail 10 < 容器 id/ 容器名称 >
十分钟之后,总算让我逮到了:
尽管目击了全过程,但这时我仍然无能为力,因为我不晓得下面那些命令是如何主动启动的。
尝试了各种形式,但都无解,十分钟之后病毒还是会进去,最终我只能把这个被感化的容器给弃用了,从新起一个新的容器。
总结
kdevtmpfsi
病毒的产生,通常是因为 Redis 对外开放 6379
端口,且没设置明码或者明码过于简略导致。
所以服务器肯定要设置好防火墙,像3306
、6379
这种罕用端口,尽量减少对外开放的机会。
参考链接
- Linux.Packed.753
正文完