Как отключить XML-RPC в WordPress и закрыть bruteforce-атаки

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

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

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

Сначала проверьте, есть ли у сайта реальные зависимости. XML-RPC нужен не всем, и часто его держат включённым «на всякий случай», хотя он давно не используется.

Сценарии, где отключение обычно безопасно

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

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

Диагностика проблемы: как понять, что именно атакуют

Не стоит отключать всё подряд, если проблема на самом деле в другом. Сначала посмотрите, что происходит в логах веб-сервера или в панели хостинга. Типичный признак — большое количество POST-запросов к /xmlrpc.php с разных IP и с короткими интервалами.

Если есть доступ к логам Nginx или Apache, ищите строки с этим путём. Примерно так это выглядит:

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

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

Что проверить до изменений

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

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

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

Вариант 1: отключить через `functions.php` или mu-plugin

Лучше не править активную тему, если сайт живой и тема может обновляться. Надёжнее добавить небольшой mu-plugin в wp-content/mu-plugins/ или вынести код в свой мини-плагин.

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

Этот вариант отключает сам механизм XML-RPC на уровне WordPress. Если кто-то обратится к /xmlrpc.php, WordPress не даст использовать API.

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

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

Для Nginx:

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

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

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

Если у вас управляемый хостинг, проверьте, поддерживает ли он такие правила. Иногда панель ограничивает доступ к конфигам, и тогда остаётся только фильтр WordPress или встроенная защита хостинга.

Вариант 3: ограничить, а не отключать

Иногда XML-RPC нужен точечно. Тогда лучше не держать его открытым для всех, а ограничить доступ по IP или закрыть только самые опасные методы. Это уже более тонкая настройка и имеет смысл, если вы точно понимаете, какой сервис обращается к сайту.

Для большинства сайтов это избыточно. Если нет явной зависимости, проще отключить полностью.

Что делать, если нужен Jetpack или внешняя интеграция

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

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

уберите лишние сервисы, которые больше не используются;
проверьте, можно ли перевести интеграцию на REST API;
ограничьте доступ на уровне firewall или WAF;
усильте защиту админки: сложные пароли, 2FA, ограничение попыток входа.

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

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

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

Минимальный чек-лист проверки

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

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

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

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

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

На практике проблемы возникают не из-за самого отключения, а из-за того, что его делают без проверки зависимостей.

Отключили XML-RPC и сломали Jetpack. Значит, не проверили зависимости заранее. Верните доступ и переведите интеграцию на другой способ подключения, если он доступен.
Добавили правило в .htaccess, но оно не сработало. Часто это значит, что сайт работает на Nginx или правила Apache переопределяются конфигурацией хостинга.
Отключили только в WordPress, а запросы всё равно грузят сервер. Тогда нужен запрет на уровне веб-сервера или WAF, иначе запросы будут доходить до PHP.
Проверили только в браузере. Браузерный тест недостаточен. Нужна проверка логов и реального ответа сервера.
Сделали правку в теме. После обновления тема перезапишется. Для таких задач используйте mu-plugin или отдельный плагин.

Безопасность и производительность: что ещё стоит закрыть рядом

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

Полезно проверить:

есть ли ограничение попыток входа;
включена ли двухфакторная аутентификация для администраторов;
обновлены ли ядро, тема и плагины;
не открыт ли REST API без необходимости для чувствительных данных;
не создают ли плагины лишнюю нагрузку на admin-ajax.php.

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

Что в итоге должно измениться

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

Если после изменений что-то ломается, не ищите проблему в самом факте отключения. Обычно причина в неучтённой интеграции, неверном месте правки или в том, что закрыли файл не тем способом и не на том уровне.