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

Первые действия: что делать прямо сейчас

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

Если сайт на 1С-Битрикс внезапно начал перенаправлять посетителей на казино, появился белый экран или реклама — это наверняка взлом. Часто владельцы сначала думают, что «упал хостинг» или «ошибка PHP», но на деле внутри уже работает вредоносный скрипт. Проверьте, не изменился ли index.php или .htaccess — именно туда злоумышленники внедряют редирект-код.

Другие признаки — невозможность войти в админку, подозрительные файлы в корне (например, wp-config.php-подобные на Битриксе), появление чужих учёток, массовая рассылка писем или неизвестные задания в cron. Всё это говорит, что сайт битрикс заражен и требует срочной диагностики.

Что нужно сделать немедленно, чтобы не усугубить ситуацию

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

Действие	Зачем это нужно
Отключите публичную часть сайта Включите режим обслуживания или временно переименуйте index.php.	Это остановит распространение вируса и убережёт клиентов от заражённых страниц.
Смените все пароли FTP, админка, база данных, SSH.	Злоумышленник часто сохраняет доступы после взлома — смена паролей перекроет ему путь обратно.
Проверьте права доступа к каталогам /bitrix, /upload, /local.	В этих директориях чаще всего скрываются вредоносные скрипты. Проверьте, чтобы не было прав на запись 777.
Сделайте резервную копию Даже если сайт заражён.	Позволит восстановить работу, если в процессе очистки что-то пойдёт не так.
Проверьте системные файлы init.php и include.php.	Там часто прячется вредоносный код — base64, iframe или eval. Проверьте на наличие подозрительных вставок.

Почему важно не трогать файлы руками и не удалять “лишнее”

Многие владельцы, заметив вирус на сайте Битрикс, начинают удалять всё подряд — и часто стирают системные файлы CMS. После этого даже специалисту восстановить сайт сложнее и дороже. Не редкость, когда вместе с вредоносным скриптом случайно удаляют urlrewrite.php, .access.php или компоненты шаблона.

Если вы не уверены, какие файлы безопасны, лучше заархивировать всё и передать на анализ. Я часто вижу случаи, когда вредонос прячется внутри комментариев PHP или base64-кода в шаблоне, который обычный глаз не заметит.

<?php
// Пример "зараженного" файла: злоумышленник мог вставить base64-пayload.
// Это безопасный демонстрационный пример — строка декодируется в обычный текст.
// **Никогда** не выполняйте подобные блока на боевом сервере.

$payload_b64 = 'W0VYQU1QTEVdIFRoaXMgUGF5bG9hZCBpcyBpbnRlbmRpb25hbGx5IGhhcm1sZXNzIC0gZG8gbm90IGV4ZWN1dGUu';
/*
  base64_decode($payload_b64) -> "[EXAMPLE] This Payload is intentionally harmless - do not execute."
  Часто вредоносный код выглядит так (пример вредоносного паттерна, НЕ выполнять):
  eval(base64_decode('...'));
  Но в статье этот фрагмент используем как иллюстрацию, не выполняя decode().
*/

echo '<!-- Демонстрация: содержимое payload (декодировано для показа) -->';
echo '<pre>' . htmlspecialchars(base64_decode($payload_b64)) . '</pre>';

?>

Когда уже пора звать специалиста

Если сайт битрикс не открывается после взлома, вы видите белый экран, а в логах — ошибки fatal error или unexpected symbol — значит, вирус уже нарушил структуру кода. Здесь самостоятельные действия могут только усугубить ситуацию.

Позвать специалиста стоит, если:

• Вы не можете войти в админку или восстановить доступ к FTP;
• На сайте появились подозрительные редиректы или реклама;
• Сайт стал отправлять письма без вашего ведома;
• Антивирус хостинга сообщает о заражении;
• После ваших попыток что-то исправить сайт перестал открываться вовсе.

На этом этапе важна скорость — чем дольше вирус остаётся на сервере, тем выше риск утечки данных клиентов и санкций от поисковиков. Поэтому если вы замечаете признаки взлома сайта на 1С-Битрикс — действуйте в течение первых часов.

