Відновлення сайту після злому 1С-Бітрікс

Відновлення сайту після взлому 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/.

Аналіз вектора атаки

Без розуміння того, як саме проникли на сайт, відновлення безглуздо — взломають повторно через ту ж дирку.

Типові вектори для Бітрікса:

Аналізуйте 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/ перечеркує всю роботу.