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

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

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

Когда XML-RPC действительно стоит отключить

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

Сценарии, где он чаще всего не нужен

• редакторы работают только через /wp-admin/;
• нет внешних сервисов, которые публикуют записи через XML-RPC;
• не используется старое мобильное приложение WordPress;
• не подключены сервисы автопостинга, завязанные именно на XML-RPC, а не на REST API.

Когда отключать нельзя без проверки

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

Диагностика: как понять, используется ли xmlrpc.php

Перед изменениями стоит посмотреть не только на настройки, но и на фактические обращения к файлу. Самый простой способ — логи веб-сервера и проверка ответов сервера.

Что искать в логах

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

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

На Apache путь к логу может отличаться, но логика та же: ищете частоту запросов, источник и код ответа. Если там постоянно 200 или 403 на фоне большого числа попыток, это уже полезный сигнал для решения.

Проверка ответа сервера

Если открыть /xmlrpc.php в браузере, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не значит, что интерфейс безопасен. Для проверки лучше использовать curl:

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

Если вы уже отключили XML-RPC, ожидаемое поведение зависит от способа блокировки: это может быть 403 Forbidden, 404 Not Found или ответ от WordPress с ошибкой доступа. Важно не конкретное число, а то, что endpoint перестал принимать рабочие запросы.

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

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

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

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

add_filter( 'xmlrpc_enabled', '__return_false' );

Лучше размещать такой код не в основной теме, а в небольшом mu-plugin или в отдельном плагине для технических настроек. Тогда отключение не исчезнет после смены темы.

Вариант 2: заблокировать на уровне nginx

Если сервер на nginx, можно отрезать доступ к файлу ещё до WordPress. Это полезно, когда атаки идут массово и вы хотите снизить лишнюю нагрузку.

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

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

Вариант 3: блокировка через .htaccess

На Apache можно закрыть доступ к xmlrpc.php через правила в .htaccess. Это не лучший вариант для высоконагруженных сайтов, но для типового хостинга работает нормально.

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

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

Пошаговое решение без лишнего риска

Если задача — отключить XML-RPC и не сломать интеграции, удобнее идти коротким маршрутом.

1. Проверьте логи и убедитесь, что через xmlrpc.php не ходят нужные сервисы.
2. Сделайте резервную копию конфигурации сервера или файла functions.php.
3. Выберите способ блокировки: код, nginx, Apache или плагин безопасности.
4. Внесите изменение только на одном сайте или в staging-окружении, если оно есть.
5. Проверьте ответ /xmlrpc.php через браузер и curl.
6. Посмотрите логи ещё раз: запросы должны либо исчезнуть, либо получать отказ.

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

Проверка должна быть не формальной, а практической. Недостаточно просто увидеть, что страница открывается иначе.

• Откройте https://ваш-домен/xmlrpc.php в браузере — доступ должен быть ограничен.
• Выполните curl -I https://ваш-домен/xmlrpc.php и проверьте код ответа.
• Посмотрите access-лог через 10–15 минут после изменения: новые обращения должны получать отказ.
• Если у вас был внешний сервис публикации, протестируйте его отдельно.

Если вы отключали XML-RPC через фильтр WordPress, а запросы всё равно доходят до PHP, значит блокировка слишком поздняя. В этом случае лучше перенести ограничение на уровень nginx или Apache.

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

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

Такое бывает, когда сайт использует старый сервис автопубликации или мобильный клиент. Симптом простой: внешняя система перестаёт отправлять записи, а в логах видны ошибки авторизации. Решение — либо вернуть XML-RPC, либо перевести интеграцию на REST API, если это поддерживается.

Добавили код в активную тему

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

Сделали блокировку только в WordPress

Фильтр xmlrpc_enabled отключает функциональность на уровне CMS, но сам запрос всё равно доходит до PHP. При атаке это лишняя нагрузка. Если у вас уже есть всплеск обращений, лучше закрыть endpoint на веб-сервере.

Сломали правила в .htaccess

На shared-хостингах часто встречается смешение старого и нового синтаксиса Apache. Если после правки сайт начал отдавать 500 ошибку, первым делом верните резервную копию файла и проверьте, поддерживает ли сервер директиву Require all denied.

Что делать для безопасности и производительности дальше

Отключение XML-RPC не заменяет нормальную защиту входа в админку. Если на сайт идут брутфорс-атаки, стоит дополнительно проверить:

• наличие двухфакторной аутентификации для администраторов;
• ограничение попыток входа;
• актуальность ядра, тем и плагинов;
• отсутствие лишних плагинов, которые тоже принимают внешние запросы;
• логи 403/401 на предмет повторяющихся IP и user-agent.

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

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