Як перевірити, чи увімкнено XML-RPC на сайті
XML-RPC - це інтерфейс віддаленого керування, який іде в комплекті з WordPress, за адресою /xmlrpc.php. Він увімкнений за замовчуванням, перемикача в адмінці для нього немає, і він давно є мішенню для атак: метод system.multicall дозволяє запхати сотні спроб входу в один запит, а pingback.ping використовували, щоб спрямовувати трафік на чужі сайти. Саме тому багато хостингів і фаєрволів просто закривають цей шлях. Перевірка на цій сторінці показує стан саме вашого сервера: вона звертається до /xmlrpc.php ззовні й повертає код відповіді та кінцевий URL. Читайте цей код уважно: 405 не означає «заблоковано», це означає протилежне.
Перевірте свій сайт
-
Опитайте /xmlrpc.php ззовні
Введіть у чекер на цій сторінці повний шлях, https://ваш-сайт.com/xmlrpc.php, і запустіть перевірку. Це звичайний GET-запит із зовнішнього сервера, тобто рівно те, що бачить сканер. У відповіді важливі дві речі: HTTP-код і URL, на якому запит зрештою опинився. Беріть той самий домен, яким користуються відвідувачі, з https і правильною формою з www або без нього, інакше ви перевірите редирект, а не сам ендпойнт.
-
Прочитайте код і не сплутайте 405
405 Method Not Allowed - це нормальна відповідь живого XML-RPC у WordPress: файл на місці, він увімкнений і просто відхиляє GET, бо приймає лише POST. Більшість читає 405 як «заблоковано», і це навпаки. Код 200 разом із текстом «XML-RPC server accepts POST requests only» означає те саме, увімкнено: старіші версії WordPress відповідають так, без коду 405. 403 Forbidden означає, що шлях щось блокує: правило на сервері, плагін безпеки або WAF перед сайтом. Багато хостингів і CDN блокують його за замовчуванням, тож 403 часто означає, що робити вже нічого не треба. 404 Not Found означає, що файлу немає: або сайт не на WordPress, або файл видалили чи перейменували.
-
Подивіться на кінцевий URL, перш ніж вірити коду
Якщо кінцевий URL не той /xmlrpc.php, який ви запитували, читайте код щодо місця, куди запит потрапив, а не звідки він пішов. Редирект на головну або на сторінку входу з кодом 200 - це блокування плагіном чи правилом редиректу, а не відкритий ендпойнт. Перехід з http на https або між www і доменом без www - звичайний канонічний редирект: перезапустіть перевірку вже для кінцевого хоста. І ставтеся до 404 з обережністю, бо деякі фаєрволи навмисно віддають 404, щоб приховати ендпойнт. Код 404 доводить, що шлях не відповідає, але не завжди - що файл видалено.
-
Вирішіть, чи потрібен вам XML-RPC узагалі
Тримати його варто, лише якщо ним щось справді користується. На практиці це Jetpack, частина функцій якого досі спілкується із сайтом через XML-RPC, вхідні пінгбеки й трекбеки та старі клієнти віддаленої публікації: десктопні редактори, окремі сторонні інструменти постингу й синдикації, старі версії мобільних застосунків. Сучасні застосунки WordPress і більшість інтеграцій працюють через REST API з паролями застосунків. Якщо нічого з цього не про вас, ендпойнт не робить для вас нічого корисного, і його варто закрити. Перемикача в налаштуваннях WordPress немає: починаючи з версії 3.5 XML-RPC увімкнено за замовчуванням, а вимкнути його можна лише кодом, плагіном або правилом на сервері.
-
Вимкніть так, щоб це справді трималося
Три варіанти, від найслабшого до найнадійнішого. Плагін безпеки: майже в кожному є окремий перемикач для XML-RPC, легко відкотити, але спрацьовує він уже після завантаження WordPress. Фільтр у коді: add_filter('xmlrpc_enabled', '__return_false'); він вимикає лише методи, яким потрібен вхід, а сам файл далі відповідає, тож пінгбек-методи й відповідь 405 нікуди не зникають. Блокування шляху на сервері або на краю мережі: в .htaccess для Apache 2.4 чи LiteSpeed - <Files "xmlrpc.php"> Require all denied </Files>, у nginx - location = /xmlrpc.php { deny all; }, або правило WAF у вашого CDN на цей URI. На шаредному хостингу правило в .htaccess можна додати через файловий менеджер у панелі керування хостингом. Саме серверне правило зупиняє запит ще до запуску PHP, у цьому й сенс.
-
Перевірте, що нічого потрібного не зламалося
Після зміни зайдіть в адмінку й опублікуйте тестовий запис, а тоді перевірте те, що ви вирішили лишити. Jetpack досить швидко показує помилку зʼєднання, коли більше не може достукатися до сайту; мобільні й десктопні клієнти публікації не можуть увійти; автоматичний постинг і синдикація зазвичай припиняються тихо. Якщо ламається щось потрібне, поверніться до перемикача в плагіні або дозвольте конкретний сервіс у правилі замість того, щоб закривати шлях для всіх. Не видаляйте й не перейменовуйте сам файл xmlrpc.php: WordPress відновить його з наступним оновленням, а відсутні файли ядра ламають перевірку цілісності.
Як перевірити результат
Запустіть перевірку на цій сторінці ще раз для https://ваш-сайт.com/xmlrpc.php. Код 403 означає, що блокування працює і запит відхиляють ще до WordPress. Код 404 означає, що шлях більше не відповідає взагалі. Якщо ви й далі бачите 405 або 200 з текстом «XML-RPC server accepts POST requests only», ендпойнт лишається відкритим: або зміну зробили лише на рівні плагіна (фільтр xmlrpc_enabled за задумом лишає файл із відповіддю 405), або ваше правило потрапило не в той файл чи стоїть після іншого правила, яке вже обробило запит. Є один законний виняток: якщо ваше правило блокує тільки POST-запити, зовнішній GET і далі віддаватиме 405, а справжня перевірка - чи може ще увійти клієнт, який працює через XML-RPC.
Порада: Правило на CDN або в зовнішньому фаєрволі покриває лише той трафік, що проходить через нього. Якщо IP вашого сервера відомий, до /xmlrpc.php можна достукатися напряму, тому підстрахуйте правило на краю мережі правилом на самому сервері або обмежте доступ до сервера адресами вашого CDN. І перевірте Jetpack, перш ніж щось блокувати: частина його функцій потребує цього ендпойнта, а зʼєднання може відвалитися через кілька днів, і причину легко списати на щось інше.