Grokking sofisticado ataque de dicionário

Question

Parece que um dos meus servidores está passando por um sofisticado ataque de dicionário no ssh, pois estou vendo vários nomes de usuários sendo testados em meus servidores em ordem alfabética com falhas de senha.

As coisas incomuns sobre isso são:

• Existe apenas uma tentativa a cada 2 minutos
• toda tentativa vem de um endereço IP diferente

Você pode me ajudar a entender como isso pode ser feito a partir de endereços IP diferentes, pode ser efetivamente bloqueado ? e a persistência lenta do ataque (provavelmente levará vários meses para passar pelo alfabeto) significa alguma coisa específica?

Eu também estaria interessado em saber se alguém está vendo atividade semelhante em seus servidores ssh públicos (ou seja, somos um alvo específico ou esse invasor está cobrindo milhares de servidores ssh com esse ataque?)

Além disso, existe alguma maneira de eu revelar quais senhas (ou até hashes) estão sendo testadas ? Percebo que cada nome é tentado apenas uma ou duas vezes. Suponho que estejam tentando "senha" ou o nome de usuário do usuário, mas posso confirmar isso?

    

Answer 1

A resposta fácil para isso é não use senhas !!!

Você pode:

• use chaves ssh . Criptografe-os para segurança extra
• use um gerador de senhas de uso único como Mobile-OTP
• use kerberos

Se você precisar usar senhas, permita-as apenas a partir de sub-redes nas quais você confia, não da Internet inteira. Além disso, ajuda a executar seu daemon ssh em alguma porta diferente de 22. Normalmente eu não sugiro tais coisas, mas se reduzir o volume de ataques que você vê, tanto melhor.

Em resposta às suas preocupações específicas:

• Eu já vi esse tipo de ataque em qualquer host que eu executo que tenha um servidor ssh voltado para o público.
• Eu suspeito que eles estejam usando um dicionário de nomes de usuário / senhas desenvolvido a partir de experiências anteriores com o que funciona. Por exemplo, meus logs têm
  • 18 tentativas contra o usuário "ftp"
  • 23 tentativas contra usuário "fórum"
  • 3 para usuário "bernard"
  • 1 para o usuário "bret"
• Eu também vi esse tipo de ataque em que eles usaram logins específicos do site, mas eles provavelmente foram selecionados a partir do servidor ldap aberto do site (universidades, você deve amá-los!)
• Esses ataques provavelmente vêm de computadores zumbis que possuem um controle centralizado impressionante.
• esses ataques estão chegando a uma taxa de um a cada 1 a 5 minutos, todos os dias, todos os dias
• Eu tentei trussing sshd para ver se é trivial para coletar a senha que o atacante está tentando, e parece que você teria que corrigir o código.
  • essas pessoas fizeram exatamente isso e descobriram que as senhas eram frequentemente permutações do nome de usuário ou de uma senha bem conhecida, como sql ou admin.

Answer 2

Aqui estão algumas discussões e análises de um ataque de botnet "brutos lentos" que começou em 2008: Final Roundup de Brutes Lentos

Outra discussão do mesmo período no este site sugere

Fail2ban is but one tool to improve server security. Of course the first step is to avoid use of passwords and use serverkey authentication instead. In addition limit allowed traffic to certain IPs, disallow IP ranges, use IP tables, use blacklists such as rsync-mirrors.uceprotect.net to update your iptables for known SSH hacker origins and origin networks. For details on above 3 levels of blacklists, see uceprotect.net.

Outros itens que sugeri relacionados a esse tipo de tentativa recomendam o monitoramento das tentativas com falha e o bloqueio dos IPs de origem. Eventualmente, o mesmo IP será usado para outra análise, detectando e bloqueando a lista negra após tentativas de logon. uma conta inexistente você reduz gradualmente a ameaça ao custo do aumento do processamento de regras de firewall. Além disso, talvez seja melhor não bloquear após apenas uma única tentativa de conexão - erros de digitação acontecem.

    

Answer 3

A melhor resposta é, não faça nada sobre isso. Contanto que seus usuários tenham senhas strongs de 8 caracteres ou mais, a essa taxa, provavelmente, levará cerca de 3000 milhões de anos para forçá-lo a força bruta!

    

Answer 4

Não tenho certeza sobre sua implementação real, mas aqui estão algumas dicas gerais:

Examine suas senhas (com john the ripper ou similar) e veja se você pode aumentar o tempo limite para o login.

    

Answer 5

Instale denyhosts ou fail2ban - ele será bloqueado por IP após um determinado número de ataques. O denyhosts opera em /etc/hosts.deny e acredito que o fail2ban opera nas regras do iptables.