Por que alterar a porta ssh padrão? [fechadas]

Question

Tenho notado que muitos administradores alteram a porta ssh padrão.

Existe alguma razão racional para isso?

    

Answer 1

Não é tão útil quanto algumas pessoas afirmam, mas pelo menos reduz o impacto em seus arquivos de log, já que muitas tentativas de login de força bruta usam apenas a porta padrão em vez de verificar se o SSH está escutando em outro lugar. Alguns ataques irão procurar por SSH em outro lugar, por isso não é uma bala de prata.

Se o seu servidor for um host compartilhado de algum tipo, em vez de apenas atender às necessidades de seus projetos, usar uma porta não padrão pode ser um problema, pois você terá que explicá-lo aos seus usuários repetidamente. e mais e mais quando eles esquecem e seus programas cliente não conseguem se conectar à porta 22!

Outro problema possível com o SSH em uma porta não padrão é se você encontrar um cliente com um conjunto de filtros restritivo, que não pode se conectar à sua porta personalizada porque o filtro só permite, por exemplo, portas 22, 53, 80 e 443 para ser o destino de novas conexões de saída. Isso é incomum, mas certamente não é inédito. Em um assunto semelhante, alguns ISPs podem ver o tráfego criptografado em uma porta diferente daquelas em que é geralmente esperado (porta 443 ou HTTPS, 22 para SSH e assim por diante) como uma tentativa de ocultar uma conexão P2P e estrangular (ou bloquear) a conexão de uma maneira inconveniente.

Pessoalmente, mantenho o SSH na porta padrão por conveniência. Contanto que as precauções usuais sejam tomadas (senha strong / política chave, restrição de logins de root, ...) não precisa ser uma preocupação e o problema de crescimento do arquivo de log quando você é atingido por um ataque de força bruta pode ser mitigado usando ferramentas como como fial2ban para bloquear temporariamente hosts que fornecem muitos conjuntos ruins de credenciais de autenticação em um determinado espaço de tempo.

Qualquer que seja a porta escolhida, se você se afastar de 22, certifique-se de que ela esteja abaixo de 1024. Na maioria das configurações do Unix-a-like em sua configuração padrão, somente root (ou usuários no grupo raiz) podem ouvir portas abaixo de 1024, mas qualquer usuário pode escutar nas portas mais altas. Executar o SSH em uma porta mais alta aumenta a chance de um usuário desonesto (ou hackeado) conseguir travar seu daemon SSH e substituí-lo por um proxy próprio ou proxy.

    

Answer 2

É uma forma simples (mas surpreendentemente eficaz) de segurança através da obscuridade .

Se o seu servidor SSH não estiver na porta 22, é muito menos provável que seja encontrado por aqueles que fazem a varredura de toda a Internet, procurando por senhas fracas nas contas padrão. Se você estiver digitalizando toda a rede, não poderá verificar todas as 64k portas possíveis para encontrar o servidor SSH.

No entanto, se alguém estiver segmentando você especificamente, isso não trará nenhum benefício, já que uma simples varredura nmap única revelará a porta em que está sendo executada.

    

Answer 3

Para realmente evitar ataques de força bruta, é sempre importante seguir alguns passos:

• Instalar denyhosts ou fail2ban
• Limitar o número de conexões por segundo na porta ssh
• Alterar porta ssh
• Login raiz negado
• Ativar autenticação por chave em vez de senha

Answer 4

Sim, é útil, pois ajuda a evitar todos os ataques de força bruta e ajuda a manter os logs limpos:)

Quanto ao número da porta que é sua, vi empresas usarem 1291 com bastante frequência. Eu uso algo mais alto apenas para ajudar a evitar alguns dos scripts.

Não permitindo logins ssh root e alterando o número da porta e talvez algo como fail2ban e você deve ser de ouro. adicione o iptables para uma boa medida e mantenha-o atualizado e você não deve ter nenhum tipo de problema.

    

Answer 5

Using a nonstandard ssh port would require more explanation and documentation, and answering "I can't log in" emails.

Eu considero os seguintes benefícios de executar o sshd em uma porta não padrão mais importante do que os problemas que cria:

