O Fail2ban não protege o SSH, e é o próprio README que o diz
Instalar o fail2ban, ver o contador de banimentos a subir, sentir-se mais seguro. É essa sequência que explica por que a ferramenta está em quase todos os servidores, e é também por isso que muitos desses servidores estão menos protegidos do que os seus donos julgam.
A formulação mais clara do problema não está numa crítica ao fail2ban. Está no próprio README do fail2ban.
O que faz na realidade
O mecanismo é simples e funciona. O Fail2ban analisa ficheiros de registo como /var/log/auth.log e bane os endereços IP que conduzem demasiadas tentativas de login falhadas. Fá-lo atualizando as regras da firewall do sistema para rejeitar novas ligações a partir desses endereços IP, durante um período de tempo configurável.
Vem pronto a ler muitos ficheiros de registo padrão, incluindo os do sshd e do Apache, e pode ser apontado a qualquer ficheiro de registo à sua escolha, para qualquer erro que pretenda. Desde a versão 0.10 também corresponde a endereços IPv6.
Isto é uma peça de infraestrutura genuinamente útil. Um servidor exposto à internet acumula milhares de tentativas de login automatizadas por dia, e o fail2ban transforma essa enxurrada num fio de água.
A frase que o projeto põe no seu próprio README
É aqui que a ferramenta é mais honesta do que a maioria dos conselhos que se dão sobre ela:
Embora o Fail2Ban consiga reduzir a taxa de tentativas de autenticação incorretas, não consegue eliminar o risco apresentado por uma autenticação fraca.
Repare no que isto admite. O fail2ban atua sobre a taxa. Não atua sobre o risco. São grandezas diferentes, e confundi-las é todo o erro.
Se o seu servidor SSH aceita uma palavra-passe, um atacante tem de a adivinhar. O fail2ban abranda a adivinhação até a tornar lentíssima e torna impraticável uma força bruta ingénua. Mas a porta continua a abrir-se para quem tiver a palavra-passe, quer a tenha adivinhado, obtido por phishing, comprado numa fuga de credenciais ou retirado de um login reutilizado num site sem relação que sofreu uma brecha. Nenhum destes caminhos envolve falhas repetidas, por isso nenhum deles aciona um banimento.
O que o projeto lhe diz para fazer em vez disso
O README não fica pelo aviso. Nomeia a alternativa:
Configure os serviços para usarem apenas mecanismos de autenticação de dois fatores, ou de chave pública/privada, se quiser mesmo proteger os serviços.
É esta a correção real, e é uma mudança de natureza e não uma mudança de grau. Um servidor que aceita apenas autenticação por chave não pode ser sujeito a força bruta de todo, porque não há nada a adivinhar. A superfície de ataque não é reduzida, é eliminada.
Repare na palavra apenas. Acrescentar uma chave deixando a autenticação por palavra-passe ativada não muda nada quanto ao risco, porque o método aceite mais fraco é o que define a sua exposição. A definição que conta é desativar a autenticação por palavra-passe, não acrescentar uma chave ao lado dela.
Então deve usá-lo
Sim, e pela razão certa.
Mantenha-o pelo ruído. Registos que consegue realmente ler valem muito. Quando as tentativas de autenticação falhadas caem de milhares por dia para um punhado, uma anomalia torna-se visível em vez de ficar soterrada. Isso é um benefício operacional real e um bom argumento a favor da ferramenta.
Não o conte como a sua segurança de SSH. Se uma revisão de segurança do seu servidor termina em “o fail2ban está instalado”, a revisão parou um passo cedo demais. A pergunta que decide a sua exposição é se a autenticação por palavra-passe continua a ser aceite.
Repare no que lhe custa. Os banimentos aplicam-se a endereços, e os endereços são partilhados. Uma palavra-passe mal escrita numa rede empresarial ou móvel pode bloquear toda a gente que esteja por trás desse endereço, incluindo você. O fail2ban é uma das formas mais comuns de os administradores se trancarem fora dos seus próprios servidores.
O resumo honesto
O Fail2ban faz exatamente o que diz: reduz a taxa de tentativas de autenticação falhadas banindo na firewall os endereços ruidosos, durante um tempo configurável, com base nos seus registos.
A sua própria documentação é explícita ao dizer que isto não consegue eliminar o risco apresentado por uma autenticação fraca, e que os serviços que quer mesmo proteger devem usar mecanismos de dois fatores ou de chave pública e privada. Estas duas frases valem mais do que a maioria das checklists de hardening.
Use o fail2ban para manter os seus registos legíveis. Desative a autenticação por palavra-passe para manter o seu servidor. Não são substitutos um do outro, e só um deles muda aquilo que um atacante é capaz de fazer.
A descrição do comportamento do fail2ban, a limitação citada sobre a autenticação fraca, a recomendação de usar autenticação de dois fatores ou de chave pública e privada, e o suporte de IPv6 desde a versão 0.10, são retirados do próprio README do projeto fail2ban, verificado à data de escrita. Os detalhes de configuração variam consoante a distribuição; consulte a documentação do seu próprio pacote antes de depender de um caminho ou predefinição específicos.