19.000 tentativas de senha raiz com falha no auth.log em 2 dias?

Question

Eu estava depurando alguns problemas de login e achei que houve muitas tentativas de senha com falha no meu /var/log/auth.log Esse é um Linode VPS.

Eu tentei encontrar tentativas de 19K nos últimos dois dias.

Eu sei que devo mover o sshd para uma porta diferente, mas parece uma dor para lembrar e usar, e um monte de scripts precisaria ser atualizado. Além disso, não poderia o atacante apenas portscan para encontrar a nova porta?

Eu tenho uma senha muito strong definida para root, então não estou muito preocupado.

E eu acho que é apenas 6 por minuto .... então provavelmente não é uma preocupação de desempenho.

Mas não parece ideal.

Alguma ideia de como bloqueá-lo ou impedi-lo?

Parece vir de uma pequena lista de endereços IP ... talvez eu possa bloquear isso? Eu verifiquei alguns, e eles parecem estar na China.

Outra opção seria desabilitar o login root e configurar um usuário sudo com um nome de usuário único. Mas eu não acho que isso vai ajudar com esse problema em particular - as pessoas ainda podem TENTAR o ssh como root ...

ATUALIZAÇÃO: Após o apt-get instalar o fail2ban com as configurações padrão, vi uma redução de 6-8x no número de tentativas erradas de root no auth.log:

root@localhost:/var/log# grep "Failed password for root" auth.log | wc
    21301  327094 2261733
root@localhost:/var/log# grep "May  1.*Failed password for root" auth.log | wc
    6217   95973  664165
root@localhost:/var/log# grep "May  2.*Failed password for root" auth.log | wc
    8370  127280  880779
root@localhost:/var/log# grep "May  3.*Failed password for root" auth.log | wc
    1030   16250  111837

Eu também eliminei a autenticação de senhas root ssh e mudei para login baseado em chave apenas para root, seguindo este procedimento: link

Isso não impede que as entradas de senha com falha apareçam no auth.log, no entanto. Significa apenas que, mesmo que eles saibam a senha, eles não podem passar. Portanto, o fail2ban reduz essas entradas de log, e o ssh baseado em chave para o root fornece segurança real.

Por fim, conforme sugerido, implementei a lista de permissões de IP da porta 22 para eliminar completamente as entradas de log. Para referência, isso pode ser feito no Ubuntu com ufw assim:

apt-get install ufw
ufw allow from 127.198.4.3 to any port 22
ufw --force enable

Eu estou usando --force lá porque estou fazendo isso em scripts, não interativamente, quando eu giro novos nós.

No entanto, para lidar com o acesso do meu IP dinâmico, sem mexer no console Lish baseado na web da Linode cada vez que meu IP muda, estou usando uma abordagem híbrida.

Eu tenho um servidor principal, hospedando meu domínio principal, e os outros nós são girados conforme necessário, como sub-servidores em subdomínios. O servidor principal hospeda a chave priv usada para o ssh nos sub-servidores. Também é o IP que está na lista de permissões do ssh.

Mas o servidor principal usa NO ssh keys, nem uma whitelist de IP. Eu quero ser capaz de acessá-lo de qualquer lugar em uma emergência, mesmo se eu não tiver o arquivo de chave comigo, ou mesmo de um lugar onde eu não confiaria para instalar o arquivo de chave. Preciso de algo como acesso por senha, mas seguro em um ambiente de registro de chaves ou comprometido com ssh.

A solução para isso, que venho usando há anos, é a autenticação de 2 fatores baseada em hardware, usando um dispositivo USB YubiKey, e o módulo Yubico PAM instalado no servidor principal.

Assim, mesmo que o atacante tenha a senha de root para o servidor principal, eles não poderão entrar sem meu YubiKey. E isso é fácil de carregar comigo. Posso acessar o root no meu servidor com segurança a partir do cyber cafe mais sujo do mundo.

E depois de chegar ao servidor principal, posso ssh em qualquer um dos sub-servidores sem senha.

Portanto, ainda preciso do fail2ban no servidor principal para reduzir as entradas auth.log. Não é necessário, afinal, nos sub-servidores, porque a lista branca de IPs cuida do problema.

    

Answer 1

Tentar bloquear faixas de IP específicas contra ataques de força bruta não é a maneira ideal de abordar o problema. Há um número de botnets e servidores constantemente varrendo a internet e tentando comprometer servidores e dispositivos. Seria extremamente ineficiente tentar bloquear o tráfego, então sua melhor opção é mitigá-lo ou evitá-lo todos juntos.

Uma maneira de reduzir o número de conexões que você vê é alterar a porta SSH. A maioria dos invasores usa a abordagem shotgun para comprometer hosts, então, desde que você escolha uma porta alternativa que não seja padrão, você não verá muitas tentativas de SSH, a menos que seja um ataque direcionado. Demora muito tempo para escanear todas as portas na internet, então, embora essa não seja a melhor abordagem, pode ser considerada uma forma de atenuar alguns ataques.

Outro método de atenuação é configurar algo como o Fail2Ban para fazer o bloqueio automático de IPs que não são autenticados várias vezes. Isso pode mitigar alguns dos ataques, mas não é muito eficaz nos dias de hoje, já que a maioria dos ataques de força bruta vêm de hosts distribuídos.

A melhor maneira de lidar com a segurança do SSH é limitar o acesso ao próprio serviço. Isso pode ser feito com a lista de permissões de IPs com permissão para acessar sua porta SSH e configurando a autenticação baseada em chave e desativando a autenticação de senha. Se o invasor não conseguir acessar a porta SSH ou nunca tiver uma chance de tentar uma senha, há pouca preocupação com um ataque de força bruta.

    

Answer 2

Eu não contaria com uma senha de root longa. 18 caracteres não são muito longos, especialmente se forem principalmente palavras com alguns símbolos e números.

Geralmente, é uma má idéia permitir logins raiz com uma senha em um servidor (especialmente um servidor voltado ao público), por alguns motivos: é fácil adivinhar o nome de usuário, há muito em jogo, e há muito de pessoas com scripts.

Mudar para apenas a autenticação baseada em chave para todos os usuários também não é uma má idéia. Em grande parte, elimina a ameaça de ataques de força bruta.