Как отключить XML-RPC в WordPress и защитить сайт от брутфорса

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

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

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

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

Симптомы, что XML-RPC вам не нужен

• в логах регулярно появляются запросы к /xmlrpc.php;
• сайт получает много неудачных попыток входа с разных IP;
• в панели безопасности видно pingback-атаки или brute force по XML-RPC;
• вы не публикуете записи через сторонние приложения и не используете старые интеграции.

Диагностика: как понять, открыт ли XML-RPC

Самый простой тест — отправить запрос на /xmlrpc.php и посмотреть ответ. Если файл доступен, сервер обычно отвечает не 404, а страницей с сообщением WordPress или ошибкой метода. Это уже признак того, что endpoint жив.

Проверить можно и через командную строку:

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

Если вы видите 200, 405 или похожий ответ, файл доступен. Это не всегда означает уязвимость, но значит, что endpoint не закрыт.

Как отключить XML-RPC: рабочие варианты

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

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

Если нужен управляемый вариант внутри WordPress, добавьте фильтр xmlrpc_enabled. Лучше положить код в mu-plugin, чтобы он не зависел от активной темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Если у вас нет mu-plugin, можно временно добавить код в functions.php дочерней темы. Но для безопасности это хуже: при смене темы защита исчезнет.

Вариант 2: закрыть xmlrpc.php на уровне сервера

Если задача — не просто отключить функциональность, а именно не отдавать endpoint наружу, лучше блокировать запросы на уровне веб-сервера. Так вы уменьшаете нагрузку еще до загрузки WordPress.

Для nginx можно использовать отдельное правило:

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

Для Apache обычно используют правило в .htaccess:

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

Этот способ жестче, но и надежнее: WordPress даже не начнет обрабатывать запрос.

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

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

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

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

1. Проверьте, использует ли сайт мобильное приложение WordPress, Jetpack или внешнюю публикацию через XML-RPC.
2. Сделайте резервную копию или хотя бы сохраните текущий конфиг сервера и активные сниппеты.
3. Выберите один способ отключения: код, сервер или плагин. Не смешивайте все сразу без необходимости.
4. Внедрите правило и очистите кеш, если он есть на уровне плагина, CDN или сервера.
5. Проверьте ответ /xmlrpc.php и убедитесь, что легитимные интеграции не сломались.

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

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

Сетевой тест

Откройте https://example.com/xmlrpc.php в браузере или через curl. Если вы закрывали endpoint на уровне сервера, ожидайте 403 Forbidden или 404 Not Found в зависимости от правила. Если отключали через фильтр WordPress, ответ может отличаться, но попытка вызова метода должна не проходить.

Функциональный тест

Проверьте, не используете ли вы что-то из этого:

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

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

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

Отключили в теме, а потом сменили шаблон

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

Поставили плагин, но endpoint все равно отвечает

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

Сломали Jetpack или мобильную публикацию

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

Забыли очистить кеш

После правок на сервере или в плагине безопасности старый ответ может продолжать отдаваться через кеш. Очистите кеш плагина, объектный кеш и, если есть, CDN.

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

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

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

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

Для сайтов, где важна общая техническая чистка WordPress, иногда проще собрать базовую гигиену через один инструмент, чем держать десяток разрозненных правок. Но даже в этом случае проверяйте, что именно отключается, и не полагайтесь на «магическую» кнопку без теста.