XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишний канал для перебора паролей, pingback-спама и шумных запросов в логах. Если сайт не использует мобильное приложение WordPress, внешние публикации через XML-RPC или старые интеграции, этот интерфейс обычно проще отключить, чем постоянно разгребать последствия.
Ниже — рабочий сценарий: как понять, нужен ли XML-RPC именно вам, как отключить его без лишнего риска и как проверить, что после изменений не отвалились нужные функции.
Когда XML-RPC действительно мешает
Проблема обычно проявляется не в админке, а на уровне трафика и безопасности. В логах появляются повторяющиеся POST-запросы к /xmlrpc.php, а сайт начинает получать сотни попыток авторизации через system.multicall. Это не всегда приводит к взлому, но создаёт лишнюю нагрузку и усложняет фильтрацию атак.
Типичные признаки
- в access-логах много запросов к
xmlrpc.phpс разных IP; - в журналах безопасности видны попытки brute force через XML-RPC;
- сайт не использует Jetpack, мобильное приложение WordPress и внешние клиенты публикации;
- pingback-атаки или мусорные уведомления о ссылках уже были на сайте;
- хостинг или WAF ругается на частые POST-запросы к одному и тому же endpoint.
Если хотя бы два пункта совпадают, отключение XML-RPC обычно оправдано. Но сначала стоит проверить, не завязаны ли на него реальные сценарии работы редакции.
Диагностика: нужен ли XML-RPC вашему сайту
Перед отключением проверьте, используется ли XML-RPC фактически. Самый простой способ — открыть https://ваш-домен/xmlrpc.php. Если интерфейс доступен, это ещё не значит, что он нужен, но endpoint активен.
Дальше проверьте рабочие сценарии:
- редакторы публикуют материалы из мобильного приложения WordPress;
- подключён Jetpack и он использует удалённые функции;
- есть внешние сервисы, которые отправляют записи через XML-RPC;
- старые интеграции с блог-платформами или CMS используют XML-RPC-публикацию.
Если ничего из этого не используется, можно отключать. Если используется только одна интеграция, лучше сначала перевести её на REST API или другой способ авторизации, а уже потом закрывать XML-RPC.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, как у вас устроен сайт. Для небольшого проекта достаточно кода в теме или mu-plugin. Если нужно закрыть доступ на уровне сервера или через плагин безопасности, это тоже рабочий путь, но важно понимать компромиссы.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
Код в functions.php или mu-plugin | Нужен точечный контроль | Прозрачно и без лишних плагинов | Нужно аккуратно обновлять тему или хранить код отдельно |
| Плагин безопасности | Уже используется security stack | Удобно для админов без доступа к коду | Ещё один плагин и зависимость от его настроек |
| Правило на сервере / WAF | Нужно резать запросы до PHP | Меньше нагрузки на сайт | Требует доступа к серверу и проверки совместимости |
Вариант 1: отключить XML-RPC через код
Если нужен понятный и управляемый способ, добавьте фильтр xmlrpc_enabled. Лучше делать это не в теме, а в небольшом mu-plugin, чтобы не потерять настройку при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Если mu-plugin не используете, можно временно добавить код в functions.php дочерней темы. Но для постоянной защиты этот вариант хуже: при смене темы защита исчезнет.
Вариант 2: заблокировать доступ к xmlrpc.php на уровне сервера
Если у вас Apache, можно закрыть файл через .htaccess. Это полезно, когда нужно не просто отключить функциональность, а вообще не отдавать endpoint.
<Files xmlrpc.php>
Require all denied
</Files>
Для Nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Такой вариант хорош тем, что запросы отсекаются до WordPress. Но если у вас есть легитимная интеграция, она перестанет работать сразу, без предупреждения.
Вариант 3: использовать плагин безопасности
Если на сайте уже стоит плагин для hardening, проверьте, умеет ли он отключать XML-RPC или блокировать xmlrpc.php. Это удобно для редакторов и администраторов без доступа к серверу, но важно не дублировать защиту в нескольких местах: потом трудно понять, что именно ломает интеграцию.
Что ещё стоит отключить вместе с XML-RPC
Если цель — снизить поверхность атаки, одного XML-RPC иногда мало. На сайтах без необходимости в pingback можно отдельно ограничить и их. Это особенно полезно, если в логах видны попытки злоупотребления уведомлениями о ссылках.
Также имеет смысл проверить:
- не открыт ли REST API для анонимных сценариев, которые вам не нужны;
- не используются ли слабые пароли у редакторов и администраторов;
- есть ли ограничение попыток входа;
- не включены ли лишние публичные endpoint'ы у старых плагинов.
Но не смешивайте всё в одну правку без теста. Сначала отключите XML-RPC, потом уже смотрите, что ещё реально нужно закрыть.
Проверка результата после внедрения
После отключения важно не ограничиться «страница открывается». Проверьте несколько уровней.
Быстрая проверка в браузере
Откройте /xmlrpc.php. При блокировке на уровне сервера вы должны увидеть отказ в доступе или пустой ответ в зависимости от конфигурации. Если отключали через фильтр WordPress, endpoint может отвечать, но XML-RPC-функции будут недоступны.
Проверка через curl
curl -I https://example.com/xmlrpc.php
Если блокировка сделана на сервере, в ответе обычно будет 403 или другой отказ. Если код отключает только XML-RPC внутри WordPress, ответ может отличаться — это нормально, важно, чтобы методы не выполнялись.
Проверка логов
Посмотрите access-лог и security-лог через 24–48 часов после изменения. Цель — убедиться, что:
- запросы к
xmlrpc.phpбольше не проходят как успешные; - не выросло число ошибок 500;
- не сломались мобильные публикации и внешние интеграции;
- нет повторяющихся попыток обхода через старые endpoint'ы.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал синхронизироваться
Jetpack в некоторых сценариях использует удалённые вызовы. Если он нужен, не режьте endpoint вслепую. Сначала проверьте, какие функции Jetpack реально используются, и тестируйте отключение на staging.
Добавили правило в .htaccess, но сайт на Nginx
Это частая причина ложного ощущения защиты. Для Nginx правила из .htaccess не работают вообще. Нужно править конфигурацию сервера или использовать фильтр WordPress.
Спрятали проблему плагином, но атаки продолжаются
Некоторые плагины отключают XML-RPC только на уровне WordPress, но не закрывают сам файл на сервере. В результате endpoint продолжает отвечать, а нагрузка и шум в логах остаются. Если нужен жёсткий запрет, блокируйте доступ до PHP.
Сломали мобильную публикацию у редакции
Если редакторы публикуют материалы с телефона, отключение XML-RPC может быть критичным. В этом случае лучше заранее перевести процесс на веб-админку или другой инструмент, а не отключать всё в рабочее время.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт защищённым, но убирает один из популярных векторов атаки. Чтобы эффект был заметнее, держите рядом ещё несколько базовых мер:
- используйте сложные пароли и двухфакторную аутентификацию для админов;
- ограничьте число попыток входа;
- обновляйте ядро, темы и плагины без задержек;
- проверяйте, не оставлены ли тестовые учётки;
- не держите лишние endpoint'ы открытыми без необходимости.
Если на сайте уже используется набор для технической чистки и SEO-оптимизации, например Clearfy Pro, проверьте его настройки hardening: иногда удобнее закрыть часть лишних функций в одном месте, чем собирать защиту из нескольких разрозненных решений. Но даже в этом случае полезно понимать, что именно отключено и где.
Главная идея простая: если XML-RPC не нужен, лучше убрать его осознанно и проверить последствия, чем оставлять открытым только потому, что «так было изначально».