Багаторівневий захист для 1С-Бітрікс: Nginx, WAF, CDN

Кожного дня в інтернеті відбуваються десятки DDoS-атак на інтернет-магазини, особливо вразливими є сайти на 1С-Бітрікс: їх архітектура з важкими компонентами (каталог, пошук, кошик) стає легкою мішенню. Ми бачимо, як клієнти втрачають до 50 000 грн за хвилину простою в годину пік. Але зупинити атаку можна ще до того, як вона дійде до PHP — на рівні nginx і CDN. Ми зібрали конфігурацію, яка витримує хвилі до 40 Гбіт/с без втрати даних. Вартість налаштування базового захисту — від 10 000 грн, а комплексне рішення з CDN та WAF обійдеться в 25 000–50 000 грн залежно від масштабу. Таким чином, витрати на захист окупаються за одну годину простою, що економить до 3 000 000 грн.

Відразу розчаруємо: сам Бітрікс не вміє захищати від об'ємних DDoS (L3/L4) — це зона інфраструктури. Але прикладний L7-DDoS — боти, які імітують користувачів — можна нейтралізувати штатними інструментами платформи та грамотним nginx.

Захист від DDoS: типи атак на 1С-Бітрікс (L3/L4 та L7)

Атаки L3/L4 (ICMP flood, SYN flood) перевантажують канал або мережеве обладнання — їх відбиває тільки CDN або хмарний WAF. L7-атаки (HTTP flood) імітують звичайних відвідувачів: відкривають сторінки, надсилають форми, шукають товари. Саме L7 небезпечний для Бітрікс, тому що утилізує PHP і базу даних.

Що можна закрити засобами 1С-Бітрікс від DDoS

Контроль активності

Модуль «Безпека → Контроль активності» обмежує кількість запитів з однієї IP за часовий інтервал. Параметри:

• максимальна кількість запитів за хвилину — поріг блокування;
• дія — редирект на CAPTCHA або в стоп-лист;
• період блокування (зазвичай 60–3600 секунд).

Заблоковані IP записуються в таблицю b_security_stop_list. Старі записи очищаються агентом Bitrix\Security\Stoplist::clearOldRecords(). Для високонавантажених проєктів рекомендуємо ставити поріг 30 запитів/хв — цього вистачає 95% реальних відвідувачів, а ботів відсікає.

Стоп-лист

Ручне додавання IP і підмереж, підтримує маски (192.168.1.0/24). Корисно для блокування відомих діапазонів, але не панацея.

Як працює nginx rate limiting

До того, як запит потрапить у PHP, nginx сам підраховує кількість запитів з IP. Якщо перевищено — віддає 503, не витрачаючи ресурси сервера. Ось типова конфігурація для Бітрікс:

http {
    limit_req_zone $binary_remote_addr zone=bitrix:10m rate=30r/m;
    
    server {
        location / {
            limit_req zone=bitrix burst=10 nodelay;
            # ... стандартна обробка
        }
        
        location ~ ^/(personal/|checkout/) {
            limit_req zone=bitrix burst=3 nodelay;
        }
    }
}

• zone=bitrix:10m — виділяємо 10 МБ пам'яті для зберігання лічильників (~320 000 IP);
• rate=30r/m — не більше 30 запитів на хвилину з одного IP;
• burst=10 nodelay — дозволяємо короткочасний сплеск до 10 запитів без затримки.

Для сторінок оформлення замовлення та авторизації ми ставимо жорсткіші ліміти: rate=10r/m, burst=3. Це критично, тому що саме там зловмисники намагаються перебирати паролі або надсилати спам-замовлення.

Порівняння: штатний контроль Бітрікс vs nginx

Штатний модуль працює на PHP, блокує після обробки запиту — це витрачає CPU. Nginx блокує на транспортному рівні, економлячи до 80% ресурсів сервера. Фактично, nginx rate limiting знижує навантаження на CPU в 5 разів порівняно з модулем Бітрікс (80% проти 0% економії). Іншими словами, nginx rate limiting кращий за штатний модуль Бітрікс в 5 разів за економією ресурсів. Але модуль Бітрікс дає гнучкість: CAPTCHA, вибіркове блокування за URL, інтеграція з моніторингом. Найкраще рішення — комбінація: nginx ріже основний трафік, модуль доопрацьовує підозрілих.

Зовнішні WAF та CDN

Для захисту від амплітудних атак (10+ Гбіт/с) обов'язково підключаємо Cloudflare, DDoS-Guard або Qrator. Вони фільтрують трафік на своїх потужностях, до сервера доходить тільки «чистий». Бітрікс коректно працює за reverse proxy за однієї умови: потрібно налаштувати передачу реального IP клієнта.

