15%

Збережіть 15% на всі хостинг-послуги

Перевірте свої навички і отримайте Знижку на будь-який план хостингу

Використовуй код:

Skills
Почати
01.11.2024

Що таке 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 обмежені однією спробою введення облікових даних на 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?

Перш ніж вимикати його, запитайте себе:

Випадок використанняВсе ще потребує XML-RPC?
Мобільний додаток WordPress (сучасний)❌ Ні — використовує REST API
Плагін Jetpack⚠️ Частково — перевірте документацію Jetpack
WooCommerce❌ Ні
Інтеграції IFTTT / Zapier❌ Ні — використовуйте REST API або вебхуки
Windows Live Writer / MarsEdit✅ Так — застарілі клієнти
Зворотні посилання / Пінгбеки❌ Ні — можна вимкнути окремо

Для переважної більшості власників сайтів 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 для редагування і додайте наступний блок в кінець файлу:
<Files xmlrpc.php>
    Order Allow,Deny
    Deny from all
</Files>
  1. Збережіть файл і закрийте редактор.

Щоб перевірити, що це працює, відвідайте yourdomain.com/xmlrpc.php у вашому браузері. Ви повинні отримати помилку 403 Forbidden замість стандартної відповіді XML-RPC.

Переваги: Блокування на рівні сервера більш ефективне; зменшує навантаження на сервер; не потрібен плагін.

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

> Професійна порада: Якщо ваш хостинг використовує Nginx замість Apache, додайте наступне до конфігурації блоку сервера Nginx:

>

>

location = /xmlrpc.php {
    deny all;
}

Метод 3: Вимкнення через functions.php (гак фільтра WordPress)

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

Покроково:

Варіант A — Через редактор теми (швидко, але не рекомендується для виробництва):

  1. У панелі керування WordPress перейдіть до Зовнішній вигляд → Редактор тем.
  2. Виберіть functions.php зі списку файлів з правої сторони.
  3. Додайте наступний код в кінець файлу:
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
Plugin URI: https://example.com
Description: Вимикає функціональність XML-RPC
Version: 1.0
Author: Your Name
*/

add_filter('xmlrpc_enabled', '__return_false');
?>
  1. Перейдіть до Плагіни → Встановлені плагіни у панелі керування та активуйте Disable XML-RPC.

Переваги: Чисто, незалежно від теми (при використанні методу користувацького плагіна); легко скасувати.

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

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

Для найсильнішого захисту комбінуйте метод 2 (.htaccess) з методом 3 (гак фільтра):

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

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

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

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

  1. Тест браузера: Відвідайте 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 Хостинг — Повний доступ root дозволяє вам реалізувати конфігурації безпеки на рівні сервера, включаючи користувацькі правила Nginx або Apache для блокування xmlrpc.php на рівні інфраструктури. Ідеально для розробників та зростаючих сайтів, які потребують детального контролю.
  • Спільний веб-хостинг — Економічна точка входу для сайтів WordPress з керованими конфігураціями безпеки та легким доступом до редагування .htaccess через панель керування.
15%

Збережіть 15% на всі хостинг-послуги

Перевірте свої навички і отримайте Знижку на будь-який план хостингу

Використовуй код:

Skills
Почати