Segurança no WordPress em nível de servidor e usuário

Muitos administradores confiam apenas em plugins de segurança (como Wordfence ou iThemes), mas a verdade dura é: plugins rodam em nível de aplicação (PHP). Se o ataque derrubar o PHP ou explorar uma falha no Nginx/Apache, o plugin nem sequer “acorda” para defender o site.

A verdadeira segurança no WordPress acontece antes mesmo da requisição chegar ao PHP. Aqui está o guia de hardening “nível sysadmin”, focado em impedir que o servidor seja comprometido, mesmo que o WordPress tenha uma vulnerabilidade.

1. Bloqueio de Execução de PHP (A Regra de Ouro)

A forma mais comum de hackear WP é fazer upload de um arquivo malicioso (backdoor/shell) disfarçado para a pasta wp-content/uploads e executá-lo. Se você impedir que arquivos PHP sejam executados nessas pastas, você mata 90% dos vetores de ataque automatizados.

No Nginx:

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

No Apache (.htaccess):

Você deve criar um arquivo chamado .htaccess especificamente dentro da pasta de uploads(wp-content/uploads) do seu WordPress, e não na pasta raiz do site. Insira:

<FilesMatch “\.php”>
Require all denied
</FilesMatch>

2. Imutabilidade de Arquivos Críticos (`chattr`)

Permissões Linux padrão (chmod) não são suficientes se o atacante ganhar acesso com o usuário do sistema. A “bala de prata” do sysadmin é o atributo de imutabilidade.

Use o comando chattr +i em arquivos que nunca devem mudar automaticamente. Isso impede que até mesmo o usuário root altere ou delete o arquivo sem antes remover o atributo.

Onde aplicar: wp-config.php e, em casos extremos, o index.php da raiz.

chattr +i /home/usuario/public_html/wp-config.php

Nota: Se você precisar editar esse arquivo, terá que rodar chattr -i primeiro.

3. Hardening do PHP (php.ini / pool.d)

O WordPress não precisa de acesso a todas as funções do sistema operacional. Restrinja o que o interpretador PHP pode fazer.

Desabilitar Funções Perigosas: No seu php.ini ou na configuração do FPM, desabilite funções que scripts de shell usam para comandar o servidor.

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

Open_basedir: Garanta que o PHP esteja “preso” no diretório do usuário, impedindo que um site invadido leia o /etc/passwd ou arquivos de outros sites no mesmo servidor.

4. Matando o XML-RPC

O arquivo xmlrpc.php é um legado usado para pingbacks e o app mobile do WP, mas hoje serve quase exclusivamente para ataques de Brute Force e amplificação de DDoS.

Ação: Bloqueie o acesso a ele diretamente no Web Server (Nginx/Apache), para não gastar recursos do PHP processando o bloqueio.
Nginx:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Apache:

No arquivo .htaccess na raiz do seu site. Adicione as seguintes linhas no topo do arquivo (antes da linha # BEGIN WordPress para garantir que a regra seja lida primeiro):

<Files "xmlrpc.php"> 
Require all denied 
</Files>

<Files "xmlrpc.php"> 
Require all denied 
</Files>

⚠️ Antes de aplicar, saiba disto:

Bloquear o xmlrpc.php vai quebrar as seguintes funcionalidades:

Plugin Jetpack: Muitos módulos do Jetpack dependem desse arquivo para se comunicar com os servidores da Automattic.
App Mobile do WordPress: Você não conseguirá gerenciar o site pelo aplicativo de celular oficial.
Pingbacks/Trackbacks: Seu blog não receberá notificações automáticas de links de outros blogs.

5. Web Application Firewall (WAF)

O que é WAF?

WAF (Web Application Firewall) é uma camada de segurança que fica entre a internet e o seu site, inspecionando todo o tráfego HTTP/HTTPS antes que ele chegue ao WordPress. Ele analisa as requisições em tempo real e bloqueia as que parecem maliciosas — sem precisar que a ameaça já tenha chegado ao servidor.

O diagrama abaixo mostra como o tráfego flui pelo WAF antes de chegar ao WordPress:

Não deixe o PHP filtrar ataques SQL Injection ou XSS. Faça isso antes.
Tenha no seu servidor:

ModSecurity + OWASP CRS(Nginx,Apache,LiteSpeed,OpenLiteSpeed): É o padrão da indústria. Ele analisa os pacotes de entrada e bloqueia padrões de ataque conhecidos antes que eles toquem o WordPress.
Nginx Rate Limiting: Configure limites de requisições por segundo para a página wp-login.php. Um humano não faz 10 tentativas de login por segundo, um bot sim.

6. Escondendo a Infraestrutura no seu servidor

Informação é poder para o atacante. Não anuncie suas versões.

Desative a assinatura do servidor (Server Signature).
Remova cabeçalhos como X-Powered-By: PHP/8.1.
Bloqueie acesso a arquivos “invisíveis” ou de texto que desenvolvedores esquecem: .git, .env, readme.html, license.txt.

Resumo da Estratégia

Camada	Ação	Objetivo
Borda	Firewall / Fail2Ban / Crowdsec	Bloquear IPs agressivos e portas não usadas.
Web Server	Nginx/Apache Rules	Bloquear XMLRPC, limitar acesso ao wp-login, esconder headers.
Sistema	`chattr +i`	Tornar o `wp-config.php` indestrutível.
PHP	`disable_functions`	Impedir que o WP execute comandos de shell (bash).
Aplicação	Plugin de Cache/Segurança	Auditoria de arquivos e 2FA (última linha de defesa).

Clique aqui e consulte nossos planos de Gerenciamento de Servidor

Veja mais: Guia Completo do DirectAdmin para Administradores | Instalação, Segurança e Performance
Veja mais: Como configurar lemp com wordpress e let´s encrypt
Veja mais: Como configurar lamp com wordpress e let´s encrypt
Veja mais: Criando atalho para listar diretórios e arquivos em ordem crescente
Veja mais: Como Instalar Openlitespeed no Ubuntu 20.04