Protegendo o MySQL para o seu site WordPress

Publicados: 2023-01-18

O WordPress, o CMS mais popular, é executado no MySQL, o banco de dados mais popular do mercado. Gastar algum tempo para garantir que a instalação do MySQL e a instalação da configuração do banco de dados do WordPress sejam adequadamente protegidas contra vetores de ataque comuns pode ajudá-lo a reduzir os riscos. Isso é especialmente verdadeiro se você mesmo estiver gerenciando seu servidor MySQL.

Vale a pena notar que muitas instalações do WordPress usam MariaDB, que é um fork do MySQL. Como ambos funcionam de maneira muito semelhante, usaremos MySQL para significar MySQL e MariaDB. Independentemente de qual tipo de RDMS você está executando, fortalecer seu MySQL pode ajudá-lo a minimizar os riscos de ataques de hackers. No entanto, isso não substitui outras medidas de segurança, como instalar um firewall de aplicativo da Web, garantir que você tenha a versão mais recente de plug-ins, temas e WordPress e fortalecer o WordPress.

Atenção , este artigo é direcionado ao MySQL 8.0 rodando no Linux (Ubuntu). Embora os conceitos sejam traduzidos para outros sistemas operacionais e versões MySQL/MariaDB, os comandos e caminhos de arquivo usados ​​nesses exemplos podem ser diferentes. Antes de fazer qualquer alteração em um sistema de produção, é altamente recomendável testar quaisquer alterações em um ambiente de preparação ou pré-produção.

Neste artigo, que é voltado principalmente para aqueles que gerenciam seu próprio MYSQL, oferecemos várias dicas e tutoriais sobre como proteger o MySQL. Mesmo assim, vale a pena ler a extensa lista de práticas recomendadas apresentadas neste artigo para qualquer pessoa que gerencie sites WordPress. Proteger seu servidor MySQL é uma etapa crítica para manter um WordPress seguro e proteger-se de diferentes tipos de ataques de força bruta, injeção de malware e outros tipos de ataques.

Índice

  • Considere usar um banco de dados como um serviço (DBaaS
  • Mantenha o MySQL atualizado
  • Execute o MySQL em uma máquina dedicada
  • Vincular o MySQL a um endereço IP
  • Limite o uso de ferramentas GUI baseadas na Web
  • Execute o daemon MySQL usando um usuário dedicado
  • Use o script mysql_secure_installation
  • Crie um usuário de banco de dados WordPress dedicado
  • Certifique-se de que local_infile esteja desabilitado
  • Desabilitar o histórico de comandos do MySQL
  • Certifique-se de que o mysqld não seja iniciado com o argumento –skip-grant-tables
  • Faça backup do seu banco de dados
    • Faça backups frequentes
    • Verifique a integridade de seus backups com frequência
    • Armazene seus backups com segurança
  • Ativar e aplicar conexões TLS
    • Alterar o prefixo da tabela
    • Como implementar mudanças
    • Mantendo seu WordPress seguro

Considere o uso de um banco de dados como serviço (DBaaS)

Vale a pena considerar o banco de dados como serviço se você não estiver hospedando o WordPress em um plano gerenciado. Ele substitui o modelo tradicional de instalação do MySQL localmente por um serviço ao qual você se conecta. Isso pode se adequar ao seu caso de uso se você estiver executando seu site WordPress com um provedor de hospedagem que oferece serviços de banco de dados gerenciados. As opções disponíveis geralmente incluem Amazon RDS, DigitalOcean Managed MySQL e Linode Managed MySQL). À primeira vista, esses serviços podem ser mais caros do que você mesmo executar o MySQL. No entanto, eles fazem todo o trabalho pesado de executar bancos de dados de nível de produção. A maioria dos serviços inclui predefinições de práticas recomendadas de segurança, patches e manutenção de segurança contínuos e backups.

Usar um banco de dados como serviço (DBaaS) é uma das melhores opções em termos de segurança e confiabilidade. Embora isso não seja obrigatório, ainda é bom ter. No entanto, se você deseja gerenciar o MySQL sozinho, segue uma coleção de dicas de proteção para manter em mente.

Mantenha o MySQL atualizado