• 99,9999% dos ataques de força bruta são realizados por bots que procuram apenas a porta 22 e nunca perdem tempo tentando descobrir a porta não padrão. Ataques de força bruta e as contra-medidas como denyhosts ou fail2ban consomem recursos, que você salvará simplesmente executando o servidor ssh em uma porta não padrão.
• Você se livrará de todos os relatórios inúteis sobre bots que tentam invadir seu sistema. Se algum IP aparecer no relatório de logins com falha, é provável que seja um ser humano.

Além disso, se você quiser ser realmente desagradável, você sempre pode executar um sshd falso (com DenyUsers * ) na porta padrão 22, enquanto seu sshd regular é executado na porta 54321. Isso garantirá você que todos os bots e introvertidos vão tentar eternamente fazer login em um serviço que nega todos os logins, porque ninguém jamais pensará em tentar encontrar seu serviço sshd real .

Meus 2 centavos.

    

Answer 6

Fazer isso por qualquer motivo de "segurança" é falso. É o melhor exemplo de segurança pela obscuridade que não é segurança.

Se você quiser manter seus logs um pouco mais leves e limpos, então sim, é útil, já que você não conseguirá tantas tentativas de bruteforce para bater de portas / crianças com script.

    

Answer 7

Eu rodaria ssh na porta padrão e usaria algo como fail2ban ou denyhosts para limitar o número de ataques de dicionário.

Outra opção é desabilitar o login com senhas altogheter e somente permitir logins com chaves ssh.

    

Answer 8

Porque há muitas pessoas más por aí que examinam todos os IPs do servidor para abrir portas em uma tentativa de exploração. Eu costumava ter ataques de martelo em minha porta SSH durante todo o dia até que eu mudei para outra porta e em um IP que não estava ligado a nenhum dos meus sites.

    

Answer 9

Sempre modifico meu SSHd para usar a porta 2222, todos que precisam entrar nos meus servidores sabem disso e não é segredo. Não há absolutamente nenhum ganho de segurança ao fazer isso (a menos que o pretenso hacker seja um idiota absoluto).

O único benefício que recebo disto é que o log de autenticação não tem um milhão de tentativas de login falhadas para 'root', 'alice', 'bob', 'sally', 'admin ', etc.

    

Answer 10

É útil que os bots de script que tentam ataques de adivinhação de senha de força bruta geralmente se concentram na Porta 22, portanto, mudar as portas geralmente os coloca fora. Você precisará equilibrar o valor de mitigar esse risco com a dificuldade de configurar os clientes ssh para se conectarem à porta não padrão (não é um problema muito grande se você não tiver muitos usuários conectados, reconhecidamente).

Como alternativa, você poderia reduzir o risco de força bruta desativando a autenticação por senha e exigindo a autenticação por chave RSA.

Normalmente, não altero a porta no SSHD, por isso não posso sugerir outro número, mas verifique o termo comumente usado lista de portas para encontrar outro número (ou seja, um que não esteja sendo usado por outra coisa e, portanto, possa ser verificado).

    

Answer 11

Eu diria que a única coisa que você está se protegendo ao alterar a porta SSH são as verificações automatizadas que tentarão obter acesso usando nomes de usuário / senhas padrão, se suas políticas de senha estiverem restritas, você não deveria ter se preocupar com eles.

    

Answer 12

Se você desativar logins de senha em seu servidor (o que é altamente recomendado), a alteração da porta SSH será completamente inútil. Ao desabilitar os logins de senha (e exigir autenticação baseada em chave), você remove a possibilidade de tentativas de senha de força bruta, de modo que não está ganhando nada por meio de números de porta.

Se você continuar a permitir a autenticação com base em senha, estará se abrindo à possibilidade de uma tentativa de força bruta bem-sucedida ou - mais comum, em minha experiência - sua senha ser comprometida porque você a digita ao usar um sistema executando um keylogger.

    

Answer 13

A segurança através da obscuridade provou ser inútil, geralmente eu configuro o acesso ssh com a porta padrão por todas as razões mencionadas acima (problemas do cliente na reconfiguração, problemas de firewall e proxy, etc.).

Além disso, eu sempre desabilito o login de raiz e a autenticação de senha e como último passo eu uso o fail2ban para me livrar dessas mensagens irritantes no syslog. No Debian / Ubuntu, é tão simples quanto digitar aptitude install fail2ban . A configuração padrão funciona muito bem, mas eu costumo ajustar alguns parâmetros para serem mais restritivos, tendo mais tempo de banimento (pelo menos um dia) e apenas duas tentativas de autenticação com falha como gatilho para o banimento.

    

