Багаторівневий захист для 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. Адміністратор проєкту.

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