Как отключить XML-RPC и защитить WordPress от brute force без поломки нужных интеграций

XML-RPC в WordPress часто отключают «на всякий случай», а потом удивляются, почему перестали работать мобильное приложение, внешние публикации или старые интеграции. На практике задача не в том, чтобы просто закрыть xmlrpc.php, а в том, чтобы понять, нужен ли он вообще, и если нужен — ограничить риск brute force и массовых запросов.

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

Когда XML-RPC реально проблема

Файл xmlrpc.php сам по себе не «дыра», но он часто используется для перебора паролей и для лишней нагрузки на сайт. Особенно это заметно на проектах, где:

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

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

Диагностика: используется ли XML-RPC сейчас

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

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

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

Если у вас есть доступ к серверу, можно быстро проверить, отвечает ли endpoint:

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

Ответ 200 или 405 сам по себе ещё не означает проблему, но подтверждает, что endpoint доступен извне.

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

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

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

Добавьте в functions.php дочерней темы или в собственный мини-плагин:

add_filter( 'xmlrpc_enabled', '__return_false' );

Это отключает XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно.

Если нужно не просто отключить функциональность, а вернуть 403 на сам файл, можно добавить правило на уровне сервера. Для Nginx это обычно делают так:

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

Для Apache можно использовать правило в .htaccess:

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

Серверное ограничение полезно, если вы хотите отсечь лишние запросы ещё до загрузки WordPress.

Вариант 2: отключить через плагин

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

Если XML-RPC нужен частично: как снизить риск

Иногда отключать его полностью нельзя. Например, если у вас есть рабочая интеграция, которую пока не успели перенести. В таком случае лучше не оставлять всё как есть, а ограничить поверхность атаки.

• закройте доступ к xmlrpc.php на уровне WAF или сервера, если интеграция идёт с фиксированных IP;
• проверьте, можно ли заменить XML-RPC на REST API или прямую авторизацию через OAuth/ключи сервиса;
• убедитесь, что у администраторов включены сложные пароли и 2FA;
• ограничьте попытки входа и следите за логами авторизации.

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

Проверка результата после внедрения

После отключения обязательно проверьте не только сам endpoint, но и реальные сценарии сайта.

Чек-лист проверки

• открывается ли /xmlrpc.php в браузере или через curl;
• не сломалась ли публикация из мобильного приложения WordPress;
• работают ли внешние сервисы, которые вы используете для автопостинга или синхронизации;
• нет ли новых ошибок в логах веб-сервера;
• не выросло ли число 403/405 ответов на стороне WAF или CDN.

Если вы отключали XML-RPC через фильтр, можно проверить поведение так:

curl -X POST https://example.com/xmlrpc.php -d '<methodCall><methodName>system.listMethods</methodName></methodCall>'

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

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

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

Такое случается, когда сайт давно работает, а список подключений никто не документировал. Решение простое: сначала инвентаризация, потом отключение. Если интеграция критична, ищите замену или ограничивайте доступ по IP.

Поставили плагин, который блокирует не только XML-RPC

Некоторые плагины безопасности меняют сразу несколько механизмов. После установки проверьте, не затронуты ли REST API, авторизация в админке и кэширование. Если поведение стало странным, вернитесь к точечному решению через код.

Закрыли файл на сервере, но забыли очистить кеш и проверить CDN

Иногда старый ответ продолжает отдаваться через кеширующий слой или CDN. После изменения правил очистите кеш на сервере, в плагине и на стороне CDN, если он есть.

Сделали запрет через .htaccess, но сайт на Nginx

Это банальная, но частая ошибка. Для Nginx .htaccess не работает вообще. Если сервер другой, правило нужно писать в его конфиге или использовать WordPress-фильтр.

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

Если цель — не просто отключить один файл, а уменьшить риск brute force и лишнюю нагрузку, полезно сделать ещё несколько вещей:

• включить двухфакторную аутентификацию для администраторов;
• ограничить число попыток входа;
• обновить ядро, темы и плагины;
• проверить, не торчит ли лишняя админка в публичном доступе;
• посмотреть, не создаёт ли сам сайт много бесполезных запросов к xmlrpc.php через сторонние сервисы.

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

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