Відновлення сайту після злому 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 місяців. Замовте аудит безпеки, щоб переконатися, що ваш сайт захищений.

Що робити, якщо сайт на Бітріксі вже зламали?

Серйозний масовий злам Бітріксів — через вразливість у модулі vote (BDU:XXXX-05127). Через неї заливали веб-шели пачками. Причина? Власники не оновлювали ядро по півроку, а модуль голосувань стояв «про всяк випадок». Сертифіковані фахівці з 10-річним досвідом вибудовують комплексну безпеку сайту так, щоб між випуском патча та його застосуванням минали дні, а не місяці. І щоб навіть без патча сайт не ліг від типової атаки.

Ми гарантуємо: критичні вразливості закриваємо протягом доби, а повний аудит — за 1–2 дні. Замовте аудит безпеки прямо зараз — отримайте звіт із пріоритетами та план усунення.

Як налаштувати модуль «Проактивний захист»? (потужний, але не з коробки)

Модуль security встановлений майже на кожному Бітріксі, але правильно налаштований — хіба що на кожному п'ятому. Що конкретно потрібно ввімкнути та підкрутити:

• WAF (Веб-антивірус) — фільтрує SQL-ін'єкції, XSS, CSRF, path traversal на рівні OnPageStart. Ключове налаштування — режим «Активна реакція»: не просто логувати, а блокувати. У /bitrix/admin/security_filter.php перевіряємо, що всі типи атак увімкнені, а винятки — мінімальні.
• Контроль активності (/bitrix/admin/security_iprule.php) — ліміти на кількість запитів з одного IP. За замовчуванням 100 запитів на хвилину. Для API-ендпоінтів, куди стукають мобільні додатки, потрібні винятки — інакше заблокуєте своїх же користувачів.
• 2FA — OTP через Google Authenticator. Вмикається в налаштуваннях користувача. Для групи «Адміністратори» робимо обов'язковим через OnAfterUserAuthorize — без другого фактора в адмінку не пускаємо.
• Контроль цілісності (/bitrix/admin/security_file_verifier.php) — хеші системних файлів. Якщо хтось змінив файл у /bitrix/modules/ — система помітить. Запускаємо перевірку по cron щоденно через агент CSecurityFileVerifier::Verify().
• Стоп-лист — b_security_filter_stoplist. Автоматичне блокування IP при спрацюванні WAF. Ручне додавання підмереж — коли бачимо сканери.
• Журнал безпеки — b_event_log. Хто, коли та що змінював в адмінці. Зберігання мінімум 90 днів. При розслідуванні інциденту — безцінно.

Що включає аудит безпеки сайту Бітрікс?

Серверний рівень — тут найчастіше і діри:

• phpinfo() доступний по /info.php або /phpinfo.php — зустрічається на кожному третьому проєкті. Атакуючий отримує версію PHP, шляхи, модулі, конфігурацію. Видаляємо.
• display_errors = On на продакшні — стектрейси зі шляхами до файлів та іменами таблиць відлітають користувачеві в браузер.
• PHP-функції exec, system, passthru, proc_open не відключені в php.ini. Якщо веб-шел все-таки заллють — з цими функціями він отримає повний контроль над сервером.
• Версія PHP < 8.1 — без security-апдейтів. PHP 7.4 більше не підтримується, але досі живе на чверті проєктів.

Рівень додатку:

