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.
É 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.
Para realmente evitar ataques de força bruta, é sempre importante seguir alguns passos:
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.
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:
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.
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.
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.
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.
man ssh-keygenpara muita informação.
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).
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.
p / s: 1124 não é minha porta SSH no. Haha
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.