Взломали сайт на 1С-Битрикс: что делать в первые часы и как восстановить

Пошаговый план для владельца бизнеса, если сайт заражён, редиректит на спам или отдаёт вредоносный код

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

• Зафиксируйте симптомы, время обнаружения и сохраните журналы.
• Изолируйте уязвимый участок или временно закройте сайт технической страницей.
• Смените с доверенного устройства пароли, ключи и активные сессии.
• Найдите точку входа и все точки закрепления, затем восстановите проверенную версию.
• Обновите платформу и модули, проверьте настройки защиты и наблюдайте за сайтом после запуска.

Ниже разобран порядок действий и проверки, по которым можно понять, что восстановление завершено, а причина инцидента закрыта.

Кому и зачем полезна эта статья

Материал написан для владельцев сайтов и интернет-магазинов на 1С-Битрикс, а также для маркетологов и руководителей, которые обнаружили признаки взлома и не знают, что делать в первые часы. Здесь нет пошаговых команд для консоли — вместо этого разобрана логика действий: что важно сделать сразу, что можно доверить штатным средствам платформы, а где без участия разработчика или специалиста по безопасности не обойтись.

Как понять, что сайт действительно взломан

Симптомы редко возникают по отдельности — обычно это связка из нескольких признаков:

• Редиректы посетителей на посторонние сайты — фарму, казино, ставки, взрослый контент.
• Новые файлы в каталогах /upload/, /bitrix/, /local/, которых там не должно быть.
• Странное поведение форм, корзины или других компонентов — часто это следствие внедрения кода в шаблоны.
• Подозрительные конструкции в init.php, .htaccess, header.php — вызовы eval, base64_decode, gzinflate и подобные признаки обфускации.
• Новые пользователи в админке, которых никто не создавал.
• Предупреждения от поисковых систем: Google Search Console и Яндекс.Вебмастер показывают предупреждения о вредоносном ПО и взломанном контенте, а сами симптомы — не просто «глюки», а признаки активного вредоносного кода.

Google отдельно поясняет, что при подключении сайта к Search Console владелец получает уведомления о подозрительных действиях — взломах, фишинге и социальной инженерии, а браузер Chrome при этом может показывать пользователям предупреждение о том, что сайт может быть взломан или заражён. Раздел «Проблемы безопасности» в Search Console — первое место, куда стоит заглянуть: если Google обнаружил, что сайт взломан или опасен для посетителей, страницы в выдаче помечаются значком предупреждения. [6]

Заражение может затрагивать несколько файлов, учётных записей или механизмов закрепления. Поэтому удаление одного найденного файла ещё не подтверждает очистку: дополнительно проверяют каталоги загрузок и кэша, /local/php_interface/, задания, пользователей, базу и журналы.

Как работает типичная атака на Bitrix-сайт

У инцидента обычно есть три части: первоначальный доступ, закрепление и использование полученного доступа. Первоначальной причиной может стать уязвимый модуль, скомпрометированная учётная запись, открытый служебный интерфейс или небезопасная доработка.

После входа злоумышленник может создать дополнительную учётную запись, изменить планировщик заданий, добавить веб-шелл или изменить файлы и записи в базе. Поэтому удаление одного заметного файла ещё не доказывает, что доступ закрыт.

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

Что делать в первые часы

Шаг 1. Зафиксируйте состояние, не начинайте чистку вслепую

Первая ошибка, которую совершают под давлением паники, — начать удалять «подозрительные» файлы, не разобравшись в масштабе. Правильная последовательность иная: сначала ограничить ущерб, сохранить текущее состояние и логи, восстановить временную линию событий и определить точку входа — и только после этого приступать к восстановлению. [1]

Практически это означает:

• Сделать резервную копию сайта в текущем, заражённом виде и отдельно скопировать логи веб-сервера — это материал для расследования, даже если в финальную версию сайта эти файлы не попадут.
• Зафиксировать симптомы и точное время обнаружения: какие URL пострадали, какие скриншоты и предупреждения есть, с каких IP шли подозрительные запросы.
• Учитывать, что момент реального взлома почти всегда раньше момента, когда проблему заметили — а значит, несколько последних резервных копий тоже могут быть скомпрометированы.

Шаг 2. Изолируйте сайт и отключите скомпрометированные каналы доступа

Также стоит:

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

Шаг 3. Смените все пароли и ключи доступа

Доступы ротируют по согласованному плану: сначала создают рабочий доверенный канал для команды, затем меняют административные учётные записи, SSH-ключи, доступ к хостингу и почте. Пароль базы, API-ключи и секреты интеграций обновляют вместе с конфигурацией приложения и сразу проверяют ключевые сценарии, чтобы сайт сохранил работоспособность.

Поиск и удаление вредоносного кода

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

В актуальных версиях «1С-Битрикс» поиск троянов входит в штатные средства безопасности. Он помогает находить подозрительные участки, однако результат сканера нужно проверять вручную: возможны как ложные срабатывания, так и незамеченные точки закрепления. [2]

