Segurança no MySQL – vulnerabilidades ou

pontos fortes?

O banco de dados é parte fundamental de um sistema, sendo o provedor dos dados, ou seja, o
sistema realiza uma série de validações e aplica as regras de negócio e os demais controles de
acesso a informação para por fim armazenar e buscar os dados segundo tais políticas no database.
Fica claro que um dos pontos fracos e de maior importância em tal sistema é o banco de dados, e
por isso o administrador deve providenciar e implementar estratégias de segurança que impeçam
acessos indevidos e indisponibilidades do banco de dados.
O MySQL tem determinadas peculiaridades que podem se tornar vulnerabilidades ou pontos fortes
na segurança do sistema, isso dependerá do uso de tais recursos pelo administrador. Meu objetivo
aqui é explanar esses recursos exibindo as vulnerabilidades e erros mais comuns cometidos, bem
como as implementações necessárias para ter um ambiente seguro.

Instalação e Sistema Operacional

Minha recomendação é instalar sempre o MySQL em sistemas UNIX ( Like Linux ), por que você
tem maior controle sobre a instalação, facilidade em implementar rotinas automatizadas e por
apresentar melhor performance no Unix. Seguindo essa linha, você pode instalar via gerenciador de
pacotes ou através dos binários. Caso opte pela instalação via binários lembre-se de criar um
usuário e grupo “mysql” para o daemon.
Para modificar o usuário e grupo padrão de arquivos pasta você pode utilizar o comando a seguir:
chown -R mysql:mysql /seudatadir

Preferencialmente, edite o usuário de sistema operacional “mysql” e coloque um bash que

impossibilite o login na conta, deixando o usuário exclusivamente funcional para “DAEMON”
Além disso outros arquivos como arquivo de “socket” e “pid” devem ser sempre do usuário
MySQL. A ideia é sempre evitar que qualquer usuário do sistema operacional tenha acesso aos
datafiles ou arquivos do banco de dados de modo que possa copia-los, modifica-los ou remove-los!
O mesmo vale para os backups, não deixe os arquivos de backup fora desse padrão, pois
informações valiosas podem ser obtidas através dos backups do banco de dados, portanto trate de
implementar as mesmas políticas no diretório de backup, inviabilizando os acessos de outros
usuários que não sejam “root” ou “mysql“.
Outros arquivos podem ser mantidos dessa forma, impossibilitando a leitura dos demais usuários
“/etc/my.cnf“, esse arquivo contem informações relevantes sobre as configurações do banco de
dados, trate com carinho as permissões de acesso do mesmo.
Após a instalação do MySQL recomendo que execute de imediato um programa auxiliar
disponibilizado junto ao MySQL, segue:
mysql_secure_installation

Esse programa fará algumas verificações no catalogo de usuários,senhas, e nos bancos de dados
padrão, siga o setup respondendo as perguntas!

Outra falha clássica! Ao utilizar o client do mysql o mesmo salva os comandos executados pelo
usuário em um arquivo “.mysql_history” similar ao “.history” do linux! A cagada está feita!
Dependendo da versão do MySQL o mesmo grava até os comandos de criação de usuário nesse
arquivo, de forma que obtendo acesso ao home do usuário em questão você conseguirá descobrir
credencias de acesso ao banco de dados, e os demais comandos executados por aquele usuário.
Como resolver? Aponte esse arquivo para o “/dev/null”, por exemplo:
rm /home/usuario/.mysql_history

ln -s /dev/null /home/usuario/.mysql_history

O restante fica por conta da boa administração do sistema operacional, evitando a criação de
acessos e permissões indevidas.
Usuários e privilégios
Já foi apresentada uma breve introdução sobre a parametrização de usuários no tópico anterior. Você
pode iniciar a correção de problemas de segurança em usuários utilizando o script
“mysql_secure_installation“, fora isso você deverá remover os usuários padrão, não deixar nenhum
acesso sem senha como medidas básicas de segurança! Vamos lá:
Qual é o usuário que existe em todaaaaa nova instalação MySQL?
O “root”, se alguém tentar utilizar algum método de força bruta em seu banco de dados,
provavelmente utilizará o usuário “root”, pois ele existe em toda instalação e raramente é removido!
A boa prática indica que se crie um novo usuário como as mesmas permissões do “root” mas com
outro login, além disso remova os demais usuários que não serão utilizados e crie senhas para todos
os usuários do banco de dados, veja abaixo um exemplo:
Isso lhe garantirá boas práticas de acesso e uma segurança adicional evitando ataques de brutal
force, já que você não terá acessos padrão, quanto as credencias de acesso e privilégios dos demais
usuários você pode adotar outras práticas, segue:
• Crie uma conta para cada aplicativo no banco de dados, evitando que um aplicativo
tenhas as mesmas permissões de acesso do outro
• Limite ao extremo os acessos, converse com os desenvolvedores e veja quais são os
privilégios necessário, e lembre-se de atribuir tais privilégios ao database correto
• Nunca utilize “grant all privileges on *.* to “, somente utilize essa cláusula para
criar novos administradores, usuários de aplicação não devem ter acesso extras. Pois
caso o aplicativo seja invadido o atacante terá o mínimo de acesso possível.
• Evite atribuir privilégios de DROP pois se aplicativo for invadido o atacante terá
mais dificuldade para apagar tabelas ou causar outros danos
• Nunca mantenha usuários sem senha em seu banco de dados
• Evite criar usuários com permissão de acesso partindo de qualquer HOST, utilize nas
cláusulas sempre a relação “usuario@host”, como em:
CREATE USER 'APPMOB'@'10.0.0.3' IDENTIFIED BY 'SenHASd$@#%23';

