xmlrpc.php в корне WordPress выглядит безобидно: это старый служебный интерфейс, через который сайт когда-то принимал публикации из внешних программ. Если он отвечает из интернета, у злоумышленника появляется второй вход рядом с wp-login.php. Сам по себе открытый файл пароль не выдаёт. Он даёт канал, по которому пароль можно проверять пачками, а сайт — заставлять обращаться туда, куда его попросили.Ниже — почему находка «xmlrpc.php доступен» стоит в критическом приоритете, чем она отличается от уже взломанного сайта и что делать, если мобильное приложение или Jetpack этим файлом ещё пользуются.
Что это за файл
XML-RPC — протокол удалённого вызова процедур. Клиент отправляет на сервер имя метода и аргументы, сервер отвечает результатом или ошибкой. В WordPress точкой входа исторически стал xmlrpc.php. Через него работали десктопные редакторы, некоторые мобильные приложения и связка с WordPress.com.
С появлением REST API (/wp-json/) этот канал почти никому из обычных посетителей не нужен. Файл при этом остаётся в ядре и по умолчанию включён. Пока его не закрыли на сервере, в плагине или на reverse proxy, любой адрес в интернете может отправить на него запрос.
Важная граница: открытый XML-RPC — это не уязвимость вида «выполнить код без пароля». Свежий WordPress не отдаёт через этот файл содержимое wp-config.php и не пускает в админку гостя. Находка сканера означает другое: интерфейс аутентификации и несколько служебных методов доступны снаружи так же, как форма входа.
xmlrpc.php сам по себе сайт не отдаёт. Он упрощает то, что и так пытаются делать на wp-login.php: проверять пароли. Плюс добавляет эффекты, которых у обычной формы входа нет.Как сканер понимает, что доступ открыт
Стандартный скан TrafficVeil не ломает сайт и не отправляет в xmlrpc.php вызовы методов. Проверка безопасная и внешняя: один GET на https://домен/xmlrpc.php.
Файл считается доступным только если совпали два условия. Код ответа — 200 или 405. В теле есть маркер xml-rpc или xmlrpc. Именно так живой WordPress отвечает на GET: метод не тот, запросы он принимает иначе, но сам текст подтверждает, что точка включена. Ответ 403 или 404 сканер открытым доступом не считает.
В отчёте это отдельная строка поверхности WordPress: «Включён» или «Не подтверждён». Если включён, появляется находка «xmlrpc.php доступен» с приоритетом critical и действием block_xmlrpc. На тарифе Starter и выше это действие можно применить из отчёта: правило режет путь на edge, после чего сканер повторяет тот же публичный GET и ставит проверку пройденной только если поверхность исчезла.
На Free этого правила нет. Сканер находку покажет, закрытие XML-RPC в кабинете начнётся со Starter, где есть профиль WordPress.
Что злоумышленник получает от открытого файла
Дальше — классы злоупотребления. Имена методов и последствия, без запросов и без порядка аргументов. Этого достаточно, чтобы понять находку в отчёте. Этого недостаточно, чтобы повторить атаку.
Проверка паролей пачками
Обычная форма wp-login.php принимает одну пару «логин и пароль» на один HTTP-запрос. Лимит запросов в секунду с одного IP такую атаку замедляет: каждая попытка — отдельное соединение.
У XML-RPC есть метод, который принимает внутри одного HTTP-запроса много вложенных вызовов. В каждый вложенный вызов кладётся очередная попытка входа. Снаружи это выглядит как один запрос к одному URL. Внутри WordPress проверяет десятки и сотни паролей. Лимит «N запросов в минуту» почти не мешает, потому что считает запросы, а не вложенные попытки.
Именно поэтому находка критическая, хотя файл не является дырой в коде. Канал обходит смысл простого rate limit на границе. Закрывать нужно сам URL, а не только частоту обращений к нему.
Пароли обычно берут не «с нуля», а из уже утёкших баз: один и тот же пароль часто стоит и на почте, и в админке. XML-RPC в этой схеме — дешёвый способ прогнать базу по конкретному WordPress.
Отличие «нет такого пользователя» от «не тот пароль»
Форма входа и XML-RPC по-разному ошибаются, когда логина не существует и когда логин есть, а пароль нет. По характеру ошибки можно собрать список настоящих учётных записей и уже по нему гонять пароли. Это не чтение базы пользователей целиком. Это сужение перебора.
Рядом сканер отдельно проверяет более прямую утечку логинов: открытый REST /wp-json/wp/v2/users и параметр ?author=1. Если XML-RPC открыт и логины уже лежат в REST, перебор начинается не с пустого места. Эти находки в отчёте стоят рядом не случайно. Закрывать лучше обе.
Успешный подбор — это уже доступ
Если пара логин/пароль подошла, интерфейс XML-RPC отвечает так же, как ответил бы легитимной программе-редактору. Для учётной записи с правом публиковать или править записи это возможность создавать и менять содержимое сайта. Для администратора набор доступных методов шире: злоумышленник действует от имени этой учётной записи, не открывая браузерную админку.
Дальше сценарий обычный для угнанной админки: новая учётка, правка темы или плагина, подмена контента. Сканер на этапе «файл отвечает» этого не видит: он видит только открытую дверь.
Pingback: сайт заставляют сходить по чужому адресу
Отдельный метод нужен был для обратных ссылок: чужой блог сообщал «я на вас сослался», WordPress ходил по указанному адресу и проверял, что ссылка на месте.
Если метод включён, сайт можно использовать как посредника. Он сам откроет соединение туда, куда сказал отправитель запроса. Адрес может быть внешним — тогда ваш сервер участвует в нагрузке на чужой ресурс, и в чужих логах виден IP origin, а не IP атакующего. Адрес может быть внутренним — тогда снаружи прощупываются порты и имена, до которых из интернета напрямую не достучаться. Это класс SSRF: сервер делает запрос от своего имени по указке клиента.
На современных версиях ядра часть старых ошибок pingback уже закрыта. Рассчитывать на это как на единственную защиту не стоит: файл либо нужен и тогда его надо ограничить по IP, либо не нужен и тогда его не должно быть в интернете вообще.
Подключите домен и посмотрите живую ленту: кто пришёл, с какой сети, что запрашивал и по какому правилу был пропущен или заблокирован.
Чем это не является
По отчёту легко сделать слишком сильный вывод. Имеет смысл разделить четыре состояния.
- Файл не подтверждён. GET не дал 200/405 с маркером XML-RPC. Либо точка закрыта, либо на запрос ответила заглушка, чужая CMS или страница ошибки. Это не доказательство, что WordPress где-то ещё прячет тот же интерфейс под другим путём.
- Файл доступен. Интерфейс включён. Паролей сканер не подбирал, методы не вызывал, содержимое сайта не читал.
- Учётная запись уже подобрана. Это инцидент. Его видно по успешным входам и по изменениям на сайте, а не по строке «xmlrpc.php доступен».
- Взлом через уязвимый плагин. Другой класс. Его ищут базы версий и CVE в том же стандартном скане. Открытый XML-RPC их не заменяет и не отменяет.
Поэтому формулировка «через XML-RPC получают доступ к сайту» верна только во второй половине фразы: доступ получают, если удаётся пройти аутентификацию. Открытый файл эту аутентификацию удешевляет. Он не отменяет её.
Кому файл ещё нужен
Слепое «закрыть всем» ломает легитимные сценарии. Имеет смысл проверить их до кнопки в отчёте.
- Приложение WordPress для телефона и старые редакторы. Часть из них до сих пор публикует записи через XML-RPC. После блокировки пропадет публикация, сайт для читателей останется.
- Jetpack и связь с WordPress.com. Им нужен этот вход. Если связка используется, полный запрет пути её оборвёт. Тогда ограничение должно быть по источнику, а не для всего интернета.
- Редкие плагины интеграций. Если публикация или синхронизация идут из внешней системы, она почти наверняка ходит на
xmlrpc.php. Это видно в логах домена по этому пути.
Если ни одного такого клиента нет, файл можно закрывать целиком. Для обычного сайта на современной теме и REST API это нормальное состояние, а не урезание функций.
Как закрыть
Закрытие на edge и закрытие на origin решают разные задачи. Edge перестаёт пускать интернет к файлу, даже если на хостинге WordPress его не выключали. Origin перестаёт исполнять методы, даже если кто-то обратился к серверу в обход прокси.
В TrafficVeil. Профиль WordPress на тарифе Starter и выше содержит правило «Блокировать xmlrpc.php». Запрос к этому пути режется до приложения. В сканере то же правило включается действием block_xmlrpc из находки. Повторная проверка — снова внешний GET. Пока файл отвечает маркером XML-RPC, находка не считается снятой.
Лимит попыток входа на wp-login.php эту находку не закрывает. Как показано выше, пачка попыток внутри одного запроса к XML-RPC таким лимитом почти не ловится. Нужен запрет пути. Лимит входа оставляют рядом: форма логина после закрытия XML-RPC никуда не девается.
На самом WordPress. Интерфейс отключается фильтром ядра, который возвращает «XML-RPC выключен», либо правилом веб-сервера, которое не отдаёт файл. Имеет смысл сделать и то и другое, если сайт не завязан на мобильную публикацию. Плагины безопасности делают то же самое. Проверять результат всё равно снаружи: фильтр в теме, которую потом сменили, защитой не является.
Если файл нужен одному сервису. Полная блокировка не подходит. Ограничьте путь списком адресов этого сервиса и смотрите в логах, не появляется ли тот же URL с других сетей. Сканер после такого ограничения должен перестать видеть публичный XML-RPC. Если находка осталась, ограничение не работает для произвольного клиента из интернета.
Сделать
- Посмотреть в отчёте строку
xmlrpc.phpи соседние строки: форма входа, REST пользователей,?author=. - Проверить логи пути за последние дни: есть ли живой клиент, кроме сканеров.
- Если клиента нет — включить блокировку XML-RPC и пересканировать.
- Оставить лимит входа на
wp-login.php. - На origin выключить интерфейс, чтобы обход edge его не вернул.
Не делать
- Не считать находку доказательством, что сайт уже взломан.
- Не закрывать только rate limit и не оставлять сам файл.
- Не выключать XML-RPC, не проверив Jetpack и мобильную публикацию.
- Не публиковать в отчёте для клиента тела запросов и примеры вызовов. Для решения достаточно факта «файл отвечает».
Как это выглядит в отчёте
Стандартный скан идёт по поверхности сайта, а не по одному файлу. XML-RPC стоит в одном списке с формой входа, админкой, REST, readme.html, debug.log и листингом uploads. Версии ядра, плагинов и CVE считаются отдельно: открытый файл их не перекрывает и ими не объясняется.
Приоритет critical у строки потому, что канал годится для перебора без ошибки в коде и без авторизации на старте. Закрывается одним правилом на edge. Пока оно выключено, следующая проверка принесёт ту же находку — в мониторинге она останется повторной.
После включения правила внешний GET больше не должен получать живой маркер XML-RPC. Если получает, запрос до файла всё ещё доходит: правило не на этом домене, домен смотрит мимо прокси, или ответ 200/405 рисует не WordPress, а другая заглушка с тем же текстом. Это уже разбор конкретного домена, а не повторное включение той же галочки.
Короткий вывод
Открытый xmlrpc.php — публичный интерфейс WordPress для удалённых вызовов. Через него не скачивают конфиг одним фактом существования файла. Через него проверяют пароли пачками в одном HTTP-запросе, отличают существующие логины и, если метод pingback включён, заставляют сам сайт открывать соединения по указанному адресу. Подошедший пароль превращает это в доступ от имени учётной записи.
Сканер TrafficVeil фиксирует только открытость: GET, код 200 или 405 и маркер XML-RPC в теле. Методы он не вызывает. Закрытие — правило блокировки пути на Starter и выше, плюс отключение интерфейса на origin, если мобильная публикация и Jetpack не завязаны на этот файл. Лимит входа на форму логина нужен дополнительно и XML-RPC не заменяет.
Частые вопросы
Открытый xmlrpc.php уже означает, что сайт взломан?
Как сканер понимает, что XML-RPC открыт?
Почему недостаточно лимита попыток входа?
На каком тарифе можно закрыть xmlrpc.php?
Команда TrafficVeil разрабатывает инструменты защиты сайтов от ботов, DDoS и веб-атак. Разборы ботов пишем по логам подключённых доменов и открытым данным операторов.
