kdevtmpfsi использует весь процессор - PullRequest
Новая
       3

kdevtmpfsi использует весь процессор

2 голосов
/ 10 февраля 2020

Мы используем экземпляр amazon EC2 (Ubuntu) для запуска Apache. Недавно мы заметили, что существует процесс, использующий весь ЦП.

enter image description here

Мы удалили его с помощью следующей процедуры 

[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

Но через несколько минут он снова запустился автоматически. Кто-нибудь знает, как это исправить?

Ответы [ 3 ]

3 голосов
/ 12 февраля 2020

Решение, упомянутое здесь, сработало для нас. Вы в основном создаете файлы, используемые майнером, без каких-либо прав, поэтому майнер не может их создавать и использовать. 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`
1 голос
/ 19 февраля 2020

Другой ответ здесь хорош, и вы должны сделать все, что упомянуто там. Но, если вещь продолжает возвращаться, и / или вы на самом деле не используете Docker, у вас, вероятно, есть не исправленная уязвимость RCE в phpUnit. Подробности здесь:

https://www.sourceclear.com/vulnerability-database/security/remote-code-execution-rce/php/sid-4487

Наша ситуация была такой:

  • Docker не используется вообще.
  • Мы удалили все файлы, относящиеся к майнеру.
  • Мы заблокировали все, используя приведенные выше команды touch и chmod.
  • Чертова штука продолжала пытаться работать на вид случайной раз.

После того, как вы заперли вещи с помощью изменений touch / chmod, он на самом деле ничего не может сделать, но он все еще раздражает, и эта уязвимость phpUnit - ОГРОМНАЯ дыра, которую в любом случае нужно подключить.

Надеюсь, это поможет.

0 голосов
/ 29 апреля 2020

Мне показались полезными все вышеперечисленные решения, но все они, кажется, временное решение, так как нам нужно отслеживать экземпляр, и если мы замечаем какую-либо злонамеренную деятельность, повторите тот же процесс.

Я сталкивался этот вирус около 1 месяца назад и применил все решения, описанные выше, которые прекрасно работают в течение ограниченного периода, после этого он снова придет.

Даже я не установил docker в систему, поэтому docker открыто Порт API не был проблемой.

Но есть некоторые программы с открытым исходным кодом, которые являются открытыми воротами для родства.

PhpMailer и Solr имеют некоторую уязвимость Remote Code Exe c, вызывающую целое проблема.

Простое решение состоит в том, чтобы обновить версию Solr до 8.5.1, и есть еще одна вещь, которую вы можете установить в качестве защиты, которая будет на 100% удалять вирус, и он будет постоянным.

Вот полное объяснение: https://github.com/amulcse/solr-kinsing-malware

...