Что такое xmlrpc.php в WordPress и как его отключить (полное руководство 2024)

WordPress питает более 43% всех веб-сайтов в интернете — и с этим доминированием приходит значительная поверхность атаки. Одной из наиболее часто используемых точек входа является файл под названием xmlrpc.php. Независимо от того, являетесь ли вы опытным разработчиком или владельцем сайта, управляющим своей первой установкой WordPress, понимание того, что делает этот файл, почему он опасен и как его отключить, критически важно для безопасности вашего сайта.

Это руководство охватывает все, что вам нужно знать о xmlrpc.php: его назначение, реальные угрозы, которые он представляет, и три проверенных метода его отключения — без необходимости в техническом образовании.

Что такое xmlrpc.php в WordPress?

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

Введенный задолго до появления WordPress REST API, xmlrpc.php был основным мостом между WordPress и внешним миром. Он обеспечивал:

• Удаленную публикацию контента — Клиенты блогов, такие как Windows Live Writer или MarsEdit, могли публиковать статьи непосредственно на ваш сайт.
• Управление мобильными приложениями — Официальное мобильное приложение WordPress исторически полагалось на XML-RPC для управления постами, страницами и комментариями.
• Обратные ссылки и пингбеки — Протокол обрабатывает межсайтовые уведомления, оповещая другие блоги, когда вы ссылаетесь на их контент.
• Интеграции третьих сторон — Сервисы, такие как IFTTT, Zapier (в старых конфигурациях) и различные плагины, использовали XML-RPC для программного взаимодействия с WordPress.

Хотя эти функции были действительно полезны в начале 2010-х годов, WordPress с тех пор представил REST API, который обеспечивает более безопасный, современный и гибкий способ достижения тех же результатов. В результате xmlrpc.php теперь в значительной степени устарел — но он остается активным по умолчанию на каждой установке WordPress.

Почему xmlrpc.php является угрозой безопасности?

Проблема с xmlrpc.php заключается не в самом протоколе — это то, что файл остается включенным даже когда вы его не используете, создавая ненужный вектор атаки. Исследователи безопасности и хостинг-провайдеры постоянно отмечают его как одну из главных уязвимостей WordPress. Вот почему:

1. Атаки усиления перебора

Это наиболее опасная и широко используемая угроза. Стандартные атаки перебора против страницы входа WordPress (wp-login.php) ограничены одной попыткой учетных данных на HTTP-запрос. XML-RPC кардинально это меняет.

Метод system.multicall в XML-RPC позволяет злоумышленнику объединить сотни или даже тысячи комбинаций имени пользователя/пароля в один HTTP-запрос. Это означает:

• Традиционные плагины ограничения частоты и попыток входа обходятся.
• Злоумышленники могут проверить огромные списки учетных данных с минимальной пропускной способностью.
• Журналы сервера показывают намного меньше запросов, что затрудняет обнаружение.

Одна ботнет может скомпрометировать сайт WordPress со слабым паролем за минуты, используя эту технику.

2. Усиление DDoS через пингбеки

Злоумышленники могут использовать функциональность пингбека в xmlrpc.php, чтобы превратить ваш сайт WordPress в невольного участника атаки распределенного отказа в обслуживании (DDoS). Отправив специально созданный запрос пингбека, злоумышленник может инструктировать ваш сервер отправлять HTTP-запросы на целевой URL — фактически используя ресурсы вашего сервера и репутацию IP против третьей стороны.

Это не только наносит вред цели атаки, но также может привести к занесению IP-адреса вашего сервера в черный список, что повлияет на доставляемость и репутацию вашего сайта.

3. Истощение ресурсов сервера

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

4. Ненужное раскрытие

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

Вам действительно нужен xmlrpc.php?

Перед отключением спросите себя:

Для подавляющего большинства владельцев сайтов WordPress ответ: вам это не нужно. Отключите это.

Как отключить xmlrpc.php в WordPress: 3 способа

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

Способ 1: Использование плагина безопасности WordPress (самый простой)

