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

Question

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

• DenyHosts
• Sshguard
• fail2ban

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

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

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

    

Answer 1

Eu uso o DenyHosts, então posso pelo menos responder por isso:

Prós

• É completamente automático
• É configurável (quantas tentativas fracassadas antes da lista negra, nomes de usuários que não existem, nomes de usuário que existem e uma entrada especial para o root)
• Ele pode enviar um e-mail com uma lista de hosts recém-colocados na lista negra periodicamente e / ou executar um determinado programa toda vez que um novo host for colocado na lista negra
• Suporta automaticamente os anfitriões que não estão na lista negra após algum tempo

Contras

Eu não tenho nenhuma desvantagem irreparável, desde que você a use corretamente:

• Na sua configuração padrão, você não irá alertá-lo para novos hosts na lista negra, portanto, se alguém estiver atacando sua rede de centenas de endereços diferentes, talvez você não perceba imediatamente, como faria se estivesse monitorando seus registros manualmente. como mencionado na seção de profissionais) ele pode enviar um e-mail para você ou executar um executável para alertá-lo quando novos hosts forem adicionados
• Por padrão, ele colocará seus hosts na lista negra da mesma forma que qualquer outro, portanto, você provavelmente desejará adicioná-los a /etc/hosts.allow . Eu me tranquei apenas uma vez ao digitar minha senha, e uma vez que alguém do trabalho tentou fazer login na minha conta root como piada e colocar meu IP no trabalho na lista negra, levei alguns dias para descobrir por que de repente eu não conseguia me conectar para a minha rede do trabalho mais

Answer 2

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

• Especifique o caminho para qualquer arquivo de log (apache, ssh, nginx, servidor de e-mail, etc.).
• Especifique regex para padrões de ataque (por exemplo, mais de 10 "erros 404" pelo mesmo ip em log de acesso nginx em 6 segundos)
• Especifique regex para ignorar certos padrões (muito útil!)
• Especifique o tempo de proibição
• 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 tcp wrappers, então ele só funciona com serviços que olham para o arquivo /etc/hosts.deny. Mas, para ser justo com o DenyHosts, o sshd é compilado para usar o TCP Wrappers na maioria das distribuições Linux. Eu também acho que o DenyHosts é mais fácil de configurar do que o fail2ban (mas menos poderoso).

Referência a um SF semelhante pergunta

    

Answer 3

Uma proteção simples e efetiva 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 quebrarão suas senhas fracas e possivelmente funcionarão 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 se auto-DoS (oops, eu estraguei tudo na configuração! Opa, eu fiz um monte de rsync rápido e agora estou banido do dia!) ou auto-assistido DoS (Ops, o invasor vem de / subverteu uma máquina na mesma sub-rede que eu (faixa de IP dinâmico, rede da faculdade ...) e estou sendo banido também!).

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

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

Outro método que você não menciona é batida de porta . Ele não sofre de problemas de auto-DoS (além de configuração incorreta), mas não atravessa bem os firewalls e pode adicionar vários segundos de latência ao estabelecimento da conexão.

Se você tiver boas senhas ou puder viver sem a autenticação por senha, desative a autenticação por senha. (Chaves e senhas únicas 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, você não confia que ela não tenha um keylogger também). Então 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 (contanto que você tenha verificado que nenhuma de suas chaves veio de um computador). OpenSSL de baixa entropia do Debian ).

Em suma, observe que a alteração da porta não reduz significativamente sua exposição. Você terá menos varredura , mas tudo o que você pode cortar é o resultado mais simples que procura explorar antigas vulnerabilidades e senhas fracas. Contanto que você mantenha seu daemon atualizado e imponha senhas razoáveis ou limites de taxa de tentativas razoáveis, trocar a porta é mais uma responsabilidade do que uma medida de segurança.