XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам, брутфорсу и странным обращениям к /xmlrpc.php. Если сайт не использует старые мобильные клиенты, Jetpack в режиме, который требует XML-RPC, или внешние сервисы с этим протоколом, его обычно проще закрыть полностью. Но делать это нужно аккуратно: сначала понять, кто именно стучится, потом выбрать способ блокировки и только после этого проверять, не отвалились ли нужные сценарии.
Когда XML-RPC действительно стоит отключать
Самый частый сценарий — сайт получает много запросов к xmlrpc.php без видимой пользы. Это видно в логах веб-сервера, в отчётах WAF или в плагинах безопасности. Если вы не публикуете записи через старые внешние клиенты и не используете интеграции, завязанные именно на XML-RPC, держать его открытым смысла мало.
Но есть и обратная сторона: некоторые старые приложения, мобильные клиенты и отдельные сервисы для удалённой публикации до сих пор используют XML-RPC. Поэтому перед блокировкой важно проверить, не завязан ли на него ваш рабочий процесс.
Признаки, что проблема есть
- в логах много обращений к
/xmlrpc.phpс одинаковых IP или с перебором логинов; - в панели безопасности появляются события, связанные с brute force через XML-RPC;
- сайт не использует внешнюю публикацию, но endpoint остаётся доступным;
- после установки плагинов защиты вы видите, что XML-RPC всё равно отвечает кодом 200.
Диагностика: проверить, кто и как обращается к xmlrpc.php
Перед изменениями откройте access log веб-сервера или журнал в панели хостинга и найдите обращения к xmlrpc.php. Если у вас есть SSH-доступ, можно быстро отфильтровать строки по имени файла. Это не требует сложных инструментов и сразу показывает, есть ли реальная активность.
grep