SSHD Consumindo 100% da CPU (Centenas de processos) - Não morrerá

Question

Recentemente eu notei que o SSHd em alguns sistemas que eu administro vai começar a gerar processos que não param, que consumirão grandes quantidades de CPU.

O syscall mostra que os processos estão todos 'rodando' e não são zumbis ou estão esperando por seus pais matá-los (pelo menos não tanto quanto eu posso dizer).

Eu tentei de tudo para matar esses processos ... o único método confiável que encontrei até hoje é reiniciar o servidor inteiro (o que não é o ideal). Eu tentei mudar o servidor openssh para dropbear, mas ele não se comporta da maneira que eu preciso para meus aplicativos.

Eu tentei:

killall -9 sshd

matando cada sshd pelo seu id. Poucas outras coisas (htop + sigterm, etc ...)

Eu adoraria algumas ideias para matar esses processos ou para resolver o que causa isso.

    

Answer 1

Se eles são realmente sshd do OpenSSH, meu palpite é que um script em algum lugar os esteja executando em um loop quebrado e um de seus processos filhos esteja sobrecarregando toda a CPU.

Como Marki555 sugeriu, strace iria ajudá-lo, mas você deve usar strace -f para que o strace siga os processos filhos. De man strace :

   -f          Trace child processes as they are  created  by  cur-
               rently  traced  processes as a result of the fork(2)
               system call.

Como strace gera muitos dados, também pode ser uma boa idéia usar o argumento -e (por exemplo, para mostrar apenas as chamadas open ()):

   -e expr     A qualifying expression which modifies which  events
               to  trace  or  how to trace them.  The format of the
               expression is:
                         [qualifier=][!]value1[,value2]...

Outro comando que você pode tentar é ps xaf ou pstree -a para obter uma visão de árvore fácil de entender dos processos e seus processos filhos para que você possa determinar qual processo iniciou esses sshd's. lsof também pode ajudá-lo, ele informará quais arquivos um processo abriu.

E, claro, verifique se você está usando o OpenSSH mais recente. Eu estou pensando rsync + grandes arquivos + ssh em um antigo OpenSSH 3.4p1 seria problemático.

Se esses não forem realmente processos sshd, então uma soma de verificação MD5 do arquivo binário pode ser exibida corretamente, mas pode não ser o programa sshd real em execução. Além disso, o comando md5sum pode ser uma versão de backdoor modificada para relatar a soma de verificação correta para determinados arquivos (como o sshd).

Você deve dar uma olhada em / proc / [sshd pid] / exe e ter certeza de que é um link simbólico para / usr / sbin / sshd (ou onde quer que seu sshd esteja), assim como / proc / [sshd pid] / environ para ver quais variáveis de ambiente ele está usando, e / proc / [sshd pid] / cmdline para ver qual comando realmente o iniciou.

Embora um invasor possa ter renomeado o programa malicioso para "sshd", ele foi executado para fazer parecer que ele é sshd. Poderia até ter movido / usr / sbin / sshd para / tmp / sshd, em seguida, movido o sshd malicioso para / usr / sbin / sshd para tentar ocultá-lo desse tipo de análise / proc, mas quando / tmp / sshd é movido de volta para / usr / sbin / sshd o link simbólico / proc / [sshd pid] / exe será mostrado em ls as:

   lrwxrwxrwx 1 root root 0 May 19 06:47 /proc/[sshd pid]/exe ->  (deleted)/usr/sbin/sshd

Além disso, se esses sshd's estiverem fazendo algo para impedir ativamente a análise normal do processo, você pode tentar kill -STOP em vez de kill -9 para "pausar" o processo (use kill -CONT para continuá-lo. Consulte link ).

No entanto, se um invasor tiver privilégios de root, um rootkit poderá ser instalado ocultado em / proc, netstat, ls, etc. Se você estiver realmente comprometido, o melhor curso de ação será colocar o sistema offline e montá-lo em outro sistema (limpo), em seguida, faça a perícia (ou use um desses CDs vivos do Linux feitos para análise forense).