Meu servidor SSH foi comprometido? Em caso afirmativo, como e quais etapas devo seguir?

Question

Recentemente, habilitei o acesso ssh à minha máquina para trabalhar em um projeto em grupo com meus colegas de classe. Eu li o guia para configurar o ssh no Ubuntu e tentei seguir boas práticas de segurança. Eu desabilitei a autenticação de senha, então a única maneira de entrar era com chaves RSA, e eu só tinha 2 chaves listadas no arquivo authorized_keys: a minha (usei durante o teste para ver se o ssh estava funcionando corretamente) e um amigo.

Esta noite eu estava curioso para ver se meu amigo estava no meu sistema quando eu estava usando, então eu pesquisei por um comando que me diria se alguém estava ssh'd, e se sim, quem. O resultado que obtive foi:

sudo netstat -tnpa | grep ESTABLISHED.*sshd

Eu tentei e a saída foi:

tcp        0      0 192.168.1.86:22         59.47.0.150:44728       ESTABLISHED 7416/sshd: [accepte

Isso não parecia certo. Entrei em contato com meu amigo e ele me garantiu que não estava logado. Tentei o comando novamente e vi:

tcp        0      0 192.168.1.86:22         59.47.0.150:44728       ESTABLISHED 7416/sshd: root [pr

Neste momento eu fiquei um pouco assustado com a palavra "root" e enviei uma mensagem para um amigo que sabia mais sobre essas coisas do que eu. Ele me disse para tentar:

 ps aux | grep ssh

qual é o resultado:

root      3702  0.0  0.0  61364  2872 ?        Ss   Apr12   0:00 /usr/sbin/sshd -D
root      7473  0.0  0.0 112692  3920 ?        Ss   20:46   0:00 sshd: root [priv]   
sshd      7474  0.0  0.0  62784  1516 ?        S    20:46   0:00 sshd: root [net]    
sid       7476  0.0  0.0  22476   936 pts/1    S+   20:46   0:00 grep --color=auto ssh

Agora eu estava completamente apavorado, então mesmo que eu quisesse esperar um pouco e ver se eu poderia descobrir quem estava logado, eu decidi apenas sudo stop ssh .

Depois de mais algumas pesquisas, descobri que 59.47.0.150 é um IP dentro / próximo de Shenyang, China, e parece ser especificamente conhecido por malicioso ataques .

Então, minhas perguntas para vocês são:

1. Podemos dizer com certeza que um IP da China de alguma forma SSH em minha máquina? Mesmo que aceitasse apenas autorização de chave RSA?

2. Podemos dizer com certeza que ele também teve acesso root? No meu ssh-config, eu tinha o padrão PermitRootLogin without-password . Eu originalmente pensei que isso significava que o login de raiz não era permitido (eu sei que os dois soam contraditórios, mas eu o pesquisei e esse foi o resultado que obtive)

3. Se sim, como?

4. Existe alguma maneira de ver que danos foram causados até agora?

5. Como posso me proteger contra isso no futuro? Eu ainda preciso ter o ssh rodando eventualmente para completar o meu projeto em grupo.

Obrigado por qualquer ajuda que você possa oferecer!

EDIT: Como por sugestão de saiarcot895 e Steven, verifiquei auth.log, que teve as seguintes linhas repetidas muito:

    Apr 13 20:43:50 PrometheusU sshd[7392]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.47.0.150  user=root
Apr 13 20:43:55 PrometheusU sshd[7394]: reverse mapping checking getaddrinfo for 150.0.47.59.broad.bx.ln.dynamic.163data.com.cn [59.47.0.150] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 13 20:43:55 PrometheusU sshd[7394]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.47.0.150  user=root
Apr 13 20:43:58 PrometheusU sshd[7394]: Failed password for root from 59.47.0.150 port 54813 ssh2
Apr 13 20:44:03 PrometheusU sshd[7394]: message repeated 2 times: [ Failed password for root from 59.47.0.150 port 54813 ssh2]
Apr 13 20:44:04 PrometheusU sshd[7394]: Received disconnect from 59.47.0.150: 11:  [preauth]

Isso significa que o invasor entrou no sistema e não conseguiu fazer login no root ou que está tentando acessar diretamente o root, falhou e não acessou nada?

    

Answer 1

  

Podemos dizer com certeza que um IP da China de alguma forma SSH em minha máquina? Mesmo que aceitasse apenas autorização de chave RSA?

É improvável que eles tenham sido autenticados, a menos que tenham conseguido obter uma chave válida. Tente conectar-se a partir de um host que você controla sem uma chave e verifique os processos em execução. Eles devem ser semelhantes ao que você viu. O fato de o processo [net] estar sendo executado como sshd indica que eles não foram bem-sucedidos no login.

  

Podemos dizer com certeza que ele / ela também tem raiz? No meu ssh-config, eu tinha o padrão PermitRootLogin without-password . Eu originalmente pensei que isso significava que o login de raiz não era permitido (eu sei que os dois soam contraditórios, mas eu o pesquisei e esse foi o resultado que obtive)

A opção usada permite logins para root, mas desabilita a autenticação de senha para root. É uma boa prática não permitir logins de raiz via SSH, a menos que você realmente precise deles. Se você restringir o acesso o mais strong possível. A menos que você tenha ativado uma chave, é improvável que você possa efetuar login na raiz usando o SSH. O without-password desativa logins baseados em senha, mas não desativa o método de autenticação de senha.

  

Se sim, como?

Você pode verificar o log de autenticação para ver se alguma autenticação foi bem-sucedida. No entanto, se tiverem sucesso, podem ter substituído as evidências.

  

Existe alguma maneira de ver que danos foram causados até agora?

A execução de um verificador de rootkit e a verificação de assinaturas de arquivos off-line devem indicar se algum arquivo foi comprometido. Obter assinaturas de arquivos e armazená-las off-line enquanto você estiver seguro fornecerá uma linha de base.

  

Como posso me proteger contra isso no futuro? Eu ainda preciso ter o ssh funcionando eventualmente para completar o meu projeto de grupo.

O sshd suporta o uso de tcpwrappers para restringir o acesso. Crie um conjunto de regras que permita apenas o acesso de intervalos de endereços dos quais você espera tráfego.

    

Answer 2

Muitos ataques de força bruta ssh estão ocorrendo. É possível que você tenha um pacote ssh obsoleto e eles ficaram assim.

Verifique se há falhas ssh nos registros, ele pode simplesmente fazer uma força bruta contra você.

vá para / tmp e poste sua saída de ls -al, se houver um rootkit que possa aparecer lá.

Você pode definir a permissão de usuários em ssh e o fail2ban também é útil.

Definir / tmp e / home como não-executáveis no fstab, se possível, ajudará muito.

    

Answer 3

Se for apenas um ataque de força bruta preenchendo os logs, basta alterar a porta.

A maioria dos scripts é estúpida e há servidores suficientes que escutam a porta 22. Eu sempre defino o meu como, por exemplo, 30200 ou 225. Isto pode ser feito com facilidade no

/etc/ssh/sshd.conf

Basta alterar o número da porta e reiniciar o daemon.

O sistema pode então ser acessado com uma opção adicional ao ssh

ssh -p224 [email protected]

Ma logs sempre estavam se enchendo, eu mudei a porta e o barulho sumiu.