Как отключить XML-RPC и защитить wp-login.php от brute force в WordPress

Автор: Виктория Ларионова | Опубликовано: 03.09.2026

Если на сайте уже закрыты дубли, настроены sitemap и canonical, следующий частый источник проблем — лишние точки входа в админку. На практике это обычно xmlrpc.php и стандартная форма входа wp-login.php. Первый часто используют для перебора паролей и pingback-атак, второй — для brute force по логину и паролю.

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

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

Обычно это видно по логам, нагрузке или странным запросам к одному и тому же файлу. Если сайт небольшой, а в access log постоянно идут обращения к /xmlrpc.php или /wp-login.php, это уже повод проверить конфигурацию. Иногда атаки не ломают сайт напрямую, но создают лишнюю нагрузку на PHP и базу данных.

Что смотреть в логах

много POST-запросов к xmlrpc.php;
повторяющиеся попытки входа на wp-login.php с разных IP;
ошибки 401/403 на входе, если уже стоит защита;
подозрительные запросы с параметром action=login или частые обращения к xmlrpc.php?rsd.

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

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

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

Быстрая проверка на стороне сайта

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

Если хотите проверить наличие обращений без догадок, посмотрите access log веб-сервера. На nginx это обычно что-то вроде:

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

На shared-хостинге доступ к логам может быть ограничен. Тогда ориентируйтесь на плагины безопасности или статистику в панели хостинга.

Как отключить XML-RPC без лишнего риска

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

Способ	Плюсы	Минусы
Код в `functions.php` или mu-plugin	Прозрачно, легко проверить, не зависит от интерфейса плагина	Нужно аккуратно вносить изменения
Плагин безопасности	Быстро включить из админки	Дополнительная зависимость, возможны конфликты
Отключение на уровне сервера	Снимает нагрузку раньше PHP	Требует доступа к конфигу nginx/Apache

Вариант через код

Если XML-RPC не нужен, можно отключить его фильтром xmlrpc_enabled. Для сайта на продакшене удобнее положить это в mu-plugin, чтобы настройка не зависела от активной темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Если вы не хотите создавать отдельный плагин, тот же код можно добавить в functions.php дочерней темы. Но для защиты сайта это менее удобно: при смене темы правило легко потерять.

Более жёсткий вариант через сервер

Если у вас nginx, можно сразу отдавать 403 на запросы к xmlrpc.php. Это полезно, когда атаки идут массово и вы хотите отрезать их до запуска PHP.

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

Для Apache обычно используют правило в .htaccess:

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

Если у вас есть сервисы, которым XML-RPC нужен, не применяйте это правило без проверки. В таком случае лучше ограничить доступ по IP или закрыть endpoint через WAF/Cloudflare.

Как защитить wp-login.php от brute force

Отключение XML-RPC не решает проблему входа в админку. wp-login.php всё равно остаётся открытым, и его надо защищать отдельно. Здесь обычно работают три меры: ограничение попыток входа, двухфакторная аутентификация и дополнительный барьер на уровне сервера или reverse proxy.

Что реально помогает

лимит попыток входа по IP или по логину;
смена стандартного URL входа, если это не ломает процессы команды;
2FA для администраторов и редакторов;
ограничение доступа к wp-login.php по IP для закрытых проектов;
защита на уровне Cloudflare или fail2ban, если есть доступ к серверу.

Смена URL входа — не замена нормальной защите, а только дополнительный слой. Если пароль слабый, скрытый адрес не спасёт. Поэтому сначала лимиты и 2FA, потом уже косметические меры.

Ограничение по IP для закрытого проекта

Если админка нужна только вашей команде и у вас статические IP, можно закрыть wp-login.php на уровне nginx. Это один из самых надёжных вариантов для корпоративных сайтов и внутренних порталов.

location = /wp-login.php {
    allow 203.0.113.10;
    allow 203.0.113.11;
    deny all;
}

Но если команда работает из разных сетей, VPN или мобильного интернета, такой подход быстро начнёт мешать. В этом случае лучше использовать 2FA и лимит попыток входа.

Пошаговая схема внедрения

Проверьте, используется ли XML-RPC реальными сервисами.
Если не используется, отключите его через xmlrpc_enabled или на уровне сервера.
Поставьте ограничение попыток входа на wp-login.php.
Включите 2FA для администраторов.
Проверьте логи и убедитесь, что атаки не идут через альтернативные endpoint’ы.

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

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

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

Проверка XML-RPC

После отключения откройте /xmlrpc.php в браузере или выполните запрос через curl:

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

Если вы закрывали endpoint через сервер, ожидайте 403 Forbidden или 404 Not Found в зависимости от конфигурации. Если отключали только через WordPress-фильтр, сервер может всё ещё отдавать файл, но WordPress не должен принимать XML-RPC как рабочий канал.

Проверка защиты входа

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

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

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

Отключили XML-RPC, а Jetpack перестал синхронизироваться

Значит, сервис действительно использовал этот endpoint. Решение простое: не отключать его глобально, а ограничить доступ и проверить, можно ли перевести интеграцию на другой способ связи. Если сервис критичен, сначала тестируйте на staging.

Поставили два плагина защиты входа сразу

Так часто ломают авторизацию. Один плагин считает попытки входа, второй добавляет капчу, третий меняет URL. В итоге пользователь получает блокировку, а вы — ложные срабатывания. Оставьте один основной механизм и проверьте его отдельно.

Закрыли `wp-login.php` по IP, но забыли про VPN и мобильные сети

Это типичная проблема для команд с плавающими адресами. Если IP нестабилен, лучше использовать 2FA, а не жёсткий allowlist.

Спрятали URL входа, но не закрыли XML-RPC

Это создаёт ложное ощущение безопасности. Боты всё равно могут атаковать через xmlrpc.php, а иногда и через стандартный wp-login.php, если он доступен. Защита должна быть на обоих уровнях.

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

Если сайт получает много мусорных запросов, отключение XML-RPC даёт не только безопасность, но и немного разгружает PHP. Это особенно заметно на слабых тарифах и при активных брутфорс-атаках.

держите WordPress, плагины и тему в актуальном состоянии;
используйте уникальные пароли и 2FA для администраторов;
не храните доступы в общих чатах и документах без защиты;
проверяйте, не создаёт ли плагин безопасности лишние редиректы и циклы;
если есть серверный доступ, настройте fail2ban или аналогичный механизм на повторяющиеся ошибки входа.

Если нужен более широкий аудит технических дублей и служебных страниц, на практике удобно сочетать точечную защиту с общей чисткой сайта. Например, Clearfy Pro от WPShop закрывает часть SEO- и технических дублей, но защиту входа и XML-RPC всё равно стоит настраивать отдельно: https://wpshop.ru/plugins/clearfy?utm_source=wponline.ru&utm_medium=article&utm_campaign=otklyuchit-xmlrpc-i-zashchitit-wp-login-ot-bruteforce-v-wordpress

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