Почему XML-RPC — частая причина инцидентов в WordPress
XML-RPC — это интерфейс удалённых вызовов WordPress. Он нужен для части сценариев: мобильные приложения WordPress, Jetpack, старые интеграции публикации и методы вроде pingback.ping.
На практике XML-RPC часто не используется, но остаётся включённым по умолчанию. И именно /xmlrpc.php регулярно всплывает в логах как источник:
- брутфорса (включая
system.multicall, когда десятки попыток авторизации упаковывают в один запрос); - паразитного трафика и «разогрева» CPU на PHP-FPM;
- pingback-атак, когда ваш сайт используют как отражатель для DDoS или пытаются «простучать» внутренние ресурсы.
С точки зрения админа это классический быстрый выигрыш: убираете ненужную поверхность атаки — и сразу видите эффект по нагрузке и стабильности.
Как понять, используется ли XML-RPC именно у вас
Перед тем как делать xmlrpc disable, стоит за 10 минут проверить зависимости и реальный профиль трафика.
1) Проверьте логи веб-сервера
Ищите обращения к /xmlrpc.php в access log (подставьте свой путь):
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50
Если видите постоянный поток запросов с повторяющимися IP/UA и высокой частотой, почти всегда это брут или pingback-активность.
2) Быстрый тест доступности endpoint
Проверьте, что endpoint вообще доступен снаружи:
curl -I https://example.com/xmlrpc.php
Часто вернётся 200 или 405. Важен сам факт: endpoint доступен — значит, по нему будут «стучать».
3) Уточните зависимости
Если вы используете Jetpack, мобильное приложение WordPress или внешние системы публикации «в блог», полная блокировка XML-RPC может сломать процессы.
Практическое правило: если вы не уверены, что XML-RPC нужен, в большинстве случаев он не нужен. Но безопаснее начать с ограничения опасных методов и rate limit, а уже потом отключать полностью.
Стратегия защиты: отключить полностью или ограничить доступ
Выберите подход, исходя из того, как вы администрируете сайт и какие интеграции реально работают.
Вариант A: полностью отключить XML-RPC
Оптимально для WordPress-сайтов без Jetpack/мобильных клиентов и без старых интеграций. Плюс в том, что запрос не дойдёт до PHP и не будет греть CPU.
Вариант B: оставить XML-RPC, но запретить pingback и ограничить частоту
Компромисс, если XML-RPC нужен для публикаций/приложений, но pingback вы не используете. Обычно этого достаточно, чтобы сильно снизить риск и нагрузку.
Вариант C: разрешить XML-RPC только доверенным IP
Самый строгий вариант: когда XML-RPC использует одна интеграция (например, корпоративный сервис публикации). Требует стабильных IP и дисциплины в их обновлении.
Отключаем XML-RPC на Nginx (запрос не доходит до PHP)
Если Nginx стоит фронтом, закрывать /xmlrpc.php лучше здесь: это быстрее и надёжнее, чем фильтровать внутри WordPress.
Полная блокировка /xmlrpc.php
location = /xmlrpc.php {
return 403;
}
Если хотите «мягче» (иногда так проще уменьшить шум от сканеров), верните 404:
location = /xmlrpc.php {
return 404;
}
Разрешить только доверенным IP
Если endpoint нужен, но только для конкретной интеграции, включите allowlist. Важно: обработку PHP оставьте такой же, как в вашей рабочей конфигурации.
location = /xmlrpc.php {
allow 203.0.113.10;
allow 203.0.113.11;
deny all;
include fastcgi_params;
fastcgi_pass php-fpm;
}
Rate limit для /xmlrpc.php (если оставляете доступ)
Ограничение частоты резко снижает эффективность брутфорса и «мультизапросов». Пример схемы для Nginx:
limit_req_zone $binary_remote_addr zone=xmlrpc:10m rate=5r/m;
location = /xmlrpc.php {
limit_req zone=xmlrpc burst=10 nodelay;
include fastcgi_params;
fastcgi_pass php-fpm;
}
Числа подбирайте по логам. Для большинства сайтов 5 запросов в минуту на IP для XML-RPC более чем достаточно. Если у вас WordPress крутится на VDS, полезно посмотреть метрики PHP-FPM до и после включения лимитов: эффект обычно виден сразу.
Отключаем XML-RPC на Apache и в .htaccess
На Apache логика та же: проще закрыть файл на уровне веб-сервера, чем отдавать запрос внутрь PHP.
Полная блокировка
<Files "xmlrpc.php">
Require all denied
</Files>
Разрешить только доверенным IP
<Files "xmlrpc.php">
Require ip 203.0.113.10 203.0.113.11
</Files>
Отключение XML-RPC на уровне WordPress (когда нет доступа к конфигам)
На типовом виртуальном хостинге или в условиях, когда вы не можете менять конфиги Nginx/Apache, можно отключить XML-RPC через WordPress. Это менее эффективно (запрос всё равно попадёт в PHP), но как быстрый «пластырь» работает.
Полностью отключить XML-RPC
Добавьте фильтр в functions.php темы или в мини-плагин:
add_filter('xmlrpc_enabled', '__return_false');
Отключить только pingback
Если вам нужен XML-RPC для приложений/публикации, но pingback не нужен:
add_filter('xmlrpc_methods', function($methods) {
unset($methods['pingback.ping']);
unset($methods['pingback.extensions.getPingbacks']);
return $methods;
});
На практике лучше комбинировать: отключить/ограничить на веб-сервере и оставить фильтры в WordPress как дополнительную страховку.
WAF rules для WordPress: что реально помогает против /xmlrpc.php
Если XML-RPC включён (или вы не можете отключить его полностью), WAF — второй слой. Важно: начинайте с режима логирования и смотрите, что реально срабатывает, иначе легко «подстрелить» легитимные интеграции.
Если вы используете WAF на базе OWASP CRS, сначала включите режим DetectionOnly, изучите события, затем переводите конкретные правила в блокировку. Так меньше шансов сломать Jetpack или корпоративные публикации.
1) Блокировать pingback по содержимому запроса
В типичных атаках в теле запроса встречается строка pingback.ping. Универсальная логика правила: если URI равен /xmlrpc.php и тело содержит pingback.ping — блокировать.
2) Ограничивать частоту и «всплески» multicall
Метод system.multicall не «уязвимость», но ускоритель перебора паролей. Если WAF умеет детектировать частые запросы к /xmlrpc.php и/или сигнатуры multicall — используйте это. Если не умеет, делайте rate limit на Nginx/Apache (пример выше).
3) Фильтровать явный мусор по UA/гео/подсетям (аккуратно)
Если видите сотни запросов с одинаковыми User-Agent или из географий, где у вас нет аудитории, можно добавить мягкие ограничения. Не делайте агрессивных банов «наугад»: корпоративный NAT и мобильные сети легко попадают под раздачу.
Проверка, что защита работает: короткий чек-лист
1) Проверяем ответы сервера
После внедрения правил убедитесь, что endpoint реально закрыт:
curl -I https://example.com/xmlrpc.php
Ожидаемо увидеть 403 или 404 (в зависимости от выбранного варианта). Если у вас allowlist, проверьте и с доверенного IP, и с обычного.
2) Проверяем, что не сломали нужные сценарии
- Jetpack: синхронизация, публикации, статистика.
- Мобильное приложение WordPress: авторизация и публикации.
- Внешние интеграции: импорт, кросспостинг, публикации.
3) Смотрим логи и нагрузку
После отключения или ограничения /xmlrpc.php обычно заметно падают:
- количество запросов к
/xmlrpc.php; - пики CPU у PHP-FPM;
- ошибки 499/504 на фронте (если воркеры были забиты).
Если параллельно вы настраиваете HTTPS и HSTS, полезно держать миграцию под контролем: пригодится материал про 301, HSTS и SSL при переносе домена.
Типовые ошибки и как их избежать
Ошибка 1: закрыть XML-RPC на backend, но оставить доступ через фронт/балансировщик
Если перед сайтом стоит CDN или балансировщик, убедитесь, что правило применяется на самом «входе». Иначе фронт продолжит проксировать запросы, а инфраструктура будет тратить ресурсы на повторные попытки и таймауты.
Ошибка 2: полная блокировка при активном Jetpack
Если Jetpack действительно нужен, начните с блокировки pingback и rate limit. Потом решайте, можно ли отключить XML-RPC целиком.
Ошибка 3: надеяться только на WAF
WAF — отличный слой, но самая дешёвая защита — не принимать запрос вообще. Для WordPress это особенно заметно на небольших серверах: лишние запросы к PHP стоят дорого.
Минимальный «золотой набор» для WordPress security вокруг XML-RPC
- Если XML-RPC не нужен — закрыть
/xmlrpc.phpна Nginx/Apache. - Если нужен — отключить pingback и поставить rate limit на endpoint.
- Добавить WAF-правила: блок
pingback.ping, контроль всплесковsystem.multicall, базовую антибрут-логику. - Регулярно просматривать логи по
/xmlrpc.phpи метрики PHP-FPM.
Итог
XML-RPC в WordPress — не «зло» само по себе, но это типичный пример функции, которая часто включена без необходимости. Практичная стратегия простая: выключаем всё, что не используем; всё, что используем — ограничиваем и защищаем. Такой подход почти всегда даёт быстрый выигрыш и по безопасности, и по стабильности.
Если хотите двигаться дальше, по похожей схеме имеет смысл «укреплять» и другие точки входа WordPress: /wp-login.php, wp-admin/admin-ajax.php, REST API.
