IP aleatório está constantemente tentando se conectar ao SQL Server

Question

Estamos criando um aplicativo baseado em nuvem que depende de um banco de dados de login e de muitos bancos de dados de clientes individuais. Usando o rackspace, configuramos um servidor (windows server 2012) com o SQL Management Studio 2012 (Web) e estamos nos procedimentos de teste / controle de qualidade antes do lançamento.

Usando o visualizador de eventos de servidores para procurar algumas informações de depuração, notei que alguns IPs tentam estabelecer uma conexão com nosso banco de dados SQL a cada minuto. Estamos usando o usuário 'sa' padrão como superusuário.

Minhas perguntas são:

• Podemos definir um número máximo de solicitações para qualquer IP individual antes que uma 'proibição' seja colocada de alguma forma?

• A alteração do nome da conta do usuário para algo aleatório será útil?

• Existem outras medidas que podemos tomar para proteger nosso banco de dados?

Answer 1

Como outros já mencionaram a sua estrutura de segurança é completamente errado ... Dito isto, aqui estão algumas das melhores práticas para olhar .... também ver link para o artigo completo abaixo. Eu sugeriria repensar sua estrutura e abordagem de segurança a partir do zero.

link

Lista de verificação básica de segurança do SQL Server

Defina uma senha em sua conta SA e restrinja seu uso. Além disso, altere a senha periodicamente para evitar que ela seja "propagada" e usada por desenvolvedores ou por muitos administradores. Altere a senha SA se qualquer um que a conhece sair da empresa. Use a ferramenta do eEye para verificar sua rede em busca de servidores SQL sem senha.

Coloque seu SQL Server atrás de um firewall, separado do IIS ou dos servidores da Web. Permitir somente conexões ao servidor SQL a partir desses servidores da web designados. Seu servidor SQL nunca deve estar voltado para a Internet ou ter acesso público.

Remova BUILTIN / Administrators da função sysadmin e conceda direitos sysadmin no SQL a contas de domínio específicas que precisam dela.

Use a Autenticação do Windows e o Modo Somente Windows, se possível. Dessa forma, um hacker em potencial deve se autenticar primeiro no domínio, e não apenas no SQL Server.

Não execute o SQL Server em um controlador de domínio.

Altere a conta de inicialização do serviço do SQL Server para algo além do LocalHost.

Ative a opção Logon com falha (guia Propriedades do servidor | Segurança) para procurar logins com falha para ver se uma pessoa não autorizada está tentando acessar o servidor. Monitore os logs do SQL e configure alertas no SQL usando NETSEND ou email, se possível.

Mantenha-se atualizado sobre patches e service packs para o sistema operacional e o SQL. Veja Ferramentas para Proteger o IIS para algumas opções.

Proteja todos os procedimentos armazenados estendidos. Controle todo o acesso a dados por meio de procedimentos armazenados e conceda acesso a eles, em vez de conceder permissões gerais de db_datareader e db_datawriter aos dados em si. Veja a Parte I deste artigo para mais informações.

Altere a porta padrão do SQL Server no Utilitário de configuração de rede do servidor e bloqueie a porta padrão 1433. Peça ao seu administrador de rede que permita a nova porta.

Certifique-se de que o grupo Todos não tenha acesso de gravação às chaves de registro do SQL Server

    

Answer 2

Você deve realmente remover o SQL Server da Internet e bloqueá-lo para que o acesso externo não seja permitido. Em seguida, use uma VPN para cada site do cliente. Sim, essa não é a configuração mais fácil, mas é a única maneira de bloquear tentativas de conexão aleatórias em todas as horas do dia. Além disso, os "ataques" tendem a aumentar em velocidade à medida que mais probes encontram sua instância do SQL aberta ao mundo externo.

A implementação do que está sendo feito precisa ser vista de uma perspectiva de segurança. Além disso, este é o acesso ao próprio SQL Server; O SSMS simplesmente fala SQL para que você possa gerenciá-lo.

    

Answer 3

Primeiro, você não deveria estar usando SA, como outros apontaram.

Em segundo lugar, este servidor não deve ser exposto à Internet, por motivos que você viu. O que Nathan C disse; configurar uma VPN.

Por último, a menos que você tenha configurado especificamente o SQL com um certificado, o tráfego será descriptografado por padrão e sujeito a sniffing. (Não é o nome de usuário / senha, mas seus dados reais.)

Sério, isso é quase certamente uma violação do PCI. Por favor, proteja isso.

    

Answer 4

Eu bloquearia a porta TCP 1433 (porta usada pelo SQL Management Studio) no firewall para ips externos e permitiria somente o host local ou um conjunto de ips confiáveis.