Файл xmlrpc.php в WordPress часто оставляют без внимания, пока в логах не появляются массовые запросы с попытками подбора паролей, pingback-спам или лишняя нагрузка на сайт. Полностью отключать его можно не всегда: у части сайтов через XML-RPC работают старые мобильные клиенты, внешние сервисы публикации и некоторые интеграции. Поэтому задача обычно не в том, чтобы «убрать файл», а в том, чтобы понять, нужен ли он вообще, и закрыть его без побочных эффектов.
Ниже — рабочая схема: как диагностировать проблему, чем лучше закрывать доступ, как проверить результат и какие ошибки встречаются чаще всего.
Когда xmlrpc.php действительно проблема
Сценарий обычно узнаётся по логам веб-сервера или по резкому росту запросов к одному и тому же URL. Если сайт небольшой, а /xmlrpc.php дергают сотни раз в минуту, это почти всегда не нормальная активность. Чаще всего атакуют метод system.multicall, потому что он позволяет упаковать много попыток входа в один HTTP-запрос.
Что смотреть в логах
Проверьте access log и обратите внимание на повторяющиеся POST-запросы к /xmlrpc.php, одинаковые user-agent, большое число ответов 200 или 403, а также всплески нагрузки на PHP-FPM. Если у вас включён fail2ban или аналогичный механизм, он тоже может показывать массовые обращения именно к этому файлу.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если сайт за Cloudflare или другим прокси, полезно смотреть не только серверные логи, но и события на уровне WAF. Иногда атака не бьёт по админке напрямую, а перегружает именно XML-RPC.
Сначала проверьте, нужен ли xmlrpc.php вашему сайту
Перед отключением не стоит действовать вслепую. Убедитесь, что вы не используете старые сценарии, завязанные на XML-RPC:
- публикация через внешние клиенты и десктопные редакторы;
- старые мобильные приложения WordPress;
- pingback и trackback, если они ещё нужны;
- интеграции сторонних сервисов, которые не перешли на REST API.
Если ничего из этого не используется, безопаснее закрыть доступ полностью. Если есть сомнения, лучше сначала ограничить запросы или запретить только опасные методы.
Диагностика: отключать или ограничивать
Для практики удобно разделить варианты на три уровня: полное отключение, блокировка отдельных методов и фильтрация на уровне сервера. У каждого подхода свой компромисс.
| Подход | Что делает | Когда подходит | Минус |
|---|---|---|---|
| Плагин | Отключает XML-RPC или часть методов | Если нужен быстрый и управляемый способ | Добавляет зависимость от плагина |
| Код в теме/му-плагине | Точечно запрещает доступ | Если нужен контроль без лишних плагинов | Нужно аккуратно тестировать |
| Конфиг сервера | Режет запросы до PHP | Если атака уже идёт и важна экономия ресурсов | Можно случайно заблокировать легитимные интеграции |
Если задача — просто убрать брутфорс и pingback-спам, обычно достаточно кода или настроек сервера. Если нужен быстрый откат и понятный интерфейс, можно использовать плагин вроде Clearfy Pro, где есть инструменты для отключения лишних функций WordPress и чистки технического мусора. Но даже в этом случае полезно понимать, что именно вы выключаете, а не просто ставить галочку.
Пошаговое решение через код
Самый предсказуемый вариант — запретить XML-RPC на уровне WordPress. Для этого лучше использовать mu-plugin, чтобы решение не зависело от темы и не исчезло после обновления.
Вариант 1: полностью отключить xmlrpc.php
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter('xmlrpc_enabled', '__return_false');Такой код отключает сам механизм XML-RPC. После этого запросы к xmlrpc.php перестанут работать как рабочий интерфейс WordPress, а не просто вернут ошибку на уровне веб-сервера.
Если вам нужно именно запретить доступ к файлу до запуска WordPress, можно закрыть его на уровне Nginx или Apache. Это полезно, когда атака создаёт лишнюю нагрузку и вы хотите отрезать её раньше.
Вариант 2: блокировать xmlrpc.php на уровне Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess или конфиге виртуального хоста:
<Files "xmlrpc.php">
Require all denied
</Files>Этот способ жёстче, чем фильтр WordPress. Он хорош, когда XML-RPC точно не нужен. Если есть интеграции, сначала протестируйте их на копии сайта.
Вариант 3: оставить XML-RPC, но запретить опасные методы
Если вы не готовы отключать всё целиком, можно ограничить только pingback и некоторые методы, которые чаще всего используют для злоупотреблений. Это не панацея, но иногда достаточно, чтобы убрать шум и не ломать старые сценарии.
<?php
add_filter('xmlrpc_methods', function ($methods) {
unset($methods['pingback.ping']);
unset($methods['pingback.extensions.getPingbacks']);
return $methods;
});Такой подход полезен, если сайт ещё получает легитимные XML-RPC-запросы, но pingback вам не нужен. Однако от brute force по логину он не защищает так же хорошо, как полное отключение.
Проверка результата после внедрения
После изменения нужно проверить не только то, что страница перестала отвечать, но и то, что сайт не потерял нужную функциональность.
- Откройте
/xmlrpc.phpв браузере или черезcurlи проверьте код ответа. - Посмотрите access log: число запросов к файлу должно снизиться или уйти в 403/404.
- Проверьте, работают ли внешние сервисы, если они у вас были подключены.
- Убедитесь, что админка и REST API не затронуты.
Простой тест через curl:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали файл на уровне сервера, ожидаемым результатом будет 403 Forbidden или 404 Not Found. Если отключали через фильтр WordPress, ответ может отличаться в зависимости от конфигурации, но сам XML-RPC должен перестать выполнять методы.
Для функциональной проверки можно отправить тестовый XML-RPC-запрос из внешнего клиента, если он у вас используется. Если клиент перестал подключаться, а вы этого не планировали, значит, блокировка слишком жёсткая.
Частые ошибки и как их исправить
Отключили XML-RPC в плагине, а атака не исчезла
Иногда запросы продолжают идти, потому что злоумышленники просто стучатся в файл, а не пытаются успешно авторизоваться. В этом случае нужно блокировать доступ на уровне сервера или WAF, а не только внутри WordPress.
Сломали публикацию из внешнего сервиса
Если вы используете старый клиент или сервис автопостинга, он может зависеть от XML-RPC. Тогда не выключайте всё сразу: сначала проверьте, какие именно методы нужны, и только потом режьте лишнее.
Отключили не там, где надо
Код в теме — плохое место для такой настройки. При смене темы защита исчезнет. Для постоянного решения используйте mu-plugin или серверный конфиг.
Путают XML-RPC и REST API
Это разные механизмы. Закрытие xmlrpc.php не должно ломать REST API, но если после изменений перестал работать редактор, мобильное приложение или интеграция, проверьте, не блокируете ли вы лишнее на уровне прокси или фаервола.
Что делать для безопасности и производительности
Если цель — не просто убрать один вектор атаки, а снизить общий шум на сайте, полезно сочетать несколько мер:
- отключить pingback и trackback, если они не нужны;
- ограничить попытки входа в админку;
- включить WAF или хотя бы базовые правила на уровне сервера;
- проверить, не создаёт ли сайт лишние запросы к PHP из-за тяжёлых плагинов;
- держать WordPress, тему и плагины в актуальном состоянии.
Если у вас уже есть плагин для технической чистки и отключения лишних функций, вроде Clearfy Pro, имеет смысл проверить, не дублирует ли он ваши серверные правила. Иногда администраторы закрывают один и тот же механизм сразу в нескольких местах, а потом не могут понять, где именно возник конфликт.
Как понять, что решение сработало
Признаки нормального результата довольно приземлённые: в логах стало меньше обращений к xmlrpc.php, нагрузка на PHP снизилась, а нужные интеграции не отвалились. Если вы закрывали файл на уровне сервера, запросы должны обрываться до запуска WordPress. Если отключали через фильтр, XML-RPC перестаёт выполнять методы, но сайт продолжает работать как обычно.
Хорошая практика — оставить заметку в конфигурации или в mu-plugin с пояснением, почему XML-RPC отключён. Через полгода это сэкономит время вам или другому администратору, когда возникнет вопрос, почему внешняя публикация больше не работает.