Alterar o número da porta padrão realmente aumenta a segurança?

Tenho visto conselhos dizendo que você deve usar números de porta diferentes para aplicativos particulares (por exemplo, intranet, banco de dados privado, qualquer coisa que nenhum usuário externo use).

Não estou totalmente convencido de que possa melhorar a segurança porque

1. Existem scanners de portas
2. Se um aplicativo estiver vulnerável, ele permanecerá assim, independentemente do número da porta.

Perdi alguma coisa ou respondi minha própria pergunta?

Não fornece nenhuma defesa séria contra um ataque direcionado. Se o seu servidor estiver sendo direcionado, então, como você diz, eles farão uma varredura na porta e descobrirão onde estão suas portas.

No entanto, remover o SSH da porta padrão 22 impedirá alguns dos ataques de script infantil e não direcionados e amadores. Esses são usuários relativamente pouco sofisticados que estão usando scripts para varrer grandes blocos de endereços IP por vez, especificamente para verificar se a porta 22 está aberta e, quando encontrarem um, eles iniciarão algum tipo de ataque (força bruta, ataque de dicionário, etc). Se a sua máquina estiver nesse bloco de IPs que está sendo varrido e não estiver executando o SSH na porta 22, ela não responderá e, portanto, não aparecerá na lista de máquinas para o ataque deste script infantil. Portanto, existe alguma segurança de baixo nível fornecida, mas apenas para esse tipo de ataque oportunista.

A título de exemplo, se você tiver o registro de tempo no servidor (supondo que o SSH esteja na porta 22) e retire todas as tentativas únicas de SSH com falha que você puder. Em seguida, remova o SSH dessa porta, aguarde um pouco e faça o log diving novamente. Você, sem dúvida, encontrará menos ataques.

Eu costumava executar o Fail2Ban em um servidor público da web e era muito, muito óbvio quando mudei o SSH da porta 22. Ele cortou os ataques oportunistas em ordens de magnitude.

É muito útil manter os logs limpos.

Se houver falhas nas tentativas com o sshd em execução na porta 33201, você pode assumir com segurança que a pessoa está direcionando para você e você tem a opção de tomar as ações apropriadas, se desejar. Como entrar em contato com as autoridades, investigar quem pode ser essa pessoa ( fazendo referência cruzada com os IPs de seus usuários registrados ou o que for), etc.

Se você usar a porta padrão, será impossível saber se alguém está atacando você ou se são apenas idiotas aleatórios fazendo verificações aleatórias.

Não, não faz. Na verdade não. O termo para isso é Segurança por Obscuridade e não é uma prática confiável. Você está correto em ambos os seus pontos.

O Security by Obscurity, na melhor das hipóteses, impedirá as tentativas casuais de procurar por portas padrão, sabendo que em algum momento elas encontrarão alguém que deixou a porta da frente aberta. No entanto, se houver alguma ameaça séria que você enfrenta ao mudar a porta do deault, o processo inicial será mais lento, mas apenas marginalmente por causa do que você já apontou.

Faça um favor a si mesmo e deixe suas portas configuradas corretamente, mas tome as devidas precauções de travá-las com um firewall, autorizações, ACLs, etc.

É um nível leve de obscuridade, mas não uma lombada significativa no caminho para invadir. É uma configuração mais difícil de suportar a longo prazo, pois tudo o que fala com esse serviço específico precisa ser informado sobre a porta diferente.

Era uma vez uma boa idéia para evitar worms de rede, pois eles tendiam a varrer apenas uma porta. No entanto, o tempo do verme que se multiplica rapidamente já passou.

Como outros já apontaram, alterar o número da porta não oferece muita segurança.

Gostaria de acrescentar que a alteração do número da porta pode realmente ser prejudicial à sua segurança.

Imagine o seguinte cenário simplificado. Um cracker verifica 100 hosts. Noventa e nove desses hosts têm serviços disponíveis nessas portas padrão:

Port    Service
22      SSH
80      HTTP
443     HTTPS

Mas há um host que se destaca da multidão, porque eles, o proprietário do sistema, tentaram ofuscar seus serviços.

Port    Service
2222    SSH
10080   HTTP
10443   HTTPS

Agora, isso pode ser interessante para um cracker, porque a verificação sugere duas coisas:

1. O proprietário do host está tentando ocultar os números de porta em seu sistema. Talvez o proprietário pense que há algo valioso no sistema. Este pode não ser um sistema comum.
2. Eles escolheram o método errado para proteger seu sistema. O administrador cometeu um erro ao acreditar na ofuscação da porta, o que indica que eles podem ser um administrador inexperiente. Talvez eles tenham usado ofuscação de porta no lugar de um firewall adequado ou de um IDS adequado. Eles também podem ter cometido outros erros de segurança e vulneráveis ​​a ataques de segurança adicionais. Vamos sondar um pouco mais agora, certo?

Se você fosse um cracker, escolheria dar uma olhada em um dos 99 hosts executando serviços padrão em portas padrão, ou em um host que esteja usando ofuscação de porta?

Vou contra a tendência geral, pelo menos parcialmente.

Por si só , mudar para uma porta diferente pode levar alguns segundos enquanto é procurado, e, portanto, nada em termos reais. No entanto, se você combinar o uso de portas não padronizadas com medidas anti-portscan, isso poderá proporcionar um aumento realmente valioso na segurança.

Aqui está a situação que se aplica aos meus sistemas: Serviços não públicos são executados em portas não padrão. Qualquer tentativa de conexão com mais de duas portas a partir de um único endereço de origem, com ou sem êxito, dentro de um período especificado, resulta na queda de todo o tráfego dessa fonte.

