Як захистити WordPress від атак через XML-RPC

Що таке XML-RPC і чому він становить ризик

XML-RPC дозволяє зовнішнім клієнтам виконувати певні дії у WordPress через HTTP-запити до /xmlrpc.php. На відміну від звичайної роботи в адмінці, для цього не потрібно відкривати браузерний інтерфейс: запити надходять безпосередньо до endpoint.

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

Окремий ризик пов’язаний із Pingback. Якщо функція доступна й налаштована невдало, сайт можуть намагатися використати для небажаних запитів до інших ресурсів або для відбиття великої кількості трафіку. Фактичний ризик залежить від версії WordPress, конфігурації, плагінів і правил сервера.

• Масові спроби входу через XML-RPC.
• Зловживання методом system.multicall.
• Pingback-атаки та небажані вихідні запити.
• Непотрібний публічний endpoint, який складніше контролювати, ніж звичайну форму входу.

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

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

Перегляньте, як команда керує сайтом: чи використовуються мобільний застосунок, автоматична публікація, зовнішні редактори, системи кроспостингу або інструменти, що взаємодіють із WordPress саме через xmlrpc.php. Якщо ви не можете підтвердити жоден сценарій використання, вимкнення endpoint зазвичай є доцільним.

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

• Перевірте документацію активних інтеграцій і службових плагінів.
• Уточніть у розробника або хостинг-провайдера, чи є залежність від /xmlrpc.php.
• Зафіксуйте поточну конфігурацію, щоб швидко повернути зміни в разі проблем.
• Не орієнтуйтеся лише на те, що endpoint існує: важливо знати, чи є реальні запити до нього.

Як вимкнути XML-RPC у WordPress

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

Створіть файл, наприклад wp-content/mu-plugins/disable-xmlrpc.php. Якщо каталогу mu-plugins немає, його потрібно створити. Додайте в файл такий код:

<?php
/**
 * Disable XML-RPC when it is not required by the site.
 */
add_filter('xmlrpc_enabled', '__return_false');

Що робить цей фільтр

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

Важливо розуміти обмеження: код працює після того, як веб-запит уже потрапив на сервер і почав оброблятися WordPress. Він не прибирає сам файл із файлової системи та не гарантує, що запити взагалі не досягатимуть PHP. Тому для зменшення навантаження бажано додати блокування на веб-сервері або WAF.

• Не редагуйте файли ядра WordPress: оновлення можуть перезаписати зміни.
• Не додавайте код лише в тему, якщо він має діяти незалежно від зміни теми.
• Якщо інтеграція перестала працювати, тимчасово відкотіть правило та з’ясуйте, чи справді вона використовує XML-RPC.

Заблокуйте /xmlrpc.php на рівні веб-сервера або WAF

Якщо XML-RPC не потрібен зовсім, блокування на рівні веб-сервера є сильнішим заходом. Запит відхиляється до запуску WordPress, тому зменшується зайва обробка PHP і навантаження від автоматизованих сканерів.

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

<Files "xmlrpc.php">
    Require all denied
</Files>

Приклад для Nginx

У Nginx блокування зазвичай додають у конфігурацію потрібного server-блоку. Після зміни конфігурацію потрібно перевірити та коректно перезавантажити веб-сервер. На керованому хостингу доступу до цього файлу може не бути — тоді зверніться до адміністратора або використайте WAF.

location = /xmlrpc.php {
    deny all;
    return 403;
}

Що врахувати під час блокування

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

WAF може блокувати шлях /xmlrpc.php, обмежувати частоту запитів або дозволяти доступ лише з визначених IP-адрес. Повне блокування підходить, коли endpoint точно не використовується. Якщо XML-RPC потрібен окремій інтеграції, краще розглянути обмеження доступу, rate limiting і журналювання, а не безумовний deny.

• Блокуйте точний шлях /xmlrpc.php, щоб не зачепити інші ресурси.
• Після зміни перевірте код відповіді ззовні: очікуваним результатом є відмова, наприклад 403.
• Не вважайте приховування XML-RPC через robots.txt захистом: robots.txt не забороняє HTTP-запити.

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

Перевірка має складатися з двох частин: тесту доступності endpoint і перевірки функцій сайту. Запит до xmlrpc.php можна виконати з командного рядка або через інструмент моніторингу. Приклад перевіряє лише HTTP-відповідь і не виконує автентифікацію:

curl -i https://example.com/xmlrpc.php

Що вважати нормальним результатом

Після серверного блокування зазвичай очікується 403 або інша відповідь, яку визначив WAF. Якщо використано лише фільтр WordPress, endpoint може відповідати повідомленням про вимкнений XML-RPC або іншим результатом, залежно від версії та конфігурації.

Після перевірки endpoint протестуйте авторизацію в адмінці, створення і редагування запису, роботу форм, cron-завдань і всіх зовнішніх інтеграцій. Окремо перевірте Jetpack або мобільне керування, якщо вони використовуються.

Перегляньте журнали веб-сервера та WAF. Велика кількість запитів до /xmlrpc.php після блокування не означає, що захід не працює: важливо, чи доходять вони до PHP і чи створюють навантаження.

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

XML-RPC не те саме, що REST API

Вимкнення XML-RPC не блокує WordPress REST API. Це різні механізми та різні адреси: XML-RPC зазвичай працює через /xmlrpc.php, а REST API — через /wp-json/. Після застосування фільтра або правила веб-сервера запити до REST API можуть залишитися доступними.

Не намагайтеся закрити /wp-json/ лише тому, що вимикаєте XML-RPC. REST API використовується багатьма сучасними функціями WordPress, редактором, блоками, темами та інтеграціями. Його обмеження потребує окремого аналізу дозволів, публічних маршрутів і вимог конкретного сайту.

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

• XML-RPC: /xmlrpc.php.
• REST API: /wp-json/.
• Окреме блокування одного механізму не захищає автоматично інший.
• Захист від атак через XML-RPC не усуває ризики вразливих плагінів або викрадених облікових даних.

Типові помилки під час захисту XML-RPC

Найпоширеніша помилка — встановити блокування без перевірки залежностей. Через це перестають працювати автоматичні публікації або віддалене адміністрування, а причина виявляється лише після релізу.

Інша проблема — додати фільтр у файл ядра або випадковий шаблонний файл. Таке рішення може зникнути після оновлення або перестати діяти після зміни теми. Для службової логіки використовуйте MU-плагін чи окремий власний плагін.

Також не варто покладатися тільки на перейменування або видалення xmlrpc.php. Файл є частиною WordPress, а ручне втручання може бути відновлене під час оновлення та створити непередбачувані помилки. Безпечніше використовувати фільтр і контрольоване правило веб-сервера.

Нарешті, блокування XML-RPC не є повною стратегією hardening. Якщо атаки продовжуються через форми входу, REST API або вразливий плагін, потрібні додаткові правила WAF, захист облікових записів і своєчасне оновлення компонентів.

• Не перевіряти Jetpack, мобільні застосунки та зовнішні інтеграції.
• Редагувати ядро WordPress.
• Вважати robots.txt або приховування URL достатнім блокуванням.
• Забути перевірити логи та фактичне навантаження після змін.
• Плутати XML-RPC із REST API.