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 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:
Prós
- É completamente automático
- É configurável (quantas tentativas falhadas antes da lista negra, para nomes de usuário que não existem, nomes de usuário que existem e uma entrada especial para root)
- Ele pode lhe 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
- Ele oferece suporte à remoção automática da lista negra de hosts após um tempo
Contras
Eu não tenho nenhum contras irreparáveis, desde que você o use corretamente:
- Em sua configuração padrão, ele não irá alertá-lo sobre hosts recém-colocados na lista negra, portanto, se alguém estiver atacando sua rede de centenas de endereços diferentes, você pode não notar imediatamente como faria se estivesse monitorando seus registros manualmente, mas (como mencionado em a seção de profissionais) pode enviar um e-mail ou executar um executável para alertá-lo quando novos hosts forem adicionados
- Por padrão, ele irá bloquear seus hosts da mesma forma que qualquer outro, então você provavelmente deseja adicioná-los a
/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 mais
Outro é fail2ban , que depende do iptables (por isso funciona com qualquer serviço, não apenas ssh). Com fail2ban, você pode:
- Especifique o caminho para qualquer arquivo de log (Apache, ssh, nginx, servidor de correio, ...).
- Especifique regex para padrões de ataque (por exemplo, mais de 10 "erros 404" pelo mesmo ip no log de acesso nginx em 6 segundos)
- Especifique regex para ignorar certos padrões (muito útil!)
- Especifique o tempo de proibição
- Envie um e-mail (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, 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.