Інтеграція 1С-Бітрікс з DDoS-Guard

Інтеграція 1С-Bitrix з DDoS-Guard

DDoS-Guard — CDN та anti-DDoS-сервіс, популярний у СНГ через сервери в Москві та прийнятну ціну. Як будь-який reverse proxy, він ломає стандартну поведінку Bitrix: IP-адреси, SSL-терміналізацію, роботу модулів security та statistic. Відмінність від Cloudflare — у деталях: інший заголовок для реального IP, інші IP-діапазони, інша логіка кешування. Розберемо специфіку.

Визначення реального IP клієнта

DDoS-Guard передає IP клієнта у заголовку X-Forwarded-For. На відміну від Cloudflare (який шле CF-Connecting-IP — один IP), X-Forwarded-For може містити ланцюг: клієнт, прокси1, прокси2. Реальний IP — перший у списку.

У /bitrix/php_interface/dbconn.php додайте до підключення ядра:

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

Проблема підробки: заголовок X-Forwarded-For може бути підроблений, якщо сервер приймає підключення в обхід DDoS-Guard. Обов'язково закрийте прямий доступ до сервера — тільки IP-діапазони DDoS-Guard у файрволі. Актуальні діапазони публікуються в документації DDoS-Guard та через DNS-запит до _origin.ddos-guard.net.

SSL та редиректи

DDoS-Guard терміналізує SSL на своєї стороні й може підключатися до origin-сервера по HTTP (режим «Гнучкий SSL») або HTTPS (режим «Повний SSL»).

При гнучкому SSL Bitrix не знає, що клієнт прийшов по HTTPS. Заголовок X-Forwarded-Proto: https передається DDoS-Guard, але Bitrix його не перевіряє за замовчуванням. Додайте у dbconn.php:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
    && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Без цієї настройки: нескінченний цикл редиректів при ввімкненому «Перенаправленню на HTTPS» в админці, змішаний вміст на сторінках, форми відправляються по HTTP.

Кешування: відмінності від Cloudflare

DDoS-Guard кешує статику (JS, CSS, зображення) автоматично. HTML за замовчуванням не кешується — на відміну від Cloudflare, де потрібно явно вимикати кеш для PHP.

Це спрощує інтеграцію: композитний кеш Bitrix працює штатно, подвійного кешування не виникає. Але є нюанс — DDoS-Guard кешує статику агресивно, й після оновлення JS/CSS-файлів користувачі можуть отримати старі версії.

Рішення:

• Версіонування файлів — Bitrix додає ?v=timestamp до підключуваних файлів автоматично, якщо використовується \Bitrix\Main\Page\Asset. Перевірте, що кастомні шаблони теж це роблять.
• Purge-кеш через API DDoS-Guard — після деплою викличте API для скидання кешу конкретних ресурсів або всього домена.

Проактивний захист та Web Application Firewall

DDoS-Guard фільтрує L3/L4-атаки (SYN-flood, UDP-flood) та частину L7-атак (HTTP-flood). Але WAF-правила DDoS-Guard менш гранулярні, ніж у Cloudflare. Проактивний фільтр Bitrix залишається важливим рубіжем.

Типова проблема: DDoS-Guard при сильній атаці вмикає JavaScript Challenge — сторінку-перевірку, яка відсіює ботів. Якщо на сайт звертається 1С (обмін даними по HTTP) або платіжна система (callback) — вони не пройдуть JS Challenge. Виключіть IP-адреси 1С-сервера й платіжних шлюзів з перевірки через налаштування DDoS-Guard («Білий список IP»).

Модуль статистики та геолокація

Модуль statistic визначає геолокацію за IP. Якщо REMOTE_ADDR не перевизначений — усі відвідувачі будуть геолоковані по IP DDoS-Guard (Москва або Ростов-на-Дону). Після коректної настройки заголовків геолокація працює штатно.

Модуль sale використовує геолокацію для автоматичного визначення міста доставки. Без виправлення IP дилер з Бреста побачить «Москва» в полі міста при оформленні замовлення.

Моніторинг та налагодження

Після підключення DDoS-Guard додайте перевірки:

Терміни