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

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

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

Когда XML-RPC можно отключать, а когда лучше не трогать

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

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

• Вы заходите в админку только через браузер.
• Публикация идет напрямую из WordPress, без сторонних десктоп-клиентов.
• Мобильное приложение WordPress не используется.
• Нет старых интеграций, которые обращаются к xmlrpc.php.

Сценарии, где нужно сначала проверить интеграции

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

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

Самый простой признак — большое количество запросов к /xmlrpc.php в логах веб-сервера. Часто это не один IP, а автоматизированный перебор с разных адресов. Еще один симптом — лишняя нагрузка на PHP без заметного роста обычного трафика.

Если есть доступ к access log, проверьте обращения к этому файлу. Пример для Nginx:

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

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

Можно также проверить, отвечает ли файл сейчас:

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

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

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

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

Способ	Когда подходит	Плюс	Минус
Плагин	Нужен быстрый способ без правки кода	Легко включить и отключить	Добавляет еще один слой управления
Код в теме или mu-plugin	Есть доступ к файлам сайта	Контроль без лишних плагинов	Нужно аккуратно обновлять и не потерять правку
Правило на сервере	Есть доступ к Nginx/Apache	Блокирует запрос раньше PHP	Требует доступа к конфигу и понимания окружения

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

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

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

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

Если хотите не просто отключить, а еще и отдать ошибку при прямом обращении, можно дополнительно закрыть сам endpoint через init:

<?php
add_action( 'init', function () {
	if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
		wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
	}
} );

На практике первого варианта обычно достаточно. Второй полезен, если вы хотите явно завершать такие запросы с кодом 403.

Вариант 2: закрыть xmlrpc.php на уровне Nginx

Если у вас Nginx, блокировка на сервере экономит ресурсы: запрос не доходит до PHP вообще. Это особенно полезно при брутфорсе.

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

После изменения конфигурации проверьте синтаксис и перезагрузите Nginx штатным способом для вашего сервера. Если вы используете Apache, аналогичный эффект можно получить через правила .htaccess, но на практике это зависит от конфигурации хостинга.

Вариант 3: использовать плагин, если нужен быстрый откат

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

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

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

Проверка должна быть не «на глаз», а через конкретный ответ сервера. После внедрения откройте https://example.com/xmlrpc.php или выполните запрос через curl.

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

Что считать нормальным результатом:

• если XML-RPC отключен через WordPress-код, вы не должны получать рабочий ответ метода;
• если блокировка сделана на сервере, ожидаем 403 Forbidden или аналогичный отказ;
• в логах после этого не должно быть успешной обработки XML-RPC-запросов.

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

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

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

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

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

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

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

Даже если WordPress внутри не обрабатывает XML-RPC, сам endpoint может продолжать принимать запросы и создавать лишнюю нагрузку. Если атака идет массово, лучше закрыть его еще и на уровне Nginx или Apache.

Поставили плагин, который делает слишком много

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

Чек-лист перед и после отключения

• Проверить, используется ли мобильное приложение WordPress.
• Проверить внешние сервисы публикации и автопостинга.
• Посмотреть access log на обращения к /xmlrpc.php.
• Выбрать один способ блокировки: код, сервер или плагин.
• После изменений проверить ответ curl -i https://example.com/xmlrpc.php.
• Убедиться, что обычная авторизация и публикация в админке работают как раньше.
• Посмотреть логи еще раз через несколько часов или дней, если атаки были активными.

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

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

Для производительности важно еще и то, где именно вы блокируете запрос. На уровне WordPress это проще, но при массовых атаках выгоднее закрывать endpoint на веб-сервере, чтобы не тратить ресурсы PHP и базы данных на заведомо лишние обращения.

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