Если вам нужно решение без кода с минимальным риском что-то сломать, плагин безопасности — ваша лучшая отправная точка.

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

• Wordfence Security — комплексный брандмауэр и сканер вредоносов с блокировкой XML-RPC.
• iThemes Security (теперь Solid Security) — специальный переключатель для отключения XML-RPC.
• Disable XML-RPC — легкий плагин с одной функцией, который делает ровно то, что обещает.

Пошаговая инструкция:

1. Войдите в панель администратора WordPress.
2. Перейдите в Плагины → Добавить новый.
3. Найдите выбранный плагин (например, “Disable XML-RPC”) и нажмите Установить, затем Активировать.
4. Перейдите на страницу настроек плагина. Для специализированных плагинов безопасности, таких как Wordfence или iThemes Security, найдите раздел с названием XML-RPC или WordPress Tweaks.
5. Включите опцию отключить XML-RPC или блокировать запросы XML-RPC.
6. Сохраните изменения.

Преимущества: просто, обратимо, не требует редактирования файлов.

Недостатки: добавляет зависимость от плагина; файл все еще существует на сервере (запросы блокируются на уровне приложения, а не на уровне сервера).

Способ 2: Блокировка xmlrpc.php через .htaccess (рекомендуется для серверов Apache)

Для хостинга на базе Apache редактирование файла .htaccess блокирует запросы на уровне веб-сервера — еще до загрузки WordPress. Это более эффективно и обеспечивает более сильную защиту, чем плагин один.

Пошаговая инструкция:

1. Получите доступ к файлам вашего сайта через FTP (используя FileZilla или аналогичное) или через Файловый менеджер панели управления хостингом.
2. Перейдите в корневой каталог WordPress — обычно это public_html или www.
3. Найдите файл .htaccess. Если вы его не видите, включите отображение скрытых файлов в FTP-клиенте (в FileZilla: Server → Force Showing Hidden Files) или в настройках файлового менеджера.
4. Откройте .htaccess для редактирования и добавьте следующий блок в конец файла:

# Block WordPress xmlrpc.php
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

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

Чтобы проверить, работает ли это, посетите https://yourdomain.com/xmlrpc.php в браузере. Вы должны получить ошибку 403 Forbidden вместо стандартного ответа XML-RPC.

Преимущества: блокировка на уровне сервера более эффективна; снижает нагрузку на сервер; не требует плагина.

Недостатки: требует доступа к файлам; неправильное редактирование .htaccess может временно сломать сайт (всегда делайте резервную копию).

> Совет профессионала: если ваш хостинг использует Nginx вместо Apache, добавьте следующее в конфигурацию блока сервера Nginx:

>

> “`nginx

> location = /xmlrpc.php {

> deny all;

> access_log off;

> log_not_found off;

> }

> “`

Способ 3: Отключение через functions.php (фильтр WordPress)

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

Пошаговая инструкция:

Вариант A — через редактор темы (быстро, но не рекомендуется для production):

1. В панели управления WordPress перейдите в Внешний вид → Редактор тем.
2. Выберите functions.php из списка файлов справа.
3. Добавьте следующий код в конец файла:

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

1. Нажмите Обновить файл для сохранения.

Вариант B — через пользовательский плагин (рекомендуется):

Вместо редактирования functions.php вашей темы (который перезаписывается при обновлении темы), создайте простой пользовательский плагин:

1. Используя FTP или Файловый менеджер, перейдите в wp-content/plugins/.
2. Создайте новую папку с названием disable-xmlrpc.
3. Внутри этой папки создайте файл с названием disable-xmlrpc.php со следующим содержимым:

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Disables XML-RPC functionality for improved security.
 * Version: 1.0
 * Author: Your Name
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

1. Перейдите в Плагины → Установленные плагины в панели управления и активируйте Disable XML-RPC.

Преимущества: чистое решение, независимое от темы (при использовании метода пользовательского плагина); легко отменить.

