A porta padrão do SQL Server é 1433. Nosso administrador informou que a porta precisa ser alterada "por motivos de segurança".
É realmente muito mais seguro mudar a porta? Se o servidor estiver protegido por um firewall e permitir apenas conexões a partir de um certo intervalo de IPs, isso não é suficiente?
Respostas:
Ajuda contra verificações de portas comuns que podem ser iniciadas em sites de verificação de portas. Mas isso não ajudará contra um invasor comprometido. É apenas outra camada, mas não acrescenta muito sobre o firewall, como você mencionou.
Se os servidores SQL estiverem conectados diretamente à Internet (o que não deveriam ser), ele poderá oferecer alguma proteção, pois a maioria dos scripts de ataque genéricos usa apenas os números de porta padrão.
Se seus servidores SQL não estiverem acessíveis diretamente da Internet, isso será inútil. Qualquer firewall precisará permitir conectividade com a porta remota. Assim que executo o software cliente na máquina, posso ver qual porta o SQL Server está usando através do comando NET STAT. Nesse ponto, você me desacelerou exatamente de 2 a 3 segundos.
Ele quebrará aplicativos que esperam a porta 1433.
Alguns aplicativos podem ser configurados para lidar com isso, mas isso precisa ser implantado.
Eu apenas deixaria. Se eles "hackearem" sua instância padrão na porta 1433, você já estará com o bollix.
Você pode especificar a porta para instâncias nomeadas, mas a porta 1434 precisa ser aberta para resolver a instância na porta ...
Os hackers costumam varrer endereços IP em busca de portas comumente usadas, por isso não é incomum usar uma porta diferente para "voar sob o radar". Isso é apenas para evitar a detecção, exceto que não há segurança adicional usando uma porta diferente.
Se apenas um intervalo de IP limitado puder acessar a porta, você já estará "sob o radar", então não vejo uma boa razão para usar uma porta diferente.
Na verdade sim. Para usar outro exemplo, o administrador do laboratório Linux da minha universidade mudou a porta SSH de 22 para um valor obscuro. Ele relatou que a rede caiu de aproximadamente 10.000 pings / ataques por dia para aproximadamente 1 ou 2 por mês. É verdade que, se você ainda não está sofrendo esse tipo de ataque, talvez não valha a pena o esforço na maioria dos casos. Ainda assim, ao mudar para uma porta alternativa discreta, você evita ataques amplos do probe e outros enfeites.
Eu acho que este é um problema de duas partes.
1) O software de varredura de porta comum pode tentar as portas comuns primeiro, mas não há nada especificamente limitando-o de tentar todas as portas, e você precisa assumir que poderá imprimir o protocolo ao imprimir uma impressão digital quando encontrar uma porta aberta .
2) Quando a varredura de porta mais agressiva estiver ocorrendo, você precisará detectá-la e fazer algo com esse conhecimento (como fail2ban, etc.)
Seu administrador está propondo (1), pergunte que idéias ele tem sobre (2).
Segurança através da obscuridade não é segurança.
Edit: então, novamente, alguns dizem que é ! Pessoalmente, continuarei adotando meu argumento original.
Alterar a porta os forçará a fazer uma varredura. Quando você usa uma ferramenta de segurança como o snort, com toques de rede ou SPAN, algo como uma verificação de porta do seu servidor se torna óbvia. Alguém se conectando legitimamente ao servidor SQL na porta padrão não é tão óbvio.
A melhor abordagem, eu concordo, não é segurança pela obscuridade. No entanto, alterar a porta padrão em todos e quaisquer aplicativos, quando possível, faz parte de uma estratégia abrangente e abrangente, que inclui atividades de equipe vermelhas, equipes de monitoramento de segurança de rede e toda a instrumentação correta, instalada, amadurecida e entendida por aqueles que estão usando.
Quando você tem todas essas coisas, um intruso no seu sistema se destaca como um dedo dolorido. A linha inferior - se alguém pensa que pode melhorar a segurança de seus sistemas marcando vários itens de uma lista, eles estão errados. Se eles não conseguem explicar por que precisam que a porta seja alterada, em termos inequívocos, eles não pertencem ao papel de alguém dizendo para você mudar a porta.
Quando um aplicativo se conecta ao MS SQL por TCPIP, a primeira parte da conversa ocorre em 1433 com a instância sem nome padrão - pelo menos é a desseminação de qualquer número de porta em que as instâncias nomeadas estão se comunicando. Quaisquer firewalls devem ser configurados para: a) deixar isso para os intervalos de IP apropriados; B) os números de porta fixa que qualquer instância nomeada possa estar usando. Eles devem ser configurados no gerenciador de configuração do SQL, conforme corrigidos. Você pode se comunicar com qualquer instância usando (endereço IP 192.168.22.55): (número da porta 12345) na cadeia de conexão. Se o serviço do navegador SQL não estiver ativado, o 1433 não fornecerá a conversa inicial. Se você estiver usando autenticação NT, há pouco a ganhar. Se você estiver usando a autenticação de SQL, há uma pequena quantia a ser obtida.