Как защитить WordPress от атак через XML-RPC

Что такое XML-RPC и чем он опасен

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

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

Отдельный риск связан с Pingback. Если эта функция доступна и неправильно настроена, сайт могут попытаться использовать для нежелательных запросов к другим ресурсам или отражения большого объёма трафика. Фактический риск зависит от версии WordPress, конфигурации, плагинов и правил сервера.

• Массовые попытки входа через XML-RPC.
• Злоупотребление методом system.multicall.
• Pingback-атаки и нежелательные исходящие запросы.
• Ненужный публичный endpoint, который сложнее контролировать, чем обычную форму входа.

Сначала проверьте, нужен ли сайту XML-RPC

Не отключайте XML-RPC механически на рабочем сайте, если не проверены его интеграции. После блокировки могут перестать работать удалённая публикация, некоторые функции Jetpack, старые мобильные приложения WordPress или сторонние сервисы, которые отправляют записи через XML-RPC.

Проверьте, как команда управляет сайтом: используются ли мобильное приложение, автоматическая публикация, внешние редакторы, системы кросс-постинга или инструменты, взаимодействующие с WordPress именно через xmlrpc.php. Если вы не можете подтвердить ни один сценарий использования, отключение endpoint обычно оправданно.

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

• Изучите документацию активных интеграций и служебных плагинов.
• Уточните у разработчика или хостинг-провайдера, есть ли зависимость от /xmlrpc.php.
• Зафиксируйте текущую конфигурацию, чтобы быстро вернуть изменения при возникновении проблем.
• Не ориентируйтесь только на наличие endpoint: важно понять, поступают ли к нему реальные запросы.

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

Для постоянной настройки удобно использовать MU-плагин или собственный служебный плагин. MU-плагины загружаются автоматически и не зависят от переключателя активации в обычном списке плагинов.

Создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Если каталога mu-plugins нет, его необходимо создать. Добавьте в файл следующий код:

<?php
/**
 * Disable XML-RPC when it is not required by the site.
 */
add_filter('xmlrpc_enabled', '__return_false');

Что делает этот фильтр

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

Важно понимать ограничение: код выполняется после того, как веб-запрос уже поступил на сервер и WordPress начал его обрабатывать. Он не удаляет сам файл из файловой системы и не гарантирует, что запросы вообще не будут доходить до PHP. Поэтому для снижения нагрузки желательно дополнительно добавить блокировку на уровне веб-сервера или WAF.

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

Заблокируйте /xmlrpc.php на уровне веб-сервера или WAF

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

Для Apache правило можно добавить в конфигурацию виртуального хоста или в .htaccess, если хостинг поддерживает такие директивы:

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

Пример для Nginx

В Nginx блокировку обычно добавляют в конфигурацию нужного server-блока. После изменения конфигурацию необходимо проверить и корректно перезагрузить веб-сервер. На управляемом хостинге доступа к этому файлу может не быть — в таком случае обратитесь к администратору или используйте WAF.

location = /xmlrpc.php {
    deny all;
    return 403;
}

Что учитывать при блокировке

Правила веб-сервера зависят от его типа, режима работы и настроек хостинга. Неправильная директива может привести к ошибке конфигурации или не сработать из-за прокси либо CDN. Перед применением проверьте синтаксис.

WAF может блокировать путь /xmlrpc.php, ограничивать частоту запросов или разрешать доступ только с определённых IP-адресов. Полная блокировка подходит, если endpoint точно не используется. Если XML-RPC нужен отдельной интеграции, лучше рассмотреть ограничение доступа, rate limiting и журналирование, а не безусловный запрет.

• Блокируйте точный путь /xmlrpc.php, чтобы не затронуть другие ресурсы.
• После изменения проверьте код ответа извне: ожидаемый результат — отказ, например 403.
• Не считайте скрытие XML-RPC через robots.txt защитой: robots.txt не запрещает HTTP-запросы.

Как проверить результат после изменений

Проверка должна состоять из двух частей: тестирования доступности endpoint и проверки функций сайта. Запрос к xmlrpc.php можно выполнить из командной строки или через инструмент мониторинга. Пример проверяет только HTTP-ответ и не выполняет аутентификацию:

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

Какой результат считать нормальным

После блокировки на серверном уровне обычно ожидается ответ 403 или другой ответ, заданный WAF. Если использован только фильтр WordPress, endpoint может ответить сообщением об отключённом XML-RPC или другим результатом — в зависимости от версии и конфигурации.

После проверки endpoint протестируйте авторизацию в панели администратора, создание и редактирование записей, работу форм, cron-задач и всех внешних интеграций. Отдельно проверьте Jetpack или мобильное управление, если они используются.

Просмотрите журналы веб-сервера и WAF. Большое количество запросов к /xmlrpc.php после блокировки не означает, что мера не работает: важно, доходят ли они до PHP и создают ли нагрузку.

• Проверьте сайт без кеша и через внешнее подключение.
• Сравните журналы до и после блокировки.
• Следите за ошибками интеграций в течение нескольких дней после изменений.

XML-RPC — не то же самое, что REST API

Отключение XML-RPC не блокирует REST API WordPress. Это разные механизмы и разные адреса: XML-RPC обычно работает через /xmlrpc.php, а REST API — через /wp-json/. После применения фильтра или правила веб-сервера запросы к REST API могут остаться доступными.

Не пытайтесь закрыть /wp-json/ только потому, что отключаете XML-RPC. REST API используется многими современными функциями WordPress, редактором, блоками, темами и интеграциями. Его ограничение требует отдельного анализа разрешений, публичных маршрутов и требований конкретного сайта.

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

• XML-RPC: /xmlrpc.php.
• REST API: /wp-json/.
• Отдельная блокировка одного механизма автоматически не защищает другой.
• Защита от атак через XML-RPC не устраняет риски уязвимых плагинов или украденных учётных данных.

Типичные ошибки при защите XML-RPC

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

Другая проблема — добавить фильтр в файл ядра или случайный файл темы. Такое решение может исчезнуть после обновления или перестать действовать после смены темы. Для служебной логики используйте MU-плагин или отдельный собственный плагин.

Также не стоит полагаться только на переименование или удаление xmlrpc.php. Этот файл является частью WordPress, а ручные изменения могут быть восстановлены во время обновления и привести к непредсказуемым ошибкам. Безопаснее использовать фильтр и контролируемое правило веб-сервера.

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

• Не проверить Jetpack, мобильные приложения и внешние интеграции.
• Редактировать ядро WordPress.
• Считать robots.txt или скрытие URL достаточной блокировкой.
• Забыть проверить логи и фактическую нагрузку после изменений.
• Путать XML-RPC с REST API.