Как отключить XML-RPC в WordPress и защитить сайт от brute force

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

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

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

Сам по себе файл xmlrpc.php не является уязвимостью, но он часто становится точкой входа для перебора логинов и паролей. На небольших сайтах это может выглядеть как постоянные POST-запросы с одинаковыми шаблонами. На хостингах с ограничениями по CPU это уже заметно по нагрузке и по росту мусора в access-логах.

Отключать XML-RPC имеет смысл, если вы:

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

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

Диагностика: нужен ли вам XML-RPC на самом деле

Самая частая ошибка — отключить интерфейс, а потом обнаружить, что перестали работать удалённая публикация или синхронизация. Поэтому сначала проверьте, кто обращается к xmlrpc.php и есть ли у вас реальные зависимости.

Что смотреть в логах

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

Простой способ проверить вручную — открыть URL https://ваш-домен/xmlrpc.php. Если интерфейс включён, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказательство атаки, но хороший маркер того, что endpoint доступен извне.

Какие интеграции стоит проверить заранее

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

Если вы не уверены, временно отключите XML-RPC на staging-копии и проверьте сценарии публикации, авторизации и синхронизации.

Как отключить XML-RPC в WordPress: рабочие варианты

Есть три нормальных подхода: через код, через сервер и через плагин безопасности. Для точечного контроля обычно удобнее код. Если нужен быстрый вариант без правки темы, можно использовать мини-плагин или mu-plugin.

Способ	Когда подходит	Минус
Код в mu-plugin	Нужен стабильный контроль без зависимости от темы	Нужно один раз добавить файл вручную
Правило на сервере	Есть доступ к nginx/apache и нужно блокировать до WordPress	Требует аккуратной настройки сервера
Плагин безопасности	Нужен интерфейс и дополнительные проверки	Лишняя зависимость от стороннего плагина

Вариант 1: отключить XML-RPC через код

Самый практичный способ — добавить небольшой mu-plugin. Тогда код не потеряется при смене темы и не зависит от обновлений шаблона.

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Отключает XML-RPC на сайте.
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_filter( 'xmlrpc_enabled', '__return_false' );

Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную. После этого WordPress перестанет принимать XML-RPC-запросы на уровне ядра.

Вариант 2: заблокировать xmlrpc.php на сервере

Если задача — не просто отключить функциональность, а отрезать endpoint до PHP, используйте правила веб-сервера. Это полезно, когда бот-атаки создают лишнюю нагрузку ещё до загрузки WordPress.

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

Для Apache обычно используют правило в .htaccess или конфигурации виртуального хоста:

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

Этот вариант жёстче: если какой-то сервис всё же зависит от XML-RPC, он перестанет работать сразу, без обходных путей.

Вариант 3: отключение через плагин

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

Пошаговое решение без лишнего риска

1. Проверьте, используется ли XML-RPC в реальных сценариях.
2. Сделайте резервную копию или работайте на staging-копии.
3. Выберите способ отключения: mu-plugin или серверное правило.
4. Внедрите изменение и очистите кэш, если он есть на сайте или на CDN.
5. Проверьте доступность /xmlrpc.php и поведение интеграций.

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

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

Проверка должна быть не «на глаз», а по факту ответа сервера.

• Откройте /xmlrpc.php в браузере или через curl.
• Убедитесь, что POST-запросы получают отказ или не проходят.
• Посмотрите access-лог: количество обращений к endpoint должно перестать расти из-за обычных ботов, если блокировка сделана на сервере.

Пример проверки через curl:

curl -i -X POST https://example.com/xmlrpc.php

Если XML-RPC отключён через WordPress-фильтр, вы обычно увидите отказ в обработке запроса. Если блокировка сделана на уровне nginx или Apache, ответ может быть 403 Forbidden. Оба варианта допустимы, если ваша цель — закрыть endpoint.

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

Отключили XML-RPC в теме

Так делать не стоит. При смене темы защита исчезнет. Для системной настройки используйте mu-plugin или серверную конфигурацию.

Сломали Jetpack или внешний редактор

Это означает, что у вас был реальный потребитель XML-RPC. Верните доступ на staging, проверьте, какой именно сервис требует endpoint, и решите, можно ли заменить его другим способом авторизации или API.

Поставили тяжёлый плагин ради одной галочки

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

Не проверили кэш и CDN

После изменения endpoint может продолжать отвечать из-за прокси или кэша. Очистите кэш на сайте, на сервере и на CDN, если он используется.

Что ещё можно сделать для защиты от brute force

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

• ограничение попыток входа;
• двухфакторную аутентификацию для админов;
• смену стандартного логина admin, если он ещё существует;
• защиту wp-login.php на уровне сервера или через WAF;
• обновления ядра, тем и плагинов.

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

Практический чек-лист перед выкладкой на прод

• Проверил, не использует ли сайт XML-RPC через Jetpack или внешние сервисы.
• Выбрал способ отключения: код или сервер.
• Добавил изменение не в тему, а в mu-plugin или конфиг сервера.
• Очистил кэш WordPress, сервера и CDN.
• Проверил ответ /xmlrpc.php через браузер или curl.
• Посмотрел, не появились ли ошибки в логах интеграций.

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