Answer 14

Apesar de parecer uma típica "segurança pela obscuridade", eu estimaria como tendo bom senso, já que a varredura de todas as portas possíveis (~ 64k) é muito mais custosa do que apenas uma delas.

Mas posso acrescentar que "bater à porta" é muito melhor.

    

Answer 15

Não é uma resposta, mas é muito longa para um comentário, portanto, farei esta CW.

Eu estive pensando sobre isso por um tempo e cheguei à conclusão de que há muita verdade no que Juliano diz em comentários à resposta de Alnitak. No entanto, acho que ao rodar o SSH na porta 22, fica muito fácil lançar ataques de qualquer tipo contra ele.

Para resolver esse problema, executo meus servidores SSH internos na porta 22 e uso o firewall para encaminhar a porta alta para 22 nas máquinas de destino. Isso dá alguma segurança através da obscuridade, mantendo a segurança de uma porta baixa, como Juliano apontou.

Segurança através da obscuridade não é um princípio que eu normalmente subscrevo e é frequentemente apontado que uma simples varredura de portas revelará a porta alvo, tornando a obscuridade sem valor. Para resolver esse problema, meus firewalls (Smoothwall Express), tanto no trabalho quanto em casa, usam um script chamado Guardian Active Response, que é acionado por alertas do Snort. A partir da observação, posso dizer que quando você atinge mais de 3 portas diferentes da mesma fonte, seus pacotes são descartados até o tempo de reinicialização predefinido. Isso torna bastante difícil e extremamente demorado executar uma varredura de portas, fazendo com que a obscuridade realmente valha alguma coisa. Isso, na verdade, fez com que eu fosse excluído tantas vezes no passado que defini uma exclusão para o endereço IP da minha fonte (casa ou escritório). É claro que um atacante pode tropeçar na porta correta na primeira vez, mas as chances são baixas.

    

Answer 16

O problema que você tem é que o firewall está configurado para permitir apenas que certos IPs se conectem, e o chefe está cansado de abrir IP's específicos quando ele está fora de casa. Se você está bloqueando determinados IPs no firewall, isso pode ser um saco no escuro.

Duas coisas eu penso aqui. A alteração da porta protege contra ataques automatizados. É sobre isso, mas é uma grande parte do tráfego médio de ataques ... scripts automatizados de varredura de redes. Se você alterar a porta padrão, esses ataques devem cair direto para nada. Então faz sentido a esse respeito. Mas não faz nada contra um ataque direcionado, já que o atacante pode apenas fazer uma varredura a partir do Nessus ou do NMAP para determinar que porta (s) você está usando se você tiver um amiguinho especial que odeia o suficiente.

Em segundo lugar, se você estiver usando servidores semelhantes ao UNIX, poderá instalar um utilitário como o Denyhosts para interromper ataques. Se você instalar o denyhosts, ele monitora tentativas de login incorretas e depois de tentativas incorretas (o que você determinar o número) ele irá banir o IP por um período de tempo especificado por você. O Denyhosts também pode conversar com outros hosts do denyhost e passar listas de banimento, então se um invasor for bloqueado do sistema Linux de Fred em Montana, seu sistema também receberá esse IP para banimento. Muito útil, desde que seus usuários lembrem suas senhas.

Tudo depende dos seus cenários de uso. Quantos programas você tem que são um "pé no saco" para mudar a porta de conexão para SSH / SCP (e se eles não permitirem ou causarem problemas, você realmente precisa considerar a mudança de fornecedores, pessoalmente). Se é apenas um medo potencial, eu diria que não é um problema. E este é o seu chefe, pedindo por algo que não é totalmente maluco, já que muitos administradores rodam a porta SSH (com algumas críticas de pessoas que odeiam qualquer coisa que cheire levemente a segurança através da obscuridade ... mas realmente reduz ruído de fundo causado por varreduras automatizadas.)

Fervido - alterar a porta bloqueia scripts automatizados e a maior parte do tráfego ruim. Não vai parar de atacantes direcionados. Considere também instalar um utilitário de proibição automatizado. A segurança nas camadas não prejudica você se for feita de maneira adequada e a alteração de portas ajuda mais do que prejudica na maioria das situações.

    

Answer 17

