Não é tão útil quanto algumas pessoas afirmam, mas pelo menos reduzirá o impacto nos arquivos de log, já que muitas tentativas de login de força bruta usam apenas a porta padrão em vez de varrer para verificar se o SSH está escutando em outro lugar. Alguns ataques vão procurar SSH em outro lugar, portanto, não é uma bala de prata.
Se o seu servidor for de algum tipo um host compartilhado, em vez de apenas atender às necessidades de seus projetos, o uso de uma porta não padrão pode ser uma dor, pois você precisará explicá-lo para os usuários várias e várias vezes. quando eles esquecem e seus programas clientes não conseguem se conectar à porta 22!
Outro possível problema com o SSH em uma porta não padrão é se você encontrar um cliente com um conjunto de filtros de saída restritivo, que não pode se conectar à sua porta personalizada porque o filtro deles permite apenas, por exemplo, as portas 22, 53, 80 e 443 como o destino para novas conexões de saída. Isso é incomum, mas certamente não é inédito. De maneira semelhante, alguns ISPs podem ver o tráfego criptografado em uma porta diferente daquela 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 o acelerador (ou bloco) a conexão de maneira inconveniente.
Pessoalmente, mantenho o SSH na porta padrão por conveniência. Desde que sejam tomadas as precauções habituais (política forte de senha / chave, restrição de logins raiz, ...), não é necessário se preocupar 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 incorretos de credenciais de autenticação em um determinado espaço de tempo.
Qualquer que seja a porta que você escolher, se você se afastar de 22, verifique se ela está abaixo de 1024. Na maioria das configurações semelhantes ao Unix, na configuração padrão, apenas o usuário root (ou os usuários do grupo raiz) podem ouvir portas abaixo de 1024, mas qualquer usuário pode ouvir nas portas mais altas. A execução do SSH em uma porta mais alta aumenta a chance de um usuário não autorizado (ou hackeado) conseguir travar seu daemon SSH e substituí-lo por um ou por um proxy.
Eu sou o único usuário deste servidor. Obrigado por esclarecer a questão 1024+. Eu teria usado uma porta 48xxx se eu escolhesse. De qualquer forma, neste momento ainda não entendi se é útil ou não = /
dynamic
16
+1 para o> 1024 bits.
MattC
26
É 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 pesquisam toda a Internet procurando 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 o estiver ativamente alvejando especificamente, ele não fornecerá nenhum benefício, pois uma simples nmapvarredura pontual revelará a porta na qual está realmente sendo executada.
"verifique todas as portas possíveis de 64k" ... Executar SSH em qualquer porta acima de 1023 está errado. Isso torna o sistema mais vulnerável do que deixá-lo em execução na porta padrão.
Jul10
3
@ Juliano - por favor, explique. Só porque você precisa ser root para ouvir em uma porta privilegiada (AFAIK) não torna seguro executar em uma porta não privilegiada.
Alnitak
4
A propósito, não é segurança através da obscuridade; caso contrário, você também precisará chamar a autenticação de senha da mesma forma. Segurança através da obscuridade é quando a implementação não é divulgada. Aqui, a implementação é claramente declarada (é "Alterei a porta de serviço") e o segredo ("qual porta?") Ainda é secreto.
Jul10
5
@ John - na verdade eu vejo o ponto de @ Juliano. Isso não torna o daemon SSH intrinsecamente menos seguro, mas no caso geral, a execução em uma porta não privilegiada anula a suposição normal de que o root iniciou o daemon. Portanto, se você pode, de alguma forma, parar esse daemon (por exemplo, executando DoSing), você pode iniciar seu próprio daemon falso em seu lugar sem precisar de uma exploração raiz. Esse daemon falso pode capturar detalhes suficientes para permitir novas explorações.
Alnitak
2
@ John, isso é verdade - ainda exige que o invasor tenha acesso suficiente para iniciar um novo daemon. O ponto principal é que eles não precisam mais de acesso root para iniciá-lo.
Alnitak
21
Para realmente evitar ataques de força bruta, é sempre importante seguir alguns passos:
Instale denyhosts ou fail2ban
Limitar o número de conexões por segundo na porta ssh
Parece uma boa lista, exceto a parte de mudança de porta com a qual eu realmente não concordo, isso é muita obscuridade. Um scanner de porta moderno o encontrará em alguns segundos, afinal? (e muitas redes não vai deixar aleatório porta tráfego para fora, geralmente limitado a dizer 22, 80 e 443)
Oskar Duveborn
1
Os ataques de força bruta de limite de alteração de porta que verificam se o ssh está sendo executado na porta padrão, bem, se o ataque for mais sério, somente nesse caso o invasor pode executar uma verificação das portas do furo na sua rede / hosts.
277 Ali Ali Mezgani
1
Na verdade, acho que por trás de um bom firewall, se você mantiver seus serviços atualizados e se alterar a configuração padrão deles, poderá estar protegido contra ataques de pessoas mal-intencionadas. e pode não ser de exploits 0 dias ou ataques desconhecidos
Ali Mezgani
2
O uso de denyhosts / fail2ban reduz a necessidade de alternar portas ou exigir chaves. Se você não permitir senhas, não faz sentido usar denyhosts / fail2ban ou alterar portas.
Jeremy L
1
O uso de denyhosts / fail2ban não atenua necessariamente a necessidade de medidas de segurança adicionais. O objetivo da segurança é criar o maior número possível de bloqueios de estradas para os usuários que tentam contornar a segurança. Claro que você provavelmente não precisa alterar a porta de 22 para 2222, mas diga que outro administrador aparece e reativa a senha ... você ainda terá vários outros obstáculos de velocidade. Cada etapa listada acima fornece ao administrador uma porcentagem próxima da impossibilidade de 100% de segurança.
Patrick R
12
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 depende de você, tenho visto empresas usarem 1291 com bastante frequência. Eu uso algo mais alto, porém, apenas para ajudar a evitar alguns dos scripts.
Não permitindo logins root ssh e alterando o número da porta e talvez algo como fail2ban e você deve ser de ouro. adicione iptables para uma boa medida e mantenha as coisas atualizadas e você não deve ter nenhum tipo de problema.
Mas observe a resposta de David Spillett para saber por que a porta 1291 (maior que 1024) pode ser perigosa.
Konerak
Se você for aconselhado a usar uma porta sem privilégios 2 anos depois de muitas outras respostas melhores - talvez prepare uma razão melhor do que 'eu já vi empresas fazerem isso'. Vi empresas fazerem muitas coisas. Eu raramente quero seguir o exemplo deles.
underscore_d
11
O uso de uma porta ssh fora do padrão exigiria mais explicações e documentação, além de responder aos emails "Não consigo fazer login".
Considero os seguintes benefícios da execução do sshd em uma porta não padrão mais importantes do que os problemas que ela cria:
99,9999% dos ataques de força bruta são executados por bots que procuram apenas a porta 22 e nunca perdem tempo tentando descobrir a porta não padrão. Os ataques de força bruta e as contra-medidas como denyhosts ou fail2ban consomem recursos, que você economizará 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 humano.
Além disso, se você quer ser realmente desagradável, sempre pode executar um sshd falso (com DenyUsers * ) na porta padrão 22, enquanto o sshd normal é executado na porta 54321. Isso garantirá que todos os bots e aspirantes a intrusos irão eternamente tente fazer login em um serviço que negue todos os logins, porque ninguém nunca pensou em tentar encontrar seu serviço sshd real .
Isso pode resultar em ainda mais chamadas de suporte.
23911 Brad Gilbert
3
Isso é verdade, mas a segurança aprimorada tem um preço. :)
Nascido para montar
11
Fazer isso por qualquer motivo de "segurança" é falso. É o melhor exemplo de segurança pela obscuridade, que não é segurança.
Se você deseja manter seus registros um pouco mais claros e limpos, é útil que você não tenha tantas tentativas de batidas de porta / brutais de força de script.
Sim. Quando eu tinha o ssh na porta 22, tive> 20000 tentativas de senha com falha aparecendo nos meus logs por dia. O que significava que recebia um email de aviso de segurança todos os dias. Eu tinha a autenticação por senha desabilitada - era necessário ter uma chave privada adequada para efetuar o login -, portanto, não estava preocupado com a entrada de alguém, mas prefiro receber e-mails de aviso de segurança apenas quando algo real estava acontecendo.
jdege
10
Eu executaria o 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 é desativar o login com senhas por mais tempo e permitir apenas logins com ssh-keys.
Porque existem muitas pessoas más por aí que examinam todos os IPs do servidor em busca de portas abertas, na tentativa de explorar. Eu costumava ter ataques de martelo na minha porta SSH o dia inteiro até que eu a movia para outra porta e em um IP que não estava mais vinculado a nenhum dos meus sites.
É útil, pois os bots de script que tentam ataques de adivinhação de senha de força bruta geralmente se concentram na Porta 22, portanto, alterar as portas geralmente os desencoraja. Você precisará equilibrar o valor de mitigar esse risco com a dificuldade de configurar clientes ssh para conectar-se à porta não padrão (não é uma tarefa muito grande se você não tiver muitos usuários conectando).
Como alternativa, você pode atenuar 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 a lista de portas usadas com frequência para encontrar outro número (ou seja, um que não esteja sendo usado por outra coisa e, portanto, possa ser verificado) .
Eu sempre mudo meu SSHd para usar a porta 2222, todo mundo que precisaria entrar nos meus servidores sabe disso e não é segredo. Não há absolutamente nenhum ganho de segurança fazendo isso (a menos que o possível hacker seja um idiota absoluto).
O único benefício que recebo disso é que o log de autenticação não tem um milhão de tentativas de login com falha para 'root', 'alice', 'bob', 'sally', 'admin' etc.
A segurança através da obscuridade provou ser inútil, geralmente eu configuro o acesso ssh com a porta padrão por todos os motivos mencionados acima (problemas do cliente na reconfiguração, problemas de firewall e proxy, etc.).
Além disso, eu sempre desabilito o login raiz e a autenticação de senha e, como último passo, uso o fail2ban para livrar-se 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 geralmente ajusto alguns parâmetros para serem mais restritivos, com tempo de banimento mais longo (pelo menos um dia) e apenas duas tentativas de autenticação com falha como acionador do banimento.
Eu diria que o que você mais se protege 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 forem rigorosas, você não precisará se preocupar com eles.
para não mencionar que um scanner de portas também tentará outras portas.
21411 Jim Deville
4
Se você desativar os logins de senha no servidor (o que é altamente recomendado), a alteração da porta SSH será completamente inútil. Ao desativar os logins de senha (e exigir autenticação com base em chave), você remove a possibilidade de tentativas de senha de força bruta, para que você não esteja ganhando nada ao futurar os números de porta.
Se você continuar permitindo a autenticação com base em senha, estará se deixando abrir para a possibilidade de uma tentativa bem-sucedida de força bruta ou - mais comum, na minha experiência - que sua senha seja comprometida porque você a digita ao usar um sistema executando um keylogger.
Se você é completamente inútil / completamente inútil por segurança /, eu concordo. Alterar a porta é útil para manter o ruído baixo no log de autenticação.
Chris S
"e exigindo autenticação baseada em chave"? o que é isto
dynamic
1
@ yes123, o SSH pode usar pares de chaves público-privado para autenticar um usuário em vez de uma senha. O par de chaves também pode ser protegido por uma senha, oferecendo, assim, autenticação de dois fatores (algo que você sabe = senha; algo que você tem = arquivo de chave). Se você implementar isso, poderá desativar os logins de senha (assim, alguém que conhece sua senha local não pode entrar com o arquivo de chaves e a senha do arquivo de chaves). As senhas são relativamente inseguras em comparação com as chaves, milhões de vezes mais fáceis de usar a força bruta do que os pares de chaves (embora ainda sejam difíceis normalmente). Veja man ssh-keygenpara muita informação.
Chris S
@ yes123, as várias páginas de manual relacionadas ao ssh (sshd, sshd_config, ssh, ssh_config) são leituras úteis. Este documento parece um bom tutorial sobre autenticação de chave pública com ssh.
larsks
2
Apesar de parecer uma "segurança pela obscuridade" típica, eu estimaria isso como tendo sentido, já que a varredura de todas as portas possíveis (~ 64k) é muito mais demorada do que apenas uma delas.
Mas posso acrescentar que "bater à porta" é muito melhor.
Não é uma resposta, mas é muito tempo para um comentário, então eu vou fazer essa CW.
Estou pensando nisso há um tempo e cheguei à conclusão de que há muita verdade no que Juliano diz nos comentários à resposta de Alnitak. No entanto, acho que executar o SSH na porta 22 facilita demais o lançamento de ataques de qualquer tipo contra ela.
Para resolver esse problema, eu 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.
A segurança através da obscuridade não é um princípio que eu normalmente assino e é frequentemente apontado que uma simples varredura de porta revelará a porta de destino, tornando a obscuridade inútil. Para resolver esse problema, meus firewalls (Smoothwall Express), no trabalho e em casa, usam um script chamado Guardian Active Response, que é acionado pelos alertas do Snort. Pela 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 redefinição predefinido. Isso torna bastante difícil e extremamente demorado executar uma verificação de porta, fazendo com que a obscuridade realmente valha alguma coisa. De fato, isso me levou a ser excluído tantas vezes no passado que defini uma exclusão para o meu endereço IP de origem (residencial ou comercial).
Boa ideia com a porta à frente, John! Eu acho que nós dois aprendemos algo :)
Alnitak
1
O problema que você tem é que o firewall está configurado para permitir a conexão de determinados IPs e o chefe está cansado de abrir IPs específicos quando ele está fora de casa. Se você está bloqueando certos IPs no firewall, isso pode ser um problema.
Duas coisas que penso aqui. Alterar a porta protege contra ataques automatizados. É isso, mas é uma grande parte do tráfego médio de ataques por aí ... scripts de varredura automatizada de redes. Se você alterar a porta padrão, esses ataques serão reduzidos a zero. Portanto, faz sentido a esse respeito. Mas isso não faz nada contra um ataque direcionado, pois o invasor pode apenas digitalizar a partir do Nessus ou NMAP para determinar quais portas você está usando se tiver um amiguinho especial que o odeia o suficiente.
Segundo, se você estiver usando servidores tipo UNIX, poderá instalar um utilitário como Denyhosts para interromper ataques. Se você instalar denyhosts, ele monitora as tentativas incorretas de logon e, após (qualquer que seja o número que você determinar) tentativas fracassadas, o IP será banido por um período especificado. Denyhosts também podem conversar com outros hosts denyhost e repassar listas de proibições, portanto, se um invasor for bloqueado no sistema Linux de Fred em Montana, seu sistema também receberá esse IP para banir. Muito útil desde que seus usuários lembrem suas senhas.
Tudo depende dos seus cenários de uso. Quantos programas você possui que são "problemáticos" para alterar a porta de conexão do SSH / SCP (e se eles não permitirem ou o tornarem problemático, você realmente precisará considerar mudar de fornecedor pessoalmente). Se é apenas um medo em potencial, eu diria que não é um problema. E este é o seu chefe, pedindo algo que não é totalmente maluco, pois muitos administradores de sistemas invertem a porta SSH (com algumas críticas de pessoas que odeiam qualquer coisa que cheira a um pouco de segurança através da obscuridade ... mas isso realmente diminui ruído de fundo de cruft de verificações automatizadas.)
Desacelerado - alterar as portas bloqueia os scripts automatizados e a maior parte do tráfego ruim. Não vai parar atacantes direcionados. Considere instalar também um utilitário de banimento automatizado. A segurança em camadas não o prejudica se for feito corretamente e a mudança de portas ajuda mais do que na maioria das situações.
Estou executando o SSH na porta> 1024 há mais de 5 anos. Desde então, não vejo nenhuma tentativa de portscan no meu arquivo de log (exceto eu mesmo). Existem servidores que administro usando a porta> 1024.
Muitos servidores SSH, que são executados na porta> 1024, possuem sites próprios, bastante populares.
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ê precisaria configurar para torná-lo seguro. SSH> 1024 por si só 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 desativado e outras coisas.
Portanto, se você quiser argumentar, é melhor executar o SSH na porta> 1024 por alguns anos.
Mover bem o SSH para uma porta diferente faz algum sentido, ajuda na segurança, mas não enormemente. Obviamente, para fazer 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 a porta é a abertura do alcance aceito - na verdade, eu diria que isso mais do que desfaz o benefício e expõe você mais do que é hoje. Tenho certeza de que você pode convencê-lo a mover a porta e reduzir significativamente o intervalo de entrada reunindo uma lista de pontos de entrada prováveis, em vez de apenas abri-los.
Alterar a porta ssh é um exercício inútil que compra apenas uma segurança limitada. É melhor simplesmente desabilitar a autenticação de senha, o que elimina o risco de tentativas de senha de força bruta e confiar exclusivamente na autenticação baseada em chave ssh. Se o seu ambiente exigir autenticação por senha, adote um mecanismo de dois fatores, como o SecurID ou o Wikid.
Ambos oferecem um aumento real na segurança, enquanto a alteração da porta ssh apenas oferece a ilusão de segurança.
Esse é um ponto de vista prático: operei servidores ssh privados publicamente visíveis por mais de quatro anos com a porta SSH alterada e não tive uma única tentativa de verificação de senha. Para garantir esse controle de qualidade, ativei novamente 22 em um deles por um dia. Como resultado, eu fui verificado aproximadamente a cada 10 minutos, com uma frequência de tentativa de senha em torno de 5 por segundo. Além disso, os "scan kiddies" também procuram servidores com certas vulnerabilidades do OpenSSH.
Com certeza isso é segurança pela obscuridade, o que não ajuda se você tiver um inimigo.
Funciona muito bem, independentemente do lamento da multidão "segurança através da obscuridade".
Coelhos tolos, TODA a segurança é segurança através da obscuridade. Só porque você acredita que o obscuro protocolo criptográfico Z [que exige uma combinação de amostras de DNA, chaves compartilhadas e impossibilidade de digitar por senhas humanas] é realmente seguro não o torna. A verdade é que toda e qualquer medida de segurança se baseia em probabilidades e suposições dos usuários. Que pena, se eu souber explorar essa suposição, mas aí está.
De qualquer forma,
Fazemos isso há anos, juntamente com a) limitação da taxa de tentativas de conexão (no entanto, não sei como configuramos isso, algo na configuração do ssh) eb) um script para proibir qualquer host executando um ataque de dicionário com mais de X palpites errados em Y minutos. Proibimos que o host faça a conexão por um período de tempo e isso facilita a adaptação à topologia das redes em mudança.
Se suas senhas são suficientemente complexas e podem fazer apenas três tentativas em 15 minutos, não há muito o que temer. Também não é tão difícil observar ataques distribuídos - geralmente reunimos por sub-rede e ip para descartar esse tipo de coisa.
Finalmente, tudo que você precisa é de um método secreto de esquilo para permitir conexões à sua porta, modificando as regras de f / w. Pode ser qualquer coisa ... smtp, web, magic dns query. Coisas como SecurID ou Wikid apenas entregam mais informações a terceiros. E não me inicie em certificados seguros através de terceiros.
-1, parece que você não entende o que é obscuridade ... Tornar algo não óbvio não é o mesmo que trancá-lo. Embora seja verdade que nenhuma segurança é absoluta, existem definitivamente diferenças e agrupar a autenticação de três fatores com a obscuridade não ajuda ninguém.
Chris S
1
Desculpe, Chris, isso é religião de culto de carga. Talvez você não possa abrir uma fechadura e, assim, pensar que ter uma garante segurança, mas todas as fechaduras podem ser selecionadas. Pense fora da caixa: em muitos casos, tornar algo "não óbvio" pode ser superior ao uso de uma fechadura. Seu modelo / visão de segurança é como deixar seu laptop em um carro trancado com o alarme configurado - um ajuste com uma pedra e seu laptop se foi. Mas talvez não seja um tweaker, mas alguém com uma exploração de 0 dias e tempo para matar ... Oh, olhe! Chris tem um alvo "seguro" e bastante visível! A obscuridade é uma parte MUITO importante da segurança.
random joe
Desculpe, mas suas comparações e lógica simplesmente não se sustentam. Eu sei como abrir fechaduras, é mais rápido cortá-las, quebrar uma janela, girar. Toda medida de segurança possui uma quantidade de tempo e esforço necessários para contorná-la; a obscuridade leva pequena quantidade de tempo e esforço, na ordem de minutos a horas. Segurança real, como tentativas de senha com limitação de taxa, faz com que a obtenção da senha demore bastante tempo. Essa disparidade significativa de tempo é a diferença entre segurança 'falsa' e 'real'; a obscuridade cai no primeiro.
Respostas:
Não é tão útil quanto algumas pessoas afirmam, mas pelo menos reduzirá o impacto nos arquivos de log, já que muitas tentativas de login de força bruta usam apenas a porta padrão em vez de varrer para verificar se o SSH está escutando em outro lugar. Alguns ataques vão procurar SSH em outro lugar, portanto, não é uma bala de prata.
Se o seu servidor for de algum tipo um host compartilhado, em vez de apenas atender às necessidades de seus projetos, o uso de uma porta não padrão pode ser uma dor, pois você precisará explicá-lo para os usuários várias e várias vezes. quando eles esquecem e seus programas clientes não conseguem se conectar à porta 22!
Outro possível problema com o SSH em uma porta não padrão é se você encontrar um cliente com um conjunto de filtros de saída restritivo, que não pode se conectar à sua porta personalizada porque o filtro deles permite apenas, por exemplo, as portas 22, 53, 80 e 443 como o destino para novas conexões de saída. Isso é incomum, mas certamente não é inédito. De maneira semelhante, alguns ISPs podem ver o tráfego criptografado em uma porta diferente daquela 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 o acelerador (ou bloco) a conexão de maneira inconveniente.
Pessoalmente, mantenho o SSH na porta padrão por conveniência. Desde que sejam tomadas as precauções habituais (política forte de senha / chave, restrição de logins raiz, ...), não é necessário se preocupar 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 incorretos de credenciais de autenticação em um determinado espaço de tempo.
Qualquer que seja a porta que você escolher, se você se afastar de 22, verifique se ela está abaixo de 1024. Na maioria das configurações semelhantes ao Unix, na configuração padrão, apenas o usuário root (ou os usuários do grupo raiz) podem ouvir portas abaixo de 1024, mas qualquer usuário pode ouvir nas portas mais altas. A execução do SSH em uma porta mais alta aumenta a chance de um usuário não autorizado (ou hackeado) conseguir travar seu daemon SSH e substituí-lo por um ou por um proxy.
fonte
É 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 pesquisam toda a Internet procurando 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 o estiver ativamente alvejando especificamente, ele não fornecerá nenhum benefício, pois uma simples
nmapvarredura pontual revelará a porta na qual está realmente sendo executada.fonte
Para realmente evitar ataques de força bruta, é sempre importante seguir alguns passos:
fonte
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 depende de você, tenho visto empresas usarem 1291 com bastante frequência. Eu uso algo mais alto, porém, apenas para ajudar a evitar alguns dos scripts.
Não permitindo logins root ssh e alterando o número da porta e talvez algo como fail2ban e você deve ser de ouro. adicione iptables para uma boa medida e mantenha as coisas atualizadas e você não deve ter nenhum tipo de problema.
fonte
Considero os seguintes benefícios da execução do sshd em uma porta não padrão mais importantes do que os problemas que ela cria:
Além disso, se você quer ser realmente desagradável, sempre pode executar um sshd falso (com DenyUsers * ) na porta padrão 22, enquanto o sshd normal é executado na porta 54321. Isso garantirá que todos os bots e aspirantes a intrusos irão eternamente tente fazer login em um serviço que negue todos os logins, porque ninguém nunca pensou em tentar encontrar seu serviço sshd real .
Meus 2 centavos.
fonte
Fazer isso por qualquer motivo de "segurança" é falso. É o melhor exemplo de segurança pela obscuridade, que não é segurança.
Se você deseja manter seus registros um pouco mais claros e limpos, é útil que você não tenha tantas tentativas de batidas de porta / brutais de força de script.
fonte
Eu executaria o 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 é desativar o login com senhas por mais tempo e permitir apenas logins com ssh-keys.
fonte
Porque existem muitas pessoas más por aí que examinam todos os IPs do servidor em busca de portas abertas, na tentativa de explorar. Eu costumava ter ataques de martelo na minha porta SSH o dia inteiro até que eu a movia para outra porta e em um IP que não estava mais vinculado a nenhum dos meus sites.
fonte
É útil, pois os bots de script que tentam ataques de adivinhação de senha de força bruta geralmente se concentram na Porta 22, portanto, alterar as portas geralmente os desencoraja. Você precisará equilibrar o valor de mitigar esse risco com a dificuldade de configurar clientes ssh para conectar-se à porta não padrão (não é uma tarefa muito grande se você não tiver muitos usuários conectando).
Como alternativa, você pode atenuar 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 a lista de portas usadas com frequência para encontrar outro número (ou seja, um que não esteja sendo usado por outra coisa e, portanto, possa ser verificado) .
fonte
Eu sempre mudo meu SSHd para usar a porta 2222, todo mundo que precisaria entrar nos meus servidores sabe disso e não é segredo. Não há absolutamente nenhum ganho de segurança fazendo isso (a menos que o possível hacker seja um idiota absoluto).
O único benefício que recebo disso é que o log de autenticação não tem um milhão de tentativas de login com falha para 'root', 'alice', 'bob', 'sally', 'admin' etc.
fonte
A segurança através da obscuridade provou ser inútil, geralmente eu configuro o acesso ssh com a porta padrão por todos os motivos mencionados acima (problemas do cliente na reconfiguração, problemas de firewall e proxy, etc.).
Além disso, eu sempre desabilito o login raiz e a autenticação de senha e, como último passo, uso o fail2ban para livrar-se 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 geralmente ajusto alguns parâmetros para serem mais restritivos, com tempo de banimento mais longo (pelo menos um dia) e apenas duas tentativas de autenticação com falha como acionador do banimento.fonte
Eu diria que o que você mais se protege 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 forem rigorosas, você não precisará se preocupar com eles.
fonte
Se você desativar os logins de senha no servidor (o que é altamente recomendado), a alteração da porta SSH será completamente inútil. Ao desativar os logins de senha (e exigir autenticação com base em chave), você remove a possibilidade de tentativas de senha de força bruta, para que você não esteja ganhando nada ao futurar os números de porta.
Se você continuar permitindo a autenticação com base em senha, estará se deixando abrir para a possibilidade de uma tentativa bem-sucedida de força bruta ou - mais comum, na minha experiência - que sua senha seja comprometida porque você a digita ao usar um sistema executando um keylogger.
fonte
man ssh-keygenpara muita informação.Apesar de parecer uma "segurança pela obscuridade" típica, eu estimaria isso como tendo sentido, já que a varredura de todas as portas possíveis (~ 64k) é muito mais demorada do que apenas uma delas.
Mas posso acrescentar que "bater à porta" é muito melhor.
fonte
Não é uma resposta, mas é muito tempo para um comentário, então eu vou fazer essa CW.
Estou pensando nisso há um tempo e cheguei à conclusão de que há muita verdade no que Juliano diz nos comentários à resposta de Alnitak. No entanto, acho que executar o SSH na porta 22 facilita demais o lançamento de ataques de qualquer tipo contra ela.
Para resolver esse problema, eu 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.
A segurança através da obscuridade não é um princípio que eu normalmente assino e é frequentemente apontado que uma simples varredura de porta revelará a porta de destino, tornando a obscuridade inútil. Para resolver esse problema, meus firewalls (Smoothwall Express), no trabalho e em casa, usam um script chamado Guardian Active Response, que é acionado pelos alertas do Snort. Pela 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 redefinição predefinido. Isso torna bastante difícil e extremamente demorado executar uma verificação de porta, fazendo com que a obscuridade realmente valha alguma coisa. De fato, isso me levou a ser excluído tantas vezes no passado que defini uma exclusão para o meu endereço IP de origem (residencial ou comercial).
fonte
O problema que você tem é que o firewall está configurado para permitir a conexão de determinados IPs e o chefe está cansado de abrir IPs específicos quando ele está fora de casa. Se você está bloqueando certos IPs no firewall, isso pode ser um problema.
Duas coisas que penso aqui. Alterar a porta protege contra ataques automatizados. É isso, mas é uma grande parte do tráfego médio de ataques por aí ... scripts de varredura automatizada de redes. Se você alterar a porta padrão, esses ataques serão reduzidos a zero. Portanto, faz sentido a esse respeito. Mas isso não faz nada contra um ataque direcionado, pois o invasor pode apenas digitalizar a partir do Nessus ou NMAP para determinar quais portas você está usando se tiver um amiguinho especial que o odeia o suficiente.
Segundo, se você estiver usando servidores tipo UNIX, poderá instalar um utilitário como Denyhosts para interromper ataques. Se você instalar denyhosts, ele monitora as tentativas incorretas de logon e, após (qualquer que seja o número que você determinar) tentativas fracassadas, o IP será banido por um período especificado. Denyhosts também podem conversar com outros hosts denyhost e repassar listas de proibições, portanto, se um invasor for bloqueado no sistema Linux de Fred em Montana, seu sistema também receberá esse IP para banir. Muito útil desde que seus usuários lembrem suas senhas.
Tudo depende dos seus cenários de uso. Quantos programas você possui que são "problemáticos" para alterar a porta de conexão do SSH / SCP (e se eles não permitirem ou o tornarem problemático, você realmente precisará considerar mudar de fornecedor pessoalmente). Se é apenas um medo em potencial, eu diria que não é um problema. E este é o seu chefe, pedindo algo que não é totalmente maluco, pois muitos administradores de sistemas invertem a porta SSH (com algumas críticas de pessoas que odeiam qualquer coisa que cheira a um pouco de segurança através da obscuridade ... mas isso realmente diminui ruído de fundo de cruft de verificações automatizadas.)
Desacelerado - alterar as portas bloqueia os scripts automatizados e a maior parte do tráfego ruim. Não vai parar atacantes direcionados. Considere instalar também um utilitário de banimento automatizado. A segurança em camadas não o prejudica se for feito corretamente e a mudança de portas ajuda mais do que na maioria das situações.
fonte
Estou executando o SSH na porta> 1024 há mais de 5 anos. Desde então, não vejo nenhuma tentativa de portscan no meu arquivo de log (exceto eu mesmo). Existem servidores que administro usando a porta> 1024.
Muitos servidores SSH, que são executados na porta> 1024, possuem sites próprios, bastante populares.
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ê precisaria configurar para torná-lo seguro. SSH> 1024 por si só 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 desativado e outras coisas.
Portanto, se você quiser argumentar, é melhor executar o SSH na porta> 1024 por alguns anos.
p / s: 1124 não é minha porta SSH no. Haha
fonte
Eu acho que se você ainda não descobriu a porta batendo à mão, mais, não.
fonte
Mover bem o SSH para uma porta diferente faz algum sentido, ajuda na segurança, mas não enormemente. Obviamente, para fazer 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 a porta é a abertura do alcance aceito - na verdade, eu diria que isso mais do que desfaz o benefício e expõe você mais do que é hoje. Tenho certeza de que você pode convencê-lo a mover a porta e reduzir significativamente o intervalo de entrada reunindo uma lista de pontos de entrada prováveis, em vez de apenas abri-los.
fonte
Alterar a porta ssh é um exercício inútil que compra apenas uma segurança limitada. É melhor simplesmente desabilitar a autenticação de senha, o que elimina o risco de tentativas de senha de força bruta e confiar exclusivamente na autenticação baseada em chave ssh. Se o seu ambiente exigir autenticação por senha, adote um mecanismo de dois fatores, como o SecurID ou o Wikid.
Ambos oferecem um aumento real na segurança, enquanto a alteração da porta ssh apenas oferece a ilusão de segurança.
fonte
Esse é um ponto de vista prático: operei servidores ssh privados publicamente visíveis por mais de quatro anos com a porta SSH alterada e não tive uma única tentativa de verificação de senha. Para garantir esse controle de qualidade, ativei novamente 22 em um deles por um dia. Como resultado, eu fui verificado aproximadamente a cada 10 minutos, com uma frequência de tentativa de senha em torno de 5 por segundo. Além disso, os "scan kiddies" também procuram servidores com certas vulnerabilidades do OpenSSH.
Com certeza isso é segurança pela obscuridade, o que não ajuda se você tiver um inimigo.
fonte
Funciona muito bem, independentemente do lamento da multidão "segurança através da obscuridade".
Coelhos tolos, TODA a segurança é segurança através da obscuridade. Só porque você acredita que o obscuro protocolo criptográfico Z [que exige uma combinação de amostras de DNA, chaves compartilhadas e impossibilidade de digitar por senhas humanas] é realmente seguro não o torna. A verdade é que toda e qualquer medida de segurança se baseia em probabilidades e suposições dos usuários. Que pena, se eu souber explorar essa suposição, mas aí está.
De qualquer forma,
Fazemos isso há anos, juntamente com a) limitação da taxa de tentativas de conexão (no entanto, não sei como configuramos isso, algo na configuração do ssh) eb) um script para proibir qualquer host executando um ataque de dicionário com mais de X palpites errados em Y minutos. Proibimos que o host faça a conexão por um período de tempo e isso facilita a adaptação à topologia das redes em mudança.
Se suas senhas são suficientemente complexas e podem fazer apenas três tentativas em 15 minutos, não há muito o que temer. Também não é tão difícil observar ataques distribuídos - geralmente reunimos por sub-rede e ip para descartar esse tipo de coisa.
Finalmente, tudo que você precisa é de um método secreto de esquilo para permitir conexões à sua porta, modificando as regras de f / w. Pode ser qualquer coisa ... smtp, web, magic dns query. Coisas como SecurID ou Wikid apenas entregam mais informações a terceiros. E não me inicie em certificados seguros através de terceiros.
fonte