Захист XML-RPC у WordPress: як вимкнути зловживання без поломки інтеграцій

Чому XML-RPC може бути проблемою для WordPress

Сам XML-RPC не є вразливістю, але відкритий endpoint додає ще один канал для звернень до сайту. Якщо він доступний без обмежень, зловмисники можуть надсилати велику кількість POST-запитів і перевіряти облікові дані користувачів.

Окремий ризик пов’язаний із методом <code>system.multicall</code>, який дає змогу об’єднувати кілька XML-RPC-викликів в один HTTP-запит. Це може ускладнювати виявлення brute-force на рівні простих правил захисту.

Pingback має іншу природу: функція призначена для сповіщення сайтів про посилання, але може використовуватися для небажаних запитів і відбитих атак. Тому вимкнення pingback часто є компромісом між безпекою та сумісністю.

• XML-RPC не слід плутати з REST API WordPress: блокування одного механізму не вимикає інший.
• Велика кількість запитів до <code>/xmlrpc.php</code> не завжди означає успішну атаку, але є приводом перевірити журнали та правила захисту.
• Захист XML-RPC не замінює оновлення WordPress, складні паролі, 2FA та обмеження доступу до адміністративної частини.

Спочатку визначте, чи потрібен XML-RPC

Перед блокуванням перевірте, які сервіси підключені до сайту. Повне вимкнення може порушити публікацію або керування сайтом із мобільного застосунку, роботу Jetpack чи інтеграцію із зовнішньою системою.

Якщо сайт не використовує жоден із цих сценаріїв, повне вимкнення зазвичай є найпростішим рішенням. Для корпоративного або інтернет-магазину варто додатково перевірити всі автоматичні процеси: імпорт, публікацію, синхронізацію та резервне копіювання.

Не покладайтеся лише на припущення. Після зміни налаштувань зробіть тестову публікацію, відкрийте мобільний клієнт і перевірте інтеграції, які мають доступ до WordPress.

• Складіть список плагінів і сервісів, що взаємодіють із сайтом.
• Перевірте документацію інтеграцій: одні використовують XML-RPC, інші — REST API або власний webhook.
• За можливості спочатку протестуйте зміни на staging-копії сайту.
• Після блокування перегляньте журнали помилок і повідомлення інтеграцій.

Безпечний компроміс: вимкнення pingback

Якщо XML-RPC потрібен для легітимних інтеграцій, не обов’язково блокувати весь endpoint. Можна прибрати методи, пов’язані з pingback, залишивши інші XML-RPC-виклики доступними.

Фільтр потрібно додати у власний плагін або mu-plugin. Він вилучає небезпечні для цього сценарію методи зі списку доступних XML-RPC-команд:

<?php
/**
 * Вимкнення pingback у WordPress.
 */
add_filter('xmlrpc_methods', function ($methods) {
    unset($methods['pingback.ping']);
    unset($methods['pingback.extensions.getPingbacks']);

    return $methods;
});

Що змінює цей код

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

Це не зупиняє всі brute-force-запити до XML-RPC. Якщо endpoint продовжують активно атакувати, додайте rate limiting, правила WAF або окремий захист автентифікації.

Повне вимкнення XML-RPC

Якщо XML-RPC не використовується, його можна вимкнути на рівні WordPress за допомогою фільтра <code>xmlrpc_enabled</code>:

<?php
/**
 * Повне вимкнення XML-RPC.
 */
add_filter('xmlrpc_enabled', '__return_false');

Де розмістити код

Не додавайте захист безпосередньо у файли активної теми, якщо він має працювати незалежно від дизайну. Після зміни або оновлення теми такий код можна втратити.

Практичний варіант — mu-plugin у каталозі <code>wp-content/mu-plugins/</code>. Наприклад, створіть файл <code>xmlrpc-hardening.php</code> з PHP-кодом і переконайтеся, що каталог існує. Інший варіант — невеликий власний плагін, який не залежить від теми.

• Зробіть резервну копію перед змінами.
• Не додавайте два різні правила, якщо не розумієте їхню взаємодію.
• Після активації перевірте сайт у режимі, яким користуються редактори та інтеграції.

Захист на рівні сервера та WAF

Фільтр WordPress працює після того, як запит уже досяг PHP. Щоб зменшити навантаження, додатково використовуйте вебсервер, CDN або WAF. Найкраща тактика — обмежувати частоту POST-запитів до <code>/xmlrpc.php</code>, а не бездумно блокувати весь endpoint.

Rate limiting має враховувати реальні інтеграції. Надто суворе правило може перервати синхронізацію або публікацію, особливо якщо кілька редакторів чи сервісів працюють одночасно.

На сервері також можна дозволити доступ лише з відомих IP-адрес, якщо інтеграція має стабільні адреси. Для публічних мобільних клієнтів та сервісів такий підхід часто непридатний.

• Встановіть окреме правило для POST-запитів до <code>/xmlrpc.php</code>.
• Додайте журналювання заблокованих запитів і періодично переглядайте його.
• Не використовуйте універсальне блокування за User-Agent: його легко підробити.
• Переконайтеся, що правило не блокує внутрішні health-check або легітимну інтеграцію.
• Не редагуйте конфігурацію Nginx або Apache без резервної копії та можливості швидко відкотити зміни.

Як перевірити результат і не зламати сайт

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

Перевірку краще проводити в такій послідовності:

• Зайдіть у мобільний застосунок WordPress, якщо він використовується.
• Перевірте Jetpack та інші сервіси, підключені до сайту.
• Зробіть тестову публікацію або оновлення запису через кожну важливу інтеграцію.
• Перегляньте access log вебсервера та журнал помилок WordPress.
• Переконайтеся, що сторінки сайту, адміністративна панель і REST API працюють відповідно до очікувань.
• Якщо сервіс перестав працювати, тимчасово відкотіть правило, визначте потрібний механізм підключення і налаштуйте виняток.

Поширені помилки під час захисту XML-RPC

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

Інша помилка — вважати, що вимкнення pingback автоматично захищає від brute-force. Воно прибирає окремий клас функцій, але не замінює rate limiting і захист облікових записів.

Також не варто встановлювати кілька плагінів із дубльованими функціями без необхідності. Конфлікт фільтрів або серверних правил ускладнює діагностику, коли інтеграція перестає працювати.

• Не вставляйте PHP-код у редактор записів або сторінок.
• Не зберігайте критичний захист лише у файлах теми.
• Не блокуйте <code>/xmlrpc.php</code> наосліп, якщо сайт використовує Jetpack або мобільний клієнт.
• Не вважайте відсутність помилок на головній сторінці доказом коректної роботи інтеграцій.
• Не нехтуйте 2FA, унікальними паролями та оновленнями лише тому, що XML-RPC вимкнено.