Один інцидент безпеки — редиректи на фішинг або падіння продуктивності — може коштувати бізнесу від 100 000 рублів за добу простою. Ми це знаємо: за 10+ років провели понад 500 аудитів Бітрікс-проектів. У кожному другому знаходили критичні вразливості: від XSS до SQL-ін'єкцій, від підміни прав доступу до повністю відкритої адмінки з паролем за замовчуванням. Усунення вразливостей — не разова дія, а системний процес. Ми не просто закриваємо діри, а впроваджуємо комплекс заходів: харденінг, моніторинг цілісності, проактивний фільтр. Це знижує ризик повторного зараження на 90%. Вартість такого підходу — частки відсотка від обороту, а економія на одному інциденті перекриває всі витрати. Наша команда використовує сучасні інструменти: сканери вразливостей, фазинг, ручний аудит коду. Це дозволяє знаходити навіть приховані проблеми. Безпека сайту — це не опція, а необхідність. Витік даних клієнтів може призвести до судових позовів і втрати репутації. Впровадження заходів захисту окупається за один інцидент. Перевірте свій сайт вже сьогодні — не чекайте, поки зломщики знайдуть брешу. Ми пропонуємо повний цикл: від аудиту до харденінгу та пост-інцидентного аналізу. Нижче — що ми робимо, як і які результати гарантуємо.
Типові вразливості на Бітрікс-сайтах
За нашою статистикою, 70% проектів містять XSS-вразливості. Міжсайтовий скриптинг (XSS) виникає при виведенні даних з $_GET/$_POST без екранування в кастомних компонентах і шаблонах. Приклад:
// Вразливо: echo $_GET['search']; // Правильно: echo htmlspecialchars($_GET['search'], ENT_QUOTES, 'UTF-8'); // Або через Бітрікс D7: echo \Bitrix\Main\Text\HtmlFilter::encode($_GET['search']); Рефлективний XSS в URL сторінки пошуку — типовий вектор. Перевірте всі параметри URL, які виводяться в шаблоні.
SQL-ін'єкції — зустрічаються в 30% проектів. Застаріли при використанні D7 ORM, але живі в старому коді з $DB->Query():
// Вразливо: $DB->Query("SELECT * FROM b_user WHERE LOGIN = '" . $_POST['login'] . "'"); // Правильно: $DB->Query("SELECT * FROM b_user WHERE LOGIN = '" . $DB->ForSql($_POST['login']) . "'"); PHP-ін'єкції через завантаження файлів — відсутність перевірки розширень при завантаженні через кастомні форми. Файл shell.php.jpg може бути перейменований і виконаний.
IDOR (небезпечні прямі посилання на об'єкти) — запити виду /order/?ID=12345 без перевірки належності замовлення поточному користувачеві. У стандартних компонентах Бітрікс це закрито, в кастомних — часто ні.
Як ми усуваємо зараження?
Якщо сайт вже заражений — послідовність дій:
- Ізоляція: перевести в режим обслуговування або закрити зовнішній доступ.
- Пошук шкідливого коду:
find /var/www -name "*.php" -exec grep -l "base64_decode|eval|system|exec" {} \; - Аналіз дат зміни: файли, змінені після дати останнього деплою — підозрілі.
- Порівняння з чистим дистрибутивом: завантажте чисту версію Бітрікс і порівняйте файли ядра через
diff -r. - Зміна всіх облікових даних: паролі адміністраторів, ключі API, пароль БД, FTP-доступ.
- Оновлення ядра та модулів до актуальних версій.
Таблиця b_security_log — перевірте події до моменту зараження. Часто видно IP, з якого експлуатувалася вразливість.
Що входить у повний харденінг?
Набір заходів, який закриває 90% типових векторів атак. Простий сайту на добу при зараженні обходиться бізнесу у великі суми — втрата продажів та репутаційні витрати.
| Захід | Опис | Термін виконання |
|---|---|---|
| Налаштування прав доступу | chmod 755 для папок, 644 для файлів, 440 для конфігів |
1–2 години |
| Блокування PHP в upload/ | Через nginx/apache | 30 хвилин |
| Увімкнення проактивного фільтра (WAF) | Налаштування правил, тестування | 3–4 години |
| Моніторинг цілісності | inotify + модуль Контроль цілісності | 4–6 годин |
| Аудит кастомного коду | Перевірка компонентів, подій, агентів | від 8 годин |
| Оновлення ядра та модулів | До останньої стабільної версії | 2–4 години |
Чому харденінг необхідний?
Після харденінгу сайт відповідає стандартам OWASP Top 10 та вимогам 54-ФЗ. 90% типових атак блокуються автоматично. Докладніше про типи атак можна прочитати у Вікіпедії: Cross-site scripting та SQL injection.
Практичний кейс: редиректи для ботів
Наш клієнт — великий інтернет-магазин на редакції «Бізнес Плюс». Симптом: періодично з'являються редиректи на сторонні сайти, але тільки для пошукових ботів (User-Agent). Сканер Бітрікс — чисто. Аналіз файлів за датою зміни виявив модифікований /bitrix/modules/main/include/prolog.php — в нього був інжектований код з перевіркою User-Agent та редиректом. Додатково: backdoor у /bitrix/components/bitrix/main.include/component.php. Вектор входу — скомпрометований FTP-пароль хостингу (пароль, який не змінювали кілька років, що витік через інший сервіс).
Виправлення: відновлення файлів ядра з еталонного дистрибутива, зміна всіх паролів, увімкнення двофакторної автентифікації для FTP та SSH, налаштування SFTP з ключовою автентифікацією замість паролів.
Превентивні заходи після усунення
- Моніторинг цілісності файлів: налаштуйте
inotifywaitабо використовуйте модуль «Контроль цілісності» в Бітрікс. Це в 10 разів швидше, ніж ручна перевірка раз на місяць. - WAF: увімкніть та налаштуйте проактивний фільтр в активний режим.
- Регулярні оновлення: підпишіться на розсилку security-оновлень Бітрікс.
- Обмеження доступу: FTP/SSH тільки з конкретних IP, деплой через CI/CD без постійного FTP-доступу.
Додатково рекомендуємо ознайомитися з документацією Бітрікс з безпеки.
Терміни виконання
| Завдання | Термін |
|---|---|
| Усунення конкретної вразливості в коді | 2–4 години |
| Очищення від зараження + аудит | 1–2 робочих дні |
| Повний харденінг після інциденту | 3–5 робочих днів |
Терміни залежать від ступеня зараження, обсягу кастомного коду та наявності резервних копій до зараження.
Замовте аудит безпеки вашого Бітрікс-сайту під ключ — отримайте детальний звіт і план усунення вразливостей. До харденінгу входить також оцінка проекту. Пишіть нам для консультації.







