Що таке 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 на невільного учасника атаки Distributed Denial of Service (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 — через редактор теми (швидко, але не рекомендується для продакшену):

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.

Поєднання методів для максимальної безпеки

Для найсильнішого захисту поєднайте Метод 2 (.htaccess) з Методом 3 (filter hook):

• Правило .htaccess блокує запити на рівні сервера, зменшуючи навантаження.
• Filter hook забезпечує відключення XML-RPC навіть якщо правило .htaccess коли-небудь буде обійдене або перезаписане.

Цей багатошаровий підхід дотримується принципу безпеки захист в глибину — кілька незалежних контролів, що захищають один і той же актив.

Як перевірити, що xmlrpc.php успішно вимкнено

Після застосування вибраного методу підтвердіть, що він працює:

1. Тест у браузері: Відвідайте https://yourdomain.com/xmlrpc.php. Успішна блокування показує помилку 403 Forbidden або 404 Not Found.
2. Онлайн перевірка XML-RPC: Використовуйте інструмент на кшталт xmlrpc.eritreo.it для тестування того, чи відповідає XML-RPC endpoint вашого сайту.
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, теми та плагіни в актуальному стані, регулярно моніторьте журнали доступу та вибирайте інфраструктуру хостингу, яка підтримує ваші цілі безпеки з самого початку.