Как запретить XML-RPC и отключить pingbacks в WordPress без поломки удалённых подключений

XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишний шум: попытки брутфорса, pingback-спам, ненужные запросы к xmlrpc.php. Но отключать его вслепую тоже плохая идея: если у сайта есть мобильные приложения, внешние публикации или старые интеграции, можно сломать рабочий сценарий.

Ниже — не абстрактная рекомендация, а рабочая схема: сначала быстро понять, нужен ли вам XML-RPC вообще, затем отключить только лишнее и проверить, что ничего важного не отвалилось.

Когда проблема действительно в XML-RPC

Симптомы обычно довольно приземлённые. В логах веб-сервера видно много запросов к /xmlrpc.php, иногда с одинаковыми IP и похожими payload. В панели безопасности могут появляться предупреждения о попытках авторизации через XML-RPC. Если включены pingbacks, в комментариях или модерации всплывают странные уведомления без реальной пользы.

Есть и менее очевидный сценарий: сайт работает нормально, но xmlrpc.php постоянно отвечает 200 OK на автоматические запросы. Это не всегда критично по нагрузке, но на слабом хостинге лишние обращения заметны.

Что проверить до изменений

• Используете ли вы мобильное приложение WordPress для публикации или редактирования.
• Есть ли внешние сервисы, которые отправляют записи через XML-RPC.
• Нужны ли вам pingbacks/trackbacks как часть внутреннего процесса.
• Не стоит ли сайт за CDN, WAF или reverse proxy, где уже есть отдельная защита от брутфорса.

Если хотя бы один пункт отмечен как «да», не рубите доступ полностью без теста на staging-копии.

Что лучше отключать: XML-RPC целиком или только pingbacks

Тут полезно разделить задачу на две части. Pingbacks и trackbacks почти всегда можно отключить без последствий для обычного сайта. XML-RPC — более широкий механизм, и его полное отключение оправдано только если вы точно не используете удалённую публикацию и старые интеграции.

Пошаговое решение

1. Отключите pingbacks и trackbacks в настройках

Если цель — убрать именно обратные ссылки, начните с админки. В WordPress это делается без кода: откройте Настройки → Обсуждение и снимите галочку с пункта про уведомления о ссылках с других блогов. Это не закрывает XML-RPC целиком, но убирает один из самых бесполезных источников шума.

2. Запретите XML-RPC через фильтр

Если удалённая публикация не нужна, добавьте код в functions.php дочерней темы или в небольшой mu-plugin. Так безопаснее, чем править ядро или ставить сомнительный «антиспам-плагин» с лишними функциями.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Этот фильтр штатный: WordPress его поддерживает давно, и он отключает XML-RPC на уровне ядра. После этого запросы к xmlrpc.php должны перестать обслуживаться как рабочий канал.

3. Если нужны только отдельные методы, режьте точечно

Иногда XML-RPC нужен частично: например, вы не хотите полностью закрывать канал, но хотите убрать pingback-методы. Тогда можно использовать фильтр xmlrpc_methods и удалить только лишнее.

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Это более гибкий вариант, чем полное отключение. Он полезен, если у вас есть старый внешний сервис, который ещё использует XML-RPC для публикации, но pingbacks вам не нужны.

4. При необходимости заблокируйте доступ на уровне сервера

Если вы управляете конфигурацией веб-сервера, можно закрыть xmlrpc.php до того, как запрос дойдёт до WordPress. Это снижает лишнюю нагрузку и уменьшает поверхность атаки. Но такой шаг стоит делать только после проверки, что удалённые подключения не используются.

Для Nginx обычно применяют отдельное правило в конфиге сайта. Пример зависит от вашей схемы, но логика простая: вернуть 403 или 444 для /xmlrpc.php. На Apache используют правила в .htaccess или конфиге виртуального хоста. Здесь важно не копировать чужой фрагмент без понимания, как у вас устроен стек.

Как проверить, что всё сработало

Проверка должна быть не «на глаз», а по факту ответа сервера и по журналам.

• Откройте /xmlrpc.php в браузере или через curl и посмотрите, что возвращает сервер.
• Проверьте, не используются ли внешние интеграции, которые отправляют записи через XML-RPC.
• Посмотрите access log: количество запросов к xmlrpc.php должно снизиться или исчезнуть.
• Убедитесь, что публикация из админки, REST API и обычные формы на сайте работают как раньше.

Простой тест через консоль:

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

Если вы отключали XML-RPC через фильтр, ожидаемый результат — не «успешный» ответ с рабочим методом, а отказ в доступе или нерабочий endpoint. Конкретный код ответа зависит от того, отключали вы его в WordPress или на сервере.

Частые ошибки и как их исправить

Отключили XML-RPC, а потом перестало работать мобильное приложение

Это типичный сценарий. Решение простое: верните фильтр xmlrpc_enabled назад или оставьте XML-RPC включённым, но закройте только pingbacks и ограничьте доступ по IP на уровне WAF.

Сняли галочку в обсуждениях, но спам не исчез

Потому что pingbacks — не единственный источник спама. Если запросы идут через xmlrpc.php, нужно отдельно отключать сам XML-RPC. Если спам идёт через комментарии, смотрите уже на антиспам-меры для комментариев, а не на XML-RPC.

Поставили плагин «для защиты», а сайт стал медленнее

Некоторые плагины для безопасности навешивают лишние проверки на каждый запрос. Если задача точечная, кодовый фильтр обычно проще и дешевле по ресурсам. Плагин имеет смысл только если вам нужен единый интерфейс для нескольких мер защиты.

Скопировали правило для сервера без проверки конфигурации

На одном хостинге правило в .htaccess сработает, на другом — нет, потому что сайт работает под Nginx или через прокси. Всегда проверяйте, где именно обрабатываются запросы: веб-сервер, CDN, WAF или сам WordPress.

Практические советы по безопасности и производительности

Если цель — уменьшить поверхность атаки, не ограничивайтесь только XML-RPC. Для большинства сайтов полезно одновременно отключить pingbacks, проверить лимиты авторизации и посмотреть, не открыты ли лишние публичные endpoints. Но не смешивайте всё в один большой «security snippet»: потом сложно понять, что именно сломало интеграцию.

Хорошая практика — держать такие изменения в отдельном mu-plugin. Тогда код не потеряется при смене темы и его проще отключить на staging, если что-то пошло не так.

<?php
/**
 * Plugin Name: WPFront XML-RPC Hardening
 */
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Если вам нужен более широкий набор технических чисток — дубли, лишние мета-данные, отключение эмбедов и похожие задачи — такие вещи удобнее вести отдельно, а не смешивать с защитой XML-RPC. Для этого на практике часто используют Clearfy Pro, но только если вам нужен именно набор готовых переключателей, а не точечный код.

Что делать, если доступ к XML-RPC всё-таки нужен

Иногда правильный ответ — не отключать канал полностью, а ограничить его использование. Например, разрешить доступ только с доверенных IP, закрыть его на уровне WAF или оставить XML-RPC включённым, но убрать pingbacks и следить за логами. Это особенно актуально для сайтов с legacy-интеграциями, где переписывать внешний сервис дороже, чем аккуратно ограничить endpoint.

В таком сценарии главное — не оставлять всё «как есть». Если endpoint нужен, он должен быть либо защищён, либо хотя бы наблюдаем. Иначе вы просто сохраняете старую дыру в удобной для атакующих форме.