Pain remove um rootkit perl

Question

Então, nós hospedamos uma coisa de servidor de web geoservice no escritório.

Alguém aparentemente arrombou essa caixa (provavelmente via ftp ou ssh) e colocou algum tipo de coisa de rootkit gerenciado pelo irc.

Agora estou tentando limpar tudo, achei o processo pid que tenta se conectar via irc, mas não consigo descobrir quem é o processo de invocação (já procurei com ps, pstree, lsof) O processo é um script em perl de propriedade do usuário www, mas ps aux | grep exibe um caminho de arquivo falso na última coluna.

Existe outra maneira de rastrear esse pid e pegar o invocador?

Esqueci de mencionar: o kernel é 2.6.23, que é explorável para se tornar root, mas eu não posso tocar muito essa máquina, então não posso atualizar o kernel

EDIT: lsof pode ajudar:

lsof -p 9481
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAMEss
perl 9481 www cwd DIR 8,2 608 2 /ss
perl 9481 www rtd DIR 8,2 608 2 /ss
perl 9481 www txt REG 8,2 1168928 38385 /usr/bin/perl5.8.8ss
perl 9481 www mem REG 8,2 135348 23286 /lib64/ld-2.5.soss
perl 9481 www mem REG 8,2 103711 23295 /lib64/libnsl-2.5.soss
perl 9481 www mem REG 8,2 19112 23292 /lib64/libdl-2.5.soss
perl 9481 www mem REG 8,2 586243 23293 /lib64/libm-2.5.soss
perl 9481 www mem REG 8,2 27041 23291 /lib64/libcrypt-2.5.soss
perl 9481 www mem REG 8,2 14262 23307 /lib64/libutil-2.5.soss
perl 9481 www mem REG 8,2 128642 23303 /lib64/libpthread-2.5.soss
perl 9481 www mem REG 8,2 1602809 23289 /lib64/libc-2.5.soss
perl 9481 www mem REG 8,2 19256 38662 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi/auto/IO/IO.soss
perl 9481 www mem REG 8,2 21328 38877 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi/auto/Socket/Socket.soss
perl 9481 www mem REG 8,2 52512 23298 /lib64/libnss_files-2.5.soss
perl 9481 www 0r FIFO 0,5 1068892 pipess
perl 9481 www 1w FIFO 0,5 1071920 pipess
perl 9481 www 2w FIFO 0,5 1068894 pipess
perl 9481 www 3u IPv4 130646198 TCP 192.168.90.7:60321->www.****.net:ircd (SYN_SENT)

    

Answer 1

Se eu puder lhe dar algum conselho, é para deixar de desperdiçar seu tempo limpando. Faça uma imagem do SO para material forense para mais tarde e simplesmente reinstale o servidor.

Desculpe, mas é a única forma segura de se resolver de ser rootkitted.

Mais tarde, você pode verificar a imagem, por alguns motivos, por que isso aconteceu.

De minha experiência pessoal, eu fiz isso e, mais tarde, encontrei um usuário interno que tinha uma chave SSH contendo a falha do openssl em 2008.

Eu espero, isso esclarece as coisas.

Nota:
Se você estiver indo para a imagem / backup do servidor antes de reinstalar, seja muito cuidado, como você faz isso. Como disse @dfranke, inicialize de um meio confiável para fazer o backup.

Você não deve se conectar a outras máquinas a partir de um servidor com raiz, pois sabe-se que grandes rootkits podem se espalhar por meio de sessões confiáveis, como o SSH.

    

Answer 2

A linha de comando pode ser alterada se o processo alterar argv [0]. Experimente ls -l /proc/[pid]/exe

De man 5 proc

this file is a symbolic link containing the actual pathname of the executed command. This symbolic link can be dereferenced normally; attempting to open it will open the executable. You can even type /proc/[number]/exe to run another copy of the same executable as is being run by process [number]. In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated

ps auxwf | less fornece a "visão de floresta" dos processos que podem mostrar a você qual processo iniciou esse processo (a menos que o rootkit esteja ocultando, ou o pai do aplicativo tenha saído e tenha sido reparado no init).

Isso seria principalmente acadêmico e provavelmente apenas um timewaster, mas strings -n 10 /proc/[pid]/mem pode ser divertido de assistir. Você também pode usar echo 0x7 > /proc/[pid]/coredump_filter e usar gdb gcore para forçar um coredump com tudo o que for possível, mas, em seguida, o processo é interrompido, o que pode bloquear mais análises.

Mas definitivamente aceite o conselho da Arenstar. Faça backup apenas dos dados, restaure tudo que é executável a partir dos backups e inicie novamente. Você provavelmente deve restaurar o site a partir de backups também, pode haver javascript malicioso adicionado a cada arquivo html ou php. Se você está considerando uma ação legal, você deve apenas deixar a máquina de lado, desconectá-la da rede e parar o que estiver fazendo até que os especialistas forenses tenham feito seu trabalho.

    

Answer 3

Tente "cat / proc / [id do processo] / cmdline" Embora se for um verdadeiro rootkit, ele pode modificar o kernel para se esconder melhor.

    

Answer 4

Você deve reinstalar, eu concordo. Você já tentou escapar dos personagens no caminho? Talvez uma dessas barras seja, na verdade, parte de um nome de arquivo e não de um diretório. No mínimo, você deve usar o iptables para bloquear o tráfego de saída para o host ou para o IRC geral até que seja corrigido. Verifique o netstat também.

    

Answer 5

Eu acho que agora você reinstalou. Seu tempo perdendo tempo tentando rastrear os processos e fazer perícias forenses como chances de qualquer coisa legalmente se desenvolver a partir dele seria muito pequeno e as chances de encontrar o hacker seriam fúteis de qualquer maneira. A menos que você apenas interesse em pesquisar e reverter rootkits que podem ser divertidos :)