Entradas de log ímpares e uso insano de largura de banda

Question

Eu tenho um servidor em nuvem CentOS que uso para testes e notei que nos últimos 30 dias a largura de banda foi superada (16.000 GB para ser mais precisa)

Quando eu inicialmente tentei verificar no servidor, ele estava completamente inacessível (sem resposta no SSH, na web, até mesmo no console (o console mostrava um monte de erros, nenhum prompt de login)

Eu devolvi o servidor e comecei a passar por logs e logins. Não há logins SSH em idades, nada de estranho nos logs, exceto isso a cada minuto:

Jan 17 02:20:01 wwwdev crond[21971]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:21:01 wwwdev crond[21976]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:22:01 wwwdev crond[21985]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:23:01 wwwdev crond[21990]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:24:01 wwwdev crond[22000]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:25:01 wwwdev crond[22006]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:26:01 wwwdev crond[22015]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:27:01 wwwdev crond[22024]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:28:01 wwwdev crond[22029]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:29:01 wwwdev crond[22034]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)

O que realmente estava em / tmp já passou há muito tempo desde que eu tive que reiniciar, mas eu realmente gostaria de saber o que aconteceu.

    

Answer 1

Eu não sei sabe com certeza, mas essa descrição cheira muito como um comprometimento de servidor que envia spam por e-mail. Também poderia ter sido um worm procurando por mais hosts para comprometer, mas o spam de e-mail parece mais provável.

Se você procurar o endereço IP do seu servidor em um site de reputação de e-mail, como SenderScore ou SenderBase ou simplesmente procurá-lo no Google, você pode encontrar alguma evidência disso e até mesmo exemplos do spam. Você também pode fazer check-in nas Listas negras de DNS para ver se o seu servidor está na lista negra.

O nome de usuário que o cron job estava executando, como sugere o comprometimento (se é o que foi) aconteceu através do seu site. O acesso do seu servidor web e os registros de erros nos dias anteriores ao início das tarefas do cronômetro seriam o melhor lugar para começar a procurar.

Quase esqueci o link obrigatório para MEU servidor foi invadido por EMERGÊNCIA . Muito bons conselhos sobre o que fazer e como limpar. Não se esqueça de remover ou restringir o phpMyAdmin.