Após ataques aos bancos de dados MongoDB, recentemente também vimos que os servidores MySQL estão sendo alvo de ransomware. Isso não deve ser uma surpresa, dada a crescente adoção de nuvens públicas e privadas. A execução de um banco de dados mal configurado na nuvem pode se tornar uma grande responsabilidade.
Nesta postagem do blog, compartilharemos com você várias dicas sobre como proteger seus servidores MySQL ou MariaDB.
Compreendendo o vetor de ataque
Citando SCMagazine:
“O ataque começa com a força bruta da senha de root para o banco de dados MySQL. Uma vez logado, os bancos de dados e tabelas MySQL são buscados. O invasor cria uma nova tabela chamada 'AVISO' que inclui um endereço de e-mail de contato, um endereço bitcoin e uma demanda de pagamento. ”
Com base no artigo, o vetor de ataque começa adivinhando a senha raiz do MySQL por meio do método de força bruta. O ataque de força bruta consiste em um invasor tentando muitas senhas ou frases secretas com a esperança de, eventualmente, adivinhar corretamente. Isso significa que senhas curtas geralmente podem ser descobertas rapidamente, mas senhas mais longas podem levar dias ou meses.
A força bruta é um ataque comum que aconteceria em qualquer serviço. Infelizmente para o MySQL (e muitos outros DBMS), não há recurso pronto para uso que detecte e bloqueie ataques de força bruta de endereços específicos durante a autenticação do usuário. O MySQL captura falhas de autenticação no log de erros.
Revise sua política de senha
Revisar a política de senha do MySQL é sempre o primeiro passo para proteger seu servidor. A senha de root do MySQL deve ser forte o suficiente com combinação de alfabetos, números e símbolos (o que torna mais difícil de lembrar) e armazenada em um local seguro. Altere a senha regularmente, pelo menos a cada trimestre. Com base no vetor de ataque, este é o ponto mais fraco que os hackers visam. Se você valoriza seus dados, não negligencie essa parte.
As implantações do MySQL realizadas pelo ClusterControl sempre seguirão as melhores práticas de segurança do fornecedor, por exemplo, não haverá host curinga definido durante GRANT e credenciais de login confidenciais armazenadas no arquivo de configuração são permitidas apenas ao usuário root do SO. É altamente recomendável que nossos usuários especifiquem uma senha forte durante o estágio de implantação.
Isolar o servidor MySQL
Em um ambiente de produção padrão, os servidores de banco de dados geralmente estão localizados em uma camada de nível inferior. Essa camada deve ser protegida e acessível apenas na camada superior, como aplicativo ou balanceador de carga. Se o banco de dados estiver co-localizado com o aplicativo, você pode até bloquear endereços não locais e usar o arquivo de soquete MySQL (menos sobrecarga e mais seguro).
A configuração do parâmetro "bind-address" é vital aqui. Observe que a vinculação do MySQL é limitada a nenhum, um ou todos os endereços IP (0.0.0.0) no servidor. Se você não tiver escolha e precisar que o MySQL escute todas as interfaces de rede, restrinja o acesso ao serviço MySQL de boas fontes conhecidas. Use um aplicativo de firewall ou grupo de segurança para permitir o acesso apenas de hosts que precisam acessar o banco de dados diretamente.
Às vezes, o servidor MySQL precisa ser exposto a uma rede pública para fins de integração (por exemplo, monitoramento, auditoria, backup, etc.). Tudo bem, desde que você desenhe uma borda ao redor. Não deixe que fontes indesejadas “vejam” o servidor MySQL. Você pode apostar quantas pessoas no mundo sabem que 3306 é a porta padrão para o serviço MySQL e, simplesmente realizando uma varredura de porta em um endereço de rede, um invasor pode criar uma lista de servidores MySQL expostos na sub-rede em menos de um minuto. É aconselhável usar uma porta MySQL personalizada configurando o parâmetro "port" no arquivo de configuração do MySQL para minimizar o risco de exposição.
Revise a Política do Usuário
Limite determinados usuários a deter os direitos críticos de administração, especialmente GRANT, SUPER e PROCESS. Você também pode habilitar super_read_only se o servidor for um slave, disponível apenas no MySQL 5.7.8 e Percona Server 5.6.21 e posterior (infelizmente não com MariaDB). Quando habilitado, o servidor não permitirá nenhuma atualização, além de atualizar os repositórios de replicação se os logs de status dos escravos forem tabelas, mesmo para os usuários que possuem privilégio SUPER. Remova o banco de dados de teste padrão e todos os usuários com senhas vazias para restringir o escopo da penetração. Esta é uma das verificações de segurança realizadas pelo ClusterControl, implementado como um consultor de banco de dados.
Também é uma boa ideia restringir o número de conexões permitidas a uma única conta. Você pode fazer isso configurando a variável max_user_connections no mysqld (o padrão é 0, igual a ilimitado) ou usar as opções de controle de recursos nas instruções GRANT/CREATE USER/ALTER USER. A instrução GRANT suporta a limitação do número de conexões simultâneas ao servidor por uma conta, por exemplo:
mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;
Crie uma conta MySQL com a opção de controle de recursos MAX_USER_CONNECTIONS usando ClusterControl O nome de usuário padrão do administrador no servidor MySQL é “root”. Os hackers geralmente tentam obter acesso às suas permissões. Para tornar essa tarefa muito mais difícil, renomeie “root” para outra coisa. Os nomes de usuário do MySQL podem ter até 32 caracteres (16 caracteres antes do MySQL 5.7.8). É possível usar um nome de usuário mais longo para o usuário superadministrador usando a instrução RENAME conforme mostrado abaixo:
mysql> RENAME USER root TO new_super_administrator_username;Uma observação lateral para usuários do ClusterControl, o ClusterControl precisa conhecer o usuário root e a senha do MySQL para automatizar e gerenciar o servidor de banco de dados para você. Por padrão, ele procurará por 'root'. Se você renomear o usuário root para outra coisa, especifique “monitored_mysql_root_user={new_user}” dentro de cmon_X.cnf (onde X é o ID do cluster) e reinicie o serviço CMON para aplicar a alteração.
Política de backup
Mesmo que os hackers afirmassem que você recuperaria seus dados assim que o resgate fosse pago, esse geralmente não era o caso. Aumentar a frequência de backup aumentaria a possibilidade de restaurar seus dados excluídos. Por exemplo, em vez de um backup completo uma vez por semana com backup incremental diário, você pode agendar um backup completo uma vez por dia com backup incremental de hora em hora. Você pode fazer isso facilmente com o recurso de gerenciamento de backup do ClusterControl e restaurar seus dados se algo der errado.
Se você tiver logs binários (binlogs) habilitados, melhor ainda. Você pode criar um backup completo todos os dias e fazer backup dos logs binários. Binlogs são importantes para a recuperação pontual e devem ser copiados regularmente como parte de seu procedimento de backup. DBAs tendem a perder esse método simples, que vale cada centavo. Caso você tenha sido hackeado, você sempre pode se recuperar até o último ponto antes de acontecer, desde que os hackers não tenham limpado os logs binários. Observe que a limpeza de logs binários só é possível quando o invasor tem privilégio SUPER.
Mais uma coisa importante é que os arquivos de backup devem ser restauráveis. Verifique os backups de vez em quando e evite surpresas ruins quando precisar restaurar.
Proteja seu servidor de aplicativos/web
Bem, se você isolou seus servidores MySQL, ainda há chances de os invasores acessá-los via web ou servidor de aplicativos. Ao injetar um script malicioso (por exemplo, Cross-Site Scripting, SQL injection) no site de destino, pode-se entrar no diretório do aplicativo e ter a capacidade de ler os arquivos do aplicativo. Eles podem conter informações confidenciais, por exemplo, as credenciais de login do banco de dados. Ao olhar para isso, um invasor pode simplesmente fazer login no banco de dados, excluir todas as tabelas e deixar uma tabela de “resgate” dentro. Não precisa necessariamente ser um usuário root do MySQL para resgatar uma vítima.
Existem milhares de maneiras de comprometer um servidor web e você não pode realmente fechar a porta de entrada 80 ou 443 para essa finalidade. Outra camada de proteção é necessária para proteger seu servidor web de injeções baseadas em HTTP. Você pode usar o Web Application Firewall (WAF) como Apache ModSecurity, NAXSI (WAF para nginx), WebKnight (WAF para IIS) ou simplesmente executar seus servidores web em uma rede de entrega de conteúdo (CDN) segura como CloudFlare, Akamai ou Amazon CloudFront.
Mantenha-se sempre atualizado
Você provavelmente já ouviu falar sobre a exploração crítica do MySQL de dia zero, onde um usuário não privilegiado pode escalar-se para superusuário? Parece assustador. Felizmente, todos os fornecedores conhecidos atualizaram seu repositório para incluir uma correção de bug para esse problema.
Para uso em produção, é altamente recomendável que você instale os pacotes MySQL/MariaDB do repositório do fornecedor. Não confie no repositório padrão do sistema operacional, onde os pacotes geralmente estão desatualizados. Se você estiver executando em um ambiente de cluster como Galera Cluster ou mesmo MySQL Replication, sempre terá a opção de corrigir o sistema com o mínimo de tempo de inatividade. Faça disso uma rotina e tente automatizar o procedimento de atualização o máximo possível.
O ClusterControl suporta atualização sem interrupção de versão secundária (um nó por vez) para MySQL/MariaDB com um único clique. A atualização das principais versões (por exemplo, do MySQL 5.6 para o MySQL 5.7) geralmente requer a desinstalação dos pacotes existentes e é uma tarefa arriscada para automatizar. Um planejamento e testes cuidadosos são necessários para esse tipo de atualização.
Conclusão
Ransomware é um pote de ouro de dinheiro fácil. Provavelmente veremos mais violações de segurança no futuro, e é melhor agir antes que algo aconteça. Os hackers estão mirando em muitos servidores vulneráveis e muito provavelmente esse ataque também se espalhará para outras tecnologias de banco de dados. Proteger seus dados é um desafio constante para administradores de banco de dados. O verdadeiro inimigo não é o ofensor, mas nossa atitude em relação à proteção de nossos ativos críticos.
