Registros: “Desconexão recebida de…” sem o couterpart “Aceito”

Question

Estou vendo muitos registros com esta linha:

Nov  7 03:47:41 s1 sshd[23430]: Received disconnect from XX.XXX.XX.XX: 11:
Nov  7 05:08:16 s1 sshd[24474]: Received disconnect from XX.XXX.XX.XX: 11:
Nov  7 06:33:59 s1 sshd[25526]: Received disconnect from XX.XXX.XX.XX: 11:
Nov  7 08:06:33 s1 sshd[26601]: Received disconnect from XX.XXX.XX.XX: 11:
Nov  7 09:24:14 s1 sshd[27460]: Received disconnect from XX.XXX.XX.XX: 11:
Nov  7 10:59:49 s1 sshd[28821]: Received disconnect from XX.XXX.XX.XX: 11:
Nov  7 12:14:39 s1 sshd[29894]: Received disconnect from XX.XXX.XX.XX: 11:

Eu só colo 7 linhas aqui, mas tenho centenas delas no arquivo de logs. O IP é sempre o mesmo.

Foi-me dito que isso indicava que meu servidor foi invadido e que o invasor conseguiu limpar as entradas de log que registravam as informações de login, porque para ter uma mensagem de "desconexão", eu deveria ter uma mensagem "Aceito ..." mensagem para o mesmo IP antes. Isso é verdade?

Minhas perguntas são:

• Com esses registros, posso concluir que meu servidor foi realmente invadido?
• O que esta mensagem significa? Eu li em algum lugar que o: 11 significa: "SSH2_DISCONNECT_BY_APPLICATION", mas eu não entendo o que isso realmente significa.

O servidor executa o CentOS e tem a autenticação de senha SSH desativada. Os únicos logs que dizem "Publickey aceito ..." são do meu próprio endereço IP público. Então eu acho que eles não estão fazendo login através desse método, a menos que o invasor esteja realmente limpando qualquer traço, correto?

Muito obrigado antecipadamente.

    

Answer 1

são ataques de força bruta

este método tenta encontrar o acesso de login enviando o pedido de login e depois testando o resultado, desde que o resultado não esteja logado, tente outra combinação de login / senha até que o acesso seja concedido

voltado principalmente para internet:

• FTP (geralmente a porta 21)
• SSH (geralmente porta 22)
• TS (geralmente porta 3389)
• páginas de login do site (normalmente, porta 80 e 443)

para evitar esse tipo de ataque:

• (se possível) alterando a porta padrão
• ter uma senha complexa
• tentando evitar o uso do nome de login básico (admin / root / administrator, ...)
• ter um temporizador "tentativa de falha", assim levará muito tempo para encontrar o bom login / senha combinaison.

Hoje, a maior parte da ferramenta do sistema está segura contra esse tipo de ataque

Eu não acho que você seja hackeado a menos que você tenha um baixo nível de login / senha. este log não diz nada, exceto que a tentativa falhou.

Se os Hackers se conectassem, eles teriam apagado todos os logs, não apenas alguns logs (muito tempo para nada).

O que você pode fazer (se realmente acha que foi hackeado) é verificar se tem um período sem logs ou registros de erros.

como sugerido, você pode usar alguma ferramenta para evitar ataques como fail2ban

Para informações, a mensagem SSH2_DISCONNECT_BY_APPLICATION no seu caso significa que esta é uma tentativa de login zumbi de um botnet que é criado em Java

    

Answer 2

É apenas um "spam" de probes navegando na internet. Eles não são perigosos se você não permitir a autenticação de senha. Essas mensagens provavelmente são apenas o ruído, já que geralmente não conhecem nenhuma outra autenticação além da senha.

Para reduzir o ruído, é possível configurar fail2ban , fwknop ou mover o serviço para outra porta.