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

🛡️ 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.

1. Abra o arquivo wp-config.php na raiz do site.
2. 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/' 'storage_core/data/' --all-tables --precise --report-changed-only

Com SQL manual (quando necessário):

UPDATE wp_posts
SET post_content = REPLACE(post_content, 'wp-content/uploads/', 'storage_core/data/');

UPDATE wp_postmeta
SET meta_value = REPLACE(meta_value, 'wp-content/uploads/', 'storage_core/data/');

Prática de produção: sempre execute backup completo antes do search-replace.

---

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

Mover pasta aumenta obscuridade, mas não impede execução de .php se um arquivo malicioso for carregado.

Apache (.htaccess no novo diretório)

Crie /.public_html/storage_core/data/.htaccess:

# Impede execução de scripts PHP no diretório de mídia
<Files *.php>
    deny from all
</Files>

Nginx (server block)

location /storage_core/data/ {
    location ~ \.php$ {
        deny all;
    }
}

Se você usa stack híbrida (Nginx como proxy + Apache backend), aplique regra nos dois lados para evitar bypass por rota interna.

---

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

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

1. Upload novo via painel (/wp-admin/upload.php) vai para o novo diretório.
2. Imagens antigas continuam abrindo em posts já publicados.
3. 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:

1. Revalidar chmod/chown.
2. 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:

1. Reexecutar search-replace com relatório.
2. 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:

1. Garantir bloqueio no servidor web (Apache/Nginx).
2. 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 post está licenciado sob CC BY-NC.