Por que alterar a porta ssh padrão?

Question

Tenho notado que muitos administradores alteram a porta ssh padrão. Existe alguma razão racional para isso?

    

Answer 1

O motivo mais provável é tornar mais difícil para as pessoas tentando aleatoriamente forçar qualquer login SSH que possam encontrar. Minha máquina voltada para a Internet usa a porta SSH padrão e meus registros costumavam ser preenchidos com coisas como essa (extraídas de um arquivo de log real):

sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96

Hoje em dia eu uso DenyHosts para bloquear IPs que não autenticam muitas vezes, mas provavelmente é tão fácil simplesmente trocar de porta ; virtualmente todos os ataques de força bruta deste tipo não vão incomodar a varredura para ver se o seu sshd está escutando em outra porta, eles apenas assumirão que você não está rodando um e seguir em frente

    

Answer 2

Não, é uma tática de segurança por obscuridade .

Se a sua configuração do sshd não estiver ajustada o suficiente para enfrentar os kiddies de script idiotas que estão apenas tentando a porta 22, você tem um problema de qualquer maneira.

Uma reação mais racional seria:

• verifique se seus usuários estão usando boas senhas difíceis de adivinhar / força bruta
• desabilitar a autenticação por senha (pelo menos para contas importantes) e apenas usar autenticação de chave pública
• cuidado com os problemas e atualizações do ssh-security

Algumas pessoas também podem ficar incomodadas com o ruído que o sshd escreve no log do sistema, por exemplo:

Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth

Pode ser tentador obscurecer a porta sshd ou usar uma solução de bloqueio automático (como DenyHosts, Fail2ban ou BlockHosts) para aumentar o relação sinal-ruído novamente.

Mas melhores alternativas existem. Por exemplo, você pode configurar seu daemon syslog de modo que o ruído do log sshd seja gravado apenas para - digamos - /var/log/sshd-attempts.log e o sinal (isto é, as mensagens restantes do log sshd) seja gravado em /var/log/messages etc. como antes. >

A implantação de ferramentas automáticas de bloqueio deve ser considerada com cuidado, porque adicionar mais complexidade a sistemas relevantes de segurança significa também aumentar o risco da exploração . E, de fato, ao longo dos anos, há vários relatórios Vulnerabilidade DoS para cada DenyHosts , Fail2ban e BlockHosts .

    

Answer 3

A alteração da porta SSH é principalmente teatro de segurança . Isso lhe dá uma sensação confusa de ter feito alguma coisa. Você ocultou a porta SSH sob o capacho.

Se você executar um servidor SSH na Internet, você verá muitas tentativas de login com falha em seus registros, de bots que estão procurando por senhas estupidamente fracas, chaves fracas e exploits conhecidos em versões mais antigas do servidor. As tentativas fracassadas são apenas isso: tentativas com falha . No que diz respeito a avaliar quão vulnerável você é, eles são completamente irrelevantes. O que você precisa se preocupar é com as tentativas bem-sucedidas de invasão, e você não verá essas em seus registros.

A alteração da porta padrão reduzirá o número de acessos desses bots, mas isso frustrará os invasores menos sofisticados que forem parados por qualquer segurança decente (atualizações de segurança aplicadas regularmente, senhas razoavelmente strongs ou autenticação de senha desativada). A única vantagem é reduzir o volume de logs. Se isso for um problema, considere algo como Denyhosts ou Fail2ban para limitar a taxa de conexão, ela também fará sua largura de banda boa.

A alteração da porta padrão tem uma grande desvantagem: diminui a probabilidade de você efetuar login por trás de um firewall. É mais provável que os firewalls deixem os serviços na porta padrão do que em alguma outra porta aleatória. Se você não estiver executando um servidor HTTPS, considere também fazer o SSH ouvir na porta 443 (ou redirecionar as solicitações TCP recebidas da porta 443 para a porta 22), pois alguns firewalls permitem tráfego que eles não podem decodificar na porta 443 porque parece como HTTPS.