Alguém está tentando forçar o acesso do SSH ao servidor [duplicado]

Question

Por coincidência eu olhei meus servidores ssh log (/var/log/auth.log) e notei que alguém está constantemente tentando obter acesso:

Sep  7 13:03:45 virt01 sshd[14674]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=116.31.116.42  user=root
Sep  7 13:03:48 virt01 sshd[14674]: Failed password for root from 116.31.116.42 port 13423 ssh2
Sep  7 13:03:52 virt01 sshd[14674]: message repeated 2 times: [ Failed password for root from 116.31.116.42 port 13423 ssh2]
Sep  7 13:03:52 virt01 sshd[14674]: Received disconnect from 116.31.116.42: 11:  [preauth]

Isso acontece algumas vezes a cada minuto, e vem acontecendo há muito tempo sem que eu saiba.

Pergunta Eu deveria estar preocupado com isso, se sim: o que devo fazer sobre isso?

    

Answer 1

Infelizmente, isso é absolutamente normal e algo que todo servidor SSH experimenta. Bem vindo a internet.

Contanto que você proteja seu servidor adequadamente (por exemplo, mantenha-o atualizado, permita somente login baseado em chave, desative o acesso root SSH), isso não deve ser um problema, mas você pode limitar isso ainda mais com algo como fail2ban e outras abordagens, como lista de permissões de IP, alteração de portas e outras coisas semelhantes, quando possível e apropriado.

    

Answer 2

1. Bloqueie o IP usando seu firewall (iptables ou qualquer que seja seu serviço). Sim, eles podem alterar os IPs, mas fazê-los fazer o trabalho
2. Se você tiver um firewall externo (por exemplo, o console da AWS permite definir regras de acesso por meio de uma página da Web), considere limitar a porta 22 ao JUST IP. Não há necessidade de mexer com o fail2ban neste caso
3. Como mencionado nos comentários, mude para autenticação baseada em chave e desative a autenticação por senha

4. Desativar logins de raiz . Adicione isto a /etc/ssh/sshd_config

   PermitRootLogin no
   

   Apenas deixe-os martelar na raiz tudo o que eles querem. Eles nunca chegarão a esse caminho então.

Answer 3

Além de proteger o servidor como Sven aponta, uma das melhores coisas a se fazer (especialmente se o ssh estiver lá para você, o admin) é apenas alterar a porta sshd do padrão 22 .

Não só é simples (especialmente quando você coloca uma nova porta no seu ~/.ssh/config , então você não precisa digitá-la toda vez) e ela irá parar 99% dessas verificações automatizadas para que você nem as veja, mas também ajudará um pouco, mesmo que se descubra que uma vulnerabilidade de 0-dia ssh lhe da mais tempo, ou que a sua chave tenha vazado, etc.

    

Answer 4

Esse comportamento bem normal. Eu recebo vários milhares de reais todos os dias, e eu assumo até que isso é minúsculo comparado ao que as grandes empresas enfrentam.

Mas você precisa se preocupar?

• Você instalou fail2ban ?
• Você desativou o login do root ssh?
• Você bloqueou o usuário www-data do login do ssh?
• (opcional) Você tem login baseado em senha desativado em favor do login de chave pública?
• (opcional) Você alterou a porta SSH de 22 para outra coisa?
• (opcional) Você adicionou um TOTP pam module para login?

Se sim, então você não precisa se preocupar. Esses ataques geralmente são ataques baseados em dicionário em nomes de usuários comuns em unix. Por exemplo, vejo com frequência esses "usuários" tentarem fazer login:

• raiz
• www-data
• teste
• admin

Eu realmente recomendo instalar fail2ban , já que limitará qualquer usuário tentando fazer login com base em seu ip, que sozinho deve filtrar a maior parte do tráfego malicioso. Ao contrário do que os outros dizem, eu não sou um defensor do bloqueio baseado em ip. Isso parece uma solução muito grosseira para um problema muito bom. Além disso, esses atacantes geralmente controlam vários ips, então, mesmo que você bloqueie vários (ou até mesmo vários blocos de ip), não há garantia de que você bloqueará todos eles. O Fail2ban, no entanto, é muito flexível para esses cenários.