Как включить и отключить xmlrpc.php в WordPress (и почему это важно)

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

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

Что такое xmlrpc.php и как он работает

XML-RPC (Extensible Markup Language Remote Procedure Call) — это протокол, который кодирует вызовы функций в XML и передаёт их по HTTP. WordPress поставляется с полноценным XML-RPC-сервером начиная с версии 3.5, реализованным в файле xmlrpc.php, расположенном в корневом каталоге WordPress.

Когда удалённый клиент — мобильное приложение, настольный клиент для ведения блога или скрипт автоматизации — отправляет POST-запрос на https://yourdomain.com/xmlrpc.php, WordPress разбирает XML-полезную нагрузку, аутентифицирует учётные данные, встроенные в тело запроса, и выполняет запрошенный метод. Весь обмен происходит за один HTTP-цикл запрос-ответ, что является одновременно его преимуществом и фундаментальным недостатком с точки зрения безопасности.

Основные методы XML-RPC, предоставляемые WordPress

• wp.newPost / wp.editPost — удалённое создание и обновление записей
• wp.getComments / wp.deleteComment — управление комментариями
• wp.uploadFile — загрузка медиафайлов на сервер
• pingback.ping — уведомление удалённого сайта о том, что на него была добавлена ссылка
• system.multicall — объединение нескольких вызовов методов в один HTTP-запрос

Метод system.multicall особенно опасен. Один HTTP-запрос может содержать сотни вызовов wp.getUsersBlogs, каждый из которых проверяет отдельный пароль. Это позволяет злоумышленнику выполнять тысячи попыток аутентификации, генерируя при этом лишь одну запись в журнале сервера, обходя инструменты ограничения частоты запросов, которые подсчитывают отдельные запросы.

Риски безопасности при включённом xmlrpc.php

Усиление брутфорс-атак через system.multicall

Традиционные брутфорс-атаки отправляют одну пару учётных данных на каждый HTTP-запрос. С XML-RPC злоумышленник упаковывает 500 попыток входа в один запрос system.multicall. Стандартное правило fail2ban или счётчик попыток входа видит один запрос, тогда как злоумышленник получает 500 попыток угадать пароль. Это не теоретический риск — это наиболее распространённый эксплойт XML-RPC, наблюдаемый на практике.

DDoS-атаки с усилением через пингбэки

WordPress автоматически обрабатывает входящие запросы пингбэков через xmlrpc.php. Злоумышленник может отправить специально сформированный запрос pingback.ping тысячам сайтов на WordPress, заставляя каждый из них отправлять HTTP-запрос на единственный URL жертвы. Жертва получает объёмный поток запросов, исходящих от легитимных серверов WordPress, что делает блокировку по IP неэффективной. Ваш сервер одновременно становится жертвой (исчерпание ресурсов) и невольным усилителем атаки.

SSRF через пингбэк

Механизм пингбэков может быть использован для атак типа Server-Side Request Forgery (SSRF). Злоумышленник отправляет запрос pingback.ping, в котором исходный URL указывает на ресурс внутренней сети — например, http://192.168.1.1/admin. Сервер WordPress обращается к этому URL изнутри сетевого периметра, потенциально раскрывая внутренние сервисы, недоступные из публичной сети.

Передача учётных данных в открытом виде

XML-RPC передаёт учётные данные в теле POST-запроса в виде обычного текста внутри XML-конверта. Если ваш сайт не требует HTTPS, учётные данные доступны любому наблюдателю в сети. Даже при использовании TLS учётные данные встроены в каждый отдельный запрос — здесь нет сессионного токена или потока OAuth для ограничения окна уязвимости.

Когда следует оставить xmlrpc.php включённым

По умолчанию отключайте его, но оставляйте включённым, если ваш рабочий процесс действительно зависит от любого из следующего:

