Blindagem de WordPress: como alterar e proteger o

Blindagem de WordPress: Como Alterar e Proteger o Diretório de Uploads#

O diretório padrão de uploads do WordPress (/wp-content/uploads/) é um dos alvos primários em ataques automatizados. Bots de varredura procuram por arquivos de configuração esquecidos, backups de plugins ou vulnerabilidades de execução de scripts (RCE) em caminhos fixos.

Neste guia técnico, demonstro a estratégia que apliquei para mover esse diretório para um local personalizado e adicionar camadas extras de segurança no nível do servidor (Apache/Nginx), impedindo execução de código malicioso mesmo quando há upload indevido.

A ideia aqui é bem objetiva: reduzir previsibilidade para bots, preservar integridade do ambiente e manter disponibilidade com baixo impacto de operação.

1. Planejamento e preparação da infraestrutura#

Antes de qualquer alteração no código, é obrigatório preparar o ambiente no sistema de arquivos do servidor.

Criando o novo diretório#

Acesse o servidor via SSH ou FTP e crie a nova pasta. Por segurança, prefira um nome que não contenha "uploads" ou "media".

Exemplo de caminho: /public_html/storage_core/data/

mkdir -p /public_html/storage_core/data/

Ajuste de permissões (Linux)#

O usuário que executa o webserver (www-data, apache ou o usuário da conta no cPanel) precisa de permissão de escrita.

chmod 755 /public_html/storage_core/data/

Se necessário, ajuste ownership:

chown -R accountuser:accountuser /public_html/storage_core/data/

2. Configuração no core do WordPress#

A alteração do diretório de uploads é feita via constante no wp-config.php.

Abra o arquivo wp-config.php na raiz do site.
Adicione a linha abaixo antes do comentário:

/ That's all, stop editing! Happy publishing. /

// Define o novo caminho de uploads relativo à raiz da instalação
define('UPLOADS', 'storage_core/data');

Nota técnica: a constante UPLOADS deve ser relativa ao ABSPATH, sem barra inicial.

Depois de salvar, valide com um upload de teste no painel de mídia para confirmar escrita no novo caminho.

3. Migração de dados e integridade do banco#

Movendo os arquivos existentes#

Se o site já possui imagens, mova o conteúdo legado:

Origem: /wp-content/uploads/*
Destino: /storage_core/data/

rsync -avh --progress /public_html/wp-content/uploads/ /public_html/storage_core/data/

Search and replace (ajuste de URLs)#

Esse é o ponto que mais gera incidente pós-migração: as URLs antigas ficam gravadas no banco (wp_posts e wp_postmeta).

Procurar: wp-content/uploads/
Substituir por: storage_core/data/

Com WP-CLI:

wp search-replace '/wp-content/uploads/' '/public_html/storage_core/data/' \
  --all-tables-with-prefix --precise --report-changed-only --dry-run

Execute primeiro com --dry-run para validar as alterações antes da execução definitiva.

Importante: Evite executar UPDATE ... REPLACE diretamente via SQL na tabela wp_postmeta, pois um replace textual cego corrompe arrays e objetos serializados do PHP (como metadados de mídia e tamanhos intermediários gerados pelo WordPress). Utilize sempre o wp search-replace --precise.

4. Hardening de servidor: bloqueando execução de scripts#

Mover a pasta aumenta a obscuridade, mas não impede a execução de scripts se um invasor conseguir realizar o upload de um payload malicioso.

Apache (`.htaccess` no novo diretório)#

Crie /public_html/storage_core/data/.htaccess:

# Impede execução de qualquer script no diretório de mídia (Apache 2.4+)
<FilesMatch "(?i)\.(php|phtml|phar|php[0-9])$">
    Require all denied
</FilesMatch>

Nginx (server block)#

location /storage_core/data/ {
    location ~* \.(php|phtml|phar|php[0-9])$ {
        deny all;
    }
}

Se você usa stack híbrida (Nginx como proxy reverso + Apache no backend), aplique as regras nas duas camadas para evitar bypass por roteamento interno.

5. Validação operacional pós-hardening#

Depois da migração e das regras, eu valido com checklist técnico curto:

Upload novo via painel (/wp-admin/upload.php) vai para o novo diretório.
Imagens antigas continuam abrindo em posts já publicados.
Tentativa de executar script retorna bloqueio.

Teste com curl:

curl -I https://domain.tld/storage_core/data/test-image.webp
curl -I https://domain.tld/storage_core/data/probe.php

Resultado esperado:

imagem: 200 OK (ou 304 Not Modified)
probe.php: 403 Forbidden ou 404 Not Found

Também valido logs de erro para garantir que não houve quebra silenciosa de plugin de galeria/CDN.

6. Erros comuns que eu já peguei em campo#

Erro a: novas imagens não sobem#

Causa provável:

permissão incorreta
ownership errado
open_basedir bloqueando novo caminho

Correção:

Revalidar chmod/chown.
Conferir open_basedir no php.ini ou pool FPM.

Erro b: imagens antigas quebradas após migração#

Causa provável:

search-replace incompleto
cache de plugin/CDN mantendo URL antiga

Correção:

Reexecutar search-replace com relatório.
Limpar cache de aplicação e CDN.

Erro c: acesso direto ao IP mostra uploads sem proteção#

Causa provável:

WAF/CDN ativo, mas origem exposta sem regra local

Correção:

Garantir bloqueio no servidor web (Apache/Nginx).
Se usar proxy reverso, restringir acesso de origem aos IPs confiáveis.

Conclusão estratégica#

Ao alterar o diretório padrão e aplicar bloqueios de execução, você tira o seu WordPress do radar da maior parte das varreduras genéricas e reduz impacto de payloads automatizados em upload.

Checklist final:

[ ] Backup completo antes de editar wp-config.php.
[ ] Permissões/ownership corretos na nova pasta.
[ ] Uploads novos indo para o caminho customizado.
[ ] search-replace concluído para URLs legadas.
[ ] Execução de PHP bloqueada no novo diretório.
[ ] Testes HTTP validados com curl.

Esse é o tipo de disciplina operacional que separa ambiente improvisado de infraestrutura profissional e resiliente.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

941 leituras

Creative Commons Atribuição-NãoComercial

Este post está licenciado sob CC BY-NC.

Blindagem de WordPress: como alterar e proteger o diretório de uploads