Признаки взлома сайта редко выглядят как что-то очевидное сразу: странные ссылки в поисковой выдаче, письма от хостинга о рассылке спама с вашего сервера, необъяснимое замедление, редирект посетителей на чужой сайт. К моменту обнаружения проблема обычно уже длится некоторое время.
Разберём план действий по порядку — что делать в первый час, как найти точку входа злоумышленника и как закрыть дыру, а не просто удалить видимые последствия.
Первый час: остановить распространение
- Не удаляйте сайт и не паникуйте. Резкие действия без диагностики часто уничтожают улики, по которым можно найти точку входа.
- Сделайте копию текущего состояния — файлов и базы, даже заражённых. Она понадобится для анализа и как страховка, если восстановление из старого бэкапа пойдёт не так.
- Смените все пароли — администраторов, доступа к хостингу, к базе данных, FTP. Если использовался общий пароль где-то ещё, смените и его.
- Отключите сайт от публичного доступа, если он используется для рассылки спама или заражения посетителей, — режим технических работ или временная блокировка на уровне хостинга.
- Свяжитесь с хостингом, если получили от него уведомление — там могут быть детали атаки, недоступные со стороны сайта.
Как искать точку входа
Источник взлома почти всегда лежит в одной из нескольких категорий:
| Источник | Что проверить |
|---|---|
| Устаревшее ядро или модуль | Версия продукта, дата последнего обновления безопасности |
| Уязвимое стороннее решение | Модули из Маркетплейса, самописные компоненты |
| Слабый пароль администратора | Журнал входов, попытки авторизации в логах |
| Украденный доступ разработчика | Список действующих учётных записей и их права |
| Уязвимость в загрузке файлов | Права на выполнение файлов в папке загрузок |
Проверка целостности файлов
Штатная проверка системы сравнивает файлы ядра с эталонными и показывает изменённые. Это первое, что стоит запустить: изменённые файлы ядра — прямое указание на то, что и когда было модифицировано.
Поиск постороннего кода
Внедрённый вредоносный код часто маскируется под легитимные файлы или добавляется в существующие. Признаки, по которым его ищут:
- файлы с недавней датой изменения в местах, где ничего не менялось;
- обфусцированный или закодированный через
base64_decodeкод; - подозрительные вызовы
eval,exec,system; - новые файлы в папках загрузки с расширением
.php; - новые учётные записи администраторов, которых никто не создавал.
Журнал вторжений и логи веб-сервера
Если проактивная защита была включена, журнал вторжений покажет попытки атак и, возможно, успешную. Логи веб-сервера за период до обнаружения проблемы часто содержат сам момент проникновения — характерные запросы к уязвимым скриптам или подозрительные POST-запросы к необычным адресам.
Нужна помощь с Битрикс?
Восстановление
Порядок восстановления зависит от того, найдена ли точная точка входа.
| Ситуация | Что делать |
|---|---|
| Точка входа найдена и закрыта | Восстановить актуальные данные, оставив исправление |
| Точка входа не найдена | Восстановить из резервной копии, сделанной до заражения |
| Резервных копий чистого состояния нет | Полная переустановка ядра поверх текущих данных с проверкой каждого файла шаблона |
Если чистая резервная копия есть, восстановление из неё почти всегда надёжнее, чем попытка вручную вычистить все следы — злоумышленник мог оставить несколько точек доступа, а не одну очевидную.
После восстановления
- Обновите ядро и все модули до актуальных версий.
- Смените все пароли ещё раз, уже после восстановления.
- Включите двухфакторную аутентификацию для административных учётных записей.
- Включите проактивную защиту, если она не была включена.
- Проверьте права на файлы — не должно быть 777 нигде.
- Пересмотрите список активных учётных записей и удалите лишние.
- Настройте регулярные резервные копии, если их не было.
- Уведомите поисковые системы о восстановлении, если сайт попал в список опасных.
Как не допустить повторения
- обновления безопасности устанавливаются без задержек;
- решения из непроверенных источников не устанавливаются на боевой сайт;
- пароли администраторов уникальны и не совпадают с паролями других сервисов;
- резервные копии хранятся вне сервера и регулярно проверяются;
- права на файлы и папки минимальны из необходимых.
Частые ошибки при реагировании
- Удаление всех файлов и переустановка без анализа. Причина остаётся неизвестной, и заражение может повториться сразу же.
- Восстановление без смены паролей. Если утекли учётные данные, доступ у злоумышленника остаётся.
- Игнорирование предупреждения от хостинга. Промедление увеличивает ущерб и репутационные потери.
- Поиск только видимых последствий. Видимый дефейс страницы — не всегда единственное, что изменил злоумышленник.
Итог
Действия при взломе сайта на 1С-Битрикс строятся вокруг трёх задач: остановить дальнейшее распространение, найти реальную точку входа и восстановить сайт так, чтобы закрыть именно её, а не только удалить видимые следы. Резервная копия чистого состояния — главный ресурс в этой ситуации: она превращает часы разбирательства в минуты восстановления.