/etc/rc.d/init.d/wipefs запустите проблему с CPU

Я зафиксировал его путем переименования /etc/rc.d/init.d/wipefs как предложено @Ziazis

Посмотрите в том скрипте, который запущен, это не путь по умолчанию, и при этом это не использует параметры по умолчанию. Так cat /etc/rc.d/init.d/wipefs. Если это не выполняет ничего, что Вы хотите, и Вы не хотите, чтобы это было выполнено в systemstart, просто перемещают его из /etc/rc.d или просто удалите его полностью.

Таким образом, я нашел работу wipefs сервера, оказывается, что это был сценарий, который вошел через устаревший сервис glassfish. Выполненные dpkg - проверяют, чтобы видеть, был ли Ваш пакет поставлен под угрозу. Необходимо будет заставить копию исходного wipefs откладывать корректный файл. Проверьте, что Ваша система не была поставлена под угрозу и удаляет весь/etc/rc* сценарии, которые это создает.

У меня был подобный случай в сервере, работающем java/glassfish. В моем случае wipefs был выполнен/bin/wipefs и также использовал 100% моего ЦП. Я узнал, что эта система была поставлена под угрозу. То, что следует, является самыми важными частями моего расследования.

Типичное расследование, чтобы узнать, является ли это вредоносным кодом

# man wipefs

Согласно его описанию на странице справочника этот исполняемый файл не имеет никакой причины, работающей - более рабочий в течение долгого времени и использующей много ЦП.

# locate wipefs | grep '/wipefs$' | xargs md5sum
f3798d1cdea6d4e6d18219c6d4380b4d  /bin/wipefs
f3798d1cdea6d4e6d18219c6d4380b4d  /etc/init.d/wipefs
c23a54b144df0e4cb7a2f5c2b87dec4c  /sbin/wipefs

Также не нормально иметь 3 копии его в различных местах. И нисколько не нормально иметь исполняемый файл в / и т.д.

Поиск с помощью Google md5 подозрительного/bin/wipefs, Вы получаете результаты, которые предлагают взламывание/вирус.

Но давайте продолжим двигаться:

# dpkg --verify
??5??????   /bin/ss
??5?????? c /etc/sudoers
??5?????? c /etc/mysql/my.cnf
??5??????   /bin/netstat
??5?????? c /etc/crontab

dpkg --verify списки несколько файлов, которые были изменены начиная с установки. Это - конечно, знак компромисса для исполняемых файлов (как/bin/ss и netstat). На основе описания ss и netstat (человек ss, человек netstat) очевидно, что у нас есть вредоносный код здесь, который пытается спрятаться. Предупреждение здесь: Если dpkg-V сообщает, что ничто затем не подавляет Вашу защиту, потому что не маловероятно, что вирус/хакер предпринял шаги для одурачивания его.

В моем случае crontab имел строку для выполнения/bin/wipefs каждые 12 минут. Снова абсолютно аварийный.

Давайте посмотрим на строки в wipefs:

strings /bin/wipefs
...
$stratum+tcp://pool.minexmr.cn:8888
...
Try "xmrminer" --help' for more information.

Таким образом, у нас есть код для "горной промышленности различного cryptocoins" здесь.

Перед выключением машины хорошо взглянуть на процесс с strace (если Вы довольны им), или посмотрите на файлы в/proc/-по крайней мере, кошка cmdline и ls - la fd. В моем случае позже указанный открытый файл журнала с этим содержанием:

# head /tmp/mcalog 
CMD: /bin/wipefs -B -o stratum+tcp://pool.minexmr.cn:8888 -u 49ijJ3HJUg1b2MGnDmnEDJWdphGzWXgtbbBENx43NJiAUZWf8cSGryiZtYVZz3dgRcZH3Leokoqqi8SfRexMW32aFfvoHBp -p x -k
[2018-03-05 12:00:02] huge pages: available, enabled
[2018-03-05 12:00:02] cpu: ...
[2018-03-05 12:00:02] stratum url: stratum+tcp://pool.minexmr.cn:8888
[2018-03-05 12:00:02] backup url: none
[2018-03-05 12:00:02] Pool set diff to 80000.1
[2018-03-05 12:00:02] Stratum detected new block

Таким образом, снова ссылка на pool.minexmr.cn. Давайте использовать этот бит информации для сканирования нашей системы для других файлов, которые, вероятно, связаны с этим вредоносным кодом:

find /    -mount -type f -exec sh -c 'grep -q "\.minexmr\.\|wipefs" "{}"' \; -print ; find /tmp -mount -type f -exec sh -c 'grep -q "\.minexmr\.\|wipefs" "{}"' \; -print ; find /opt -mount -type f -exec sh -c 'grep -q "\.minexmr\.\|wipefs" "{}"' \; -print

--most likely malicious--
/etc/crontab
/var/tmp/gety
/bin/wipefs
/tmp/mcalog
/opt/glassfish3/glassfish/domains/domain1/applications/Sarketsdr/gety

--maybe malicious maybe not--
/sbin/swaplabel
/sbin/blkid
/sbin/wipefs
/usr/share/locale-langpack/en_GB/LC_MESSAGES/util-linux.mo
/usr/share/command-not-found/programs.d/amd64-main.db
/bin/mount

--probably no problem--
/var/cache/man/index.db
/var/lib/dpkg/info/util-linux.list
/var/lib/dpkg/info/util-linux.md5sums
/var/lib/mlocate/mlocate.db
/var/log/syslog
/var/log/syslog.1
/var/log/apport.log.1
/usr/lib/udisks2/udisksd

Отметьте этот файл /opt/glassfish3/glassfish/domains/domain1/applications/Sarketsdr/gety. Это - вероятно, хороший признак открытой двери к нашей системе.

Таким образом, теперь мы на 100% уверены, что взламываемся, и у нас есть эти вещи сделать: 1), если это возможно, сохраните резервное копирование этой системы для расследования, если не сохраняют как можно больше копиями файлов и выводом команд 2) резервное копирование восстановления и проверка, если это чисто - или переустанавливают ОС, 3) узнают то, что мы можем сделать, чтобы не взламываться снова (по крайней мере, не таким же образом :-).