Assim como é importante garantir que você esteja executando a versão mais recente do WordPress, é importante manter o MySQL atualizado. Como a maioria dos outros softwares, as atualizações do servidor MySQL são lançadas periodicamente. Essas atualizações abordam bugs, atenuam vulnerabilidades e fornecem novos recursos. Você deve manter o MySQL atualizado com os patches de segurança mais recentes para reduzir os riscos de execução de software com vulnerabilidades conhecidas. Tenha em mente que uma vez atualizado, você será solicitado a reiniciar o 'daemon mysql.' Este é um processo que pode incorrer em algum tempo de inatividade. Como sempre, planeje com antecedência.

Execute o MySQL em uma máquina dedicada

Muitas instalações do WordPress executam MySQL, PHP e um servidor web (como Nginx ou Apache HTTP Server) na mesma máquina. Isso não é ideal - tanto em termos de desempenho quanto de segurança. Idealmente, o MySQL deve ser executado em um servidor dedicado para reduzir o raio de explosão de um ataque. Se um invasor conseguir comprometer e escalar privilégios no servidor da Web, será muito mais difícil para esse invasor se mover lateralmente e também comprometer o servidor MySQL.

Vincular o MySQL a um endereço IP

Você pode configurar o MySQL para aceitar apenas conexões TCP/IP de uma interface IPv4 ou IPv6 específica. Tudo o que você precisa fazer é definir a opção de configuração de endereço de ligação para um endereço IP específico. Isso fornece controles e restrições adicionais sobre como os aplicativos clientes (no nosso caso, WordPress) podem se conectar ao MySQL. Por padrão, essa configuração é definida como *, o que significa que o MySQL pronto para uso escutará em todas as interfaces.

Se não estiver configurado para escutar um IP específico, todos os IPs podem ser usados ​​para conectar ao MySQL. Esta configuração é especialmente importante para definir se você estiver executando o MySQL na mesma máquina que um servidor web que você está expondo à Internet (neste caso, você deve definir o endereço de ligação para 127.0.0.1 para que o MySQL escute apenas no localhost) .

Por exemplo, se você deseja que o servidor MySQL aceite apenas conexões em um endereço IPv4 específico, pode adicionar uma entrada semelhante ao exemplo abaixo. Você deve inserir isso no grupo de opções [mysqld] no arquivo de configuração /etc/mysql/mysql.conf.d/mysqld.cnf do seu servidor.

endereço de ligação = 192.168.0.24

Observe que, depois de definir isso, você precisará reconfigurar o WordPress para se conectar ao banco de dados usando esse endereço IP (a menos que já esteja fazendo isso), pois as conexões em outros endereços de host do servidor não seriam permitidas.

Limite o uso de ferramentas GUI baseadas na Web

Muitas instalações do WordPress incluem ferramentas de gerenciamento gráfico front-end baseadas na web. Exemplos comuns incluem Cpanel, phpMyAdmin ou Adminer. Essas ferramentas facilitam o gerenciamento do MySQL e outros aspectos da infraestrutura subjacente. Embora uma interface gráfica baseada na Web possa ajudá-lo a gerenciar seus bancos de dados MySQL, essas interfaces podem aumentar a superfície de ataque adicionando outro vetor. Além disso, existe o risco de serem descobertos e abusados ​​por invasores para executar consultas SQL destrutivas ou maliciosas em seu banco de dados. Os ataques podem até resultar na aquisição total do seu site WordPress.

O único servidor seguro é aquele que está desligado e desconectado – no entanto, o risco pode ser gerenciado. A desinstalação de sistemas não críticos é uma opção; no entanto, eles também podem ser bloqueados e restritos para minimizar o risco.

É possível restringir o acesso a essas ferramentas de várias maneiras. Você pode instalar o phpMyAdmin for WordPress remotamente, minimizando assim o risco para o servidor web. Como alternativa, você também pode considerar o uso de ferramentas como MySQL Workbench ou Beekeeper Studio em sua máquina local e conectar-se ao seu servidor de banco de dados por meio de um túnel SSH.

Execute o daemon MySQL usando um usuário dedicado

Assim como outros serviços executados em um servidor, você pode executar o daemon MySQL sob um usuário dedicado. Quando você executa o MySQL usando um usuário dedicado, você pode definir com precisão quais permissões esse usuário recebe dentro do sistema. A execução do MySQL sob um usuário dedicado também segue o princípio do privilégio mínimo, pois isso reduz o raio de explosão de uma vulnerabilidade do MySQL. Também diminui a possibilidade de uma configuração incorreta ser aproveitada, pois um usuário restrito não poderá acessar recursos não relacionados ao MySQL (como configurações e segredos do sistema operacional).

