Vale a pena o esforço para bloquear tentativas de login com falha

Vale a pena executar fail2ban , sshdfilter ou ferramentas semelhantes, quais endereços IP da lista negra tentam e não conseguem fazer login?

Eu já vi argumentar que esse é um teatro de segurança em um servidor "adequadamente protegido". No entanto, acho que isso provavelmente faz com que as crianças de script passem para o próximo servidor da lista.

Digamos que meu servidor esteja "adequadamente protegido" e não estou preocupado que um ataque de força bruta seja realmente bem-sucedido - essas ferramentas estão simplesmente mantendo meus arquivos de log limpos ou estou obtendo algum benefício que valha a pena bloquear tentativas de ataque de força bruta?

Atualização : Muitos comentários sobre a adivinhação de senhas por força bruta - mencionei que não estava preocupado com isso. Talvez eu devesse ter sido mais específico e perguntado se fail2ban tinha algum benefício para um servidor que permite apenas logins ssh baseados em chave.

A tentativa de limitar a taxa de login é uma maneira fácil de evitar alguns dos ataques de adivinhação de senha de alta velocidade. No entanto, é difícil limitar ataques distribuídos e muitos são executados em um ritmo baixo por semanas ou meses. Pessoalmente, prefiro evitar o uso de ferramentas de resposta automatizada como fail2ban. E isso é por duas razões:

1. Usuários legítimos às vezes esquecem suas senhas. Não quero banir usuários legítimos do meu servidor, forçando-me a habilitar manualmente suas contas novamente (ou pior, tente descobrir qual dos 100/1000 endereços IP banidos é deles).
2. Um endereço IP não é um bom identificador para um usuário. Se você tem vários usuários atrás de um único IP (por exemplo, uma escola que executa o NAT em 500 máquinas-aluno), um único usuário fazendo algumas suposições ruins pode levá-lo a um mundo de dor. Ao mesmo tempo, a maioria das tentativas de adivinhação de senha que vejo são distribuídas.

Portanto, não considero o fail2ban (e ferramentas de resposta automatizadas semelhantes) uma abordagem muito boa para proteger um servidor contra ataques de força bruta. Algumas regras simples do IPTables definidas para reduzir o spam de log (que eu tenho na maioria dos meus servidores Linux) são algo como isto:

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Impede mais de 4 tentativas de conexão de um único IP para ssh em qualquer período de 60 segundos. O restante pode ser tratado, garantindo que as senhas sejam razoavelmente fortes. Em servidores de alta segurança, forçar os usuários a usar autenticação de chave pública é outra maneira de parar de adivinhar.

Ferramentas como o fail2ban ajudam a reduzir o tráfego de rede desnecessário e a manter os arquivos de log um pouco menores e mais limpos. Não é uma grande solução para a segurança, mas facilita a vida do administrador de sistemas; é por isso que eu recomendo usar o fail2ban em sistemas onde você pode pagar.

Não se trata apenas de reduzir o ruído - a maioria dos ataques ssh tenta adivinhar as senhas com força bruta. Portanto, enquanto você vê muitas tentativas fracassadas de ssh, talvez até a 2034ª tentativa eles possam obter um nome de usuário / senha válidos.

O bom do fail2ban em comparação com outras abordagens é que ele tem um efeito mínimo nas tentativas válidas de conexões.

Bem, ele salva a sua rede de ataques de negação e economiza a sobrecarga de processamento das falhas.

Não ser o servidor mais fraco em uma lista de script kiddies é sempre uma coisa boa.

Desculpe, mas eu diria que seu servidor está protegido corretamente se o seu sshd recusar tentativas de autenticação com senhas.

PasswordAuthentication no