Existem vários pacotes diferentes para bloquear IPs dos quais ataques SSH de força bruta são lançados em seu sistema. Por exemplo:
Quais são os prós/contras disso ou de quaisquer outros?
Minha solução atual é pegar o e-mail que logwatch gera todos os dias e despejar os endereços IP notórios em um arquivo de texto que eu coloco em um script que reconstrói o iptables. É hacky, demorado e manual, e gostaria de uma maneira melhor.
(Observe que eu não perguntei qual era a "melhor" maneira de resolver o problema, porque não existe a "melhor" maneira de fazer nada.)
Eu uso DenyHosts, então posso pelo menos responder por isso:
Eu não tenho nenhum contras irreparáveis, desde que você o use corretamente:
/etc/hosts.allow
. Eu me tranquei uma vez apenas falhando ao digitar minha senha, e uma vez que alguém do trabalho tentou fazer login na minha conta root como uma piada e colocou meu IP de trabalho na lista negra, e demorei alguns dias para descobrir por que de repente não consegui me conectar para minha rede do trabalho maisOutro é fail2ban , que depende do iptables (por isso funciona com qualquer serviço, não apenas ssh). Com fail2ban, você pode:
Uma "desvantagem" do DenyHosts é que ele requer wrappers tcp, portanto, só funcionará 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).
Uma proteção simples e eficaz na prática 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 vão quebrar suas senhas fracas e possivelmente funciona através de mais firewalls do que a porta padrão (22).
A maioria dos métodos para prevenir ataques de força bruta ssh são ótimas maneiras de auto-DoS (opa, eu estraguei a configuração! Oops, fiz um monte de rsyncs rápidos e agora estou banido por hoje!) Ou auto-DoS assistido (opa , o invasor vem de/subverteu uma máquina na mesma sub-rede que eu (intervalo de IP dinâmico, rede de faculdade ...) e estou sendo banido também!).
Se você só fizer login em alguns lugares, basta colocar os endereços IP de origem na lista de permissões. Obviamente, isso não é bom se você quiser fazer o ssh do seu laptop ou telefone celular em trânsito.
Ter um daemon ssh que escuta apenas conexões IPv6 deve protegê-lo de varreduras por alguns anos ainda. Mas muitos firewalls não permitem que você transporte IPv6 de forma razoável.
Outro método que você não menciona é batida de porta . Ele não sofre de problemas de auto-DoS (exceto configuração incorreta), mas não atravessa bem os firewalls e pode adicionar latência de vários segundos ao estabelecimento da conexão.
Se você tem boas senhas ou pode viver sem a autenticação de senha, desative a autenticação de 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, também não confia que ela 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 intrusão (contanto que você tenha verificado que nenhuma de suas chaves veio de um OpenSSL de baixa entropia do Debian ) .
Resumindo, observe que mudar a porta não reduz significativamente sua exposição. Você terá menos escaneamento , mas tudo o que você pode cortar é o fruto mais fácil que busca explorar vulnerabilidades antigas e senhas fracas. Contanto que você mantenha seu daemon atualizado e imponha senhas razoáveis ou limites de taxa de tentativa razoáveis, trocar a porta é mais uma responsabilidade do que uma medida de segurança.