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

Question 1

У меня есть vps на главном сервере. В этом vps есть много веб-сайтов, но трафик в норме. Вчера серверное использование процессора внезапно увеличилось. Я не знаю, что означает эта строка.

Что это и что мне делать с этим? [ ! d7]

Question 2

Итак, я обнаружил, что wipefs работает на сервере, оказывается, это был скрипт, который пришел через устаревшую услугу из морской рыбы. Запустите dpkg -verify, чтобы узнать, был ли взломан ваш пакет. Вам нужно будет получить копию оригинала wipefs, чтобы вернуть правильный файл. Убедитесь, что ваша система не была скомпрометирована и удалены все скрипты / etc / rc *, которые она создает.

Question 3

Question 4

У меня был похожий случай на сервере с 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 копии в разных местах. И совсем не нормально иметь исполняемый файл в / etc.

При запуске 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 (man ss, man netstat), очевидно, что здесь есть вредоносный код, который пытается скрыть себя. Обратите внимание на осторожность: если dpkg -V ничего не сообщает, тогда не ставьте свою охрану, потому что маловероятно, чтобы вирус / хакер предпринял шаги, чтобы обмануть его.

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

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

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

Итак, у нас есть код для «добычи различных криптоконов» здесь.

Перед поворотом (если вам это удобно), посмотрите файлы в / proc / - по крайней мере, cat 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) узнать, что мы можем сделать, чтобы избежать повторного взлома (по крайней мере, не в то же самое: -).

Question 5

Я исправил его, переименовав /etc/rc.d/init.d/wipefs, как это было предложено @Ziazis

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

Question 6

Итак, я обнаружил, что wipefs работает на сервере, оказывается, это был скрипт, который пришел через устаревшую услугу из морской рыбы. Запустите dpkg -verify, чтобы узнать, был ли взломан ваш пакет. Вам нужно будет получить копию оригинала wipefs, чтобы вернуть правильный файл. Убедитесь, что ваша система не была скомпрометирована и удалены все скрипты / etc / rc *, которые она создает.

Question 7

Question 8

У меня был похожий случай на сервере с 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 копии в разных местах. И совсем не нормально иметь исполняемый файл в / etc.

При запуске 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 (man ss, man netstat), очевидно, что здесь есть вредоносный код, который пытается скрыть себя. Обратите внимание на осторожность: если dpkg -V ничего не сообщает, тогда не ставьте свою охрану, потому что маловероятно, чтобы вирус / хакер предпринял шаги, чтобы обмануть его.

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

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

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

Итак, у нас есть код для «добычи различных криптоконов» здесь.

Перед поворотом (если вам это удобно), посмотрите файлы в / proc / - по крайней мере, cat 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) узнать, что мы можем сделать, чтобы избежать повторного взлома (по крайней мере, не в то же самое: -).

Question 9

Я исправил его, переименовав /etc/rc.d/init.d/wipefs, как это было предложено @Ziazis

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

Andre Van Zuydam · Answer 1 · 18 July 2018 в 09:38

Итак, я обнаружил, что wipefs работает на сервере, оказывается, это был скрипт, который пришел через устаревшую услугу из морской рыбы. Запустите dpkg -verify, чтобы узнать, был ли взломан ваш пакет. Вам нужно будет получить копию оригинала wipefs, чтобы вернуть правильный файл. Убедитесь, что ваша система не была скомпрометирована и удалены все скрипты / etc / rc *, которые она создает.

ndemou · Answer 2 · 18 July 2018 в 09:38

У меня был похожий случай на сервере с 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 копии в разных местах. И совсем не нормально иметь исполняемый файл в / etc.

При запуске 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 (man ss, man netstat), очевидно, что здесь есть вредоносный код, который пытается скрыть себя. Обратите внимание на осторожность: если dpkg -V ничего не сообщает, тогда не ставьте свою охрану, потому что маловероятно, чтобы вирус / хакер предпринял шаги, чтобы обмануть его.

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

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

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

Итак, у нас есть код для «добычи различных криптоконов» здесь.

Перед поворотом (если вам это удобно), посмотрите файлы в / proc / - по крайней мере, cat 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) узнать, что мы можем сделать, чтобы избежать повторного взлома (по крайней мере, не в то же самое: -).

Zanna · Answer 3 · 18 July 2018 в 09:38

Я исправил его, переименовав /etc/rc.d/init.d/wipefs, как это было предложено @Ziazis

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

Andre Van Zuydam · Answer 4 · 24 July 2018 в 19:23

Итак, я обнаружил, что wipefs работает на сервере, оказывается, это был скрипт, который пришел через устаревшую услугу из морской рыбы. Запустите dpkg -verify, чтобы узнать, был ли взломан ваш пакет. Вам нужно будет получить копию оригинала wipefs, чтобы вернуть правильный файл. Убедитесь, что ваша система не была скомпрометирована и удалены все скрипты / etc / rc *, которые она создает.

Другим файлом, который задействован, является gety, который фактически закручивает поддельную службу wipefs — Andre Van Zuydam, 17 November 2017 в 10:47

ndemou · Answer 5 · 24 July 2018 в 19:23

У меня был похожий случай на сервере с 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 копии в разных местах. И совсем не нормально иметь исполняемый файл в / etc.

При запуске 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 (man ss, man netstat), очевидно, что здесь есть вредоносный код, который пытается скрыть себя. Обратите внимание на осторожность: если dpkg -V ничего не сообщает, тогда не ставьте свою охрану, потому что маловероятно, чтобы вирус / хакер предпринял шаги, чтобы обмануть его.

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

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

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

Итак, у нас есть код для «добычи различных криптоконов» здесь.

Перед поворотом (если вам это удобно), посмотрите файлы в / proc / - по крайней мере, cat 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) узнать, что мы можем сделать, чтобы избежать повторного взлома (по крайней мере, не в то же самое: -).

Zanna · Answer 6 · 24 July 2018 в 19:23

Я исправил его, переименовав /etc/rc.d/init.d/wipefs, как это было предложено @Ziazis

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

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

6 ответов

Другие вопросы по тегам:

Похожие вопросы: