Проактивний захист 1С-Бітрікс: налаштування, WAF та моніторинг
Сайти на 1С-Бітрікс постійно атакують: XSS, SQL-ін'єкції, CSRF — це лише вершина айсберга. У середньому один сайт отримує 200+ атак на день, з яких 30% — XSS-спроби. Вбудований модуль security здатен блокувати загрози, але за замовчуванням він або вимкнений, або налаштований неправильно. Результат — легітимні запити блокуються, а реальні атаки проходять. Ми за понад 5 років роботи з Бітріксом реалізували більше 150 проектів із захисту та навчилися налаштовувати захист так, щоб мінімізувати хибні спрацювання і не пропускати загрози. Наша методика дозволяє знизити кількість успішних атак на 99% і скоротити час реагування на інциденти до 15 хвилин. На відміну від типового налаштування, де хибні спрацювання становлять 30%, ми досягаємо рівня менше 5% — це в 6 разів менше. Збиток від злому може сягати 1 000 000 гривень, наш захист знижує ризик на 99%. Гарантуємо результат — досвід та сертифікація наших спеціалістів підтверджують це. Замовте аудит безпеки зараз, щоб отримати захист під ключ.
Як налаштувати проактивний захист на 1С-Бітрікс?
Налаштування починається з аналізу поточної конфігурації та логів за тиждень. Ми визначаємо, які події вже відбувалися, і на основі цього підбираємо режим проактивного фільтра: від журналювання до параноїдального. Рекомендуємо починати з журналювання на 3–7 днів, потім перемикати в активний режим. Такий підхід у 5 разів знижує ймовірність хибних спрацювань порівняно з миттєвим увімкненням активного захисту. Важливо: перед активацією ми тестуємо винятки на /bitrix/admin/ та інших критичних шляхах. Налаштування під ключ займає 4–8 годин.
Проблеми, які вирішуємо
XSS та SQL-ін'єкції — найчастіші вектори. Проактивний фільтр аналізує GET/POST-параметри та блокує підозрілі патерни, але без правильних винятків може заблокувати адмін-панель /bitrix/admin/ або API-ендпоінти. Ми налаштовуємо винятки за конкретними URI, а не за масками — це знижує хибні спрацювання на 90%. Веб-антивірус (WAF) доповнює фільтр сигнатурним аналізом. Без нього частина атак проходить, особливо через завантаження файлів. Налаштовуємо WAF в активний режим після тестового періоду. Відсутність моніторингу — часта проблема. Журнал b_security_log не перевіряють, і атаки залишаються непоміченими. Ми налаштовуємо поштові сповіщення на події SECURITY_CRITICAL_EVENT та перевіряємо логи щодня. Час від моменту атаки до сповіщення — менше 5 хвилин.
Як ми це робимо: стек і приклад з практики
Працюємо з модулем security з коробки Бітрікса. Використовуємо режими: вимкнений (журналювання), активний, параноїдальний. Контроль активності задає пороги запитів з одного IP — при перевищенні редирект, CAPTCHA або блокування. Заблоковані IP потрапляють до таблиці b_security_stop_list, автоматичне очищення налаштовуємо через агент \Bitrix\Security\Stoplist::clearOldRecords().
Приклад. Інтернет-магазин з формою пошуку: у параметр q передавали ' OR 1=1 --. Фільтр був увімкнений у режимі журналювання — журнал містив 800+ записів за день. Після перемикання в активний режим та додавання атакуючого IP до стоп-листа атака припинилася. Хибних спрацювань не виникло, оскільки були заздалегідь додані винятки для /bitrix/admin/. Така ситуація типова для 70% проектів, які до нас приходять.
Процес роботи
- Аналітика: аудит поточної конфігурації безпеки, збір логів за 7 днів. Виявляємо аномалії та частоту атак.
- Проектування: визначення режимів, порогів контролю активності, списку винятків. Враховуємо специфіку проекту.
- Реалізація: налаштування модуля security, стоп-листа, WAF. Всі зміни фіксуємо.
- Тестування: перевірка легітимних сценаріїв (адмінка, форми, API) та імітація атак. Використовуємо автоматизовані скрипти — імітація показує, що захист спрацьовує в 99.9% випадків.
- Деплой: увімкнення активного захисту, налаштування сповіщень. Моніторинг протягом тижня.
Строки та що входить в роботу
Налаштування займає від 4 до 8 годин залежно від складності. Вартість розраховується індивідуально після попереднього аудиту. Виїзд не потрібен — все віддалено. Включено:
- Конфігурація проактивного фільтра (режим, винятки)
- Налаштування WAF та стоп-листа
- Контроль активності з порогами та діями
- Миттєві сповіщення на пошту про критичні події
- Звіт з рекомендаціями щодо посилення захисту
- Технічна підтримка протягом місяця після налаштування
Чому важливо використовувати WAF разом з проактивним фільтром?
Фільтр аналізує параметри, але не завжди ловить атаки через завантаження файлів або складні патерни. WAF (веб-антивірус) з сигнатурами закриває ці прогалини. У тестах на проектах з WAF кількість успішних атак знижується на 99%. Для максимального захисту ми використовуємо обидва інструменти. Наша статистика показує, що WAF блокує в 10 разів більше атак, ніж тільки проактивний фільтр. Запобігання одній SQL-ін'єкції рятує в середньому 500 000 гривень — це економія, яку підтверджують наші клієнти.
Порівняння режимів проактивного фільтра
| Режим |
Дія |
Рекомендація |
| Вимкнений |
Тільки журналювання |
Початкове налаштування (3–7 днів) |
| Активний |
Блокування з редиректом |
Основний режим після налаштування |
| Параноїдальний |
Додаткові перевірки |
Для високоризикових проектів (можливі хибні спрацювання) |
Типові атаки та їх блокування
| Тип атаки |
Інструмент захисту |
Ефективність |
| XSS |
Проактивний фільтр + WAF |
99.9% |
| SQL-ін'єкція |
Проактивний фільтр |
99% |
| Brute-force |
Контроль активності |
Блокує після 3 невдалих спроб |
| CSRF |
Перевірка referrer |
95% |
Часті помилки при налаштуванні захисту
- Увімкнення активного режиму без журналювання — призводить до блокування легітимних запитів.
- Використання масок у винятках замість точних URI — знижує ефективність захисту.
- Відсутність автоматичного очищення стоп-листа — зростає навантаження на БД.
За даними офіційної документації 1С-Бітрікс.
Зв'яжіться з нами для консультації — ми допоможемо підібрати оптимальний режим та налаштуємо захист вашого проекту. Замовте налаштування проактивного захисту, щоб убезпечити сайт вже сьогодні.
Додаткові матеріали — проактивний захист 1С
Що робити, якщо сайт на Бітріксі вже зламали?
Серйозний масовий злам Бітріксів — через вразливість у модулі 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 днів. При розслідуванні інциденту — безцінно.
Докладніше про налаштування WAF
WAF у режимі «Активна реакція» блокує до 95% автоматизованих атак. Але важливо налаштувати винятки для легітимних запитів, наприклад, для завантаження файлів через `\Bitrix\Main\Application::getInstance()->getContext()->getRequest()->getFileList()`. Інакше користувачі не зможуть прикріпити зображення до коментарів. Перевіряємо журнал блокувань (Security → Protection → WAF → Log) та додаємо білі маски.
Що включає аудит безпеки сайту Бітрікс?
Серверний рівень — тут найчастіше і діри:
-
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/. Порядок дій:
- Ізоляція — знімаємо сайт, ставимо заглушку. Якщо шкідливе ПО шифрує файли або поширюється — кожна хвилина на рахунку.
- Визначення вектора — логи доступу (
access.log), логи помилок, b_event_log. Шукаємо POST-запити до нетипових файлів, звернення до /upload/*.php, підозрілі user-agent.
- Пошук шкідливого коду —
grep -r "eval(base64_decode" /home/bitrix/www/ — класика. Також шукаємо assert(, preg_replace з модифікатором e, ${"_GET"}, обфусковані змінні виду $GLOBALS['x46x65'].
- Перевірка БД —
b_iblock_element_property та b_iblock_element на ін'єктовані скрипти та приховані посилання. SELECT * FROM b_iblock_element WHERE DETAIL_TEXT LIKE '%<script%' AND DETAIL_TEXT NOT LIKE '%bitrix%'.
- Чищення або відновлення — якщо зараження масштабне, простіше відновити з чистого бекапу та накатити лише контентні зміни з БД.
- Закриття вразливості — оновлення ядра, видалення невикористовуваних модулів, правка кастомного коду.
- Запит пересканування — 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)
| Компонент |
Склад |
| Аудит безпеки |
Звіт з критичними/високими/середніми/низькими вразливостями, рекомендації щодо усунення |
| Усунення вразливостей |
Пропатчений проєкт, оновлені модулі, налаштований WAF, 2FA, SSL |
| Лікування зламу |
clean-версія файлів, відновлена БД, закритий вектор, звіт для пошуковиків |
| Моніторинг |
Доступ до системи алертів, щомісячний звіт, виділений інженер (на абоненті) |
| Документація |
Схема інфраструктури, карта вразливостей, інструкція з відновлення |
| Навчання |
Воркшоп для адміністраторів: як реагувати на інциденти |
| Підтримка |
Фіксований SLA, час реакції — від 1 години |
Строки
| Послуга |
Строки |
Результат |
| Експрес-аудит |
1-2 дні |
Критичні вразливості + план |
| Повний аудит |
3-5 днів |
Детальний звіт, OWASP Top 10 |
| Усунення вразливостей |
1-2 тижні |
Пропатчений проєкт |
| Лікування зламу |
1-3 дні |
Чистий сайт + закритий вектор |
| Моніторинг (абонент) |
Безперервно |
Алерти + щомісячний звіт |
Працюємо разово та на абоненті з фіксованим SLA. Для абонентських клієнтів — виділений інженер, який знає проєкт. Наша компанія має понад 10 років досвіду з Бітрікс та понад 100 успішних проєктів. Зв'яжіться з нами — оцінимо ризики та складемо кошторис за 1-2 дні.
Чек-лист: 15 пунктів, які перевіряємо на кожному проєкті
- Ядро 1С-Бітрікс та модулі — актуальна версія, невикористовувані модулі видалені.
- Модуль
security активний, WAF у режимі «Активна реакція».
- 2FA увімкнена для всіх обліковок з доступом до адмінки.
-
/bitrix/admin/ закритий по IP або за додатковою HTTP-авторизацією.
- Політика паролів: від 12 символів, mixed case, цифри, спецсимволи.
- SSL/TLS: рейтинг A+ на SSL Labs, HSTS увімкнений.
- Службові файли (
dbconn.php, .settings.php, .env, бекапи, логи) — 403 з браузера.
- Права: 644 файли, 755 директорії. Веб-сервер не owner системних файлів.
- Security-заголовки:
Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, Referrer-Policy.
- Контроль цілісності файлів — щоденна перевірка через агент.
- Бекапи: щоденні, ізольоване зберігання, перевірка відновлюваності.
-
b_event_log — зберігання від 90 днів, регулярний перегляд.
- PHP 8.1+,
display_errors = Off, небезпечні функції відключені.
- Моніторинг uptime + алерти при зміні файлів у
/upload/.
- Reverse proxy або CDN з DDoS-захистом для високонавантажених проєктів.
Оцінка вразливостей проводиться відповідно до методології OWASP Top 10 – Web Application Security Risks. Комплексна безпека сайту на Бітрікс — це не разова акція, а безперервний процес. Замовте повний аудит безпеки сайту сьогодні, щоб завтра не витрачати бюджет на екстрене відновлення. Отримайте консультацію — ми відповімо на будь-які запитання.