como descobrir o caminho completo do comando a partir do resultado de lsof -i

6

lsof é um ótimo utilitário, agora começou a usá-lo.

lsof -i | grep smtp = > isso dá o seguinte resultado.

httpd.pl  212548          global    3u  IPv4 893092369      0t0  TCP server07.host...blah...

No exemplo acima, httpd.pl é o script perl, que envia e-mails de spam.

Como posso saber o caminho completo do comando. ou seja, no resultado acima , quero saber o caminho completo de httpd.pl

Eu tentei pesquisar no diretório home, o arquivo httpd.pl não está lá. e também, eu tentei com lsof -p PID , isso também não dá o caminho para isso.

Existe alguma maneira, eu posso obter o caminho completo desse arquivo?

Nota: Esse tipo de problema é muito comum no ambiente de hospedagem compartilhada. Portanto, será muito útil para hospedagem compartilhada ou qualquer administrador de servidor da web.

    
por Mani 03.02.2015 / 06:48

3 respostas

1

Uma maneira seria examinar os arquivos abertos por esse processo. Dos tipos mostrados na coluna FD de lsof :

FD         is the File Descriptor number of the file or:

               cwd  current working directory;
               ...
               txt  program text (code and data);

Então, tente:

lsof -a -d txt -p 212548

Para scripts, isso mostra o caminho do interpretador usado (como /bin/bash ). Para scripts de shell, o arquivo de script parecia estar aberto em fd 255 no meu sistema, mas para scripts Perl, não havia menção do arquivo de script em lsof output.

    
por 03.02.2015 / 12:09
1

Esse httpd.pl é o nome do processo. Isso é inicializado a partir do nome base do arquivo que o processo executou pela última vez, mas também pode ser modificado por outros meios.

Com perl , é apenas uma questão de atribuir um valor a $0 :

$ perl -e '$0 = "httpd.pl"; sleep 10' & ps -fp $!
[2] 11954
UID        PID  PPID  C STIME TTY          TIME CMD
stephane 11954 31685  0 09:57 pts/8    00:00:00 httpd.pl

Então, não há como dizer se httpd.pl vem um arquivo chamado assim ou algo mais. perl ainda poderia ter sido executado com o código passado como -e ou de outro arquivo ou de stdin ...

Se o código perl foi carregado de um arquivo chamado httpd.pl (ou qualquer outro arquivo que importe), provavelmente você não poderia dizer porque perl geralmente fecha o arquivo depois de ter lido seu conteúdo, então seria não aparece na saída de lsof -p PID .

Se o script foi realmente passado para o interpretador perl e se o código perl não modificar subseqüentemente o nome do processo ou os argumentos, você poderá obter uma dica olhando seus argumentos de linha de comando com ps -fp PID . / p>

Você então veria o caminho do arquivo como passado como argumento. Pode ser um caminho relativo, em cujo caso você pode ver a entrada cwd em lsof , o que ajudaria a menos que o script altere o diretório de trabalho atual.

Se o script foi iniciado por um shell, você também poderá encontrar o caminho (novamente possivelmente relativo) na variável de ambiente _ ( grep -z '^_=' /proc/PID/environ no Linux).

De qualquer forma, o script poderia ter sido deletado logo de início.

Se você quiser ver o código desse httpd.pl , melhor seria despejar o conteúdo da memória desse processo (como com gcore , enviado com gdb ou olhando para /proc/PID/{maps,mem} no Linux). E procure o código lá.

Por exemplo, procurando #! em registros delimitados por NUL:

perl -e '$p=shift;open MAPS, "/proc/$p/maps";
  open MEM, "/proc/$p/mem" or die "open mem: $!";
  for $m (grep !m{/|\[v}, <MAPS>){
    ($a,$b) = map hex, $m =~ /[\da-f]+/g;
    seek MEM, $a, 0 or die "seek: $!";
    read MEM, $c, $b - $a or die "read: $!";
    print $c
  }' PID | grep -z '#!'

YYMV embora como o código-fonte bruto não pode mais estar lá. Você precisaria então procurar pelo código pré-compilado e decodificá-lo.

Esse stackoverflow Q & A então ajudará você a fazer isso.

    
por 01.08.2016 / 11:12
0

Por si só, lsof -i listará apenas informações da Internet. Você pode adicionar informações de arquivo (ou mostrar que ) usando a opção -d . Por exemplo:

lsof -d txt | grep -E '/httpd.pl$'

porque (a menos que um processo altere o nome sob o qual ele é executado), o nome do comando corresponderá ao nome do arquivo real que foi carregado.

Esse arquivo tem que ser executável, é claro - mas também as bibliotecas compartilhadas que ele carrega. Em um caso realmente patológico, você poderia ter um programa rodando a partir de um script (escrito em Python, por exemplo) que carrega bibliotecas compartilhadas - e renomeia a si mesmo na lista de processos.

De acordo com um thread do CentOS Processo suspeito httpd.pl , houve um processo iniciado a partir de um script PHP que se chamava httpd.pl :

For anyone that was interested. This was a backdoor installed by a php shell. the cleanup just didn't catch it on the first round.

Outro tópico, Processo mal-intencionado em execução no servidor CentOS dá mais detalhes:

The httpd.pl is a spoofed process that is running perl.

it is usually a backdoor that is set up by a php shell that will be loaded into a website somewhere

Leitura adicional:

por 30.04.2016 / 15:33