• Застарілі модулі: vote, forum, blog — часто стоять невикористовувані, але з активними обробниками. Деактивуємо та видаляємо.
• Кастомний код: grep по $DB->Query( з конкатенацією $_REQUEST — класична SQL-ін'єкція. Мають бути $DB->ForSql() або D7 ORM.
• Завантаження файлів: якщо CFile::CheckFile() не викликається або перевіряє лише розширення без MIME-типу — через форму зворотного зв'язку заллють .php файл.
• dbconn.php та .env — мають бути закриті правилами веб-сервера. Перевіряємо: curl https://site.ru/bitrix/.settings.php не повинен віддавати нічого, окрім 403.

SSL/TLS:

• Перевірка через SSL Labs — рейтинг A або вище.
• HSTS з max-age від 31536000 (рік).
• Редирект HTTP -> HTTPS на рівні Nginx, не на рівні Бітрікс.

Результат аудиту — звіт із пріоритетами: Critical / High / Medium / Low. Критичні закриваємо в перший день. Замовте аудит — оцінимо ваш проєкт за 1-2 дні.

Лікування зламаних сайтів — протокол дій

Сайт уже скомпрометований — SEO-спам, редиректи на казино, веб-шел в /upload/. Порядок дій:

1. Ізоляція — знімаємо сайт, ставимо заглушку. Якщо шкідливе ПО шифрує файли або поширюється — кожна хвилина на рахунку.
2. Визначення вектора — логи доступу (access.log), логи помилок, b_event_log. Шукаємо POST-запити до нетипових файлів, звернення до /upload/*.php, підозрілі user-agent.
3. Пошук шкідливого коду — grep -r "eval(base64_decode" /home/bitrix/www/ — класика. Також шукаємо assert(, preg_replace з модифікатором e, ${"_GET"}, обфусковані змінні виду $GLOBALS['x46x65'].
4. Перевірка БД — b_iblock_element_property та b_iblock_element на ін'єктовані скрипти та приховані посилання. SELECT * FROM b_iblock_element WHERE DETAIL_TEXT LIKE '%<script%' AND DETAIL_TEXT NOT LIKE '%bitrix%'.
5. Чищення або відновлення — якщо зараження масштабне, простіше відновити з чистого бекапу та накатити лише контентні зміни з БД.
6. Закриття вразливості — оновлення ядра, видалення невикористовуваних модулів, правка кастомного коду.
7. Запит пересканування — Google Search Console → «Запросити перевірку», Яндекс.Вебмастер → «Я все виправив».

Профілактичний аудит обходиться у 10 разів дешевше, ніж ліквідація наслідків зламу. Один з клієнтів зазначив: після аудиту ми спимо спокійно, знаючи, що сайт захищений.

Як захистити сайт на Бітріксі від DDoS?

• Cloudflare / DDoS-Guard / Qrator — проксіювання трафіку. L3/L4 атаки фільтруються на їхньому боці. L7 — через правила та challenge-сторінки. Важливо: після підключення приховати реальний IP сервера, інакше сенс втрачається.
• Rate limiting на Nginx: limit_req_zone для /bitrix/admin/, /api/, форм. Окремі ліміти для авторизованих та анонімних користувачів.
• CAPTCHA — \Bitrix\Main\Captcha\CaptchaManager для форм Бітрікс або reCAPTCHA v3 для кастомних. v3 не дратує користувачів — працює у фоні.
• Bot management — пропускаємо Googlebot, YandexBot (перевірка через reverse DNS), блокуємо сканери та скрейпери за User-Agent та поведінкою.

Порівняння: rate limiting на Nginx у 5 разів ефективніший за стандартний захист від перебору паролів у Бітріксі, оскільки зрізає атаку до того, як вона дійде до PHP.

Резервне копіювання — останній рубіж

• Щоденні бекапи: файли через rsync + дамп PostgreSQL/MySQL через pg_dump/mysqldump.
• Зберігання в ізольованому S3-сумісному сховищі. Ключове слово — ізольованому. Якщо бекапи лежать на тому ж сервері, що й сайт, зломщик видалить і їх.
• Ротація: daily × 7, weekly × 4, monthly × 12.
• Тестування відновлення — раз на квартал розгортаємо бекап на тестовому сервері. Бекап, з якого неможливо відновитися, — просто файл на диску. Ми гарантуємо відновлюваність кожного бекапу.
• Моніторинг: якщо бекап не пройшов — алерт у Telegram протягом години.

Моніторинг — виявити до того, як зателефонує клієнт

• Uptime — перевірка кожні 60 секунд через UptimeRobot / Zabbix / кастомний скрипт. Алерт у Telegram + дзвінок при даунтаймі > 5 хвилин.
• Файловий моніторинг — inotify (Linux) або cron + md5sum по критичних директоріях. Новий .php у /upload/? Алерт негайно.
• Сканування на малварь — AI-BOLIT або ClamAV за розкладом. Перевірка і файлів, і бази.
• SSL-сертифікат — попередження за 30/14/7 днів до закінчення. Let's Encrypt оновлюється автоматично через certbot, але certbot теж може зламатися.
• Блеклісти — перевірка домену та IP у Google Safe Browsing, PhishTank, Spamhaus. Потрапляння = втрата трафіку.

Чому важливий захист персональних даних?

• HTTPS everywhere — редирект на рівні Nginx.
• Шифрування в БД: паролі через \Bitrix\Main\Security\Password::hash() (bcrypt), токени — через openssl_encrypt.
• Політика конфіденційності + cookie-банер (модуль main підтримує з коробки через COption::SetOptionString("main", "cookie_agreement", "Y")).
• Журналювання доступу до ПД — хто та коли переглядав дані клієнтів.

Що входить у роботу (deliverables)

Строки

Працюємо разово та на абоненті з фіксованим SLA. Для абонентських клієнтів — виділений інженер, який знає проєкт. Наша компанія має понад 10 років досвіду з Бітрікс та понад 100 успішних проєктів. Зв'яжіться з нами — оцінимо ризики та складемо кошторис за 1-2 дні.

Чек-лист: 15 пунктів, які перевіряємо на кожному проєкті

1. Ядро 1С-Бітрікс та модулі — актуальна версія, невикористовувані модулі видалені.
2. Модуль security активний, WAF у режимі «Активна реакція».
3. 2FA увімкнена для всіх обліковок з доступом до адмінки.
4. /bitrix/admin/ закритий по IP або за додатковою HTTP-авторизацією.
5. Політика паролів: від 12 символів, mixed case, цифри, спецсимволи.
6. SSL/TLS: рейтинг A+ на SSL Labs, HSTS увімкнений.
7. Службові файли (dbconn.php, .settings.php, .env, бекапи, логи) — 403 з браузера.
8. Права: 644 файли, 755 директорії. Веб-сервер не owner системних файлів.
9. Security-заголовки: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, Referrer-Policy.
10. Контроль цілісності файлів — щоденна перевірка через агент.
11. Бекапи: щоденні, ізольоване зберігання, перевірка відновлюваності.
12. b_event_log — зберігання від 90 днів, регулярний перегляд.
13. PHP 8.1+, display_errors = Off, небезпечні функції відключені.
14. Моніторинг uptime + алерти при зміні файлів у /upload/.
15. Reverse proxy або CDN з DDoS-захистом для високонавантажених проєктів.

Оцінка вразливостей проводиться відповідно до методології OWASP Top 10 – Web Application Security Risks. Комплексна безпека сайту на Бітрікс — це не разова акція, а безперервний процес. Замовте повний аудит безпеки сайту сьогодні, щоб завтра не витрачати бюджет на екстрене відновлення. Отримайте консультацію — ми відповімо на будь-які запитання.