A boa notícia é que as instalações via gerenciadores de pacotes (como apt ou yum) cuidam dessa etapa automaticamente ao instalar o MySQL. Uma maneira rápida de verificar se o MySQL está sendo executado sob um usuário dedicado é executar o seguinte na máquina que executa o daemon MySQL.

ps-ef | egrep “^mysql.*$”

Se o MySQL estiver rodando usando um usuário dedicado, você deve esperar ver pelo menos uma linha da saída de ps retornada.

Use o script mysql_secure_installation

O pacote mysql-server vem com um utilitário shell script chamado mysql_secure_installation. Você pode usar este script para configurar um ponto de partida seguro para o servidor MySQL. Como tal, você deve executá-lo após uma nova instalação do MySQL. Este utilitário ajuda você a:

  • Definir uma senha para contas root
  • Remova as contas root que são acessíveis de fora do localhost
  • Remover contas de usuários anônimos
  • Remova o banco de dados de teste (que, por padrão, pode ser acessado por usuários anônimos)

Para invocar mysql_secure_installation, execute o seguinte comando:

sudo mysql_secure_installation

Assim que o processo de configuração começar, você receberá vários prompts perguntando se deseja habilitar o plug-in de validação de senha , que é usado para testar a força das senhas escolhidas para usuários do MySQL. É recomendável que você habilite este plug-in.

Depois de habilitar o plug-in de validação de senha, o script solicitará que você especifique uma política de validação de senha. Aqui, você deve escolher uma política de senha forte. Em seguida, você será solicitado a redefinir a senha do usuário root.

Em seguida, o script solicitará que você remova usuários MySQL anônimos. Isso é importante para reduzir qualquer chance de invasores obterem acesso ao servidor de banco de dados aproveitando um usuário MySQL anônimo.

O próximo prompt perguntará se você gostaria de desabilitar logins usando o usuário root ao autenticar remotamente no servidor MySQL. A autenticação remota usando o usuário raiz é perigosa e raramente necessária. Em vez disso, você deve fazer SSH no MySQL e usar o cliente MySQL no servidor para autenticar como usuário root ou, de preferência, usar um túnel SSH para encaminhar a porta MySQL remota para sua máquina local e conectar-se usando um cliente local.

Em seguida, você será solicitado a excluir os bancos de dados padrão (se existirem) que acompanham o MySQL. Esta é a prática recomendada para servidores MySQL de produção.

Excluir banco de dados padrão

Por fim, você será perguntado se deseja recarregar as tabelas de privilégios para que todas as alterações aplicadas tenham efeito.

Crie um usuário de banco de dados WordPress dedicado

As melhores práticas de segurança determinam a segregação de usuários e privilégios por deveres ou funções. Isso significa que todo aplicativo que faz uso do banco de dados deve ter seu próprio usuário dedicado com a quantidade mínima de permissões de banco de dados MySQL necessárias para realizar seu trabalho. Dessa forma, você garantirá que os privilégios do usuário não ultrapassem o necessário.

Essa prática deve se estender a implantações que executam vários sites WordPress - cada site WordPress deve ter seu próprio banco de dados dedicado e usuário MySQL. Isso garante que, a qualquer momento, apenas um usuário tenha acesso a um banco de dados por vez e os usuários não possam acessar outros bancos de dados, evitando acessos não autorizados e violações de dados.

A instrução SQL a seguir (substitua <host> e <password> e <database> para atender às suas necessidades) pode ser usada para criar um usuário dedicado para o seu site WordPress e conceder privilégios para uso regular. Lembre-se de que alguns plugins, temas e atualizações do WordPress podem ocasionalmente precisar de privilégios adicionais para operar corretamente (consulte a orientação oficial do WordPress sobre isso para obter mais informações).

Certifique-se de que local_infile esteja desabilitado

A instrução LOAD DATA permite que você carregue arquivos de dados em tabelas de banco de dados. Sob condições específicas, isso pode ser abusado para ler arquivos do servidor MySQL. Portanto, a menos que você tenha um caso de uso específico para isso em seu site WordPress, desative esse recurso.

