/etc/rc.d/init.d/wipefs start problema da cpu

Question

Eu tenho um vps no servidor principal. Este vps tem muitos sites, mas o tráfego é normal. Ontem, o uso da CPU do servidor subiu de repente. Eu não sei o que esta linha significa.

O que é e o que devo fazer sobre isso?

    

Answer 1

Então eu encontrei wipefs rodando em um servidor, e descobri que era um script que havia entrado por meio de um serviço glassfish desatualizado. Por favor execute o dpkg - verify para ver se o seu pacote foi comprometido. Você precisará obter uma cópia dos wipefs originais para recuperar o arquivo correto. Verifique se o seu sistema não foi comprometido e remova todos os scripts / etc / rc * que ele cria.

    

Answer 2

Eu consertei isso renomeando /etc/rc.d/init.d/wipefs como sugerido por @Ziazis

% bl0ck_qu0te%     

Answer 3

Eu tive um caso semelhante em um servidor executando java / glassfish. No meu caso, wipefs foi executado por / bin / wipefs e também estava usando 100% da minha CPU. Eu descobri que esse sistema estava comprometido. O que se segue são as partes mais importantes da minha investigação.

Uma investigação típica para descobrir se isso é um código malicioso

# man wipefs

De acordo com sua descrição na página man, este executável não tem nenhum motivo para rodar - mais ainda rodando por um longo tempo e consumindo muito CPU.

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

Também não é normal ter 3 cópias em diferentes lugares. E não é de todo normal ter um executável em / etc.

Pesquisando no md5 do / bin / wipefs suspeito você obtém resultados que sugerem hacking / virus.

Mas vamos prosseguir:

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

dpkg --verify lista alguns arquivos que foram alterados desde a instalação. Isso é certamente um sinal de comprometimento para executáveis (como / bin / ss e netstat). Com base na descrição do ss e do netstat (man ss, man netstat), é óbvio que temos aqui um código malicioso que está tentando se esconder. Uma nota de cautela aqui: Se o dpkg -V não reporta nada, então não baixe a guarda porque não é improvável que o vírus / hacker tenha tomado medidas para enganá-lo.

No meu caso, o crontab tinha uma linha para executar / bin / wipefs a cada 12 minutos. Novamente completamente anormal.

Vamos ver as strings no wipefs:

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

Então, temos código para "mineração de vários cryptocoins" aqui.

Antes de desligar a máquina, é bom dar uma olhada no processo com strace (se você estiver confortável com ela) ou ver os arquivos em / proc / - pelo menos cat cmdline e ls -la fd. No meu caso, o mais tarde apontou para um arquivo de log aberto com este conteúdo:

# 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

Então, novamente, uma referência a pool.minexmr.cn . Vamos usar esse bit de informação para procurar no nosso sistema por outros arquivos que provavelmente estão relacionados a este código malicioso:

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

Observe este arquivo /opt/glassfish3/glassfish/domains/domain1/applications/Sarketsdr/gety . Provavelmente é uma boa indicação da porta aberta do nosso sistema.

Portanto, agora temos 100% de certeza de que estamos hackeados e temos estas coisas para fazer: 1) se possível, mantenha um backup desse sistema para investigação, se não manter o máximo de cópias de arquivos e a saída de comandos possível 2 ) restaure o backup e verifique se ele está limpo - ou - reinstale o OS 3) descubra o que podemos fazer para evitar ser hackeado novamente (pelo menos não da mesma maneira: -).