• Мобильное приложение WordPress (iOS/Android): Официальное приложение использует XML-RPC для всех операций управления сайтом на самостоятельно размещённых установках WordPress.
• Плагин Jetpack: Несколько модулей Jetpack — включая publicize, мобильные push-уведомления и некоторые функции статистики — взаимодействуют через XML-RPC с серверами WordPress.com.
• Настольные клиенты для ведения блога: MarsEdit, Windows Live Writer и аналогичные инструменты работают исключительно через XML-RPC API.
• Автоматизированные конвейеры публикации: IFTTT, Zapier и пользовательские скрипты, отправляющие контент в WordPress, часто используют XML-RPC, если REST API не настроен.
• Пингбэки/трекбэки между сайтами WordPress: Если межсайтовые уведомления о пингбэках являются частью вашего редакционного процесса, отключение xmlrpc.php заблокирует их.

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

xmlrpc.php и WordPress REST API

WordPress представил REST API в версии 4.7 как современную замену XML-RPC на основе токенов. Понимание различий поможет вам решить, нарушит ли отключение XML-RPC что-либо критически важное.

Если вы создаёте новую интеграцию или переносите существующую, используйте REST API. Модель аутентификации значительно более безопасна, а конечную точку гораздо проще проверять и ограничивать по частоте запросов на уровне инфраструктуры.

Как отключить xmlrpc.php в WordPress

Выберите метод, соответствующий вашему уровню доступа к серверу и допустимому риску. Методы упорядочены от наименьшего к наибольшему уровню принудительного применения на уровне сервера.

Метод 1: Отключение через плагин (быстрее всего, доступ к серверу не требуется)

Для сред с общим хостингом или сайтов, где вы предпочитаете не редактировать файлы конфигурации сервера, плагин является наиболее доступным вариантом.

Рекомендуемые плагины:

• Disable XML-RPC-API — узкоспециализированный, с минимальным объёмом кода, активируется мгновенно
• All In One WP Security and Firewall — более широкий пакет безопасности с детализированными элементами управления XML-RPC

Шаги для Disable XML-RPC-API:

1. Перейдите в раздел Плагины > Добавить новый в панели управления WordPress.
2. Найдите «Disable XML-RPC-API» и нажмите Установить, затем Активировать.
3. Дальнейшая настройка не требуется — плагин подключается к xmlrpc_enabled и немедленно возвращает false при активации.

Шаги для All In One WP Security and Firewall:

1. После активации плагина перейдите в WP Security > Firewall.
2. Найдите раздел XML-RPC.
3. Включите опцию полной блокировки XML-RPC-запросов.
4. Сохраните настройки.

Ограничение: Блокировка на основе плагина срабатывает внутри контекста выполнения PHP WordPress. Сервер всё равно запускает PHP, загружает WordPress и обрабатывает запрос перед его отклонением. При интенсивной атаке это потребляет CPU и память. Для высоконагруженных сайтов, подвергающихся активной атаке, вместо этого используйте метод .htaccess или Nginx.

Метод 2: Отключение через .htaccess (Apache — блокировка на уровне сервера)

Блокировка на уровне .htaccess предотвращает выполнение PHP для запросов, направленных на xmlrpc.php. Это значительно эффективнее при высокой нагрузке.

1. Подключитесь к серверу через FTP, SFTP или файловый менеджер хостинга и откройте файл .htaccess в корневом каталоге WordPress (обычно public_html/.htaccess).
2. Добавьте следующий блок. Разместите его перед стандартными правилами перезаписи WordPress:

# Block all access to xmlrpc.php
<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
</Files>

1. Сохраните файл.

Чтобы убедиться, что блокировка активна, выполните тест с вашего локального компьютера:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Вы должны получить ответ 403. Ответ 200 или 405 означает, что блокировка ещё не вступила в силу.

Граничный случай — если вам всё же нужны пингбэки с определённых доверенных IP-адресов, вы можете добавить их в белый список:

<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
    Allow from 192.0.2.10
</Files>

Метод 3: Отключение через конфигурацию Nginx

Если ваш сервер работает на Nginx (что характерно для сред VPS Хостинга), файлы .htaccess не имеют никакого эффекта. Добавьте блок непосредственно в конфигурацию серверного блока вашего сайта.

# Block xmlrpc.php at the Nginx level
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

