Quais são os prós / contras dos vários métodos para bloquear ataques SSH de força bruta?

Existem vários pacotes diferentes para bloquear IPs dos quais ataques SSH de força bruta são lançados no seu sistema. Por exemplo:

• DenyHosts
• Sshguard
• fail2ban

Quais são os prós / contras destes ou de outros?

Minha solução atual é pegar o e-mail que o logwatch gera todos os dias e despejar os endereços IP flagrantes em um arquivo de texto que eu alimento em um script que reconstrói o iptables. É hacky, demorado e manual, e eu gostaria de uma maneira melhor.

(Observe que não perguntei qual era a "melhor" maneira de resolver o problema, porque não há "a melhor" maneira de fazer alguma coisa.)

Eu uso DenyHosts, pelo menos posso responder por isso:

Prós

• É completamente automático
• É configurável (quantas tentativas fracassadas antes da lista negra, para nomes de usuários que não existem, nomes de usuários que existem e uma entrada especial para raiz)
• Ele pode enviar um e-mail para você com uma lista de hosts na lista negra recentemente periodicamente e / ou executar um determinado programa toda vez que um novo host estiver na lista negra
• Ele suporta automaticamente a exclusão da lista negra de hosts depois de um tempo

Contras

Não tenho contras irreparáveis, desde que você o use corretamente:

• Em sua configuração padrão, ele não o alertará para hosts recém-colocados na lista negra; portanto, se alguém estiver atacando sua rede a partir de centenas de endereços diferentes, talvez você não perceba imediatamente como faria se estivesse monitorando seus logs manualmente, mas (como mencionado em seção profissionais), pode enviar um e-mail ou executar um executável para alertá-lo quando novos hosts forem adicionados
• Por padrão, ele lista os seus hosts da mesma forma que qualquer outro, portanto você provavelmente deseja adicioná-los /etc/hosts.allow. Tranquei-me uma vez, apenas falhando em digitar minha senha, e uma vez que alguém do trabalho tentou acessar minha conta raiz como uma piada e colocou na lista negra meu IP do trabalho, e levei alguns dias para descobrir por que de repente não consegui me conectar para minha rede do trabalho mais

Outro é o fail2ban , que depende do iptables (por isso funciona com qualquer serviço, não apenas com o ssh). Com fail2ban, você pode:

• Especifique o caminho para qualquer arquivo de log (apache, ssh, nginx, servidor de email, ...).
• Especifique regex para padrões de ataque (por exemplo, mais de 10 "erros 404" pelo mesmo IP no log de acesso ao nginx em 6 segundos)
• Especifique regex para ignorar certos padrões (muito útil!)
• Especifique o tempo de banimento
• Enviar um email (ou qualquer outro alerta ...)
• Totalmente personalizável (você pode escrever seus próprios alertas e filtros)

Uma "desvantagem" do DenyHosts é que ele requer wrappers tcp, portanto, ele funcionará apenas com serviços que examinam o arquivo /etc/hosts.deny. Mas, para ser justo com o DenyHosts, o sshd é compilado para usar TCP Wrappers na maioria das distribuições Linux. Também acho o DenyHosts mais fácil de configurar do que o fail2ban (mas menos poderoso).

Referência a uma pergunta SF semelhante

Uma proteção simples e na prática eficaz contra ataques baseados em varredura não é usar a porta padrão. 443 (a porta https) expõe você a diferentes ataques de força bruta que não quebram suas senhas fracas e possivelmente funcionam com mais firewalls do que a porta padrão (22).

A maioria dos métodos para impedir ataques de força bruta ssh são ótimas maneiras de auto-DoS (oops, eu estraguei a configuração! Oops, fiz vários rsync rápidos e agora estou banido por um dia!) Ou auto-DoS assistido (Oops , o atacante vem de / subverteu uma máquina na mesma sub-rede que eu (faixa dinâmica de IP, rede da faculdade ...) e também estou sendo banido!).

Se você fizer login apenas de alguns lugares, poderá colocar apenas os endereços IP de origem na lista de permissões. Obviamente, isso não é bom se você deseja transferir ssh do seu laptop ou celular em movimento.

Ter um daemon ssh que ouça apenas conexões IPv6 deve protegê-lo de verificações por alguns anos ainda. Mas muitos firewalls não permitem transportar o IPv6 de maneira razoável.

Outro método que você não menciona é a porta batendo . Ele não apresenta problemas de auto-DoS (exceto configuração incorreta), mas não cruza bem os firewalls e pode adicionar alguns segundos de latência ao estabelecimento da conexão.

Se você possui boas senhas ou pode viver sem autenticação por senha, desative a autenticação por senha. (Chaves e senhas de uso único são suficientes para a maioria dos casos de uso: se você não confia na máquina cliente o suficiente para armazenar uma chave ssh, não confia que ela também não tenha um keylogger). Então os ataques de força bruta custarão um pouco de CPU e largura de banda, mas não o exporão a uma invasão (desde que você verifique se nenhuma de suas chaves veio de um OpenSSL de baixa entropia Debian ).

Em suma, observe que alterar a porta não reduz significativamente sua exposição. Você terá menos varredura , mas tudo o que você pode cortar é a fruta que procura explorar vulnerabilidades antigas e senhas fracas. Desde que você mantenha seu daemon atualizado e imponha senhas razoáveis ​​ou limites razoáveis ​​de taxa de tentativa, alternar a porta é mais uma obrigação do que uma medida de segurança.