Кстати, не каждая тревога означает взлом. У меня был случай, когда антивирус на хостинге принял обычный скрипт Prism.js за вредоносный код. В итоге сайт оказался в порядке, но я получил ценный опыт — подробно рассказал об этом в статье - подкасте «Как ложная тревога помогла укрепить безопасность сайта на 1С-Битрикс».

Почему сайт на Битриксе взломали

За годы работы я заметил одну закономерность: взломы редко бывают „магией“ — почти всегда это следствие простой человеческой ошибки или пренебрежения обновлениями. Кто-то оставил старый модуль без патча, кто-то использовал одинаковые пароли для FTP и админки, а кто-то установил сомнительный шаблон с незашифрованными вызовами eval().

Часто атака — это не единичное событие, а цепочка: уязвимость в модуле даёт доступ, затем злоумышленник кладёт бэкдор в upload или init.php, после чего начинается редирект/спам. Поэтому важно смотреть не только на «первые симптомы», но и на первопричину — где именно злоумышленник смог получить доступ.

Как злоумышленники попадают на сервер: FTP, админка, API

Коротко — самые популярные векторы проникновения. Слева — вектор, справа — типичная уязвимость / следствие.

Вектор доступа	Как это происходит	Что проверять
FTP / SFTP	Слабые или скомпрометированные пароли; использование FTP без шифрования; открытые порты.	Поменять пароли, включить SFTP/SSH, посмотреть логи подключения, ограничить по IP.
Админка Bitrix	Подбор паролей, уязвимости в сторонних модулях, незакрытые сессии.	Отключить общие логины, включить двухфакторную аутентификацию, просмотреть last_login и сессии.
SSH / Панель хостинга	Скомпрометированные учётные записи хостинга или слабые ключи SSH.	Проверить ключи, сменить пароли в панели, ограничить доступ по IP, смотреть логи действий.
Сторонние модули и шаблоны (Marketplace)	Уязвимость в модуле / шаблоне (необновлённый код, небезопасные eval/exec).	обновления модулей, проверки авторитетности поставщика, сканирование на необычные include/eval.
API / внешние интеграции	Слабые ключи API, публичные эндпоинты без защиты, уязвимые webhook'и.	Ревью прав доступа, rotation ключей, проверка логов запросов и частоты вызовов.
Cron / автоматические задачи	Подменённые cron-скрипты запускают вредоносный код или загружают payload'ы.	Проверка cron и анализ скриптов и права на исполнение.

Какие модули Bitrix чаще всего становятся целью атак

На практике чаще всего злоумышленники ищут «довольно предсказуемые» места в структуре Bitrix, где можно прятать код или получить RCE (remote code execution). Обратите внимание на:

• aspro-серии/шаблоны — популярность даёт широкую «площадку» для массовых атак;
• component.php и кастомные компоненты — если разработчик вставил небезопасный eval() или include($_GET['file']);
• bitrix/modules сторонних интеграций — устаревшие версии с известными CVE;
• модули импорта/экспорта Excel/CSV (частая причина) — обработка файлов без валидации может вести к исполнению кода;
• шаблоны, где встречается base64_decode, gzinflate, eval — это типичный паттерн сокрытия бэкдоров.

