Чистка сайта на 1С-Битрикс от веб-шеллов: порядок, при котором заражение не возвращается

Главная ошибка при чистке — начинать с удаления найденных файлов. Через несколько дней заражение возвращается, потому что вход остался открыт. Разбираем порядок, при котором этого не происходит.

Порядок ниже собран по результатам двух реальных чисток одного сайта. В первый раз сайт вычистили — и через несколько дней заражение вернулось: файл пережил чистку в папке с бэкапом деплоя внутри вебрута. Во второй раз нашли настоящую причину — небезопасный вызов unserialize() в ajax-файле решения. После патча повторов не было.

Шаг 0. Снять копию «как есть»

До любых изменений сделайте полную копию файлов и базы. Она нужна:

• чтобы разобрать инцидент, если после чистки появятся вопросы;
• чтобы восстановить случайно удалённое;
• чтобы сравнить состояние до и после.

Копия хранится вне вебрута и вне сервера сайта.

Шаг 1. Собрать факты, пока они есть

Логи веб-сервера, журнал событий Битрикса, список пользователей, время последних изменений файлов. Это то, что позволит найти вход. Если логов нет — включите их прямо сейчас, дальше будет сложнее.

Что искать:

• всплески POST-запросов к одному адресу;
• обращения к файлам, которых нет в дистрибутиве;
• входы в админку с незнакомых адресов;
• события добавления файлов через админку.

Шаг 2. Найти точку входа

Основные варианты по нашей практике:

1. Уязвимость в коде решения или модуля. Например, небезопасная десериализация данных из POST-запроса. Атакующему не нужны пароли: он просто отправляет подготовленный запрос.
2. Бэкдор-администратор. Учётная запись создаётся заранее и живёт месяцами, файл загружается штатным файловым менеджером админки.
3. Утёкшие доступы. FTP или панель хостинга, пароль из старой переписки или с заражённого компьютера.
4. Крон панели хостинга. Задание, которое восстанавливает вредоносный файл после каждой чистки.

Пока вектор неизвестен, чистить бессмысленно.

Шаг 3. Собрать реестр файлов

Рабочий метод — сравнение с эталоном:

1. Скачайте дистрибутив вашей версии платформы и решения.
2. Сравните состав файлов с сайтом.
3. Всё, чего нет в эталоне и что не является вашим кодом, — в список на проверку.
4. Каждый подозрительный файл проверьте запросом: отвечает ли он на GET и POST.

Почему не сигнатуры: рабочий шелл может не содержать ни одного известного маркера. Почему не даты: mtime подделывается.

Отдельно проверьте:

• папки бэкапов деплоя внутри вебрута;
• каталоги загрузок, кэша и временных файлов;
• архивы .zip, .tar.gz, .sql в корне;
• файлы автозапуска: init.php, .htaccess, задания cron.

Шаг 4. Вынести находки в карантин

Не удалять, а перемещать в каталог вне вебрута с сохранением структуры путей. Причины:

• часть файлов может оказаться легитимной, и их нужно будет вернуть;
• карантин — это доказательная база, если инцидент разбирается дальше;
• по составу карантина видно, какие каталоги атакующий использовал.

Шаг 5. Закрыть вектор

Это главный шаг, без которого остальное бессмысленно:

• обновить платформу и решение либо применить точечный патч;
• для небезопасной десериализации — передавать ['allowed_classes' => false];
• отключить или закрыть уязвимые обработчики;
• удалить лишние учётные записи администраторов и включить журналирование;
• сменить все пароли: админка, FTP, SSH, база, панель хостинга;
• убрать бэкапы и архивы из вебрута;
• проверить задания cron панели хостинга.

Шаг 6. Проверить результат

• Повторный реестр файлов: расхождений с эталоном быть не должно.
• Проверка запросом по списку известных путей шеллов — ответы 404.
• Наблюдение неделю: не появляются ли новые файлы и подозрительные запросы.
• Отправка сайта на переобход в панелях вебмастеров, если были санкции.

Шаг 7. Сделать так, чтобы не повторилось

• Мониторинг доступности и изменений файлов с оповещением.
• Ежедневная проверка списка администраторов.
• Резервные копии вне сервера сайта, с проверкой восстановления.
• Регулярные обновления платформы и решения.
• Правило: никаких архивов и бэкапов внутри вебрута.

Частая ошибка: чистка без разбора

Если удалить найденное и не искать вход, сценарий повторяется: через несколько дней файлы возвращаются, а владелец сайта делает вывод, что «чистка не работает». Работает — но только вместе с закрытием вектора.

Если разбирать некому, мы делаем это в рамках аудита безопасности: находим вход, выносим находки в карантин, закрываем уязвимость и оставляем отчёт с тем, что нужно поддерживать дальше.