Estou executando o SSH na porta > 1024 há mais de 5 anos. Desde então, não vejo nenhuma tentativa de varredura de portas em meu arquivo de log (exceto por mim mesmo). Existem meus servidores que eu admin que rodam usando o port > 1024.

Muitos dos servidores SSH que são executados na porta > 1024, possuem seus próprios sites, o que é bastante popular.

Se o servidor SSH for executado em minha própria empresa, talvez eu já tenha postado o endereço IP desse servidor aqui para que vocês possam tentar invadir o servidor. Infelizmente o servidor SSH não é meu. ; -)

Mas há outras coisas que você deve configurar para torná-lo seguro. SSH > 1024 sozinho não seria suficiente. O número da porta não deve estar no / etc / services, deve usar o encaminhamento de porta (por exemplo, porta 1124- > 22), o acesso direto ao Root deve ser desabilitado e outra coisa.

Então, se você quiser argumentar, é melhor executar o SSH na porta > 1024 por alguns anos.

p / s: 1124 não é meu porta SSH no. Haha.

    

Answer 18

eu acho que se você ainda não descobriu a porta batendo, ou não,

    

Answer 19

O SSH bem em movimento para uma porta diferente faz algum sentido, ajuda com a segurança, mas não muito. É claro que, para isso, você precisa ter controle sobre seus firewalls, mas isso não é um problema para você. O que eu acho que desfaz o benefício de mover o porto é a abertura do intervalo aceito - na verdade, eu diria que isso mais do que desfaz o benefício e o expõe ainda mais do que você é hoje. Tenho certeza de que você pode convencê-lo a mover a porta E reduzir significativamente o intervalo de entrada agrupando uma lista de possíveis pontos de entrada, em vez de apenas abri-los todos.

    

Answer 20

Mudar sua porta ssh é um exercício inútil que só lhe garante segurança limitada. É melhor desabilitar a autenticação de senha, o que elimina o risco de tentativas de senha de força bruta e depende exclusivamente da autenticação baseada em chave ssh. Se o seu ambiente requer autenticação por senha, adote algum mecanismo de dois fatores, como o SecurID ou o Wikid.

Ambos fornecem um aumento real na segurança, enquanto a alteração da porta ssh oferece a ilusão de segurança.

    

Answer 21

Isso é prático POV: Eu operava servidores ssh privados publicamente visíveis por mais de quatro anos com a porta SSH alterada e não tive nenhuma tentativa de verificação de senha. Por causa deste controle de qualidade eu acabei de ativar 22 em um deles por um dia. Como resultado, fui examinado aproximadamente a cada 10 minutos, com frequência de tentativa de senha em torno de 5 por segundo. Além disso, "scan kiddies" também procura servidores com certas vulnerabilidades do OpenSSH.

Com certeza, isso é segurança pela obscuridade , o que não ajuda se você tiver inimigos.

    

Answer 22

Funciona muito bem, independentemente da lamentação da multidão de "segurança através da obscuridade".

Coelhos parvos, TODA a segurança é segurança através da obscuridade. Só porque você acredita que o obscuro protocolo de criptografia Z [requerendo uma combinação de amostras de DNA, chaves compartilhadas e impossível de ser digitado por senhas humanas] é realmente seguro, não o faz. A verdade é que toda e qualquer medida de segurança depende de probabilidades e suposições dos usuários. Muito ruim para você se eu souber explorar essa suposição, mas aí está.

De qualquer forma,

Fazemos isso há anos, junto com a) limitando a taxa de tentativas de conexão (no entanto, não sei como configuramos isso, algo na configuração ssh) eb) um script para banir qualquer host que esteja executando um ataque de dicionário com mais de X palpites errados em Y minutos. Proibimos o host de fazer a conexão por um período de tempo e isso facilita a adaptação à topologia de redes em mudança.

Se as suas senhas são suficientemente complexas, e elas só podem fazer 3 tentativas em 15 minutos, não há muito a temer. Também não é difícil assistir a ataques distribuídos - geralmente agrupamos por sub-rede e ip para controlar esse tipo de coisa.

Finalmente, tudo o que você precisa é de algum método secreto de squirrel para permitir conexões com sua porta, modificando as regras f / w. Pode ser qualquer coisa ... smtp, web, magic dns queries. Coisas como SecurID ou Wikid apenas entregam mais informações a terceiros. E não me faça começar em certificados seguros através de terceiros.