Как отключить XML-RPC в WordPress и закрыть brute-force атаки

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

Когда XML-RPC реально мешает

На практике с ним сталкиваются в трех сценариях: в логах видно много запросов к /xmlrpc.php, в панели безопасности сыпятся уведомления о brute-force, либо сайт начинает отвечать медленнее из-за массовых обращений к endpoint'у. Иногда проблема проявляется не как взлом, а как постоянный фон из мусорных запросов, который забивает логи и мешает увидеть реальные ошибки.

Если у вас включены мобильные приложения WordPress, публикация через внешние клиенты, интеграции старых сервисов или Jetpack, сначала проверьте, действительно ли они используют XML-RPC. Иначе можно отключить нужную функциональность вместе с нежелательной.

Диагностика: нужен ли вам XML-RPC вообще

Перед отключением полезно быстро проверить, используется ли endpoint. Самый простой способ — посмотреть access log веб-сервера и найти обращения к xmlrpc.php. Если там только сканеры и попытки подбора, закрывать можно безболезненно.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20

Если доступа к логам нет, проверьте сайт внешним запросом. Ответ 405, 403 или явная блокировка — нормальный результат после отключения. Если же вы видите стандартный ответ WordPress, endpoint открыт.

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

Еще один практический тест — временно отключить XML-RPC на тестовом стенде и проверить, не ломаются ли:

• публикация через мобильное приложение WordPress;
• подключение Jetpack, если он используется;
• внешние сервисы автопостинга;
• старые интеграции, которые работают не через REST API, а через XML-RPC.

Как отключить XML-RPC: рабочие варианты

Есть три нормальных подхода: через плагин безопасности, через серверную блокировку и через код. Выбор зависит от того, кто у вас управляет сервером и насколько часто вы меняете конфигурацию.

Вариант 1. Отключение через код

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

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

Этот вариант отключает сам XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно, но если endpoint активно дергают боты, лучше дополнительно закрыть его на уровне веб-сервера, чтобы не тратить ресурсы PHP.

Вариант 2. Блокировка на уровне Nginx

Если у вас Nginx, логичнее отрезать доступ раньше, чем запрос попадет в WordPress. Это снижает нагрузку и уменьшает шум в логах PHP-FPM.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервер. Для Nginx это стандартная процедура, но на боевом сайте ее часто забывают сделать, из-за чего правило просто не начинает работать.

nginx -t
systemctl reload nginx

Вариант 3. Блокировка через Apache

Если сайт работает на Apache, можно закрыть файл через .htaccess. Это удобно, когда нет доступа к основным конфигам сервера.

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

Для старых конфигураций Apache встречается вариант с Order deny,allow, но на новых установках лучше использовать современный синтаксис Require all denied.

Что выбрать: плагин, код или сервер

Пошаговое решение без лишнего риска

1. Проверьте, используется ли XML-RPC вашими сервисами.
2. Если интеграций нет, выберите серверную блокировку или отключение через код.
3. Внесите изменение на staging, а не сразу на продакшене.
4. Проверьте ответ /xmlrpc.php через curl -I.
5. Посмотрите access log и убедитесь, что запросы больше не доходят до WordPress.

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

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

Проверка должна быть не только визуальной. Откройте https://example.com/xmlrpc.php в браузере и посмотрите ответ. Если endpoint закрыт на уровне сервера, вы увидите отказ в доступе или пустой ответ без стандартной страницы WordPress. Если отключение сделано через фильтр, WordPress не должен принимать XML-RPC-вызовы.

Дополнительно выполните тестовый запрос:

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

И проверьте логи за несколько часов после изменения. Если раньше там были сотни однотипных обращений, а теперь их нет или они получают отказ до PHP, значит защита работает. Для сайтов под нагрузкой это еще и хороший способ уменьшить мусор в логах и упростить диагностику реальных ошибок.

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

Отключили XML-RPC и сломали интеграцию

Такое бывает, если сайт использует Jetpack, мобильное приложение WordPress или старый внешний сервис публикации. Решение простое: сначала найдите зависимость, потом отключайте endpoint. Если интеграция нужна, не блокируйте XML-RPC полностью, а ограничьте доступ на уровне firewall или по IP, если это возможно.

Сделали блокировку в .htaccess, но сайт на Nginx

Это типичная ошибка при переносе инструкций между хостингами. Для Nginx .htaccess не работает вообще, поэтому правило нужно писать в конфиге сервера или закрывать endpoint через WordPress.

Поставили security-плагин, но запросы продолжают идти

Некоторые плагины только отключают XML-RPC внутри WordPress, но не режут запросы на уровне веб-сервера. В результате боты продолжают стучаться в endpoint, а PHP все равно тратит ресурсы на обработку. Если атаки заметны, лучше добавить серверную блокировку.

Проверили в браузере, но не проверили логи

Браузерный тест показывает только факт ответа. Он не говорит, доходят ли запросы до PHP и не создает ли endpoint лишнюю нагрузку. Поэтому обязательно смотрите access log и, если есть, error log.

Что еще стоит закрыть вместе с XML-RPC

Если вы уже занимаетесь технической чисткой сайта, полезно посмотреть и на другие точки лишнего доступа: неиспользуемые REST-эндпоинты, старые тестовые страницы, открытые авторские архивы, дубли пагинации и мусорные служебные URL. Смысл не в том, чтобы «закрутить все гайки», а в том, чтобы убрать то, что реально не используется и создает шум.

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