5 tutoriais para migrar o WordPress para outro servidor
Encontrar tutoriais para migrar o WordPress não é uma tarefa muito difícil, mesmo porque com o WP, mudar de servidor é muito mais fácil.
O arquivo wp-config.php do WordPress é o mais importante. Ele centraliza todas as informações sensíveis e de configuração, entre elas as constantes de segurança para blindar o WP.
As constantes de segurança refletem diferentes áreas da aplicação e do servidor. É importante conhece-las e saber das suas utilidades e o impacto que trarão.
Mas antes de tudo, você precisa reconhecer uma constante do PHP e por conseguinte do WordPress.
Sobre as contantes do PHP
As constantes são definidas como um identificador para um valor único. Elas são “parentes” das variáveis, mas tem suas particularidades, a saber:
- Seu valor não pode ser alterado durante a execução do script;
- Os nomes são case-sensitive, ou seja, “ESTE_NOME” é diferente de “Este_Nome”;
- Por uma convenção, os nomes das constantes são todos em maiúsculos;
- Ao contrário de uma variável, seu nome não começa com $ (cifrão);
- O nome válido de uma constante começa com letra ou sublinhado e seguido por letras, números ou sublinhados;
- As constantes são criadas através da função define().
Um exemplo de constante:
define( 'WP_DEBUG', false );
O impacto das constantes no WP
Sejam as constantes de segurança, ou não, elas impactarão todo o funcionamento da aplicação.
Como as constantes são alocadas no arquivo wp-config.php e esse é carregado primeiro do que qualquer outra coisa, as definições vão impactar todo o resto.
O valor de quase todas as constantes terão o valor de true ou false. Ou seja, de verdadeiro ou falso para habilitar ou desabilitar o recurso representado pela constante.
As constantes de segurança do WordPress
Neste artigo vamos conhecer e focar em importantes constantes que impactarão as seguintes áreas:
- Banco de dados;
- Chaves de segurança (Security Keys);
- Debug;
- Permissão de arquivos;
- Edição de arquivos de temas e plugins;
- SSL;
- Atualização.
Constantes para a base de dados
Embora as constantes destinada a base de dados não seja direcionada a segurança, é muito importante que os seus valores sejam seguros.
Principalmente a constante DB_PASSWORD que armazena a senha do usuário ao banco de dados em uso. Essa senha precisa ser forte.
Um exemplo de senha forte aplicada a constante.
define( 'DB_PASSWORLD', 'IQ&36c0Mubx)ANcTXIBTgxIhtvyl4y(l}]Dsfx?03;' );
Embora não seja uma constante, a variável $table_prefix, que por padrão tem o valor “wp_”, não deve conter o valor padrão e sim um valor diferente para evitar de termos os nomes da nossa tabela público, uma vez que o esquema do banco de dados do WordPress é conhecido.
Caso você esteja utilizando o prefixo “wp_”, saiba como altera-lo e definir um mais seguro.
As chaves de segurança do WordPress
As chaves de segurança do WordPress começaram a ser adicionadas à plataforma à partir da versão 2.6. Em seguida as Salts foram adicionadas.
Elas são conhecidas como Secret Keys (chaves secretas) e Salts. São utilizadas para dar mais segurança aos dados sensíveis dos usuários como senhas e cookies.
No total são oito chaves, sendo quatro de cada tipo. Ambas são armazenadas em constantes PHP, ou no banco de dados da plataforma em caso da ausência delas no arquivo.
Sobre o gerador de Secret Keys e Salts
O WordPress.org mantém um serviço que gera automaticamente essas chaves em formatos de constantes do WordPress para você simplesmente copiar e colar no wp-config.php.
Exemplo das chaves de segurança do WordPress gerado pelo serviço do WordPress.org
Debug, seguro.
Depurar uma aplicação se faz necessário durante o desenvolvimento do projeto ou na busca pelo entendimento de algum erro inesperado.
O WordPress possui um mecanismo próprio que lhe permite ativar ou desativar, definir a exibição, ou não, dos erros na tela e gravar essas informações em um arquivo chamado debug.log e fica localizado no diretório /wp-content.
Em ambientes de produção evite deixar o mecanismo ativado, exceto se houver necessidade. E considere blindar o arquivo debug.log com a permissão correta e bloqueio através do .htaccess para evitar a exposição das sensíveis informações nele armazenadas.
As constantes referentes ao Debug do WordPress são demonstradas abaixo em conjunto ao uso da função ini_set do PHP, utilizada para definir o valor de uma configuração.
É importante seu uso, além da constante do WP, para certificarmos que o comportamento desejado para a aplicação está alinhado com o comportamento do PHP configurado no servidor.
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); @ini_set( 'log_errors', 'On' ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 'Off' );
As constantes de segurança aplicada aos arquivos
Todos os arquivos e pastas precisam ter sua correta permissão no servidor. Isso inclui o core do WordPress, os plugins e temas, ou seja, tudo. Arquivos e pastas.
Através do terminal é possível facilmente executar os seguintes comandos para essa finalidade.
find /path/to/wp-base-folder-install/ -type f ! -perm 644 -exec chmod 644 {} \;
find /path/to/wp-base-folder-install/ -type d ! -perm 755 -exec chmod 755 {} \;
O primeiro define a permissão 644 para os arquivos, enquanto o segundo a permissão 755 para os diretórios. Existem particularidades para alguns arquivos, portanto considere conhecer as permissões corretas para os arquivos e pastas do WordPress.
Em servidores Apache, e em algumas hospedagens pode ocorrer a execução do módulo suEXEC. Esse cenário combinado a atualização do WordPress pode comprometer a definição das permissões.
Existem duas constantes destinadas a essa tratativa. Uma para atuar sobre as permissões dos arquivos e outra para as pastas. São elas:
define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) ); define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) );
Evite a edição dos arquivos de temas e plugins
O painel do WordPress tem um editor que permite a edição dos arquivos de plugins e temas instalados.
É um recurso nativo e que por padrão vem ativado.
O problema desse recurso para a segurança está ligado a invasão ao painel através de um login e senha. A descoberta desses dados pode acontecer de várias formas, dentre elas o ataque de força bruta.
Uma vez que o atacante ganha acesso a área administrativa ele poderá fazer uso do recurso de edição de plugins e temas para injetar códigos maliciosos ou realizar qualquer alteração que comprometerá sua aplicação.
Com a constante DISALLOW_FILE_EDIT não será possível editar os arquivos de plugins e temas através da interface do WordPress. O seu valor precisa ser true.
define( 'DISALLOW_FILE_EDIT', true );
TLS / SSL, requerido.
O tempo em que todos os sites, independentemente da área de atuação ou tamanho, terão um certificado de segurança SSL implementado está batendo na porta.
É um caminho sem volta e temos assistido mobilizações por todos os lados para ajudar nessa implementação. A mais expressiva tem sido a Let’s Encrypt com a disponibilização do certificado gratuitamente.
Até a sua versão 4.0, o WordPress tinha duas constantes relacionados ao SSL, eram elas: FORCE_SSL_LOGIN e FORCE_SSL_ADMIN. Você deve desconsiderar a primeira que entrou em desuso.
A constante FORCE_SSL_ADMIN é utilizada para forçar o uso do mecanismo de login e todo painel administrativo do WordPress a utilizar o protocolo HTTPS e navegar os dados de forma criptografada. Incluindo, obviamente, dados sensíveis como senhas e cookies.
define( 'FORCE_SSL_ADMIN', true );
Tudo atualizado, sempre.
Manter o core, os plugins e temas atualizados é a regra mais básica e necessária para manter a segurança do WordPress e evitar ataques.
Você precisa ter o seguinte em mente: nenhum software será 100% seguro. É uma lei da segurança.
Mas quando uma brecha de segurança é descoberta, softwares comprometidos com a segurança dos seus usuários disponibilizam versões para correção, mas para isso é necessário que se atualize para a versão mais recente disponibilizada.
A constante WP_AUTO_UPDATE_CORE é uma dica fácil e rápida para lidar com os updates. No artigo as atualizações do WordPress e seus componentes de segurança detalho ainda mais essa questão.
O valor dessa constante podem ser três: true, false ou minor. Esse último é o padrão e informa que toda atualização minor será automaticamente aplicada. Utilizar um dos outros valores é algo mais avançado e você precisa conhecer os impactos e diferenças.
Proteção para o arquivo wp-config.php
Como percebido, o arquivo wp-config.php é o coração do WordPress. Todas as informações sensíveis, estratégicas e definições de comportamento da aplicação estão nele.
Você precisa considerar proteções para manter o arquivo wp-config.php seguro.
As três principais dicas são:
- Manter o arquivo um nível acima do diretório público;
- Usar a permissão 400 (readonly) ou 600 (para permissão de escrita);
- No arquivo .htaccess fazer uso de diretiva para proteção, se utilizar o Apache.
Conclusão
Considere proteger e ter um olhar diferente para com o arquivo wp-config.php. Considere mais ainda conhecer e fazer uso efetivo das constantes de segurança do WordPress para proteger o seu negócio.
Você pode imaginar que seria mais fácil se boa parte deles viessem ativadas por padrão. Eu também concordo. Mas é preciso ter a ciência que os casos de uso da plataforma são diversos.
E quando falo diverso, são diversos mesmo. Diferentes ambientes (desenvolvimento, homologação e produção); diferentes sistemas operacionais (Linux, Windows, Mac); diferentes servidores web (Apache, NGINX); diferentes combinações de sistemas e servidores e a lista continua.
Gabriel 
Leandro Vieira 