Недостатки: только на уровне приложения — файл все еще существует и может получать запросы (хотя они будут отклонены); не снижает нагрузку на сервер так эффективно, как блокировка через .htaccess.

Комбинирование методов для максимальной безопасности

Для наиболее надежной защиты комбинируйте Method 2 (.htaccess) с Method 3 (filter hook):

• Правило .htaccess блокирует запросы на уровне сервера, снижая нагрузку.
• Filter hook гарантирует отключение XML-RPC даже если правило .htaccess когда-либо будет обойдено или перезаписано.

Такой многоуровневый подход следует принципу безопасности defense in depth — несколько независимых средств защиты одного и того же ресурса.

Как проверить, что xmlrpc.php успешно отключен

После применения выбранного метода подтвердите, что он работает:

1. Тест в браузере: Посетите https://yourdomain.com/xmlrpc.php. Успешная блокировка показывает ошибку 403 Forbidden или 404 Not Found.
2. Онлайн-проверка XML-RPC: Используйте инструмент, например xmlrpc.eritreo.it, чтобы проверить, отвечает ли конечная точка XML-RPC вашего сайта.
3. Логи сервера: Проверьте логи доступа на наличие оставшихся запросов к xmlrpc.php — резкое снижение подтверждает, что блокировка работает.

Выбор правильного хостинга для безопасности WordPress

Отключение xmlrpc.php — это только один уровень безопасности WordPress. Основа безопасного сайта WordPress начинается с выбора правильного хостинг-провайдера — того, который предлагает элементы управления безопасностью на уровне сервера, регулярные резервные копии и инфраструктуру, разработанную для противостояния атакам.

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

• VPS Hosting — Полный root-доступ позволяет вам реализовать конфигурации безопасности на уровне сервера, включая пользовательские правила Nginx или Apache для блокировки xmlrpc.php на уровне инфраструктуры. Идеально подходит для разработчиков и растущих сайтов, которым требуется детальный контроль.

• Shared Web Hosting — Экономичная точка входа для сайтов WordPress с управляемыми конфигурациями безопасности и легким доступом к редактированию .htaccess через панель управления.

• VPS с cPanel — Объединяет мощь виртуального выделенного сервера со знакомым интерфейсом cPanel, что упрощает управление файлами .htaccess, SSL-сертификатами и параметрами безопасности без опыта работы с командной строкой.

• SSL Certificates — Шифрование вашего сайта с помощью HTTPS — это обязательный базовый уровень безопасности. SSL-сертификат гарантирует, что даже если выполняются XML-RPC запросы, учетные данные и передаваемые данные зашифрованы при передаче.

• Domain Registration — Держите свой домен и хостинг в одном месте для упрощенного управления DNS и снижения поверхности атаки от уязвимостей сторонних регистраторов.

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

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

Сломает ли отключение xmlrpc.php мой сайт WordPress?

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

Требует ли Jetpack xmlrpc.php?

Старые версии Jetpack полагались на XML-RPC. Современные версии Jetpack в основном используют WordPress.com REST API. Перед отключением XML-RPC проверьте документацию вашей конкретной версии Jetpack.

Могу ли я просто отключить pingback вместо всего XML-RPC?

Да. Если вы хотите сохранить XML-RPC активным для других целей, но устранить злоупотребление pingback, добавьте это в ваш functions.php:

// Disable pingbacks only
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

Удален ли xmlrpc.php в новых версиях WordPress?

Нет. По состоянию на последние выпуски WordPress, xmlrpc.php все еще включен и включен по умолчанию. Команда ядра WordPress обсуждала его будущее, но он остается для обратной совместимости.

Заключение

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

Для повторения ваших вариантов:

Применяйте метод, который подходит вашей среде, проверьте, что блокировка работает, и дополните её надёжной основой хостинга. Безопасность — это не одноразовое действие, это постоянная практика. Держите ядро WordPress, темы и плагины в актуальном состоянии, регулярно мониторьте логи доступа и выбирайте инфраструктуру хостинга, которая поддерживает ваши цели безопасности с самого начала.