xmlrpc.php no WordPress: O que é, riscos de segurança e como desativá-lo

Principais conclusões

• Deixar o xmlrpc.php aberto expõe o teu site a ataques de força bruta e DDoS, enquanto que se o desactivares manualmente através do .htaccess arriscas-te a destruir o teu site.
• Os plug-ins de segurança podem bloquear os pedidos XML-RPC, mas acrescentam um inchaço desnecessário à base de dados e diminuem a velocidade geral de carregamento da página.
• Proteja seu site sem esforço usando o alternador XML-RPC de 1 clique da Cloudways e capture cargas ocultas com o complemento Proteção contra malware por apenas US$ 4/mês por aplicativo.

Por vezes, os registos do servidor mostram picos repentinos na utilização de recursos, onde milhares de pedidos automatizados atingem um ficheiro específico chamado xmlrpc.php. Esta atividade atinge rapidamente o máximo de CPUs do servidor e indica um ataque de força bruta ativo em vez de um aumento de tráfego legítimo.

O ficheiro xmlrpc wordpress foi originalmente criado para ajudar as aplicações externas a interagir com um site. Atualmente, está obsoleto e funciona sobretudo como uma porta aberta para os bots testarem as palavras-passe.

Proteger pontos de extremidade expostos, como o XML-RPC, é um primeiro passo crítico na segurança abrangente de um site. A forma mais simples de parar estes ataques e preservar os recursos do teu servidor é encerrar completamente o ficheiro.

Neste blogue, vamos analisar o objetivo original deste ficheiro desatualizado, delinear os riscos de segurança específicos que introduz e fornecer instruções passo a passo sobre como o desativar em segurança.

O que é xmlrpc.php no WordPress?

Antes de a API REST se tornar o padrão, o xmlrpc.php era a principal forma de comunicação do WordPress com aplicativos externos.

Se quiseres publicar uma publicação a partir de uma aplicação móvel ou de uma ferramenta de blogue de terceiros, este ficheiro trata da ligação.

Permitia aos utilizadores contornar o painel de administração principal, continuando a interagir com o seu sítio. Também geria pingbacks e trackbacks. Sempre que fazias uma ligação a outro blogue no teu conteúdo, o protocolo XML-RPC enviava uma notificação automática a esse site.

A tecnologia subjacente mudou significativamente desde essas primeiras versões. A API REST do WordPress substituiu em grande parte o XML-RPC e lida com a comunicação externa de forma muito mais segura.

Como resultado, este ficheiro antigo está agora desatualizado. Para quase todos os sítios Web modernos, não serve qualquer propósito real e deixa simplesmente um ponto de acesso desnecessário aberto no teu servidor.

Os riscos de segurança: Porque deves desativar o xmlrpc.php

Como mencionámos anteriormente, deixar este ponto de acesso desnecessário aberto no teu servidor é exatamente a razão pela qual o ficheiro é uma responsabilidade tão grande.

Os piratas informáticos exploram funções específicas incorporadas no xmlrpc.php para contornar os limites de segurança padrão e comprometer os ambientes WordPress.

Ataques de login por força bruta

As páginas de início de sessão padrão estrangulam as tentativas de senha. Se um script tentar adivinhar uma senha de administrador em wp-login.php, as medidas básicas de segurança bloqueiam o endereço IP após algumas tentativas fracassadas. O XML-RPC contorna totalmente estas protecções.

Os piratas informáticos utilizam um comando chamado system.multicall para agrupar centenas de tentativas de adivinhação de palavras-passe num único pedido HTTP.

Esta técnica permite-lhes percorrer rapidamente enormes listas de credenciais sem desencadear bloqueios de início de sessão. Estes pedidos de força bruta são quase sempre efectuados por um ataque automatizado de botnet.

Ataques DDoS e falhas no servidor

A funcionalidade de pingback foi originalmente concebida para notificações de blogues, mas o protocolo carece de verificação. Um atacante pode falsificar o endereço IP do teu site e enviar pedidos de pingback a milhares de outros sites WordPress em simultâneo.

Cada um desses sites externos responde imediatamente com um ping para o teu servidor. Esta onda repentina e maciça de tráfego de entrada esgota a CPU e a memória do teu servidor, fazendo com que o site caia.

Infecções por malware e aquisições de sites

Um servidor com falhas é um problema temporário de desempenho, mas um ataque de força bruta bem sucedido é uma violação crítica. Se o exploit multicall adivinhar com sucesso as tuas credenciais de administrador, o atacante ganha controlo total sobre o teu ambiente de alojamento.

