Integrating 1C-Bitrix with DDoS-Guard

Integration of 1C-Bitrix with DDoS-Guard

DDoS-Guard is CDN and anti-DDoS service popular in CIS due to Moscow servers and reasonable price. Like any reverse proxy it breaks Bitrix standard behavior: IP addresses, SSL termination, security and statistic module operation. Difference from Cloudflare — in details: different header for real IP, different IP ranges, different caching logic. Let's cover specifics.

Determining real client IP

DDoS-Guard passes client IP in X-Forwarded-For header. Unlike Cloudflare (which sends CF-Connecting-IP — one IP), X-Forwarded-For may contain chain: client, proxy1, proxy2. Real IP is first in list.

In /bitrix/php_interface/dbconn.php add before core load:

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

Spoofing issue: X-Forwarded-For header can be faked if server accepts connections bypassing DDoS-Guard. Must close direct server access — only DDoS-Guard IP ranges in firewall. Current ranges published in DDoS-Guard docs and via DNS query to _origin.ddos-guard.net.

SSL and redirects

DDoS-Guard terminates SSL on its side and may connect to origin server over HTTP (Flexible SSL mode) or HTTPS (Full SSL mode).

With Flexible SSL Bitrix doesn't know client came via HTTPS. Header X-Forwarded-Proto: https is sent by DDoS-Guard but Bitrix doesn't check it by default. Add to dbconn.php:

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

Without this: infinite redirect loop if "Redirect to HTTPS" enabled in admin, mixed content on pages, forms submit over HTTP.

Caching: differences from Cloudflare

DDoS-Guard automatically caches static files (JS, CSS, images). HTML not cached by default — unlike Cloudflare where you must explicitly disable PHP cache.

This simplifies integration: Bitrix composite cache works normally, no double caching occurs. But there's a nuance — DDoS-Guard caches static aggressively and after JS/CSS updates users may get old versions.

Solutions:

• File versioning — Bitrix adds ?v=timestamp to connected files automatically if using \Bitrix\Main\Page\Asset. Check custom templates do same.
• Purge cache via DDoS-Guard API — after deploy call API to clear cache for specific resources or whole domain.

Proactive protection and Web Application Firewall

DDoS-Guard filters L3/L4 attacks (SYN-flood, UDP-flood) and some L7 attacks (HTTP-flood). But DDoS-Guard WAF rules less granular than Cloudflare. Bitrix proactive filter remains important line.

Typical issue: DDoS-Guard during strong attack enables JavaScript Challenge — check page filtering out bots. If site is called by 1С (data exchange over HTTP) or payment system (callback) — they won't pass JS Challenge. Exclude 1С server and payment gateway IPs from check via DDoS-Guard settings ("IP whitelist").

Statistics module and geolocation

Module statistic determines geolocation by IP. If REMOTE_ADDR not redefined — all visitors geolocked to DDoS-Guard IP (Moscow or Rostov-on-Don). After proper header configuration geolocation works normally.

Module sale uses geolocation to auto-determine delivery city. Without IP fix dealer from Brest will see "Moscow" in city field at checkout.

Monitoring and debugging

After connecting DDoS-Guard add checks:

Timeline