Se o MySQL e o servidor da web estiverem sendo executados na mesma máquina, isso pode permitir que um invasor use a instrução LOAD DATA LOCAL para ler arquivos arbitrários aos quais o processo do servidor da web tem acesso de leitura. Isso pressupõe que um invasor tenha a capacidade de executar instruções SQL arbitrárias no MySQL. Tal pode ser o caso de uma vulnerabilidade de injeção de SQL ou através da instalação de um plug-in malicioso do WordPress. Este é mais um motivo para manter seu servidor web e servidores de banco de dados separados.

Por padrão, local_infile está desativado no MySQL 8.0 (costumava ser ativado por padrão em versões anteriores do MySQL). Para evitar que o servidor MySQL aceite instruções LOAD DATA LOCAL, certifique-se de que o daemon mysqld seja iniciado com local_infile desabilitado.

Desabilitar o histórico de comandos do MySQL

No Linux, as instruções de logs do cliente MySQL executadas interativamente são salvas em um arquivo de histórico (normalmente localizado em $HOME/.mysql_history). Idealmente, o histórico de comandos do MySQL deve ser desativado, pois isso reduz a probabilidade de expor informações confidenciais, como senhas, chaves de criptografia ou outros segredos.

Para verificar se os arquivos .mysql_history não existem no sistema, execute os seguintes comandos:

localize /home -name “.mysql_history”
localize /root -name “.mysql_history”

Se os comandos acima retornarem qualquer saída, remova todos os arquivos .mysql_history. Além disso, você pode definir $HOME/.mysql_history como um link simbólico para /dev/null da seguinte maneira:

ln -s /dev/null $HOME/.mysql_history

Certifique-se de que o mysqld não seja iniciado com o argumento –skip-grant-tables

Se a senha root do MySQL for extraviada, embora não seja o método preferido, alguns administradores do MySQL podem recorrer à configuração do MySQL para iniciar com o argumento –skip-grant-tables. Ao iniciar o MySQL com este parâmetro, ele evitará a verificação de suas tabelas de concessão quando um cliente se conectar ou executar uma consulta, permitindo efetivamente que qualquer pessoa, em qualquer lugar (desde que possa acessar o banco de dados pela rede), faça qualquer coisa no servidor de banco de dados.

Para garantir que –skip-grant-tables não esteja ativado, abra o arquivo de configuração /etc/mysql/mysql.conf.d/mysqld.cnf do seu servidor e procure por skip-grant-tables. O valor não deve ser definido ou definido como skip-grant-tables = FALSE.

Faça backup do seu banco de dados

Fazer backup de seu banco de dados WordPress é absolutamente crucial para poder se recuperar rapidamente de um desastre ou ataque. Embora haja uma infinidade de maneiras de fazer backup de seu banco de dados do WordPress – de plug-ins e serviços de backup do WordPress a scripts internos que fazem um despejo do banco de dados periodicamente – a seguir estão algumas dicas importantes a serem lembradas.

Faça backups frequentes

Fazer backups regulares é bastante óbvio e autoexplicativo — quanto mais frequentemente você fizer backups de banco de dados, mais fácil será se recuperar de um incidente de perda de dados. Embora a frequência dos backups dependa do tipo de site WordPress que você está executando, como regra geral, fazer um backup diário atende bem à maioria dos casos de uso.

Verifique a integridade de seus backups com frequência

Seus backups só são úteis se funcionarem. e você provavelmente preferiria não descobrir enquanto está no meio de um incidente tentando recuperar dados. A correção simples para isso é verificar frequentemente se seus backups realmente funcionam, fazendo restaurações de teste de vez em quando. Uma boa maneira de fazer isso é definir um evento de calendário a cada poucos meses para passar por um procedimento de restauração para garantir que seus backups ainda estejam funcionando conforme o esperado. Além disso, documentar as etapas de restauração do banco de dados também é uma boa ideia — quanto menos suposições ao responder a um incidente, melhor.

Armazene seus backups com segurança

