- Auditoria no SQL Server (Server Audit)
- Como criar uma auditoria para monitorar a criação, modificação e exclusão de Jobs no SQL Server
- Como criar uma trigger de Auditoria para logar a manipulação de objetos no SQL Server
- SQL Server – Como implementar auditoria e controle de logins (Trigger de Logon)
- Monitorando operações de DDL e DCL utilizando a fn_trace_gettable do SQL Server
- Utilizando o trace padrão do SQL Server para auditar eventos (fn_trace_gettable)
- SQL Server – Trigger de auditoria de permissões e privilégios a nível de database e instância (GRANT e REVOKE)
- SQL Server – Como monitorar e auditar alterações de dados em tabelas utilizando Change Data Capture (CDC)
- SQL Server 2016 – Como “viajar no tempo” utilizando o recurso Temporal Tables
- SQL Server – Como utilizar auditoria para mapear permissões necessárias reais em um usuário
- SQL Server – Trigger para prevenir e impedir alterações em tabelas
- SQL Server – Como criar um histórico de alterações de dados para suas tabelas (logs para auditoria)
- SQL Server – Como evitar ataques de força bruta no seu banco de dados
- SQL Server – Checklist de Segurança – Uma SP com mais de 70 itens de segurança para validar seu banco de dados
- SQL Server – Como saber a data do último login de um usuário
- SQL Server – Como evitar e se proteger de ataques de Ransomware, como WannaCry, no seu servidor de banco de dados
- SQL Server – Cuidado com a server role securityadmin! Utilizando elevação de privilégios para virar sysadmin
- SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query). Agora.
- SQL Server – Entendendo os riscos da propriedade TRUSTWORTHY habilitada em um database
- SQL Server – Políticas de Senhas, Expiração de Senha, Troca de Senha Obrigatória e Bloqueio de Login após N tentativas
- SQL Server – Como criar uma auditoria de logins utilizando os logs da instância
Fala galera!
Nesse artigo de hoje vou demonstrar como ocorrem ataques de força bruta ao SQL Server e como tentar se defender desse tipo de ataque.
O que é ataque de força bruta (Brute force attack)
Clique para exibir este conteúdoAtaque de força bruta no SQL Server
Clique para exibir este conteúdoComo identificar ataque de força bruta no SQL Server
Clique para exibir este conteúdoComo monitorar possíveis invasões por força bruta
Clique para exibir este conteúdoComo evitar possíveis invasões por força bruta
Clique para exibir este conteúdoSegurança no SQL Server – Assunto SÉRIO!
Após demonstrar algumas formas de atenuar o problema de invasão por força bruta identificando e bloqueando os IP’s que estão tentando invadir o ambiente no Windows Firewall, precisamos falar sério sobre Segurança. Infelizmente é muito comum ver ambientes totalmente desleixados no quesito segurança do banco de dados, onde usuários de aplicação possuem permissão de sysadmin, usuários que acessam o banco também como sysadmin, usuários com privilégios elevados e senhas frágeis, xp_cmdshell e query dinâmica sendo práticas comuns nos ambientes e muitos outros cenários bem preocupantes.
Sobre o cenário desse post, que é o ataque de força bruta, a grande maioria dos casos ocorre pelo fato do banco de dados estar publicado para Internet, facilitando bastante a entrada de possíveis invasores e a possibilidade de alguém tentar atacar a sua instância. Em muitos casos, isso ocorre quando o servidor do banco é o mesmo da aplicação, o que não é uma boa prática nem para o banco nem para a aplicação.
O banco acaba disputando recursos do servidor (CPU, Memória, Disco, Rede) com a aplicação e ainda tem que ficar visível e exposto para Internet, sem a possibilidade da criação de Whitelist (somente os endereços da lista possuem acesso ao servidor), já que isso iria impedir que os usuários acessem a aplicação. Isso sem falar que se o servidor da aplicação for compretido, os dados do banco podem ser acessados também, o que é um cenário catastrófico.
Um outro ponto que deve ser levantado também, é que mesmo quando o ataque de força bruta é realizado no ambiente, mesmo que ele não tenha sucesso ele ainda consegue prejudicar a empresa, pois enquanto ele fica tentando as milhares de senhas para invadir o banco, esse processo acaba consumindo muitos recursos do servidor de forma desnecessária.
Além disso, muitos ransomwares, com o WannaCry (o que devastou a internet ano passado) geralmente são precedidos por ataques de força bruta para conseguir acesso ao banco de dados de modo que o atacante consiga colocar os bancos offline para que o Ransonware depois consiga criptografar os arquivos de dados (mdf) e log (ldf).
O que fazer então para resolver isso?
Bom, o PRIMEIRO passo para isso é deixar o banco invisível para a Internet. Se tiver que separar o banco da aplicação e montar 1 servidor para cada um, que o faça então, criando uma VPN para realizar a comunição entre os 2 servidores (caso estejam em redes diferentes, como o Azure). Se a empresa não tiver condições de bancar um servidor para cada um e a aplicação for acessada pela Internet, por vários IP’s e não existe possibilidade de fazer uma whitelist para limitar os IP’s que vão acessar o servidor, o jeito é implementar a solução que disponibilizei acima e torcer para não acontecer o pior, já que o script desse artigo vai bloquear apenas tentar de acesso ao banco, mas existem N outros tipos de ataques para acessar o servidor, como ataques RDP, SSH, etc..
O SEGUNDO passo é desativar e renomear o usuário SA e qualquer outro usuário padrão do SQL Server, já que esses usuários são os principais alvos de ataques por força bruta, uma vez que o invasor já sabe o login e precisa apenas da senha.
O TERCEIRO passo é evitar ao máximo a utilização de logins com autenticação SQL Server, pois o banco que tem que controlar e gerenciar essas senhas. Além disso, o hash dessas senhas fica armazenado no banco e pode ser facilmente quebrado e validado sem gerar nem exceção no log do SQL Server, conforme demonstrei no artigo SQL Server – Como identificar senhas frágeis, vazias ou iguais ao nome do usuário. Utilize sempre que possível, autenticação do Windows AD, eliminando a necessidade de digitar senhas e o SQL Server não tem informações do hash e nem da senha.
O QUARTO passo é implementar o monitoramento desse artigo e ficar sempre de olho nesse relatório, bloqueando no Firewall do Windows (ou do Azure) os IP’s que estão com muitas falhas de conexão. Esse trabalho deve ser CONSTANTE e não só de forma pontual. Deixou o banco de dados disponível para internet, então agora aguenta. Se possível, utilizar essa lista de IP’s para bloquear esses endereços a nível de organização, no Firewall geral da rede e não apenas no servidor de banco. Você também pode pegar listas de Range de IPs por País e tentar liberar apenas os IPs do Brasil (Whitelist mais abrangente).
O QUINTO passo é revisar periodicamente a senha dos logins SQL Server do seu ambiente. É muito importante que as senhas desses usuários seja alterada PELO MENOS 1X POR ANO. Além disso, as senhas desses usuários devem ser grandes e complexas (eu utilizo sempre senhas com 50 caracteres ou mais, sendo letras, números e símbolos). Além disso, é importante ter uma política anual (pelo menos) de revisão de acessos. sysadmin é só pra DBA e db_owner nem deveria ser usado (salve raríssimas exceções).
Bom pessoal, esse foi o artigo sobre Ataque de força bruta no SQL Server. Espero que vocês tenham gostado dessa linha de Segurança, que é uma área que devo investir bastante tempo estudando e escrevendo artigos esse ano e é o tema da minha palestra no MVPConf Latam 2019.
Um grande abraço e até o próximo post.
Bom dia.
Ótimo artigo. Parabéns.
Consigo de alguma maneira identificar o HOST e AppName de falha na tentativa de login ?
MUITO TOP!
Sempre fiquei preocupado com isso.