Директива return 444 закрывает TCP-соединение без отправки HTTP-ответа, что эффективнее, чем 403, поскольку не позволяет клиенту злоумышленника получить какую-либо обратную связь. После редактирования перезагрузите Nginx:

sudo nginx -t && sudo systemctl reload nginx

Разместите этот блок location внутри блока server {}, перед любыми директивами try_files или обработки PHP.

Метод 4: Отключение через functions.php (хук фильтра WordPress)

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

1. Перейдите в Внешний вид > Редактор тем в панели управления WordPress или откройте файл напрямую через SFTP по пути wp-content/themes/your-theme/functions.php.
2. Добавьте следующее в конец файла:

// Disable XML-RPC completely
add_filter( 'xmlrpc_enabled', '__return_false' );

1. Сохраните файл.

Важная оговорка: Этот фильтр отключает аутентифицированные методы XML-RPC, но не блокирует метод pingback.ping и не предотвращает доступ к файлу. Сервер всё равно обрабатывает запрос вплоть до момента, когда WordPress оценивает фильтр. Для полной защиты сочетайте это с блоком .htaccess или Nginx.

Если вы используете дочернюю тему, всегда добавляйте пользовательский код в файл functions.php дочерней темы, а не родительской. Обновления родительской темы перезапишут ваши изменения.

Метод 5: Выборочное отключение — блокировка только пингбэков

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

// Disable only the pingback method, keep XML-RPC otherwise functional
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Добавьте это в файл functions.php дочерней темы или в плагин для конкретного сайта. Это рекомендуемая конфигурация для сайтов, использующих Jetpack, но не нуждающихся в получении пингбэков.

Как повторно включить xmlrpc.php

Отмена любого из вышеперечисленных методов восстанавливает доступ к XML-RPC:

• Метод плагина: Деактивируйте или удалите блокирующий плагин в разделе Плагины > Установленные плагины.
• Метод .htaccess: Удалите блок <Files "xmlrpc.php"> из файла .htaccess и сохраните.
• Метод Nginx: Удалите блок location = /xmlrpc.php из конфигурации сервера и перезагрузите Nginx с помощью sudo systemctl reload nginx.
• Метод functions.php: Удалите строку add_filter( 'xmlrpc_enabled', '__return_false' ) и сохраните.

После повторного включения убедитесь, что конечная точка отвечает корректно:

curl -s -X POST https://yourdomain.com/xmlrpc.php 
  -H "Content-Type: text/xml" 
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Корректный XML-ответ со списком доступных методов подтверждает, что конечная точка активна.

Усиление защиты xmlrpc.php без его отключения

Если отключение невозможно, примените следующие меры для уменьшения поверхности атаки:

Принудительно используйте HTTPS: Убедитесь, что ваш сайт использует действительный TLS-сертификат. Если вы ещё не сделали этого, настройте его через своего хостинг-провайдера — SSL-сертификаты предотвращают перехват учётных данных при передаче.

Ограничьте частоту запросов на уровне брандмауэра или CDN: Настройте ваш WAF (Cloudflare, ModSecurity) для ограничения POST-запросов к xmlrpc.php до максимум 5–10 в минуту на IP.

Заблокируйте system.multicall конкретно:

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

Это устраняет вектор усиления брутфорс-атак, сохраняя при этом всю остальную функциональность XML-RPC.

Ограничьте доступ по IP: Если вы обращаетесь к XML-RPC только с известных IP-адресов (диапазон IP вашего мобильного оператора или статический офисный IP), добавьте эти адреса в белый список в .htaccess или Nginx и запретите все остальные.

Отслеживайте журналы доступа: Регулярно проверяйте журналы сервера на наличие повторяющихся POST-запросов к xmlrpc.php. Резкий рост POST-запросов со статусом 200 к этому файлу является надёжным индикатором продолжающейся брутфорс-кампании.

На VPS с cPanel или другой среде с управляемой панелью вы можете настраивать правила ModSecurity непосредственно из панели управления для применения этих ограничений без ручного редактирования файлов.

Выбор подходящего метода: матрица решений