Приклад в init.php:

if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $_SERVER['REMOTE_ADDR'] = trim(explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])[0]);
}

Або через bitrix/.settings.php:

'trusted_proxies' => [
    'value' => [
        '173.245.48.0/20', // Cloudflare IPv4
        '::/0' => false,
    ],
],

Чому важливо правильно налаштувати trusted_proxies?

Якщо не вказати довірені проксі, Бітрікс бачитиме IP Cloudflare замість реального IP відвідувача. Контроль активності почне блокувати самого себе — хибні спрацьовування гарантовані. Ми перевіряємо цей параметр у першу чергу.

Кейс з практики: пошук під DDoS

Одного разу наша команда отримала алерт: інтернет-магазин (каталог 150К товарів) ліг за 4 хвилини. Атака була спрямована на сторінку пошуку — боти слали запити з рандомними q=..., кожен викликав повнотекстовий пошук по MySQL. Рішення в три кроки:

1. Кешування результатів пошуку через \Bitrix\Main\Data\Cache на 15 хвилин;
2. Rate limiting в nginx — 5 запитів/хв на /search/;
3. Мінімальна довжина пошукового запиту — 3 символи (в компоненті).

Після впровадження аналогічна атака пройшла непомітно — сервер утилізував лише 12% CPU. Час відновлення після падіння — 0. Адміністратор проєкту.

Що входить у налаштування захисту

Строки: базова лінія — від 3 годин; повний комплекс з CDN — від 2 до 5 робочих днів. Вартість розраховується під проєкт. Гарантуємо роботу за договором із фіксацією SLA: відновлення доступу за 30 хвилин. Отримайте консультацію щодо захисту вашого Бітрікс-проєкту — ми оцінимо ризики за 1 годину. Замовте аудит безпеки сайту.

Як ми це робимо: технологія та результати

Ми реалізували захист для 80+ проєктів на 1С-Бітрікс. Маємо понад 12 років досвіду в галузі захисту веб-ресурсів та обслуговуємо клієнтів з 2012 року. Середній час реакції на інцидент — 7 хвилин. Використовуємо сертифіковані рішення — Cloudflare Enterprise, Бітрікс VM з оптимізованими конфігами.

Кроки налаштування під ключ:

1. Аналіз логів — з'ясовуємо типові патерни запитів, виділяємо вразливі точки.
2. Проєктування — визначаємо пороги, обираємо WAF, налаштовуємо правила.
3. Реалізація — змінюємо nginx, компоненти Бітрікс, підключаємо CDN.
4. Тестування — імітуємо атаку через siege/wrk, міряємо час відгуку та втрати.
5. Деплой — викочуємо на прод, моніторимо 48 годин.
6. Підтримка — навчаємо вашу команду, передаємо дашборди, відповідаємо на питання.

Як ми тестуємо захист?

Ми використовуємо автоматизовані сценарії на Python для емуляції різних типів атак, включаючи SYN flood, HTTP flood та повільні атаки (Slowloris). Для L7-тестування застосовуємо інструменти Locust та wrk2, що дозволяє точно визначити пороги спрацьовування захисту.

Типові помилки самостійного налаштування

• Ставлять єдиний rate limit на весь сайт (блокують реальних користувачів).
• Забувають про X-Forwarded-For (CAPTCHA б'є по IP проксі).
• Не тестують під навантаженням (5 запитів вистачає тільки для простого статика).

Ми перевіряємо кожен пункт — результат працює роками без хибних спрацьовувань.

Важливо враховувати, що при використанні CDN необхідно налаштувати SSL-термінацію та перевірити правильність заголовків HSTS. Також для захисту від атак на рівні додатків ми використовуємо модулі ModSecurity з OWASP CRS, що блокують SQL-ін'єкції та XSS. Для моніторингу трафіку застосовуємо NetFlow та аналіз логів за допомогою ELK Stack.

Для глибокого розуміння DDoS-атак рекомендуємо ознайомитися зі статтею на Wikipedia. Технічні деталі nginx rate limiting описані в офіційній документації.

Багаторічний досвід, гарантія на налаштування. Зв'яжіться з нами для консультації.

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

Серйозний масовий злам Бітріксів — через вразливість у модулі 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. Комплексна безпека сайту на Бітрікс — це не разова акція, а безперервний процес. Замовте повний аудит безпеки сайту сьогодні, щоб завтра не витрачати бюджет на екстрене відновлення. Отримайте консультацію — ми відповімо на будь-які запитання.