Todas as entradas do log de erros do OpenSSH 6.7 'preauth' garantem atenção humana específica?

2

Um servidor Linux (especificamente o Debian Jessie) que precisa ser exposto à Internet está emitindo vários erros do OpenSSH 6.7 preauth nos logs. Por exemplo, estou recebendo (timestamps elidados por clareza):

    Erro de
  • : Desconexão recebida de A.B.C.D: 3: com.jcraft.jsch.JSchException: Falha de autenticação [preauth]
  • fatal: não é possível negociar um método de troca de chaves [preauth]
  • fatal: nenhuma cifra correspondente foi encontrada: cliente ... servidor ... [preauth]
  • Desconexão recebida de A.B.C.D: 11: desligamento normal, obrigado por jogar [preauth]
  • Desconexão recebida de A.B.C.D: 11: ok [preauth]

e assim por diante.

Não estou muito preocupado com as sondas em si; o sistema é mantido atualizado, a configuração do OpenSSH é razoavelmente bem endurecida de acordo com as melhores práticas atuais e há proteções adicionais (por exemplo, fail2ban) em vigor.

Existe alguma razão pela qual qualquer entrada de log preauth OpenSSH justifique atenção humana específica?

As respostas para a pergunta O que significa "Desligamento normal, obrigado por jogar [preauth]" Nos registros SSH significa? indica que o caso específico nessa questão é seguro ignorar; minha pergunta é mais genérica.

    
por a CVn 07.03.2016 / 22:07

1 resposta

2

Parece que você realizou algumas etapas específicas para fortalecer o OpenSSH .

Como um efeito colateral dessas mudanças, combinado com a execução de uma versão relativamente recente do OpenSSH, você receberá muito mais entradas de log detalhadas sobre falhas de conexão.

Todas as mensagens preauth que você está vendo se enquadram nessa categoria e representam um cliente que não conseguiu estabelecer uma conexão por algum motivo. Na maioria das vezes, essas conexões falham antes que o cliente possa tentar um nome de usuário e senha.

A melhor coisa a fazer com essas entradas de log é alimentá-las em um agregador de logs e criar bons gráficos para serem examinados pelos pesquisadores de segurança. Eles não precisam de nenhuma intervenção humana individual.

Claro, você deve continuar a intervir nas mensagens que indicam que uma senha foi tentada e falhou. Suas ferramentas existentes, como o fail2ban, servirão muito bem aqui, embora você considere suas listas de proibições muito menores do que antes, já que a maioria dos bots de força bruta ssh ainda não usa criptografia moderna (que é a causa principal da maioria dessas mensagens).

Um outro lugar onde você pode precisar intervir é com usuários autorizados que não podem mais se conectar, porque eles estão usando versões antigas de clientes ssh (por exemplo, uma versão antiga do PuTTY ou FileZilla) . A atualização do cliente para a versão mais recente corrige esses problemas.

    
por 08.03.2016 / 02:35