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

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

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

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

Не каждый всплеск нагрузки связан именно с ним. Сначала посмотрите, что происходит на сервере и в WordPress:

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

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

Что проверить в первую очередь

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

Как отключить XML-RPC без лишних побочных эффектов

Самый простой путь — запретить доступ к xmlrpc.php на уровне WordPress. Это удобно, если у вас нет доступа к конфигу веб-сервера или вы хотите быстро проверить эффект. Для постоянной защиты лучше дополнить это правилом на уровне сервера или WAF.

Вариант 1: отключение через фильтр WordPress

Добавьте код в functions.php дочерней темы или в небольшой mu-plugin. Так вы не потеряете правку при обновлении темы.

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

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

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

Если нужен более жесткий барьер, можно закрыть файл напрямую. Для Apache это обычно делают через .htaccess:

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

Для nginx правило зависит от конфигурации, но логика та же: отдельный location для xmlrpc.php с запретом доступа. Если конфигом управляет хостинг, лучше попросить поддержку сделать это на серверной стороне.

Вариант 3: точечная защита вместо полного отключения

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

Защита входа от brute force: что делать вместе с отключением XML-RPC

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

Ограничение попыток входа

Поставьте лимит на повторные попытки авторизации. Это можно сделать плагином безопасности или на уровне WAF. Смысл простой: после нескольких неудачных попыток IP временно блокируется. Для WordPress это особенно полезно, если у вас слабые пароли у части пользователей или открытая регистрация.

Двухфакторная аутентификация

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

Скрывать логин или ограничивать доступ к wp-login.php не стоит без понимания последствий

Популярные «секретные URL для входа» часто ломают интеграции, усложняют поддержку и не решают проблему brute force как класс. Если нужен контроль доступа, лучше использовать ограничение по IP для админки, 2FA и нормальный rate limiting.

Пошаговая схема внедрения

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

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

Проверка должна быть не «страница открывается», а именно контроль поведения.

• Откройте /xmlrpc.php в браузере или через curl. При серверной блокировке вы должны увидеть отказ в доступе, а не стандартный ответ WordPress.
• Попробуйте отправить тестовый XML-RPC-запрос из внешнего клиента, если он у вас был настроен. Он должен перестать проходить.
• Посмотрите access-log: количество обращений к xmlrpc.php может остаться, но успешной обработки быть не должно.
• Проверьте вход в админку, публикацию записей, REST API и работу обычных форм авторизации.

Если после отключения перестал работать Jetpack или мобильное приложение, значит, у вас был реальный dependency. В этом случае откатите изменение и переходите к точечной блокировке по IP или к WAF-правилам.

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

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

Это нормально, если ботнет уже бьёт по wp-login.php. Тогда нужно ограничивать именно вход, а не только XML-RPC. Смотрите логи и разделяйте каналы атаки.

Сломался Jetpack или внешняя публикация

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

Поставили плагин безопасности и забыли, что он уже блокирует xmlrpc.php

В итоге вы получаете дублирующие правила и сложную диагностику. Проверьте, где именно стоит блокировка: в WordPress, в плагине, на сервере или на уровне CDN/WAF. Иначе можно искать проблему не там, где она реально находится.

Добавили код в родительскую тему

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

Что ещё имеет смысл сделать для безопасности

Если вы уже трогаете вход и XML-RPC, не ограничивайтесь одной точкой:

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

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

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