Восстановление сайта после взлома 1С-Битрикс
Вы обнаружили, что сайт редиректит посетителей на посторонний ресурс, поисковик показывает «Этот сайт может угрожать безопасности вашего компьютера», или хостинг прислал уведомление о рассылке спама с вашего сервера. Всё это признаки компрометации. Восстановление — это не просто удаление вредоносных файлов, а полный цикл: изоляция, анализ вектора атаки, очистка, закрытие уязвимости и мониторинг. Пропуск любого этапа приводит к повторному взлому в течение дней.
Немедленные действия
1. Изолируйте сайт. Не удаляйте ничего. Сначала сохраните текущее состояние — оно нужно для анализа. Создайте полный дамп файлов и БД. Затем ограничьте доступ: поставьте заглушку через nginx (return 503) или .htaccess с Deny from all и Allow from вашего IP. Это предотвращает дальнейший ущерб и не даёт атакующему закрепиться.
2. Смените все пароли. Немедленно, до начала анализа:
- Пароли БД (в
.settings.phpиdbconn.php) - FTP/SSH-доступы
- Пароли административных учётных записей Битрикс
- API-ключи сторонних сервисов, если они хранились в конфигах
3. Проверьте, не добавлены ли SSH-ключи или cron-задачи. Атакующие часто добавляют свой публичный ключ в ~/.ssh/authorized_keys и cron-задачи для периодической загрузки бэкдоров. Проверяйте crontab -l для всех пользователей и содержимое /etc/cron.d/.
Анализ вектора атаки
Без понимания того, как именно проникли на сайт, восстановление бессмысленно — взломают повторно через ту же дыру.
Типичные векторы для Битрикс:
| Вектор | Признаки | Где искать следы |
|---|---|---|
| Устаревшая версия ядра с известной CVE | Версия ядра в /bitrix/modules/main/classes/general/version.php ниже актуальной |
Changelog обновлений безопасности 1С-Битрикс |
| Уязвимый сторонний модуль | Бэкдор в директории модуля | /bitrix/modules/vendor.module/ |
| Компрометация учётных данных | Авторизация с нетипичного IP | b_event_log, фильтр по AUDIT_TYPE_ID = 'USER_LOGIN' |
| Загрузка shell через форму | PHP-файл в /upload/ |
Поиск .php файлов в /upload/, /bitrix/tmp/ |
| SQL-инъекция | Изменённые данные в БД, новые администраторы | Таблица b_user — новые записи с ADMIN = Y |
Анализируйте access-логи веб-сервера за период, предшествующий обнаружению. Ищите POST-запросы к нестандартным URL, обращения к файлам в /upload/ с расширением .php, запросы с характерными паттернами (eval, base64, system).
Полная очистка файловой системы
Проверка ядра. Используйте встроенный инструмент /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/.
Восстановление и закрытие уязвимости
Вариант A: чистая переустановка ядра. Скачайте свежий дистрибутив ядра с 1c-bitrix.ru и замените директории /bitrix/modules/, /bitrix/components/, /bitrix/js/. Оставьте /bitrix/php_interface/ (но проверьте init.php) и /bitrix/templates/. Это гарантирует отсутствие модифицированных файлов ядра.
Вариант B: восстановление из бэкапа. Используйте бэкап, созданный до компрометации. Определите дату взлома по логам и восстановите файлы на эту дату. После восстановления обязательно обновите ядро до последней версии — иначе та же уязвимость будет эксплуатирована повторно.
Обязательные меры после очистки:
- Обновите ядро Битрикс до последней стабильной версии
- Удалите или обновите все сторонние модули
- Включите модуль
bitrix.security: WAF (проактивный фильтр), защита от фреймов, ограничение сессий по IP - Настройте права на файловую систему: директории
0755, файлы0644, владелец — не root - Закройте доступ к
/bitrix/admin/по IP через nginx/Apache - Запретите выполнение PHP в
/upload/: в nginx —location ~* /upload/.*\.php$ { deny all; }
Мониторинг после восстановления
Первые 2-4 недели — критический период. Настройте:
- Файловый мониторинг (inotify / AIDE / tripwire) — отслеживание изменений в
/bitrix/modules/и/bitrix/php_interface/ - Мониторинг access-логов на подозрительные POST-запросы
- Проверка
b_userна появление новых административных записей (через cron + скрипт) - Внешний мониторинг HTTP-заголовков — обнаружение несанкционированных редиректов
Повторный взлом после некачественной очистки — дело не «если», а «когда». Один пропущенный бэкдор в забытой директории /bitrix/backup/ перечёркивает всю работу.