Как отключить XML-RPC в WordPress и защитить сайт от брутфорса

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

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

Когда XML-RPC стоит отключать, а когда нет

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

Типичные признаки, что XML-RPC вам не нужен

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

Когда лучше не отключать сразу

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

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

Самый простой способ — посмотреть, есть ли обращения к xmlrpc.php в access log. Если у вас есть доступ к логам nginx или Apache, это даст более честную картину, чем догадки по плагинам.

# nginx access log
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

# Apache access log
grep "xmlrpc.php" /var/log/apache2/access.log | tail -n 50

Если вы видите частые POST-запросы с одного или нескольких IP, это повод проверить защиту. Отдельно обратите внимание на system.multicall — этот метод часто используют для массового перебора логинов и паролей.

Еще один практический тест — открыть https://example.com/xmlrpc.php в браузере. Сам по себе ответ сервера не доказывает, что интерфейс нужен, но если страница доступна, значит endpoint открыт для запросов.

Пошаговое решение: как отключить XML-RPC

Есть три нормальных подхода: через код, через сервер и через плагин. Для большинства сайтов достаточно кода в functions.php дочерней темы или в небольшом MU-плагине.

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

Этот способ подходит, если вы хотите контролировать поведение из темы или собственного плагина. Он не зависит от настроек хостинга и работает предсказуемо.

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

Если нужно не просто выключить XML-RPC, а вернуть 403 на сам файл, можно добавить отдельную проверку на раннем этапе загрузки:

<?php
add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        status_header( 403 );
        exit;
    }
}, 1 );

Первый вариант обычно достаточно. Второй полезен, если у вас есть дополнительные правила безопасности и вы хотите явно блокировать запросы.

Вариант 2: заблокировать доступ на уровне веб-сервера

Если цель — снизить нагрузку и отрезать запросы еще до WordPress, блокировка на уровне nginx или Apache работает быстрее. Но здесь важно не сломать другие правила сайта и не забыть про тестирование после правки конфигурации.

Для nginx можно закрыть доступ к файлу так:

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

Для Apache в .htaccess можно использовать такое правило:

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

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

Вариант 3: использовать плагин безопасности

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

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

После внедрения не ограничивайтесь тем, что «ничего не сломалось». Проверьте endpoint напрямую и посмотрите логи.

1. Откройте /xmlrpc.php в браузере или через curl.
2. Убедитесь, что ответ не содержит обычного рабочего XML-RPC-экранa WordPress.
3. Проверьте access log: новые запросы к файлу должны либо отсутствовать, либо получать отказ.
4. Если у вас есть формы входа, протестируйте обычную авторизацию в админке.

Проверка через curl выглядит так:

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

Если вы блокировали файл через сервер, ожидайте 403 или 404 в зависимости от правила. Если отключали через фильтр WordPress, поведение может отличаться, но endpoint не должен работать как раньше.

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

Отключили XML-RPC, но забыли про нужную интеграцию

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

Сделали блокировку в двух местах сразу

Например, добавили xmlrpc_enabled в код и одновременно закрыли файл на сервере. В итоге сложно понять, что именно ломает запросы. Для диагностики оставьте один способ и проверьте его отдельно.

Путают отключение XML-RPC с защитой от брутфорса

XML-RPC действительно используют для атак, но одного отключения недостаточно, если у вас слабые пароли или открыт вход в админку без ограничений. Дополнительно стоит включить ограничение попыток входа, 2FA и нормальную политику паролей.

Правят основной файл темы

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

Практические советы по безопасности и производительности

Если вы отключаете XML-RPC ради защиты, не останавливайтесь на одном endpoint. Проверьте, не остается ли открытым лишний функционал: старые авторизационные формы, слабые пароли, неиспользуемые учетные записи администратора. Для сайтов с высокой нагрузкой полезно дополнительно смотреть на логи 404 и частые POST-запросы к системным файлам.

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

Короткий чек-лист перед публикацией изменений

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

Если нужен более мягкий путь, сначала ограничьте доступ к xmlrpc.php на уровне сервера и посмотрите логи несколько дней. Если обращений нет, можно оставить жесткую блокировку. Если обращения есть, сначала найдите источник, а уже потом отключайте endpoint окончательно.