Eu me deparei com uma
discussão há três meses sobre a necessidade de portar a porta SSH. Muitos participantes da discussão estão convencidos de que não há necessidade de transferir a porta para uma porta não padrão.
Basta mudar para a autorização de chave e instalar o Fail2ban, e isso já será uma garantia de segurança. Infelizmente, vivemos em um mundo real e em constante mudança e as medidas de segurança propostas nem sempre são suficientes.
Vamos ver - a autorização de chave deixou duas chaves ssh relativamente seguras - RSA-4096 e ED25519, as chaves DSA não estão mais incluídas nas versões mais recentes do OpenSSH. Nesse caso, é preciso levar em consideração a presença na Internet de algumas dúvidas sobre a confiabilidade do ED25519, o Google para ajudar, se alguém estiver interessado.
Além das teclas, uma senha longa é recomendada para suas chaves, a partir de caracteres aleatórios em diferentes maiúsculas e minúsculas, pelo menos.
Ataques de força bruta - vamos ver brevemente o que acontece se seu host for atacado de propósito.
Etapa 1 - coleta de informações do host, incluindo portas abertas
Essa coleta de informações está longe de ser sempre refletida em seus logs, por exemplo, a verificação de portas pode ser realizada sem o estabelecimento de uma conexão. Fail2ban é inútil aqui, ele funciona apenas em entradas de log. No primeiro estágio, os sistemas de proteção instalados também podem ser monitorados. Por exemplo, o número de tentativas de autorização antes do bloqueio, o tempo de bloqueio é determinado.
Etapa 2 - tentativas de acessar o sistema através de hackers SSH
As redes de bots com milhares de endereços são usadas para hackers, e a varredura, no caso simples, ignora as configurações padrão do Fail2ban de centenas e milhares de endereços, com uma varredura séria levando em consideração as configurações do sistema de proteção à vítima. O Fail2Ban também é inútil aqui, especialmente se o SSH estiver na porta 22 e as configurações do Fail2Ban forem deixadas por padrão.
No meu perímetro externo de um dos servidores, todas as portas estão fechadas, mas em alguns dias até vários milhares de hosts estão tentando estabelecer uma conexão com as portas padrão. Além disso, a verificação leva em consideração possíveis proteções, os pacotes de um endereço costumam ter um intervalo de vários minutos.
Obviamente, o Fail2ban pode ser eficaz para proteger alguns outros serviços com configurações não padrão para seus hosts e serviços.
Por alguma razão, sempre parece que o segundo estágio é o mais perigoso; na verdade, o primeiro estágio procura possíveis vulnerabilidades no host; elas podem ser muito mais perigosas do que um simples SSH de força bruta. Por que quebrar o SSH quando há uma porta aberta com vulnerabilidade por perto?
Quanto à alteração da porta padrão, há uma recente revisão do
BestPractic sobre segurança SSH , onde a alteração da porta padrão custa 8 pontos, a autorização da chave é o primeiro item e a instalação do Fail2ban ou de 10 pontos análogos.
As 20 melhores práticas de segurança do servidor OpenSSH .
Mudar a porta SSH para fora do padrão permite usar portas padrão como uma armadilha para rastrear tentativas de varredura e bloquear endereços IP recebidos por um longo tempo e para todas as portas, isto é 11 pontos no artigo BestPractic. Naturalmente, é necessário especificar endereços brancos para não obter um bloqueio aleatório; esses são 7 e 8 pontos no artigo BestPractic.
Assim, aumentamos o custo de coleta de informações sobre nosso sistema. As informações sobre portas abertas custarão vários milhares de endereços IP ou meses para varrer nosso sistema. Se minha porta SSH não for conhecida pelo invasor em potencial, mesmo que apareça uma vulnerabilidade, ele não poderá usá-la.