XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно ломают мобильное приложение, внешнюю публикацию или удалённый доступ через старые интеграции. На практике задача не в том, чтобы просто запретить запросы, а в том, чтобы понять, нужен ли вам этот интерфейс вообще, и закрыть его без побочных эффектов.
Если на сайте уже идут попытки перебора паролей через /xmlrpc.php, это видно по логам и по нагрузке на сервер. Но перед блокировкой стоит проверить, не использует ли кто-то из команды Jetpack, старый клиент WordPress или сторонний сервис, который до сих пор ходит именно через XML-RPC.
Когда XML-RPC можно отключать, а когда лучше оставить
Отключение оправдано, если сайт управляется только через админку WordPress и не использует внешние клиенты публикации. В этом случае XML-RPC чаще даёт лишнюю поверхность атаки, чем пользу. Но если у вас подключён Jetpack, старый мобильный клиент, удалённая публикация или интеграция с сервисом, который не умеет REST API, блокировка может сломать рабочий сценарий.
Что обычно ломается после отключения
- подключение Jetpack на старых конфигурациях;
- публикация из внешних редакторов и мобильных клиентов;
- синхронизация некоторых сервисов, которые используют XML-RPC вместо REST API;
- проверки доступности, если они завязаны на этот endpoint.
Если сомневаетесь, сначала посмотрите, есть ли обращения к xmlrpc.php в access log веб-сервера. Это самый практичный способ понять, используется ли endpoint реально, а не «по памяти».
Диагностика: как понять, что XML-RPC уже атакуют или используют
Для начала проверьте логи. На Nginx это обычно access log, на Apache — аналогичный журнал запросов. Ищите частые обращения к /xmlrpc.php, особенно с одинаковых IP и с кодами ответа 200 или 403. Если запросов много и они идут сериями, это типичный признак перебора.
Ещё один полезный тест — временно открыть страницу https://example.com/xmlrpc.php в браузере. В норме WordPress отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не уязвимость, а просто признак того, что endpoint доступен. Сам по себе он не доказывает проблему, но подтверждает, что закрывать его нужно осознанно.
Чек-лист перед отключением
- проверить access log на обращения к
/xmlrpc.php; - уточнить, использует ли команда Jetpack или внешний редактор;
- проверить, есть ли интеграции со старым мобильным приложением WordPress;
- сделать бэкап конфигурации веб-сервера и файла
.htaccess, если он используется; - сначала протестировать блокировку на staging, если он есть.
Как отключить XML-RPC: сравнение подходов
| Способ | Где применять | Плюсы | Минусы |
|---|---|---|---|
| Через код в теме или mu-plugin | Если нужен управляемый вариант внутри WordPress | Легко откатить, можно оставить комментарий в коде | Не защищает до загрузки WordPress |
| Через веб-сервер | Если нужен более жёсткий запрет на уровне сервера | Снимает нагрузку раньше, чем WordPress начнёт обработку | Нужно аккуратно править конфиг |
| Плагином безопасности | Если нужен быстрый вариант без кода | Подходит для админов без доступа к серверу | Лишняя зависимость от плагина |
Для большинства рабочих сайтов удобнее начать с кода, а если атаки идут массово — дополнить блокировкой на уровне сервера.
Пошаговое решение через код
Самый предсказуемый способ — отключить XML-RPC фильтром xmlrpc_enabled. Лучше не вставлять это в functions.php активной темы, а вынести в небольшой mu-plugin. Тогда настройка не исчезнет после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Сохраните файл, например, как wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную. WordPress подхватит такой файл автоматически, без активации в админке.
Если нужно не просто отключить XML-RPC, а вернуть понятный ответ для запросов, можно дополнительно отдать 403 на уровне WordPress. Но в большинстве случаев фильтра достаточно. Не усложняйте без необходимости.
Вариант через .htaccess для Apache
Если сайт работает на Apache, можно заблокировать доступ к xmlrpc.php на уровне веб-сервера. Это полезно, когда атаки создают лишнюю нагрузку и вы хотите отсечь запросы до запуска WordPress.
<Files xmlrpc.php>
Require all denied
</Files>
Для старых конфигураций Apache иногда встречается синтаксис Deny from all, но на современных серверах лучше использовать Require all denied. После правки обязательно проверьте, что файл конфигурации читается сервером и не ломает другие правила.
Вариант через Nginx
На Nginx блокировка делается в конфиге сайта. Это самый прямой способ, если у вас есть доступ к серверу и вы хотите закрыть endpoint без участия WordPress.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
После изменения конфига не забудьте проверить его и перезагрузить Nginx. Обычно это делается стандартными командами администрирования сервера, но конкретный путь зависит от вашей системы и прав доступа.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере и убедитесь, что доступ закрыт или что WordPress больше не отвечает как XML-RPC endpoint. Затем проверьте логи: новые обращения к этому URL должны либо исчезнуть, либо получать отказ на уровне сервера.
Если вы отключали XML-RPC через фильтр, дополнительно проверьте, что сайт не потерял нужные интеграции. Например, если Jetpack был подключён, посмотрите его статус в админке. Если использовалась внешняя публикация, попробуйте выполнить тестовый запрос из того же инструмента, который работал раньше.
Что именно смотреть после внедрения
- код ответа при обращении к
/xmlrpc.php; - отсутствие новых успешных запросов в access log;
- работоспособность Jetpack и других интеграций;
- отсутствие роста 403/500 ошибок на сайте после правки конфигурации.
Частые ошибки и как их исправить
Ошибка 1: отключили XML-RPC в теме. После смены темы защита исчезнет. Перенесите код в mu-plugin или обычный плагин.
Ошибка 2: заблокировали endpoint, не проверив интеграции. Если сайт использует Jetpack или внешний клиент, сначала протестируйте на staging или хотя бы в окно низкой нагрузки.
Ошибка 3: правят .htaccess без понимания порядка правил. На Apache важно, чтобы блок не конфликтовал с другими директивами. После изменения всегда проверяйте сайт и логи ошибок.
Ошибка 4: считают, что отключение XML-RPC решает все проблемы безопасности. Это только один из векторов. Пароли, двухфакторная аутентификация, ограничение попыток входа и обновления остаются обязательными.
Что ещё стоит сделать для защиты от brute force
Если атаки идут не только через XML-RPC, но и через wp-login.php, одной блокировки endpoint недостаточно. Нужны дополнительные меры: ограничение попыток входа, 2FA для администраторов, актуальные версии ядра и плагинов, а также нормальные пароли для всех учётных записей с правами выше подписчика.
На практике хорошо работает связка: отключённый XML-RPC, ограничение доступа к админке по IP для служебных сайтов, и отдельный плагин безопасности, который умеет логировать неудачные входы. Если нужен более широкий набор технических чисток и отключений лишних функций, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpmentor.ru&utm_medium=article&utm_campaign=kak-otklyuchit-xmlrpc-i-zashchitit-sayt-ot-bruteforce-v-wordpress
Главное — не делать защиту «вслепую». Сначала посмотрите, используется ли XML-RPC, потом выберите способ блокировки, и только после этого фиксируйте результат по логам и реальным интеграциям.