Грубо говоря, ищите любые упоминания таких паттернов в кодовой базе: eval(base64_decode(, gzinflate(base64_decode( и т.п. — это точка старта для поиска вредоносных вставок.

Как проверить, нет ли бэкдоров в include.php и init.php

Ниже — безопасный демонстрационный пример того, как может выглядеть замаскированный payload. Это иллюстрация — не запускайте такой код на продакшене. В статье используем Prism.js для подсветки:

<?php
// Пример замаскированного блока (демо, НЕ ВЫПОЛНЯТЬ)
// Злоумышленник может упаковать полезную нагрузку в base64 и декодировать её через eval.
// В демонстрации payload декодируется в безопасный текст для показа.
$payload_b64 = 'W0RFTU9fUEFZTG9BRF0gVGhpcyBpcyBhIHNhZmUgZGVtb24gc3RyaW5nLiBEbyBub3QgZXhlY3V0ZQ==';

/* Вредоносный паттерн (частая маскировка, НЕ ВЫПОЛНЯТЬ):
   eval(base64_decode('...'));
   или
   @eval(gzinflate(base64_decode('...')));
*/

// Безопасный вывод для статьи (только для демонстрации, не запускать в бою)
echo '<!-- ДЕКОДИРОВАННЫЙ PAYLOAD (демо) -->';
echo '<pre>' . htmlspecialchars(base64_decode($payload_b64)) . '</pre>';
?>

Алгоритм проверки файлов include.php и init.php:

1. Создайте локальную копию файлов (скачайте, не открывая в браузере);
2. Ищите паттерны: base64_decode(, eval(, gzinflate(, preg_replace('/.*/e') и т.п.;
3. Прогоните grep/AG/IDE: grep -R --line-number "base64_decode" . — это быстро выявляет подозрительные вставки;
4. Если находите блоки с закодированным содержимым — не выполняйте их. Скопируйте строку в безопасное окружение и декодируйте локально через инструменты, а не на сервере;
5. После обнаружения — пометьте файл как подозрительный, сделайте бэкап и передайте специалисту для анализа и безопасного удаления.

Как долго вирус живёт в системе Bitrix

Вредоносные скрипты могут оставаться в кодовой базе месяцами: бэкдоры прячутся в init.php, шаблонах или в /upload, периодически активируясь через cron или внешние вызовы. Даже если сайт «вроде работает», злоумышленник мог установить персистентный доступ — тогда сайт битрикс заражен "тихо", но опасно.

Типичные сроки и поведение вирусов:

• Несколько часов — активные редиректы и массовые рассылки (паническая фаза).
• 1–7 дней — установка персистентных бэкдоров, модификация файлов, распространение по шаблонам.
• Недельный+ период — интеграция с внешними сервисами, утечка данных, штрафы поисковиков и блокировки.

Что будет, если не лечить сайт вовремя

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

Время с момента заражения	Оценка риска	Что делать
Менее 24 часов	Низкий → Средний	Отключить публичную часть, сменить пароли, выполнить быструю самодиагностику и срочно связаться со специалистом.
1–3 дня	Средний → Высокий	Провести полный аудит файлов и cron, проверить базу данных, приоритизировать восстановление из бэкапа.
4–7 дней	Высокий	Возможна персистенция бэкдоров — необходим комплексный анализ, очистка, проверка логов и внешних интеграций.
Больше 7 дней	Критический	Увеличен риск утечки данных и компрометации поисковой выдачи — нужно срочное восстановление с аудитом и мониторингом.

Как удалить вирус с сайта Bitrix

Где искать вредоносный код (index.php, init.php, cron.php)

Когда сайт на 1С-Битрикс заражён, первый шаг — понять, где именно прячется вредоносный код. Чаще всего вирусы внедряются в ключевые файлы CMS: index.php, init.php, include.php и системные скрипты, запускаемые через cron.php. Эти файлы выполняются при каждом открытии сайта, поэтому даже небольшой внедрённый фрагмент вроде eval(base64_decode(...)) способен вызвать редиректы или скрытую загрузку вредоносных данных.

Ниже — таблица с типичными местами заражения и симптомами, по которым можно определить источник проблемы:

Файл / каталог	Что проверять	Типичные признаки заражения
/index.php	Первые и последние строки файла.	Подозрительный код с eval(), base64_decode(), неизвестные редиректы, iframe.
/bitrix/php_interface/init.php	Все нестандартные подключения и include-блоки.	Код с @include, error_reporting(0), скрытые base64-вставки — типичный бэкдор.
/local/ и /upload/	Проверить наличие PHP-файлов, которых быть не должно.	Посторонние .php в каталогах для загрузок, имена вроде img.php, cache.php.
/bitrix/modules/	Неофициальные или устаревшие модули.	Изменённые файлы без обновлений, встроенные eval или curl-запросы на сторонние домены.
/cron.php и планировщики	Скрипты, которые выполняются по расписанию.	Добавленные неизвестные задания, подозрительные shell-скрипты или обращения к внешним IP.

Как найти и удалить подозрительные скрипты вручную

Если антивирус хостинга сообщил о заражении или сайт битрикс редиректит на другие сайты, можно попробовать выполнить первичную проверку вручную. Откройте корневую папку сайта и отсортируйте файлы по дате изменения. Всё, что изменилось в день появления взлома, требует внимания. Начните с index.php и init.php — именно там чаще всего вставляют вредоносные строки, которые запускаются первыми.

Используйте поиск по содержимому: найдите в IDE или через SSH фразы base64_decode, eval(, gzinflate, str_rot13. Если видите такие конструкции, не удаляйте их вслепую — сначала закомментируйте, проверьте поведение сайта и сохраните резервную копию. После анализа можно безопасно удалить найденные фрагменты и заменить повреждённые файлы чистыми версиями из дистрибутива Bitrix.

Как использовать антивирус Bitrix и сторонние сканеры

Bitrix включает встроенный инструмент — «Антивирус», который проверяет шаблоны и компоненты на подозрительные вставки. Найти его можно в админке: Настройки → Проактивная защита → Антивирус. Включите регулярную проверку и активируйте опцию «Проверять новые файлы». Однако встроенный антивирус видит только часть угроз — для полной проверки стоит использовать внешние сервисы.

• VirusTotal — проверка отдельных файлов на вирусы (загрузите заражённый скрипт и получите отчёт по антивирусным базам);
• Sucuri SiteCheck — сканирование сайта онлайн на вредоносные скрипты и редиректы;
• Quttera Web Malware Scanner — анализ сайта на вредоносные iframe, eval и внешние загрузки.

Для локальной проверки можно использовать ClamAV или Imunify360. Они хорошо находят скрытые PHP-бэкдоры, особенно в случаях, когда сайт битрикс заражен трояном, а вредонос прячется в шаблонах.

Как очистить базу данных от следов взлома

Не все вирусы ограничиваются файлами — часть внедряется прямо в базу данных, например, в контент или настройки шаблонов. В таких случаях нужно проверить таблицы b_option, b_file, b_event и b_user на наличие подозрительных ссылок и PHP-вставок. Вредоносный код может храниться даже в полях с настройками модулей — именно поэтому после восстановления файлов важно очистить и БД.

Пошаговый подход:

Если после удаления вирусов сайт битрикс не открывается — восстановите систему из резервной копии и повторно проверьте файлы. Иногда вирус добавляет собственные cron-задания, которые возвращают вредонос при каждом запуске, поэтому важно проверять и задачи планировщика.

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

Вариант 1: восстановление из резервной копии

Если у вас есть свежая резервная копия сайта на 1С-Битрикс — это самый надёжный и безопасный способ вернуть сайт к жизни.

Главное — не пытаться поверх заражённой версии «накинуть» файлы из бэкапа: перед восстановлением обязательно удалите старую структуру или перенесите её в отдельную папку для анализа.

На большинстве хостингов восстановление выполняется через панель управления (ISPmanager, cPanel, Plesk) или через встроенный модуль «Резервное копирование» в админке Битрикс. Укажите путь к архиву, выберите базу данных и дождитесь окончания процесса — система сама развернёт файлы и структуру таблиц. После этого важно сразу сменить все пароли: FTP, SSH, доступ к БД и админке.

Вариант 2: ручное восстановление структуры сайта

Если резервной копии нет, восстановить сайт можно вручную — но делать это нужно аккуратно, шаг за шагом. Начните с загрузки чистого дистрибутива 1С-Битрикс с официального сайта. Разверните его в тестовой папке, затем перенесите из старого проекта только нужные директории: /upload (контент), /local/templates (ваш шаблон), /bitrix/php_interface/ (если не заражён). Всё остальное лучше взять из оригинала, чтобы не перенести бэкдор.

Далее подключите существующую базу данных и выполните синхронизацию — обновите структуру через «Проверку системы» в админке. Если появляются ошибки PHP или белый экран — проверьте логи /bitrix/php_interface/dbconn.php и настройки .settings.php.

Проверка корректности работы после восстановления

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

Ниже таблица с основными пунктами проверки после восстановления:

Что проверить	Как проверить	Что считается нормой
Главная страница и разделы	Откройте в браузере, следите за скоростью загрузки и редиректами.	Отсутствие автоматических переходов, корректное отображение верстки.
Админ-панель	Войдите в /bitrix/admin/, выполните пару операций (создание, редактирование страниц).	Без ошибок PHP, без неожиданных перезагрузок, интерфейс открывается быстро.
Формы обратной связи	Отправьте тестовое сообщение, проверьте журнал почты.	Письмо приходит корректно, не уходит в спам, нет массовых рассылок.
SEO и robots.txt	Откройте /robots.txt и /sitemap.xml, проверьте через Google Search Console или Яндекс.Вебмастер.	Нет внешних ссылок на сторонние домены, sitemap корректно индексируется.
Журнал событий и агенты	Просмотрите вкладку «Монитор производительности» и «Агенты».	Нет неизвестных заданий cron, фоновые процессы не создают лишнюю нагрузку.

Когда все пункты чек-листа выполнены, сайт можно считать безопасным. Рекомендую также включить мониторинг изменений файлов и периодически запускать встроенный антивирус Bitrix. Это поможет вовремя обнаружить новые угрозы, если злоумышленники попытаются вернуться.

Скачать инструмент для защиты сайта на 1С-Битрикс

Что это за скрипт и зачем он нужен

Для владельцев сайтов на готовых решениях АСПРО выпущен специальный скрипт, который автоматически исправляет уязвимости в шаблонах и компонентах. Он анализирует код, находит опасные вызовы unserialize() и добавляет к ним защиту от десериализации произвольных объектов. Такой способ помогает быстро закрыть критичные дыры в безопасности, не дожидаясь обновлений от разработчиков.

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

Какие проблемы он устраняет

Скрипт помогает устранить ряд уязвимостей, характерных для типовых решений:

• Добавляет параметр ['allowed_classes' => false] к вызовам unserialize();
• Фильтрует пользовательские данные в шаблонах и модулях;
• Блокирует выполнение PHP-вставок там, где должны быть только HTML или JS;
• Предотвращает внедрение вредоносного кода через сериализованные настройки;
• Снижает риск удалённого выполнения команд (RCE) в решениях АСПРО и аналогичных сборках.

Главная цель — уменьшить вероятность повторного взлома и обеспечить базовую защиту до следующего обновления CMS.

Для кого подходит этот способ

Инструмент рассчитан прежде всего на сайты, созданные на решениях АСПРО — Aspro: Next, Max, Digital и других. Именно в таких шаблонах чаще всего встречаются опасные вызовы unserialize() и недостаточная фильтрация данных. При необходимости можно запустить проверку и на других проектах — программа просто покажет, если найдёт похожие проблемы.

Как установить и запустить проверку

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

1. Скачайте архив fixit.zip и разместите его в каталоге /bitrix/tools/fixit/ или во временной папке.
2. Откройте в браузере https://ваш_сайт/bitrix/tools/fixit/index.php.
3. Дождитесь завершения проверки и просмотрите отчёт — он покажет все изменённые файлы.
4. Убедитесь, что сайт работает корректно (корзина, формы, поиск, каталог).
5. Удалите временные файлы инструмента и очистите кеш.

Пример официального архива: fixit.zip — распространяется бесплатно для клиентов решений АСПРО.

Проверка после обновления кода

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

Что проверить	Как проверить	Результат
Загрузка страниц	Откройте несколько разделов и убедитесь, что нет ошибок PHP и лишних редиректов.	Сайт открывается быстро, страницы работают корректно.
Журнал изменений	Посмотрите отчёт после запуска — там указаны все затронутые файлы.	Ошибок нет, изменения применены успешно.
Админ-панель	Перейдите в /bitrix/admin/ → «Проактивная защита».	Нет предупреждений об опасных вызовах или открытых уязвимостях.

Дополнительно можно провести внешний аудит:

• Sucuri SiteCheck — поиск вредоносных редиректов и скриптов;
• VirusTotal — проверка отдельных файлов;
• Quttera Malware Scanner — расширенное сканирование шаблонов и JS-кода.

Если после исправления проблема осталась

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

Как исправить пункты, которые вы не прошли

Если какие-то пункты не отмечены, начните с базового: смените слабые пароли, ограничьте доступ к админке и включите модуль «Проактивная защита». После этого проверьте каталоги /upload и /local — в них часто прячутся вредоносные файлы.

Как автоматизировать защиту и мониторинг

Чтобы не проверять вручную, настройте регулярный аудит безопасности:

• Установите фоновую антивирусную проверку через Imunify360 или ClamAV;
• Настройте уведомления о любых изменениях файлов на сервере;
• Включите автоматическое резервное копирование;
• Проверяйте отчёты безопасности в админке Битрикс не реже одного раза в неделю.

Как защитить сайт Bitrix от повторного взлома

Настройка модуля «Проактивная защита»

Модуль «Проактивная защита» — один из самых недооценённых инструментов безопасности в 1С-Битрикс. Его задача — блокировать типовые атаки: SQL-инъекции, межсайтовые скрипты (XSS), подмену данных и опасные POST-запросы. Если сайт уже однажды был скомпрометирован, включение этого модуля — первое, что стоит сделать.

Чтобы активировать защиту, откройте в админке раздел Настройки → Проактивная защита → Панель безопасности и отметьте пункты «Включить фильтр безопасности» и «Запретить выполнение опасных запросов». После активации сохраните настройки и перезапустите кеш. Уже одно это сокращает вероятность повторного заражения в несколько раз.

Как запретить выполнение PHP в upload и local

Каталоги /upload и /local часто используются злоумышленниками для загрузки вредоносных скриптов. Чтобы заблокировать их выполнение, достаточно добавить короткий фрагмент кода в файл .htaccess внутри этих папок:

# Защита от выполнения PHP в /upload и /local
<FilesMatch "\.php$">
    Deny from all
</FilesMatch>

Теперь любые PHP-файлы, загруженные пользователями, не смогут выполняться на сервере. Это одно из простейших, но крайне эффективных решений.

Регулярные обновления и аудит безопасности

Безопасность Bitrix во многом зависит от своевременных обновлений. Многие уязвимости закрываются именно в новых версиях модулей, но владельцы сайтов часто их не устанавливают месяцами. Обновление системы раз в 2-3 недели — это не формальность, а базовая профилактика.

Чтобы не забывать о проверках, стоит вести небольшой график аудитов и обновлений:

Периодичность	Что проверять	Результат
Каждую неделю	Ошибки в логах, странные задачи в cron, доступы FTP.	Поддерживается чистота и контроль.
Раз в месяц	Обновление модулей, CMS и шаблонов, анализ сторонних библиотек.	Закрываются актуальные уязвимости.
Раз в квартал	Полный аудит безопасности, сверка прав доступа, тест восстановления бэкапа.	Гарантия, что сайт можно восстановить даже после сбоя.

Системный подход даёт ощутимый эффект: вместо постоянного тушения «пожаров» вы переходите к стабильной и предсказуемой защите.

Как включить логирование изменений файлов

Логирование помогает отследить любые несанкционированные правки. Если в коде вдруг появляется подозрительная вставка, журнал покажет, кто и когда внёс изменения. Активировать можно через PHP-скрипт или агент, который будет записывать результаты в отдельный лог-файл:

<?php
AddEventHandler("main", "OnAfterFileSave", function($filePath) {
    $logFile = $_SERVER["DOCUMENT_ROOT"]."/bitrix/logs/file_changes.log";
    $entry = date("Y-m-d H:i:s")." — изменён файл: ".$filePath.PHP_EOL;
    file_put_contents($logFile, $entry, FILE_APPEND);
});
?>

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

Реальные примеры восстановления

Кейс: сайт взломали, на главной странице — чужой проект. Восстановлен за 1 день

Сайт строительной компании утром открылся… с чужим логотипом и ссылкой на турецкий магазин сантехники. Админка недоступна, index.php переписан, в корне десятки файлов с именами вроде wp-config.php и readme.html (классика подмена).

Кейс: сайт редиректил на казино — восстановлен за 3 часа

Интернет-магазин внезапно начал перенаправлять посетителей с мобильных устройств на сторонние сайты. Симптом — редирект только с телефонов, а в админке всё выглядело идеально.

Проверка показала: в шаблоне подключён js-файл с base64-кодом, внедрён через баннерную область. Вирус подменял скрипты Google Tag Manager и вёл на казино.

«Мы думали, что потеряли весь трафик, а оказалось — достаточно было найти одну строчку кода. Спасибо, что вернули продажи!»
— из отзыва владельца интернет-магазина мебели.

Кейс: вирус в init.php — полная очистка и защита за 1 день

Вирусное заражение через local/php_interface/init.php — частый сценарий. В этом случае злоумышленник внедряет обратное подключение к внешнему серверу и получает доступ к файлам.

<?php
@include base64_decode('aWYgKCFlbXB0eSgkX1NFUlZFUlsiUkVNT1RFX0FERFJFU1MiXSkpIHsgLy8g... ');
?>

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

Частые вопросы (FAQ)

Сайт на Битриксе внезапно редиректит на другие сайты. Это взлом?

В 9 из 10 случаев — да. Чаще всего вредонос прячется в шаблоне (JS со встроенным base64), в index.php или в local/php_interface/init.php. Для начала отключите публичную часть, смените пароли (FTP/SSH/БД/админка) и сделайте резервную копию текущего состояния.

Как отличить «ложную тревогу» от реального заражения?

Если редирект появляется только на мобильных, ночью или из поиска — это вирус. «Ложные» срабатывания чаще касаются подсветки кода (например, Prism) или инлайн-скриптов без выполнения. Проверьте логи веб-сервера, сравните хэши системных файлов и прогоните выборочно через VirusTotal.

В админку /bitrix/admin/ не зайти — что делать в первую очередь?

Отключите сайт (режим обслуживания), смените все доступы на уровне сервера, проверьте .htaccess и dbconn.php на подмену. Затем восстановите «чистые» версии ядра и шаблонов из бэкапа или дистрибутива и проверьте планировщик (cron/агенты) на подозрительные задания.

Можно ли «вылечить» без резервной копии?

Можно, но риск выше. Работайте в копии проекта: развёртывайте чистый дистрибутив, переносите контент и шаблоны по частям, сравнивайте файлы и чистите базу от iframe/<script>/серийных вставок. Если что-то идёт не так — откатывать сложнее без бэкапа.

Нужен ли специальный скрипт для исправления уязвимостей, если сайт на решениях АСПРО?

Да, на типовых сборках это помогает быстро закрыть опасные конструкции (например, неограниченный unserialize()). Но такой скрипт не заменяет обновления ядра/модулей и не лечит уже внедрённые бэкдоры — используйте его вместе с ручной проверкой.

Как убедиться, что вирус удалён полностью и сайт защищён от повторного взлома?

Проверьте: чистоту файлов (сравнение с дистрибутивом), отсутствие подозрительных задач в cron, очистку базы от вредоносных вставок, запрет выполнения PHP в /upload и /local, включённую «Проактивную защиту» и веб-антивирус. Плюс — поставьте мониторинг изменений файлов и регулярные бэкапы вне сервера.