O que é o xmlrpc.php e como desativá-lo no WordPress?

Por que isso importa

O XML-RPC é uma antiga interface de controle remoto do WordPress. Antes de a API REST existir, era assim que editores de desktop e apps para celular publicavam posts. Ele ainda vem em todo site WordPress, em /xmlrpc.php, e ainda aceita nome de usuário e senha em cada requisição.

Isso o torna uma segunda porta de login. Ocultar o wp-login.php não mexe nele. Um código de limite de login que observa apenas o formulário de login não o enxerga. E, com o system.multicall, uma única requisição HTTP pode carregar centenas de palpites de senha. Um limite que conta requisições vê uma tentativa onde houve quinhentas.

Isso não é teoria. Criamos esta camada depois que uma loja continuou recebendo tentativas de senha pelo XML-RPC quando sua página de login já estava oculta.

Você usa o XML-RPC? Provavelmente não, se nenhum destes casos se aplica a você:

• Você conecta o site ao Jetpack.
• Você publica ou modera pelo app oficial do WordPress para celular.
• Você usa uma ferramenta de blog para desktop mais antiga, ou um serviço que pede seu nome de usuário e sua senha do WordPress (em vez de uma senha da aplicação) para publicar em seu nome.
• Você depende de pingbacks de outros blogs.

Se não tiver certeza, feche apenas o login e mantenha os pingbacks. Isso elimina o risco de adivinhação de senhas e mantém as partes inofensivas. Você sempre pode apertar mais depois.

Erros comuns

• Ocultar o login e parar por aí. A adivinhação de senhas simplesmente se muda para o xmlrpc.php.
• Bloquear o arquivo inteiro sem verificar. O Jetpack e o app oficial do WordPress para celular se conectam pelo XML-RPC. Se você os usa, feche só os métodos de login ou teste com cuidado.
• Confiar em uma opção sem testar. Alguns métodos deixam partes do XML-RPC respondendo. Sempre confira o resultado com uma requisição real (veja o passo 4, ou verifique o que o seu site expõe).
• Esquecer a camada de cache. Se uma regra da CDN já bloqueia o xmlrpc.php, uma configuração no nível do WordPress não vai mostrar efeito nenhum. Tudo bem; só saiba qual camada está fazendo o trabalho.

Sem plugin

Opção 1: o filtro xmlrpc_enabled. Adicione isto a um pequeno plugin obrigatório (must-use) (wp-content/mu-plugins/no-xmlrpc-login.php) ou ao functions.php do seu tema filho:

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Isso desativa os métodos do XML-RPC que exigem login. Os pingbacks continuam funcionando porque não precisam de login. Sozinho, ele não remove o system.multicall, e o arquivo continua respondendo às requisições. Para remover também o método multicall:

<?php
add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

Opção 2: bloquear o arquivo no servidor. No Apache, no .htaccess:

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

No Nginx: location = /xmlrpc.php { deny all; }. Esta é a opção mais rígida e não custa nada ao servidor, mas também acaba com os pingbacks, o Jetpack e o app para celular, e fica fora do WordPress, então é fácil esquecê-la quando você muda de hospedagem.

Se algo der errado

• O Jetpack mostra um erro de conexão. O Jetpack precisa do XML-RPC. Mude de "Desativar completamente" para "Desativar login, manter pingbacks" ou remova a regra do servidor.
• O app do WordPress para celular não consegue acessar. Mesma causa. Use o navegador no celular ou permita o login via XML-RPC e conte com os limites de login mais os dois fatores.
• Uma ferramenta de publicação parou de postar. Verifique se ela usa o XML-RPC. A maioria das ferramentas modernas migrou para a API REST com senhas da aplicação.

Com o Hushfort

A Trava de Backdoor faz parte do Hushfort Pro. A Varredura de Superfície, que mostra se o XML-RPC está aberto, está no Hushfort Security, o plugin de segurança gratuito para WordPress.

A Trava de Backdoor faz parte da camada Blindagem de Superfície do Hushfort. Ela oferece quatro opções:

• Desativar login, manter pingbacks (recomendado): a adivinhação de senhas pelo XML-RPC se torna impossível, enquanto pingbacks e trackbacks continuam funcionando. Ideal para lojas.
• Desativar completamente: a opção mais rígida. O Jetpack e o app oficial para celular não conseguem se conectar.
• Desativar só o system.multicall: fecha a adivinhação em massa e deixa o resto como está.
• Não alterar: o padrão do WordPress.

Depois, a Varredura de Superfície confere o resultado com requisições reais, para você ver o que alguém de fora vê. A Proteção de Carga também cobra mais pelas requisições ao xmlrpc.php do que por uma visualização de página normal, o que freia qualquer ruído restante.