Что такое XML-RPC? Старый способ, которым приложения общаются с WordPress через файл xmlrpc.php. Большинству небольших сайтов его можно отключить. Я бы так и сделал, если вы не пользуетесь Jetpack или старым приложением для публикации. Но сначала проверьте, не держится ли на нем что-то нужное.
Что такое XML-RPC в WordPress?
XML-RPC - старый протокол удаленного вызова: приложение отправляет XML в HTTP-запросе POST, а WordPress выполняет действие. В WordPress он доступен по адресу /xmlrpc.php. По умолчанию он включен с WordPress 3.5, который вышел в 2012 году.
Через него приложения и другие сайты могли публиковать записи, править контент и управлять сайтом удаленно. На нем же работают пингбэки и трекбэки. Тогда это было удобно: опубликовать запись из отдельной программы другим способом было сложнее.
Сейчас большую часть этих задач решает REST API - он входит в ядро WordPress с версии 4.7. Официальное мобильное приложение WordPress умеет работать через REST API с паролями приложений. Так что публикация с телефона сама по себе не повод оставлять XML-RPC открытым. Проверьте именно свое приложение.
Есть нюанс. Jetpack до сих пор использует XML-RPC для части соединения с WordPress.com. Он также нужен некоторым старым программам для ведения блога, интеграциям вроде IFTTT/Zapier и прежним приложениям для Android или iOS. Старое - не значит заброшенное.
Почему боты долбятся в xmlrpc.php?
Их привлекает system.multicall. С его помощью можно упаковать сотни попыток подобрать логин и пароль в один HTTP-запрос. Ограничитель, который считает запросы к wp-login.php, может не заметить ни одной попытки. А бот тем временем перебирает пароли через XML-RPC.
Вот чем атака через xmlrpc.php отличается от обычного перебора на странице входа. Цель та же - угадать рабочий логин с паролем. Но путь другой, и попытки собраны иначе. Защищать страницу входа нужно, только XML-RPC это автоматически не прикрывает. В статье про защиту входа в WordPress разбираем парадную дверь. С XML-RPC придется определиться отдельно.
Есть еще pingback.ping. Атакующий может заставить ваш сайт слать запросы чужому серверу в рамках отраженной DDoS-атаки или проверять внутренние адреса. Вряд ли ради этого владелец магазина запускал сайт.
И еще одна деталь: XML-RPC принимает пароли приложений, а многие варианты 2FA не защищают вход через него. Дополнительный шаг на привычной странице входа не доказывает, что этот адрес тоже под защитой.
Как проверить, включен ли XML-RPC
Начните с простого. Откройте в браузере https://yoursite.com/xmlrpc.php, подставив свой домен. Если видите XML-RPC server accepts POST requests only., адрес доступен. Это подсказка, а не доказательство, что работают все методы XML-RPC или вход: браузер отправил GET-запрос, а XML-RPC использует POST.
Если пользуетесь терминалом, попросите сервер показать список методов:
curl -s -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' https://yoursite.com/xmlrpc.phpЕсть доступ к логам сервера? Поищите повторяющиеся записи POST /xmlrpc.php с разных незнакомых IP. Так обычно шумят боты. Если адрес заблокирован, вместо ответа вы можете получить отказ. Если XML-RPC вам не нужен, это как раз хороший результат.
Стоит ли отключать XML-RPC?
Для большинства небольших сайтов - да, полностью. Если вы редактируете страницы в WordPress, принимаете заказы через магазин и не подключали старую программу для публикации, скорее всего, разницы не заметите. Зачем держать запасной вход открытым только потому, что он достался вместе с движком?
Не спешите блокировать XML-RPC, если используете:
- Jetpack - ему нужен XML-RPC для части соединения с WordPress.com.
- Старое приложение на компьютере или телефоне, которое публикует записи на сайте.
- Старую автоматизацию или другую интеграцию, завязанную на XML-RPC.
Не уверены? Запишите, какие приложения публикуют или синхронизируют контент. Потом отключите адрес, проверьте эти связи и, если что-то сломается, отмените изменение. Если интеграцию настраивал подрядчик, сначала спросите его. Узнать о поломке посреди дня, когда идут заказы, - так себе вариант.
Как отключить XML-RPC в WordPress
Выберите один способ. Собирать все варианты в кучу не нужно. Я предпочитаю блокировку на сервере: запрос даже не доходит до PHP. Но если править конфигурацию сервера не хочется, переключатель в плагине проще.
Заблокировать xmlrpc.php на сервере
На Apache добавьте это в файл .htaccess сайта:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx аналогичная настройка выглядит так:
location = /xmlrpc.php { deny all; }Не знаете, где лежит конфигурация? Попросите хостинг или специалиста, который обслуживает сайт. Если пользуетесь Jetpack, не перекрывайте XML-RPC целиком, если не готовы потерять соединение. Можно разрешить доступ только IP-адресам Jetpack, но за таким списком придется следить.
Добавить фрагмент кода или mu-plugin
Этот PHP-фильтр отключает методы XML-RPC, для которых нужен вход:
add_filter( 'xmlrpc_enabled', '__return_false' );Важно: пингбэки он не выключает. Если выбрали этот путь, уберите и их методы:
add_filter( 'xmlrpc_methods', function ( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Добавьте фрагмент через инструмент для сниппетов или mu-plugin, а не туда, где он пропадет после смены темы. И не ждите, что проверка через браузер покажет заблокированный адрес: этот способ меняет возможности XML-RPC, но не останавливает запрос на сервере.
Использовать плагин безопасности или файрвол
Во многих плагинах безопасности есть переключатель для отключения XML-RPC. Если не хотите трогать серверные файлы, начните с него. Включили - проверьте приложения и интеграции. И почитайте описание настройки: иногда она запрещает вход, но оставляет методы пингбэков.
А если XML-RPC нужно оставить?
Оставляйте осознанно. Если без него не работает Jetpack или старое приложение, ограничьте частоту запросов через файрвол, используйте длинные уникальные пароли и убедитесь, что защита распространяется на /xmlrpc.php. Тут пригодится бесплатный файрвол WordPress. Защита входа WordPress тоже полезна, но проверьте настройки: правила для wp-login.php могут не покрывать XML-RPC.
После любого изменения опубликуйте тестовую запись из приложения которым пользуетесь. Если у вас Jetpack - проверьте и его соединение. Пока не проверили то, что могло сломаться, работа не закончена.
Чего отключение XML-RPC не исправит
Оно не заменит слабые пароли и не обновит старый плагин. И не помешает ботам находить логины через REST API - это отдельная история, ее разбираем в статье про перечисление пользователей через REST API. XML-RPC - одна дверь из нескольких. Не нужна - закройте, но про остальной сайт тоже не забывайте.
Проверка на две минуты
Откройте адрес /xmlrpc.php на своем сайте. Видите сообщение про POST? Тогда задайте себе один вопрос: что у меня еще использует XML-RPC? Проверьте Jetpack и приложения для публикации. Если ответ - «ничего», отключите XML-RPC и попробуйте опубликовать запись привычным способом. Две минуты на такую проверку полезнее, чем оставлять ботам дверь, которой вы сами не пользуетесь.