Как отключить XML-RPC в WordPress и закрыть лишний канал для brute force

XML-RPC в WordPress часто всплывает не как полезная функция, а как источник лишнего шума в логах, перебора паролей и странных запросов к /xmlrpc.php. На небольших сайтах этот файл нередко никто не использует, но он остаётся доступным и продолжает принимать запросы. Если у вас нет мобильного приложения WordPress, внешних публикаций через старые клиенты или интеграций, которые завязаны именно на XML-RPC, его обычно имеет смысл отключить.

Ниже — не абстрактная теория, а рабочая схема: как понять, нужен ли вам XML-RPC, чем его отключать, как не сломать интеграции и как проверить результат после внедрения.

Когда XML-RPC действительно мешает

Проблема обычно выглядит одинаково: в логах веб-сервера много запросов к /xmlrpc.php, иногда с попытками system.multicall, иногда с перебором логинов. На уровне сайта это может не проявляться сразу, но нагрузка и риск подбора учётных данных остаются. Если сайт небольшой, а внешних сервисов немного, этот канал часто просто не нужен.

Перед отключением важно не гадать, а проверить реальные сценарии использования. XML-RPC нужен не всем, но если вы пользуетесь:

• старым мобильным приложением WordPress для публикации;
• внешними редакторами, которые отправляют записи через XML-RPC;
• некоторыми сервисами автопостинга и синхронизации;
• Jetpack в режимах, где ему нужен доступ через XML-RPC;

то отключение надо делать аккуратно и с тестом на стороне интеграции.

Диагностика: используется ли XML-RPC сейчас

Начните с простого: посмотрите логи доступа веб-сервера или отчёт в панели хостинга. Если запросы к /xmlrpc.php идут регулярно, это уже повод разобраться, кто их делает. Если логов нет, можно проверить вручную через браузер или curl.

Быстрая проверка ответа сервера

curl -I https://example.com/xmlrpc.php

Если XML-RPC включён, вы обычно увидите ответ, связанный с самим файлом, а не 404. Это ещё не значит, что он нужен, но показывает, что точка доступа открыта.

Полезно также проверить, не завязаны ли на него плагины и внешние сервисы. Если у вас есть интеграция, которая публикует записи извне, временно отключите её на тестовом стенде и посмотрите, не перестанет ли работать отправка контента.

Что проверить в админке и на стороне сервисов

• используется ли мобильное приложение WordPress;
• есть ли внешние редакторы или планировщики публикаций;
• подключён ли Jetpack и какие функции он реально использует;
• есть ли старые интеграции, которые не переведены на REST API;
• не завязаны ли на XML-RPC сторонние сервисы автопостинга.

Как отключить XML-RPC без лишнего риска

Есть несколько рабочих подходов. Если нужен быстрый и обратимый вариант, удобнее всего использовать код в теме или мини-плагине. Если вы предпочитаете административный интерфейс, можно закрыть XML-RPC через плагин безопасности или оптимизации. Но для точечного контроля код обычно предсказуемее.

Вариант через код

Если вам нужно именно отключить XML-RPC, добавьте фильтр xmlrpc_enabled. Для небольшого сайта это самый понятный способ.

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

Этот код можно добавить в functions.php дочерней темы, но надёжнее вынести в маленький mu-plugin, чтобы он не зависел от смены темы.

Пример mu-plugin:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Вариант через сервер

Если вы хотите отрезать запросы раньше, чем они дойдут до WordPress, можно закрыть доступ на уровне веб-сервера. Это полезно, когда к /xmlrpc.php идёт много мусорного трафика.

Для Nginx типовой вариант выглядит так:

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

Для Apache чаще используют правила в .htaccess, но здесь важно не сломать общий доступ к сайту и не копировать чужие правила без понимания. Если нет уверенности, начните с фильтра WordPress и только потом переносите блокировку на сервер.

Проверка результата после внедрения

После отключения не ограничивайтесь тем, что страница перестала открываться в браузере. Нужно проверить именно поведение точки входа и отсутствие побочных эффектов.

• Откройте /xmlrpc.php в браузере или через curl.
• Проверьте, что ответ изменился на ожидаемый: 403, 404 или другой контролируемый отказ.
• Посмотрите логи веб-сервера: новые запросы к этому файлу не должны доходить до WordPress.
• Проверьте внешние интеграции, если они были подключены.
• Убедитесь, что публикация записей из админки, REST API и обычные формы работают как раньше.

Если вы отключали XML-RPC через фильтр, а запросы всё ещё проходят, значит, где-то остался обходной путь: кэш, прокси, правило на сервере или другой плагин, который вмешивается в обработку запроса.

Частые ошибки и как их исправить

Отключили XML-RPC и потеряли интеграцию

Это самая частая ситуация. Причина обычно в том, что интеграция была старой, а документацию никто не проверял. Решение простое: либо вернуть XML-RPC только на время миграции, либо перевести сервис на REST API, если он это поддерживает.

Поставили плагин, который делает больше, чем нужно

Некоторые плагины безопасности не только отключают XML-RPC, но и добавляют другие ограничения. В результате можно получить ложные блокировки, проблемы с авторизацией или конфликт с кэшем. Если задача точечная, лучше использовать минимальное решение.

Закрыли файл в WordPress, но не на сервере

Это не ошибка как таковая, но уязвимое место остаётся открытым для лишних запросов. WordPress их просто отклонит, однако веб-сервер всё равно будет принимать и обрабатывать обращения. Если атака идёт массово, серверный блок даёт более чистый результат.

Сломали проверку на staging, а на проде не тестировали

XML-RPC часто вспоминают только после того, как перестаёт работать публикация из внешнего сервиса. Поэтому сначала проверьте все сценарии на копии сайта, а уже потом переносите изменение на боевой домен.

Чек-лист перед отключением

• Проверить, используется ли мобильное приложение WordPress.
• Проверить внешние редакторы и сервисы автопостинга.
• Посмотреть логи на запросы к /xmlrpc.php.
• Выбрать способ отключения: код или сервер.
• Сделать тест на staging, если сайт с интеграциями.
• После внедрения проверить ответ на /xmlrpc.php и логи.

Что делать, если XML-RPC нужен, но атаки идут

Иногда полностью отключить XML-RPC нельзя. Тогда задача меняется: не убрать функцию, а сократить поверхность атаки. В таком случае имеет смысл:

• ограничить доступ по IP, если интеграция работает с фиксированного адреса;
• усилить защиту входа: сложные пароли, двухфакторная аутентификация, лимит попыток;
• вынести публикацию в REST API, если сервис это поддерживает;
• следить за логами и не держать открытым лишний функционал.

Если вам нужен более широкий технический аудит сайта, полезно параллельно проверить дубли, индексацию и служебные страницы. Для этого часто используют инструменты вроде Clearfy Pro: он помогает чистить лишние элементы и уменьшать количество технического мусора на сайте, но применять его стоит только там, где вы понимаете, что именно отключаете.

Как понять, что решение сработало

Признаки нормального результата довольно конкретные:

• /xmlrpc.php больше не отвечает как рабочая точка входа;
• в логах нет новых успешных обращений к XML-RPC;
• внешние сервисы, которые вы проверили заранее, продолжают работать или были осознанно переведены на другой способ интеграции;
• нагрузка от мусорных запросов снижается, если именно XML-RPC был источником шума.

Если после отключения вы видите ошибки в публикации или синхронизации, не возвращайте всё назад автоматически. Сначала найдите конкретную интеграцию, которая зависит от XML-RPC, и решите, можно ли заменить её на REST API или другой способ обмена данными.