Para vencer esse sistema, seria necessária sorte (atingir a porta correta antes de ser bloqueada) ou uma varredura distribuída, que aciona outras medidas, ou um tempo muito longo, que também seria percebido e acionado.

Na minha opinião, mover a porta na qual um aplicativo é executado não aumenta a segurança - simplesmente pelo motivo de o mesmo aplicativo estar sendo executado (com os mesmos pontos fortes e fracos) apenas em uma porta diferente. Se o seu aplicativo tiver um ponto fraco, mover a porta que ele escuta para uma porta diferente não resolverá o problema. Pior, encoraja-o ativamente a NÃO lidar com a fraqueza, porque agora ela não está sendo constantemente pressionada pela verificação automatizada. Esconde o problema real, que é o problema que realmente deve ser resolvido.

Alguns exemplos:

• "Limpa os logs" - Então você tem um problema de como está lidando com os logs.
• "Reduz a sobrecarga da conexão" - a sobrecarga é insignificante (como a maioria das varreduras) ou você precisa de algum tipo de filtragem / mitigação de negação de serviço feita upstream
• "Reduz a exposição do aplicativo" - Se o seu aplicativo não suporta a verificação e a exploração automatizadas, seu aplicativo tem sérias deficiências de segurança que precisam ser corrigidas (por exemplo, mantenha-o corrigido!).

A verdadeira questão é administrativa: as pessoas esperam que o SSH esteja em 22, o MSSQL em 1433 e assim por diante. Movê-los é mais uma camada de complexidade e documentação necessária. É muito chato sentar em uma rede e ter que usar o nmap apenas para descobrir para onde as coisas foram movidas. As adições à segurança são efêmeras, na melhor das hipóteses, e as desvantagens não são insignificantes. Não faça isso. Corrija o problema real.

Você está certo de que isso não trará muita segurança (como o intervalo de portas do servidor TCP possui apenas 16 bits de entropia), mas você pode fazê-lo por dois outros motivos:

• como outros já disseram: invasores que tentam muitos logins podem sobrecarregar seus arquivos de log (mesmo que ataques de dicionário de um único IP possam ser bloqueados com fail2ban);
• O SSH precisa de criptografia de chave pública para trocar chaves secretas para criar um túnel seguro (esta é uma operação cara que, em condições normais, não precisa ser feita com muita frequência); conexões SSH repetidas podem desperdiçar energia da CPU .

Observação: não estou dizendo que você deve alterar a porta do servidor. Estou apenas descrevendo razões razoáveis ​​(IMO) para alterar o número da porta.

Se você fizer isso, acho que precisará deixar claro para todos os outros administradores ou usuários que isso não deve ser considerado um recurso de segurança e que o número da porta usada não é sequer um segredo e que o descreve como um recurso de segurança que traz segurança real não é considerado um comportamento aceitável.

Eu posso ver uma situação hipotética em que haveria um potencial benefício de segurança na execução do seu sshd na porta alternativa. Isso seria no cenário em que uma vulnerabilidade remota trivialmente explorada é descoberta no software sshd que você está executando. Nesse cenário, executar o sshd em uma porta alternativa pode fornecer o tempo extra necessário para que você não seja um destino aleatório de drive-by.

Eu mesmo corro o sshd em uma porta alternativa em minhas máquinas particulares, mas isso é principalmente uma conveniência para manter a desorganização em /var/log/auth.log. Em um sistema multiusuário, eu realmente não considero que o pequeno benefício hipotético de segurança apresentado acima seja motivo suficiente para o incômodo extra causado pelo sshd não ser encontrado na parte padrão.

Aumenta ligeiramente a segurança. Na medida em que o invasor que encontrou a porta aberta agora precisa descobrir o que está sendo executado na porta. Ainda não tendo acesso aos seus arquivos de configuração (ainda :-)), ele não tem idéia se a porta 12345 está executando http, sshd ou um dos milhares de outros serviços comuns, portanto, eles precisam fazer um trabalho extra para descobrir o que está sendo executado antes que possam ser seriamente. atacá-lo.

Também como outro pôster apontou, enquanto as tentativas de logon na porta 22 poderiam ser crianças sem roteiro, trojans zumbis ou mesmo usuários genuínos que digitaram incorretamente um endereço IP. É quase certo que uma tentativa de efetuar login na porta 12345 seja um usuário genuíno ou um invasor sério.

Outra estratégia é ter algumas portas de "armadilha de mel". Como nenhum usuário genuíno saberia sobre esses números de porta, qualquer tentativa de conexão deve ser considerada maliciosa e você pode bloquear / relatar o endereço IP incorreto automaticamente.

Há um caso especial em que o uso de um número de porta diferente definitivamente tornará seu sistema mais seguro. Se sua rede estiver executando um serviço público, como um servidor Web, mas também executando um servidor Web apenas para uso interno, você poderá absolutamente bloquear qualquer acesso externo executando um número de porta diferente e bloqueando qualquer acesso externo a essa porta.

Não por si só. No entanto, não usar a porta padrão para um aplicativo específico (por exemplo, SQL Server) forçará basicamente o invasor a verificar suas portas; esse comportamento pode ser detectado pelo firewall ou outras métricas de monitoramento e o IP do invasor bloqueado. Além disso, o "script kiddie" médio provavelmente será dissuadido quando a ferramenta simples ou o script de comando que eles estão usando não encontrar uma instância do servidor SQL na sua máquina (porque a ferramenta verifica apenas a porta padrão).