Depois de adivinharem a tua palavra-passe através do XML-RPC, a primeira coisa que fazem é instalar uma backdoor oculta do WordPress. Utilizam este acesso persistente para lançar cargas maliciosas, modificar ficheiros centrais ou redirecionar o teu tráfego orgânico para domínios maliciosos.

Automatiza a tua defesa contra malware

Bloqueia backdoors ocultos em suas trilhas. O complemento Cloudways Malware Protection isola e remove automaticamente cargas maliciosas no nível do sistema operacional antes que elas possam ser executadas.

Ativar a proteção

Como verificar se o xmlrpc.php está a ser executado no teu site

Tens três formas simples de verificar se este ponto final está ativo na tua instalação do WordPress.

1. O teste do navegador

O método mais rápido não requer ferramentas externas. Abre o teu navegador Web, escreve o teu domínio e adiciona /xmlrpc.php ao final do URL.

Se a página carregar um ecrã em branco com uma única linha onde se lê “XML-RPC server accepts POST requests only,“, o ficheiro está exposto e ativo. Se vires um erro 403 Forbidden ou 404 Not Found, o teu servidor já está a bloquear o acesso.

2. Ferramentas de validação em linha

Também podes executar uma verificação de diagnóstico utilizando um validador XML-RPC online gratuito. Estas aplicações Web simulam o tipo exato de pedidos externos que um bot faria.

Se o teu site for seguro e o ficheiro estiver bloqueado, a ferramenta não conseguirá estabelecer ligação.

Se o ponto final for deixado em aberto, o validador passará com êxito a verificação e confirmará a vulnerabilidade.

3. O método da linha de comando

Se preferires trabalhar no terminal, podes enviar um pedido POST direto utilizando um comando cURL. Cola a seguinte linha no teu terminal, substituindo o URL fictício pelo teu nome de domínio real:

curl -d "system.listMethods" https://yourdomain.com/xmlrpc.php

Se o ficheiro estiver ativado, o teu servidor enviará uma resposta XML bruta e estruturada com a lista dos métodos disponíveis.

Como desativar o xmlrpc.php (Os métodos manuais)

Se geres o teu próprio servidor ou utilizas um anfitrião partilhado básico, tens duas formas tradicionais de desativar este ponto final manualmente.

Método 1: Desativar através de um plug-in

A solução manual mais simples é instalar um plugin de segurança dedicado, como o Disable XML-RPC. Uma vez instalado e ativado, o plugin bloqueia automaticamente os pedidos de entrada para o ficheiro.

É isso mesmo!

Mas… a principal desvantagem desta abordagem é o inchaço da base de dados. Adicionar plugins de propósito único adiciona uma sobrecarga desnecessária à tua instalação do WordPress.

Cada plugin adicional obriga o teu servidor a processar mais código em cada carregamento de página, o que acaba por diminuir o desempenho do teu site.

Método 2: Desativação através de .htaccess ou Regras do Servidor

Se quiseres evitar plugins inchados e estiveres à procura de uma alternativa leve ao Wordfence, é preferível o bloqueio ao nível do servidor. Podes bloquear totalmente o acesso modificando os ficheiros de configuração do teu servidor principal.

Para servidores Apache, acede ao teu site através de SFTP ou do gestor de ficheiros do teu alojamento. Localiza o ficheiro .htaccess na tua pasta de raiz (normalmente public_html) e cola o seguinte excerto:

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

Se estiveres a executar um servidor NGINX, terás de adicionar este bloco de código ao teu bloco de servidor:

location = /xmlrpc.php {
    deny all;
}

O risco: Editar manualmente os arquivos de configuração do servidor principal é altamente arriscado. A falta de um único parêntese, a utilização da sintaxe errada ou a colagem do código na secção errada desencadeará imediatamente um erro interno do servidor 500 e colocará todo o teu site offline.

Sempre cria um backup do seu .htaccess ou arquivo de bloco do servidor antes de fazer qualquer alteração. Se fores um usuário do Cloudways, podes criar rapidamente um backup completo sob demanda com um único clique no painel de Gerenciamento de aplicativos.

Defesa automatizada contra explorações XML-RPC: O complemento de proteção contra malware da Cloudways

Se você hospedar seu site WordPress no Cloudways, não precisa arriscar quebrar seu site com edições manuais do servidor. Tens acesso a ferramentas de nível de plataforma que bloqueiam o ponto de entrada XML-RPC, filtram o tráfego malicioso e param automaticamente as cargas de malware.

Apanha a carga útil com a proteção contra malware

