Setting up DDoS protection in 1C-Bitrix

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1175
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    747
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

DDoS Protection Setup for 1C-Bitrix

A DDoS attack on a Bitrix site follows a recognizable pattern: first PHP-FPM load spikes, then the MySQL/PostgreSQL request queue builds up, and finally the server either stops responding or returns 502/503. Bitrix itself does not protect against volumetric DDoS — that is an infrastructure concern. However, application-layer L7 DDoS can be significantly mitigated using platform-level tools.

What Can Be Handled by Bitrix

Activity Control (Security → Activity Control) — limits the number of requests from a single IP per time period. Settings:

  • Maximum requests per minute — threshold for blocking
  • Action: redirect to CAPTCHA or add to stop list
  • Block duration

Blocked IPs are stored in b_security_stop_list. Clear old records via the agent Bitrix\Security\Stoplist::clearOldRecords().

Stop List (Security → Stop List) — manually add IP addresses and subnets. Supports CIDR notation (e.g., 192.168.1.0/24).

Web Server-Level Protection

Nginx rate limiting configuration — applied before the request reaches PHP:

limit_req_zone $binary_remote_addr zone=bitrix:10m rate=30r/m;

location / {
    limit_req zone=bitrix burst=10 nodelay;
    # ...
}

For checkout and login pages — apply stricter limits:

location ~ ^/(personal/|checkout/) {
    limit_req zone=bitrix burst=3 nodelay;
}

CDN and External WAF

For serious protection — Cloudflare, DDoS-Guard, Qrator. They filter traffic before it reaches the server. Bitrix works correctly behind a reverse proxy — you need to properly forward X-Forwarded-For so that the stop list blocks real IPs rather than the proxy address.

Add to init.php:

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

Or use the \Bitrix\Main\Server module and the trusted_proxies setting in bitrix/.settings.php.

Real-World Case

An attack targeted the search page of an online store: bots sent requests with varying q=... parameters, each triggering a full-text MySQL search. The server went down in 4 minutes. Solution: caching search results via \Bitrix\Main\Data\Cache, nginx rate limiting (5 requests/minute for the /search/ URL), and adding a minimum search query length requirement (3 characters) in the component. The next attack — the server held.

Delivery Time

Setting up built-in activity control and nginx rate limiting — 3–5 hours. Integration with an external CDN/WAF — 1 to 2 business days.