Nunca mantenha backups do seu site WordPress em seu servidor web ou banco de dados (especialmente em seu servidor web). Os backups são um ótimo lugar para os invasores mergulharem no lixo. É altamente recomendável armazenar seus backups em um local externo seguro. Se você estiver fazendo dumps de banco de dados periódicos, considere armazenar seus dumps de banco de dados em um serviço de armazenamento de objetos. Isso pode incluir Amazon S3, Cloudflare R2, DigitalOcean Spaces, Linode Object Storage, etc. Seguir esse caminho pode ser uma maneira excelente e econômica de armazenar seus backups de banco de dados. No entanto, tenha muito cuidado para não tornar o depósito de armazenamento que está usando acessível ao público.

Ativar e aplicar conexões TLS

A menos que você esteja executando o MySQL na mesma máquina que seu servidor web (o que, como já abordamos acima, não é uma prática de segurança ideal), é altamente recomendável criptografar dados entre WordPress e MySQL usando Transport Layer Security (certificado TLS), anteriormente referido como Secure Socket Layer (certificado SSL).

Por padrão, quando você instala o MySQL, ele gera automaticamente um certificado autoassinado para você. Você pode verificar isso executando o seguinte (como alternativa, você pode usar o script mysql_ssl_rsa_setup para gerar novos certificados).

Você precisará copiar ca.pem da lista acima (por exemplo, via SCP) para o servidor que executa seu site WordPress. Depois de carregar o arquivo ca.pem para o servidor WordPress, você precisará mover o certificado para o armazenamento confiável de certificados do sistema operacional e atualizar o armazenamento confiável de certificados da seguinte maneira.

Atenção, o nome do arquivo do certificado CA deve terminar com uma extensão de arquivo .crt (por exemplo, mysql-ca.crt é válido, mas mysql-ca.pem.crt ou mysql-ca.pem são inválidos).

sudo mv ca.pem /usr/local/share/ca-certificates/mysql-ca.crt
sudo update-ca-certificates

Em seguida, você precisa configurar o WordPress para usar TLS ao se conectar ao MySQL, adicionando o seguinte ao seu arquivo wp-config.php de sua instalação do WordPress.

define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

Depois de atualizar o wp-config.php, o WordPress iniciará as conexões com seu servidor MySQL usando TLS.

Em seguida, é recomendado que você imponha conexões TLS ao seu servidor MySQL usando a variável de sistema require_secure_transport adicionando o seguinte ao seu arquivo /etc/mysql/mysql.conf.d/mysqld.cnf.

require_secure_transport = ATIVADO

Por fim, reinicie o MySQL para que as alterações entrem em vigor.

systemctl reinicie o mysql

Alterar o prefixo da tabela

Por padrão, todas as tabelas do WordPress são criadas com o prefixo 'wp_'. Isso pode facilitar o sucesso dos invasores em determinados ataques, como injeção de SQL, pois eles saberiam os nomes das tabelas do banco de dados. Embora isso por si só não vá protegê-lo, é um exercício simples, recomendado por muitos como a melhor prática de segurança do WordPress.

Você pode alterar o prefixo do banco de dados durante o processo de instalação ou a qualquer momento, embora o último seja um pouco mais complexo. De qualquer forma, você pode encontrar tutoriais online sobre como alterar o prefixo do banco de dados do WordPress.

Como implementar mudanças

Esperançosamente, este artigo forneceu uma visão geral do reforço de segurança do MySQL no contexto da execução de um site WordPress. Embora não haja balas de prata na segurança do site, com algum esforço, adotar uma abordagem de defesa em camadas para a segurança tornará o ataque ao seu site significativamente mais difícil para os invasores.
Embora este guia apresente várias técnicas de proteção para o MySQL, o MySQL é apenas um componente do ecossistema do WordPress. Como tal, você também deve considerar outros aspectos da segurança do WordPress abordados em nosso guia de proteção de segurança do WordPress. Isso, juntamente com medidas de segurança comprovadas, como a autenticação de dois fatores do WordPress, ajudará você a garantir que esteja o mais seguro possível.

Se parecer muito para absorver, lembre-se de que você pode (e provavelmente deve) aplicar gradualmente as várias técnicas de endurecimento abordadas neste guia.

Mantendo seu WordPress seguro

Lembre-se de que os invasores geralmente estão atrás de alvos fáceis, pois não precisam se esforçar tanto para explorar sites mal protegidos. Estar um passo à frente da postura de segurança do próximo site WordPress torna você um alvo menos atraente.