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

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

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

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

Проблема не в самом файле xmlrpc.php, а в том, что он часто становится точкой входа для перебора паролей и лишней нагрузки. В отличие от обычной формы входа, здесь можно отправлять пачки запросов, а некоторые боты используют метод system.multicall, чтобы проверять много комбинаций за один HTTP-запрос.

Типичные признаки:

• в логах веб-сервера много обращений к /xmlrpc.php с кодом 200 или 403;
• в панели хостинга растёт число PHP-запросов без роста реального трафика;
• в wp-login.php и xmlrpc.php идут параллельные попытки входа;
• на слабом хостинге сайт начинает отвечать медленнее в часы атаки.

Что проверить до отключения

Сначала убедитесь, что XML-RPC вам не нужен. Он может использоваться:

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

Если сайт живёт только в админке WordPress и никаких внешних публикаций нет, отключение обычно безопасно.

Диагностика: как понять, что атака идёт именно через xmlrpc.php

Самый простой способ — посмотреть access log веб-сервера или журнал в панели хостинга. Ищите повторяющиеся запросы к /xmlrpc.php, особенно с одинаковым user-agent, короткими интервалами и большим количеством неудачных попыток.

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

# Пример поиска в access.log
# Nginx/Apache формат может отличаться, но сама идея та же
grep "xmlrpc.php" access.log | tail -n 50

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

Как отключить XML-RPC в WordPress

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

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

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

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

Код лучше разместить в mu-plugin или в отдельном мини-плагине, а не в functions.php активной темы. Тогда отключение не пропадёт при смене темы.

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

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

Для 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 нужен только для одного сервиса, полное отключение может быть слишком жёстким. Тогда можно оставить его включённым, но закрыть доступ через WAF, fail2ban или правила безопасности хостинга. Это уже не настройка WordPress, а инфраструктурное решение, и оно зависит от конкретной панели и провайдера.

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

1. Проверьте, используется ли XML-RPC в реальных сценариях: мобильное приложение, интеграции, внешняя публикация.
2. Сделайте резервную копию файлов и базы, если вносите изменения на сервере или в коде.
3. Выберите способ отключения: фильтр xmlrpc_enabled или блокировка xmlrpc.php на сервере.
4. Внедрите изменение сначала на тестовой копии сайта, если она есть.
5. Проверьте, не сломались ли авторизация, публикация и внешние сервисы.
6. Посмотрите логи после изменения: запросы к /xmlrpc.php должны либо исчезнуть, либо получать отказ без нагрузки на PHP.

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

Проверка должна быть не формальной, а практической. Откройте /xmlrpc.php в браузере или отправьте тестовый запрос. Если доступ закрыт на уровне сервера, вы увидите отказ до обработки WordPress. Если отключение сделано через фильтр, WordPress должен вернуть сообщение о том, что XML-RPC выключен.

Можно проверить и через командную строку:

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

Дальше смотрите на три вещи:

• нет ли успешных ответов 200 на XML-RPC-запросы;
• не выросло ли число ошибок 500 после изменения;
• не перестали ли работать нужные интеграции.

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

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

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

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

Спрятали проблему плагином, но не убрали нагрузку

Некоторые плагины только блокируют подозрительные запросы на уровне WordPress. Это может помочь, но PHP всё равно будет запускаться. Если атака идёт массово, серверный блок обычно эффективнее.

Добавили правило в .htaccess, а сайт на Nginx

Это типичная ошибка при копировании советов из интернета. На Nginx .htaccess не работает, и правило нужно добавлять в конфигурацию сервера или через панель хостинга.

Проверили только в браузере

Открыть xmlrpc.php в браузере недостаточно. Боты используют POST-запросы и методы XML-RPC, поэтому проверяйте именно реальный сценарий запроса и логи сервера.

Что делать для безопасности и производительности дальше

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

• ограничить число попыток входа;
• включить двухфакторную аутентификацию для админов;
• использовать актуальные версии WordPress, тем и плагинов;
• проверить права на файлы и доступ к админке;
• закрыть лишние REST-эндпоинты только если они действительно не нужны, а не «на всякий случай».

Если вы хотите убрать и другие лишние элементы WordPress, имеет смысл смотреть не только на безопасность, но и на техническую чистку сайта. Например, в Clearfy Pro есть набор настроек для удаления части служебного шума и оптимизации типовых дублей и скриптов: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверяйте, что именно отключаете, и как это влияет на ваш сайт.

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