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

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

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

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

Отключение имеет смысл, если вы не используете:

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

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

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

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

Проверьте, есть ли обращения к xmlrpc.php в логах

Если у вас есть доступ к access.log, посмотрите, есть ли регулярные запросы к /xmlrpc.php. Для Linux-серверов это можно сделать так:

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

Если в логах видны частые POST-запросы с разных IP, это уже повод закрыть интерфейс или хотя бы ограничить доступ на уровне сервера.

Проверьте плагины и внешние сервисы

Посмотрите, не подключены ли:

• Jetpack;
• сервисы автопостинга;
• мобильные клиенты WordPress;
• интеграции с редакторами и планировщиками публикаций.

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

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

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

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

Этот вариант отключает сам XML-RPC на уровне WordPress. В большинстве случаев этого достаточно, чтобы запросы к /xmlrpc.php перестали обслуживаться.

Если нужен более жёсткий вариант

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

Для Nginx можно добавить правило в конфигурацию сайта:

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

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

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

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

Сравнение подходов: плагин, код или сервер

Если у вас есть доступ к конфигу сервера, лучше сочетать код и серверное правило. Если доступа нет — достаточно фильтра WordPress.

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

1. Проверьте, используется ли XML-RPC в текущих интеграциях.
2. Сделайте бэкап файлов и базы, либо работайте на staging-копии.
3. Добавьте add_filter( 'xmlrpc_enabled', '__return_false' ); в mu-plugin или дочернюю тему.
4. Если возможно, закройте /xmlrpc.php на уровне Nginx или Apache.
5. Проверьте, что сайт не потерял нужные подключения.
6. Посмотрите логи через 1–2 дня и убедитесь, что запросы к XML-RPC больше не проходят.

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

Проверка должна быть не формальной, а технической. Откройте в браузере https://ваш-домен/xmlrpc.php. В норме вы не должны видеть рабочий ответ XML-RPC. Если серверный блок настроен жёстко, возможен ответ 403 Forbidden. Если закрытие сделано только через WordPress, файл может отвечать, но сам XML-RPC будет отключён на уровне приложения.

Дополнительно проверьте POST-запросом. Самый простой способ — через curl:

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Если всё закрыто корректно, вы не должны получить рабочий список методов XML-RPC. В зависимости от способа блокировки ответ может быть 403, 405 или другой отказ без валидного XML-RPC-ответа.

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

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

Отключили XML-RPC, а Jetpack перестал работать

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

Закрыли xmlrpc.php на сервере, но забыли про staging

На тестовом сайте часто оставляют старые интеграции для проверки. В результате на staging всё работает, а на проде — нет. Держите одинаковую политику безопасности на обеих средах, иначе тесты теряют смысл.

Использовали плагин, который конфликтует с кешем или безопасностью

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

Оставили доступ открытым, но отключили только часть методов

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

Что ещё сделать для защиты от brute force-атак

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

• ограничение попыток входа в админку;
• сложные пароли и уникальные логины;
• 2FA для администраторов;
• защита /wp-login.php на уровне WAF или сервера;
• актуальные версии WordPress, темы и плагинов;
• отключение лишних пользователей с правами администратора.

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

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

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

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

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