Для производственных сайтов, размещённых на выделенных серверах, блокировка на уровне сервера Nginx или Apache всегда предпочтительнее решения на основе плагина, поскольку полностью предотвращает выполнение PHP для вредоносных запросов, устраняя нагрузку на CPU, которую создаёт блокировка через плагин при продолжительных атаках.

Практический контрольный список ключевых выводов

• Перед отключением XML-RPC проверьте, действительно ли какой-либо активный плагин или сервис в вашем стеке требует его — проверьте Jetpack, мобильные приложения и любые инструменты автоматизации публикации.
• Если зависимостей нет, применяйте блокировку на уровне сервера (.htaccess или Nginx), а не плагин — это эффективнее и не зависит от деактивации плагинов.
• Если вы вынуждены оставить XML-RPC активным, безусловно удалите system.multicall и pingback.ping через фильтр xmlrpc_methods — эти два метода составляют подавляющее большинство злоупотреблений XML-RPC.
• Всегда принудительно используйте HTTPS на любом сайте WordPress, принимающем аутентифицированные запросы, включая XML-RPC.
• После применения любой блокировки убедитесь с помощью curl, что конечная точка возвращает 403 или разрывает соединение — не предполагайте, что конфигурация верна, без тестирования.
• В средах VPS или выделенных серверов на базе Nginx используйте return 444 вместо deny all, чтобы не давать злоумышленникам никакой обратной связи на уровне HTTP.
• Ведите журнал и отслеживайте POST-запросы к xmlrpc.php — внезапный всплеск является ранним предупреждением о кампании по подбору учётных данных или усилению DDoS-атак.
• Если вы управляете несколькими сайтами WordPress, рассмотрите возможность централизации этой конфигурации на уровне сервера или CDN, а не применения правил плагинов для каждого сайта отдельно.

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

Если вы настраиваете новую среду WordPress и хотите получить чистую и безопасную базовую конфигурацию с самого начала, панели управления VPS с предварительно настроенным ModSecurity обеспечивают защиту WAF на уровне сервера без необходимости создавать правила вручную.

—

Часто задаваемые вопросы

Нарушит ли отключение xmlrpc.php работу WordPress REST API?

Нет. REST API (/wp-json/) — это полностью отдельная конечная точка со своей собственной аутентификацией и маршрутизацией. Блокировка xmlrpc.php никак не влияет на функциональность REST API. Эти две системы архитектурно независимы.

Нарушит ли отключение xmlrpc.php работу Jetpack?

Это зависит от того, какие модули Jetpack вы используете. Jetpack постепенно переносит функции на REST API, но некоторые старые модули — включая определённые функции publicize и уведомлений — по-прежнему взаимодействуют через XML-RPC. Проверьте страницу отладки Jetpack в разделе Jetpack > Панель управления > Отладка, чтобы узнать, указано ли подключение XML-RPC как требование, прежде чем отключать его.

Какой метод более безопасен — .htaccess или functions.php?

Метод .htaccess значительно более безопасен в условиях атаки. Он блокирует запрос на уровне веб-сервера до загрузки PHP, потребляя минимум ресурсов. Фильтр functions.php срабатывает внутри контекста выполнения PHP WordPress, то есть сервер всё равно загружает WordPress для каждого заблокированного запроса — что дорого обходится при высокообъёмной атаке.

Может ли злоумышленник всё ещё эксплуатировать xmlrpc.php, если я отключу его только через фильтр WordPress?

Частично. Фильтр xmlrpc_enabled предотвращает аутентифицированные вызовы методов, но файл остаётся общедоступным, и сервер по-прежнему обрабатывает входящие запросы. Конечная точка пингбэков может оставаться частично функциональной в зависимости от версии WordPress. Для полной защиты сочетайте фильтр с блокировкой на уровне сервера.

Как проверить, доступен ли xmlrpc.php на моём сайте в данный момент?

Выполните следующую команду в локальном терминале, заменив домен своим:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Ответ 200 означает, что конечная точка открыта. Ответ 403 или разрыв соединения (000) подтверждает, что она заблокирована. Вы также можете использовать онлайн-инструмент на xmlrpc.eritreo.it для проверки уязвимости пингбэков конкретно.