Как запретить авторизацию через XML-RPC в WordPress

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

Задача здесь точечная: не ломать рабочие сценарии, но убрать именно вход через XML-RPC. Это решается на уровне WordPress-кода или веб-сервера, в зависимости от того, что вам важнее — гибкость или жёсткая блокировка.

Когда это действительно нужно

Сценарий обычно один из трёх:

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

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

Диагностика проблемы

Сначала убедитесь, что атака или нежелательные запросы действительно идут через XML-RPC. Посмотрите access log веб-сервера и найдите обращения к /xmlrpc.php. Если видите много POST-запросов с разными логинами, это типичный перебор.

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

Что проверить перед изменениями

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

Если вы не уверены, сначала ограничьте авторизацию, а не весь endpoint целиком.

Способ 1: запретить авторизацию через фильтр WordPress

Самый аккуратный вариант — оставить XML-RPC доступным, но отключить методы, которые используются для логина. Для этого подходит фильтр xmlrpc_methods. Он позволяет удалить методы wp.getUsersBlogs и похожие, которые нужны для аутентификации клиентов.

Добавьте код в functions.php дочерней темы или в небольшой mu-plugin:

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['wp.getUsersBlogs'] );
    unset( $methods['system.multicall'] );
    return $methods;
} );

Здесь есть нюанс: system.multicall часто используют для массовых попыток входа, потому что один запрос может содержать много попыток авторизации. Если убрать только wp.getUsersBlogs, часть атак всё равно будет проходить через multicall. Поэтому в большинстве случаев имеет смысл убрать оба метода.

Но если у вас есть легитимный клиент, который использует system.multicall для других задач, сначала протестируйте на staging. Не все интеграции одинаково переживают такую правку.

Способ 2: заблокировать авторизацию на уровне сервера

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

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

location = /xmlrpc.php {
    if ($request_method = POST) {
        set $block_xmlrpc_login 0;
        if ($request_body ~* "wp.getUsersBlogs|system.multicall") {
            set $block_xmlrpc_login 1;
        }
        if ($block_xmlrpc_login) {
            return 403;
        }
    }

    include fastcgi_params;
    fastcgi_pass php-fpm;
}

Этот вариант требует аккуратной проверки, потому что работа с $request_body в Nginx зависит от конфигурации и может вести себя не так, как ожидается в конкретной сборке. Если у вас нет опыта с такими правилами, безопаснее использовать WordPress-фильтр выше.

Для Apache можно идти через правила модулей, но там тоже важно не переборщить: грубая блокировка xmlrpc.php целиком часто ломает то, что потом приходится долго искать по логам.

Сравнение подходов

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

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

1. Проверьте логи и убедитесь, что атака идёт через xmlrpc.php.
2. Сделайте резервную копию файла темы или подготовьте mu-plugin.
3. Добавьте фильтр xmlrpc_methods и уберите методы авторизации.
4. Проверьте работу внешних клиентов, если они есть.
5. Посмотрите, исчезли ли попытки логина через XML-RPC в логах.

Если сайт обслуживает несколько редакторов, лучше сначала внедрить изменение на staging и только потом переносить на продакшен. Это особенно важно, если у вас есть мобильные клиенты или сторонние сервисы публикации.

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

Проверка должна быть не только визуальной. Нужны как минимум три шага.

• Отправьте тестовый запрос на /xmlrpc.php с методом wp.getUsersBlogs и убедитесь, что авторизация не проходит.
• Проверьте access log: запросы к XML-RPC должны либо исчезнуть, либо перестать доходить до успешной аутентификации.
• Если используете внешний клиент, попробуйте выполнить его обычный сценарий без логина через XML-RPC.

Для быстрой проверки можно использовать curl с XML-телом запроса. Пример ниже имитирует вызов метода авторизации:

curl -i https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data-binary @- <<'XML'
<?xml version="1.0"?>
<methodCall>
  <methodName>wp.getUsersBlogs</methodName>
  <params>
    <param><value><string>test</string></value></param>
    <param><value><string>wrong-password</string></value></param>
  </params>
</methodCall>
XML

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

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

Удалили весь xmlrpc.php без проверки

Это самая частая ошибка. После неё ломаются мобильные приложения, старые интеграции и сервисы, которые вы не успели учесть. Если нужен только запрет логина, не отключайте endpoint целиком.

Оставили system.multicall

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

Внесли правку в родительскую тему

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

Не проверили сторонние интеграции

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

Что ещё стоит сделать для защиты

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

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

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