WordPress XML-RPC: como desativar e proteger sites de clientes

O ficheiro xmlrpc.php existe em todas as instalações WordPress e é um alvo frequente de ataques de brute force e amplificação DDoS. Na maioria dos sites modernos, esta funcionalidade pode ser desativada sem quebrar nada. Saber quando e como fazê-lo é parte do hardening de segurança que toda a agência deve aplicar.

O que é o XML-RPC e por que é um risco

XML-RPC foi introduzido no WordPress para permitir publicação remota — a ideia era que aplicações externas, como clientes de email ou apps móveis antigas, pudessem publicar conteúdo via chamadas XML sobre HTTP.

O problema central é que o xmlrpc.php permite fazer múltiplas tentativas de autenticação numa única chamada HTTP através do método system.multicall. Um atacante pode testar centenas de combinações de utilizador e password numa única requisição, tornando os limites de rate por IP quase inúteis.

Além do brute force, sites WordPress com XML-RPC ativo têm sido usados como amplificadores em ataques DDoS — o atacante envia uma pequena requisição que faz o servidor enviar uma resposta muito maior para um alvo.

Quando pode desativar com segurança

Na maioria dos sites WordPress atuais, o XML-RPC não é necessário. Pode desativar com segurança se:

  • Não usa a aplicação WordPress Mobile (iOS/Android)
  • Não usa Jetpack (este requer XML-RPC ativo)
  • Não usa ferramentas de publicação remota como MarsEdit ou Windows Live Writer
  • Não tem integrações IFTTT ou Zapier que usem o endpoint XML-RPC
  • Não usa WooCommerce API via XML-RPC (improvável em instalações modernas)

Se usa Jetpack, existe uma alternativa: bloqueie todos os IPs exceto os servidores da Automattic. O Jetpack publica os IP ranges que usa.

Como desativar XML-RPC em WordPress

Método 1: via .htaccess (Apache)

Adicione ao ficheiro .htaccess na raiz do WordPress:

# Bloquear XML-RPC
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

Esta abordagem bloqueia o acesso ao ficheiro antes do PHP ser invocado, poupando recursos do servidor.

Método 2: via nginx

No bloco de configuração do servidor:

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

Método 3: via wp-config.php ou plugin

Adicione ao functions.php do tema (ou, melhor, a um plugin próprio de customizações):

add_filter('xmlrpc_enabled', '__return_false');

Esta abordagem desativa o processamento XML-RPC ao nível do WordPress mas o PHP ainda é invocado para cada requisição ao ficheiro — menos eficiente que o bloqueio via servidor web.

Método preferido para agências

Bloqueio via servidor web (método 1 ou 2). É o mais eficiente e funciona independentemente de alterações no WordPress. Para gerir múltiplos sites, inclua esta configuração nos templates de servidor que usa ao criar novos ambientes.

O que verificar antes e depois de desativar

Antes

  • Confirmar que o site não usa Jetpack (painel → Jetpack)
  • Verificar no log de acesso se há chamadas legítimas ao xmlrpc.php além dos ataques
  • Verificar integrações com terceiros que possam usar XML-RPC

Depois

  • Confirmar que https://seusite.pt/xmlrpc.php retorna 403 Forbidden
  • Verificar que o site funciona normalmente
  • Se usa Jetpack: confirmar que continua a sincronizar com WordPress.com
  • Verificar nos logs de servidor que as tentativas de acesso ao xmlrpc.php estão a ser bloqueadas

XML-RPC vs REST API: a alternativa moderna

A WordPress REST API (introduzida no WordPress 4.4, 2015) substitui o XML-RPC para praticamente todos os casos de uso modernos. É mais segura, mais fácil de usar e bem documentada. Se alguma integração usa XML-RPC, vale a pena verificar se existe equivalente via REST API.

A REST API tem os seus próprios vetores de ataque — principalmente o endpoint /wp-json/wp/v2/users que expõe usernames por defeito. Para mitigar, adicione ao functions.php:

add_filter('rest_endpoints', function($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

Incluir no processo de hardening padrão

O bloqueio de XML-RPC deve estar na checklist de configuração de qualquer novo site WordPress. Junto com proteção do wp-admin, autenticação de dois fatores e remoção de informação de versão do WordPress, forma um conjunto de medidas de baixo esforço e alto impacto.

Quer que apliquemos hardening de segurança nos sites dos seus clientes?

O nosso serviço de manutenção WordPress inclui configuração de segurança e monitorização contínua.

Falar connosco