Determine de onde o “sh” está sendo executado sob um usuário www-data do apache usando PF ou NETSTAT [duplicado]

Question

Estou trabalhando com um servidor Ubuntu 8.04 Plesk 9.5.4 comprometido. Parece que um script no servidor está continuamente fazendo pesquisas reversas para IPs aleatórios na Internet.

Eu a vi pela primeira vez usando top e notei flashes constantes disso: sh -c host -W 1 '198.204.241.10'

Eu escrevi este script para interrogar ps a cada 1 segundo para ver com que frequência esse script acontece:

#!/bin/bash
while :
do
    ps -ef | egrep -i "sh -c host"
    sleep 1
done

Os resultados são que esse script é executado com frequência, a cada poucos segundos:

www-data 17762  8332  1 10:07 ?        00:00:00 sh -c host -W 1 '59.58.139.134'
www-data 17772  8332  1 10:07 ?        00:00:00 sh -c host -W 1 '59.58.139.134'
www-data 17879 17869  0 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'
www-data 17879 17869  1 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'
www-data 17879 17869  0 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'
root     18031 17756  0 10:07 pts/2    00:00:00 egrep -i sh -c host
www-data 18078 16704  0 10:07 ?        00:00:00 sh -c host -W 1 '59.58.139.134'
www-data 18125 17996  0 10:07 ?        00:00:00 sh -c host -W 1 '91.124.51.65'
root     18131 17756  0 10:07 pts/2    00:00:00 egrep -i sh -c host
www-data 18137 17869  0 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'
www-data 18137 17869  1 10:07 ?        00:00:00 sh -c host -W 1 '198.204.241.10'

Minha teoria é: se eu puder ver quem está lançando o processo sh ou o formulário em que foi lançado, posso isolar ainda mais o problema.

Alguém pode me orientar usando netstat ou ps para identificar de onde sh está sendo executado?

Eu posso obter muitas sugestões de que o sistema operacional está desatualizado e, portanto, o Plesk, mas tenha em mente que existem algumas razões muito concretas para esse servidor estar executando o software legado. Minha pergunta é direcionada a administradores avançados de sistemas Linux que têm profunda experiência com comprometimentos de segurança e usam netstat e ps para chegar ao fim.

ATUALIZAÇÃO 26 de outubro 14:01 SAST

O comando grep -lr 'sh -c host' deixado nos comentários deixados por @ramruma me ajudou a encontrar rapidamente o website correspondente executando o script. Como se constata o servidor não está comprometido . O que está acontecendo, em vez disso, é que existe um fórum nesse local produzido por Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC que faz uma pesquisa inversa toda vez que alguém acessa o fórum.

Acontece que o fórum está sem manutenção e com muitos spams, e por que inicialmente pensamos que ele está comprometido é porque muitas das pesquisas reversas apontavam para IPs estrangeiros conhecidos por spam. A bondade só sabe como um site pode executar esse comando, mas, por enquanto, vou encerrar a questão como inofensiva.

Com relação às respostas gerais recebidas sobre "restaurar do backup", cheguei ao ServerFault para ajudar a isolar o problema e deixei claro em minha solicitação inicial. Às vezes, restaurar a partir de backup é impraticável ou mesmo impossível. É melhor descobrir o problema ou encontrar o compromisso, caso possa surgir no futuro.

    

Answer 1

Embora pareça que você já descobriu a causa desse problema, o despejo da tabela de processos com pstree e alguns args teria ajudado.

Substitua o comando ps no loop por:
pstree -apu www-data >> getyousomespam.txt

Você só deseja executar isso por cerca de 30 segundos devido à parede de texto que ele geraria. Isso exibirá todos os processos pertencentes a www-data, seus processos ancestrais, todas as transições ao longo do caminho ( -u ), argumentos de linha de comando nos quais você pode pesquisar ( -a ) e PIDs ( -p ). p>

Obviamente, esta informação seria completamente bunk se você foi comprometida, mas se você não tiver (como parece ser o caso aqui), isso forneceria a trilha do texto que você estava procurando ... ou pelo menos um bom começo.

Edit:
pstree não se preocupa com os terminais de origem, mas se você puder isolar as coisas a um processo ancestral persistente, ter o PID facilitaria a conclusão do trabalho de lá.

    

Answer 2

Pare. Você está indo sobre isso da maneira errada. Seu servidor está comprometido, você precisa desconectá-lo e restaurar a partir de um backup em bom estado. Veja também Como faço para lidar com um servidor comprometido?