Se um atacante ultrapassar com sucesso os teus limites de início de sessão através de uma exploração de força bruta XML-RPC, o seu próximo passo imediato é colocar uma backdoor no teu servidor. Encontrar esses scripts ocultos manualmente requer um profundo conhecimento técnico e desperdiça um tempo valioso.

O complemento Cloudways Malware Protection atua como sua proteção contra falhas automatizada contra essas violações. Alimentado pelo Imunify360, ele opera no nível do sistema operacional para proteger todo o seu ambiente de servidor.

• Bloqueio ativo de ameaças: Usa a autoproteção de aplicativos em tempo de execução (RASP) para isolar instantaneamente backdoors ocultos lançados por invasores. Impede que o código malicioso seja executado antes que o hacker possa assumir o controle.
• Limpeza automatizada: Analisa todo o seu servidor para localizar scripts ocultos resultantes de uma violação e limpa o código infetado sem danificar os seus ficheiros principais legítimos.

A sua ativação demora apenas alguns cliques e a verificação inicial é executada inteiramente em segundo plano.

Passo 1: Navega até à Segurança da Aplicação

Faz login na plataforma Cloudways e seleciona o aplicativo de destino. Clica em Segurança do aplicativo no menu de gerenciamento à esquerda.

Passo 2: Ativa o complemento

Seleciona o separador Proteção contra malware e clica no botão Ativar proteção. Isto ativa a monitorização em tempo real e inicia uma verificação em segundo plano abrangente dos seus diretórios e base de dados.

Passo 3: Monitoriza os resultados

Podes acompanhar a limpeza automática em três separadores simples:

• Malicioso: Mostra os caminhos exactos dos ficheiros de ameaças isoladas e confirma se foram limpos, colocados em quarentena ou removidos.
• Histórico de verificações: Fornece um registo de verificações anteriores e permite ativar verificações manuais.
• Defesa proativa: Regista os eventos de tempo de execução em que os scripts PHP maliciosos foram impedidos de serem executados.

A alternância XML-RPC de 1 clique

Enquanto a Proteção contra Malware lida com as cargas descartadas, você ainda deve fechar completamente o ponto de entrada XML-RPC. A Cloudways fornece uma alternância integrada que aplica regras no nível do servidor instantaneamente, poupando-te de edições .htaccess arriscadas.

• Vai a Definições da aplicação no teu painel de controlo.
• No separador Definições do WordPress, encontra a opção XML-RPC.
• Muda para Desativado.

Parando o tráfego de bots na borda

Desativar o ficheiro impede os hackers de iniciarem sessão, mas os scripts automatizados continuarão a fazer ping repetidamente ao ponto final fechado. Milhares desses pedidos falhados continuarão a drenar a CPU do teu servidor.

O Cloudways Cloudflare Enterprise Add-on resolve isso. Seu firewall de aplicativo da Web de nível empresarial atua como um filtro de borda. Identifica o tráfego mal-intencionado e bloqueia essas solicitações de força bruta XML-RPC antes que elas cheguem ao seu servidor.

Sabe mais sobre como a filtragem de borda protege os teus recursos na nossa comparação WAF vs. firewall.

Quando é que precisas de manter o xmlrpc.php ativado?

Para 99% dos sites WordPress modernos, a resposta é nunca.

Desde a introdução da API REST do WordPress na versão 4.7, quase todas as ferramentas de publicação remota, aplicações móveis e plug-ins principais migraram para a API baseada em JSON mais recente, mais rápida e mais segura.

A única altura em que deves deixar este ficheiro ativo é se estiveres a lidar com um caso extremo altamente específico:

• Estás a utilizar uma aplicação de publicação remota personalizada e antiga que não é actualizada há anos.
• Estás a executar um plug-in específico e desatualizado que requer explicitamente o protocolo XML-RPC para funcionar e não pode ser substituído.

Uma boa regra de ouro: Se não tens a certeza absoluta se precisas do xmlrpc.php, não precisas dele. É perfeitamente seguro desactivá-lo.

Terminar!

O ficheiro xmlrpc.php existe desde os primeiros dias do WordPress, mas já não é relevante para a maioria dos sites. Atualmente, cria principalmente riscos de segurança ao dar aos atacantes uma forma fácil de lançar ataques de força bruta e DDoS.

Deixá-la aberta é um risco que não precisas de correr.

Quer o bloqueies manualmente através do teu ficheiro .htaccess ou utilizes a opção de 1 clique no teu painel de controlo Cloudways, a desativação deste ponto final deve ser uma parte padrão da tua lista de verificação de segurança.

Para ter total tranquilidade, combine essa etapa preventiva com o complemento Cloudways Malware Protection para garantir que todas as ameaças automatizadas sejam capturadas e limpas antes que possam ser executadas.