Как защитить WordPress от атак через XML-RPC и не сломать нужные интеграции

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

Сначала подтвердите источник нагрузки

Посмотрите access/error-логи веб-сервера и убедитесь, что всплеск действительно связан с xmlrpc.php. Одновременно проверьте обычную страницу входа: перебор паролей может идти через несколько точек.

Если XML-RPC не используется

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

Если XML-RPC нужен

• используйте уникальные сложные пароли и двухфакторную аутентификацию для администраторов;
• ограничивайте подозрительные запросы rate limiting или WAF;
• не публикуйте административные учётные данные в скриптах;
• обновляйте WordPress, тему и плагины;
• удаляйте неиспользуемые плагины, а не просто отключайте их.

Почему одной блокировки xmlrpc.php мало

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

Проверка после изменений

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