• Lembre-se: atribua os privilégios necessários, somente os necessários, e um dia você dará

graças por ter feito isso! Além da segurança externa, que contempla a defesa para ações mal
intencionadas, você evitará que erros sistêmicos ou erros humanos afetem o sistema.

Política de troca de senha e expiração de

senhas
Sim! O MySQL possui essa funcionalidade!
Até a versão 5.5 o MySQL não possui nenhum recurso que possibilita-se forçar a troca de senha dos
usuários ou validar a força de senha, a partir da versão 5.6 isso é possível, sendo melhor
implementado esse recurso na versão 5.7!
Para usuários de aplicativo ou seja, usuários que executam a aplicação, você não deve implementar
politica de troca de senha, já que isso poderá impactar na indisponibilidade da aplicação, mas
usuários utilizados por funcionários ou colaboradores da organização você deve certamente
implementar! Visto que o mercado de trabalho proporciona a troca de colaboradores a todo instante
e usuários são facilamente esquecidos no banco de dados.
Recomendo a leitura do artigo “Expirar e forçar troca de senha MySQL 5.7.4“

Rede e infraestrutura
A maior brecha de segurança poderá ser encontrada aqui! O tráfego de informações entre o servidor
e o client MySQL não são criptografados, portanto com um programa de captura de pacotes você
pode analisar todo o tráfego e coletar as transações do banco de dados, o que é uma vulnerabilidade
muito grave em um sistema! Os métodos mais comuns utilizados para sanar essa falha são:
 • Manter o banco de dados em uma rede diferente do sistema e restringir o acesso entre o
sistema e o banco de dados através de uma VLAN
• Utilizar SSL no MySQL, isso é possível e fará com que os dados trafeguem criptografados,
veja como em: http://dev.mysql.com/doc/refman/5.6/en/ssl-connections.html
• Não! Nunca, pelo amor de Deus! Evite isso, não deixe o seu banco de dados aberto para a
internet, deixar a porta 3306 ou seja lá a porta que o seu banco de dados esteja operando
disponível na internet é uma brecha bem grave! Se você tiver de deixar o seu banco de dados
disponível para acessos externos, utilize uma VPN, regras de firewall não serão suficientes,
você precisa encapsular os pacotes através de um protocolo seguro como uma VPN.
• Altere a porta padrão do banco de dados, por padrão os programas de varredura e força bruta
irão operar na porta 3306, isso pode ser feito através da edição do arquivo de configuração
do MySQL:
[mysqld]

port = 13306

Replicação
• Ao criar usuários para manipulação e operação da replicação, siga as instruções do site
oficial do MySQL, não atribua privilégios a mais do que o necessário.
• Utilize o MySQL com SSL para encapsular os pacotes que trafegam na rede
• Não trate seu ambiente de contingência como uma salinha de bagunça! Aplique as mesmas
políticas de segurança utilizadas no seu ambiente de produção, pois ele poderá ser alvo de
ataque.

Aplicação e codificação
• Utilize frameworks durante o desenvolvimento de seu aplicativo, preferencialmente
frameworks bem consolidados, eles irão evitar erros clássicos de SQL INJECTION.
• Veja exemplos de tratamento de SQL INJECTION em
http://www.php.net/manual/pt_BR/security.database.sql-injection.php
• Evite atribuir muitos privilégios ao usuário de aplicação, restrinja o acesso do usuário de
aplicação ao database do aplicativo em questão e não libere privilégios de DROP
• Grave todas as senhas no banco de dados com algum tipo de HASH, assim se o atacante
conseguir extrair informações via SQL INJECTION o mesmo não conseguirá identificar as
senhas de acesso do sistema, e não analisará ou obterá informações estratégicas geradas pelo
sistema em tempo de execução.
• Crie rotinas em PROCEDURES que façam as operações no banco de dados, tanto de
SELECT, INSERT,DELETE e deixe o usuário de aplicação só com privilégio de execução
nas PROCEDURES, assim o atacante estará limitado a executar as PROCEDURES e nada
mais.
Log e monitoramento
Após implementar uma política de segurança em seu database e ambiente operacional, crie plugins
de monitoramento que possibilitem a verificação dessas políticas, de modo que você tenha a
garantia de que seu ambiente continua operando conforme planejado. Verifique os catálogos de
usuário do banco de dados, verifique as permissões de acesso dos usuários, valide as permissões e
os owners dos arquivos no sistema operacional, crie PROCEDURESe TRIGGERS para monitorar
as atividades de seus usuários. Veja um exemplo:

Para maiores informações, você pode ver as minhas referências:

http://dev.mysql.com/doc/refman/5.6/en/mysql-secure-installation.html
Mas uma vez utilizo como referência uma documentação da nossa amiga “Percona“, para
informações avançadas como configuração de SELINUX entre outras, recomendo a seguinte
apresentação: http://www.percona.com/sites/default/files/presentations/mysql-security-webinar.pdf
Dúvidas? Tire suas dúvidas aqui! Sugestões de segurança são bem vindas!