Контроль целостности сравнивает текущее состояние с заранее созданным файлом проверки. Он полезен, только если контрольный файл сформирован в доверенном состоянии и хранится так, чтобы злоумышленник не мог незаметно заменить его. [3]

Почему одного восстановления из резервной копии недостаточно

Копию сначала проверяют, затем восстанавливают в изолированной среде и закрывают установленную причину инцидента. Возврат уязвимой версии с прежними ключами способен снова открыть тот же путь атаки. После восстановления нужны обновления, смена доступов, проверка журналов и наблюдение за повторными признаками.

Настройка защиты после восстановления

Панель безопасности и проактивный фильтр

Панель безопасности показывает состояние настроек и рекомендуемый уровень защиты. В документации платформы используются уровни «начальный», «стандартный», «высокий» и «повышенный». Их включение не заменяет проверку собственного кода, модулей и серверной конфигурации. [4][10]

Проактивный фильтр снижает риск ряда типовых атак на входные данные. Дополнительно проверяют журнал событий, двухэтапную авторизацию администраторов, права файлов, активные сессии и доступность служебных интерфейсов. [5]

Резервное копирование как страховка, а не панацея

Частоту копирования выбирают по RPO — допустимому объёму данных, который бизнес готов потерять. Для магазина с частыми заказами интервал обычно короче, чем для редко обновляемого сайта.

Копии хранят отдельно от рабочего сервера и защищают другим набором доступов. Готовность подтверждает учебное восстановление: на изолированной площадке разворачивают копию и проверяют базу, файлы, вход, оформление заказа и интеграции.

Если есть подозрение на утечку персональных данных клиентов

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

Если расследование подтверждает инцидент с персональными данными, оператор действует по статье 21 152-ФЗ: направляет первичное уведомление в установленный срок и результаты внутреннего расследования — следующим сообщением. Техническую фиксацию событий лучше вести вместе с ответственным за персональные данные и юристом, чтобы не подменять установленный факт предположением. [8]

Типичные ошибки при реагировании на взлом

• Удаление файлов без анализа. Так легко стереть улики, которые помогли бы найти точку входа и все точки закрепления, а сам бэкдор при этом может остаться незамеченным в другом каталоге.
• Восстановление из копии без устранения причины. Уязвимый модуль, прежний ключ или сохранённая точка закрепления способны снова открыть доступ после запуска.
• Игнорирование предупреждений поисковых систем. Даже после очистки сайта отметка о взломе в выдаче не исчезает автоматически — нужно явно проверять статус в Search Console и Яндекс.Вебмастере и по необходимости запрашивать повторную проверку.
• Самостоятельные правки «вслепую» без уверенности в масштабе проблемы, а также попытки договориться с вымогателями, если в переписке появляются угрозы публикации данных, — оба сценария могут только усугубить ущерб.
• Забыть про юридическую сторону, когда затронуты персональные данные — технической очистки сайта недостаточно, если наступают обязательства по 152-ФЗ.

Когда достаточно своими силами, а когда нужна внешняя помощь

Штатный разработчик может вести восстановление, если команда умеет сохранить журналы, изолировать сайт, проверить файлы, базу и задания, определить точку входа и безопасно ротировать доступы. Количество заметно изменённых файлов само по себе масштаб инцидента не подтверждает.

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

«Пятый фактор» может провести техническое расследование, очистить и восстановить сайт, закрыть установленную причину и проверить результат после запуска. Состав работы зависит от фактических следов и архитектуры проекта.

Вывод

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

Источники

[1] NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations — https://doi.org/10.6028/NIST.SP.800-61r3

[2] 1С-Битрикс — Поиск троянов — https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=35&LESSON_ID=26614

[3] 1С-Битрикс — Контроль целостности файлов — https://dev.1c-bitrix.ru/user_help/settings/security/security_file_verifier.php

[4] 1С-Битрикс — Панель безопасности — https://dev.1c-bitrix.ru/user_help/settings/security/security_panel.php

[5] 1С-Битрикс — Журнал событий — https://dev.1c-bitrix.ru/user_help/settings/utilities/event_log/event_log.php

[6] Google Search Console — отчёт о проблемах безопасности — https://support.google.com/webmasters/answer/9044101?hl=ru

[7] Яндекс Вебмастер — угрозы безопасности — https://yandex.ru/support/webmaster/ru/service/security-threats

[8] Официальное опубликование правовых актов — 152-ФЗ, статья 21 — https://ips.pravo.gov.ru/api/ips/legislation/document?baseid=None&hash=98490812b3409e2a8d78a11ca9010f434ea3d9250a11dbbdb78690cd5551bdd6

[9] 1С-Битрикс — памятка по кибербезопасности — https://www.1c-bitrix.ru/download/files/cyber_ok.pdf

[10] 1С-Битрикс — модуль проактивной защиты — https://docs.1c-bitrix.ru/pages/security/proactive-security.html