Вы когда-нибудь замечали, что ваш сайт начинает тормозить, а в логах — тысячи странных запросов? Наш сайт РтиИваз недавно подвергся массированной атаке. Целью был файл xmlrpc.php, который уже старый, но до сих пор открытая дверь для взлома хакерами. Заодно мы нашли и другие проблемы: сбои WP-Cron, ложные блокировки и перегрузку от навязчивых ботов.
В этой статье я расскажу, как мы шаг за шагом привели сайт в порядок. Методы подойдут любому сайту на WordPress. Поехали!
Диагностика: как понять, что сайт атакуют
Первым звоночком стало сообщение от плагина WP Crontrol: «Неожиданный код ответа HTTP: 503». Но при проверке логов доступа мы не нашли ни одной 503 ошибки. В чём дело?
Оказалось, что плагин безопасности Shield Security блокировал запросы к wp-cron.php, посчитав их подозрительными. Отключение плагина через ФТП сразу же «вылечило» WP-Cron — это помогло нам найти виновника проблемы.
Что делать:
Всегда проверяйте логи access_log и error_log. Если при полном отключении плагина проблема исчезает — значит, виноват плагин, и его нужно перенастроить, а не удалять.
Главная атака на xmlrpc.php и как её остановить
Через несколько дней мы заметили в логах тысячи запросов:
POST /xmlrpc.php HTTP/1.0″ 503 …
Атака шла с десятков IP, с поддельными заголовками «Jetpack». Цель — перебор паролей и создание нагрузки на сервер.
Мы перепробовали несколько способов:
А) Настройка Shield Security (работает, но неидеально).
Включили в Shield Security опцию Immediate IP Block для XML-RPC. Плагин начал блокировать IP после первого же запроса к xmlrpc.php. Атаки стали менее интенсивными, но каждый запрос всё равно запускал WordPress и потреблял много ресурсы.
Б) Полная блокировка через .htaccess (лучшее решение этой проблемы).
Самый эффективный и простой способ — закрыть доступ к xmlrpc.php на уровне веб-сервера, если вы не используете Jetpack. Добавьте в корневой .htaccess (рекомендуется для Apache):
<Files xmlrpc.php>
Require all denied
</Files>После этого любой запрос к xmlrpc.php будет отклоняться ещё до запуска PHP и WordPress. Нагрузка на сервер упадет мгновенно.
⚠️ Важное предупреждение! Прежде чем блокировать XML-RPC, убедитесь, что ваш сайт его не использует. Его могут использовать некоторые плагины (например, старые версии Jetpack) либо приложения для публикации с мобильных устройств. Если вы не пользуетесь такими сервисами, блокировка будет безопасной.
В логах Shield Security мы увидели:
• «Выявление автора» — попытки подобрать логин через /?author=1.
• «Анонимный REST API» через пространство имён peepso — атака на уязвимость старой версии плагина PeepSo, который много лет назад установил и удалил.
Shield Security уже блокировал их, но мы ещё усилили защиту:
• Для перебора имён пользователей включили опцию «Immediate IP Block» для неудачных входов.
• В целях безопасности удалите неиспользуемые плагины, например, PeepSo. Если они вам нужны — обязательно обновите их до последней версии.
• Настроили автоматический чёрный список IP (Auto Black List) с лимитом в 3 «оффенса» и блокировкой на 1 час.
Эти меры отсекают атакующих практически мгновенно.
Включаем CrowdSec для усиления
Shield Security умеет использовать базу данных вредоносных IP от CrowdSec. Мы включили опцию «Block Request With Ability To Auto-Unblock». Это даёт два преимущества:
• Запросы с IP из чёрного списка CrowdSec блокируются сразу.
• Реальный пользователь, попавший под блокировку, может разблокировать себя сам (без вашего участия) — достаточно ему перейти по ссылке из письма (Е-майл) или пройти капчу.
Это золотая середина между безопасностью и удобством.
Разбираемся с кодом 503 — оказывается он не всегда плох
Важное открытие: код 503 Service Unavailable не обязательно означает, что сайт упал. В нашем случае Shield Security намеренно возвращал 503 для заблокированных запросов — хитроумно имитируя перегрузку сервера, чтобы сбить с толку атакующих ботов.
Вывод: не пугайтесь ошибки 503 в логах. Проверяйте, какой именно ресурс возвращает ошибку. Если это xmlrpc.php или wp-cron.php — скорее всего, плагин безопасности хорошо делает свою работу.
Итог: что мы сделали и что вам стоит повторить
- Нашли причину с помощью отключения плагинов и анализа логов.
- Полностью заблокировали xmlrpc.php через .htaccess — это остановило атаку.
- Включили Immediate IP Block для неудачных входов и подозрительных запросов.
- Активировали CrowdSec с возможностью авторазблокировки для легитимных пользователей.
- Поняли, что 503 ошибка — это нормально, если сайт под атакой.
Эти шаги помогли нам снизить нагрузку на сервер, отбить атаку и сохранить доступность сайта. Надеюсь, и вам они пригодятся.
Есть вопросы? Пишите в комментариях — постараюсь помочь.
Читайте еще:
