Protecting 1C-Bitrix from DDoS: Multi-Layer Nginx, WAF, CDN Configuration

Every day in the Russian internet, dozens of DDoS attacks hit online stores. Sites on 1C-Bitrix are especially vulnerable: their architecture with heavy components (catalog, search, cart) becomes an easy target. We've seen clients lose up to 50,000 rubles per minute of downtime during peak hours. But you can stop an attack before it reaches PHP—at the nginx and CDN level. In 12 years, we've built a configuration that withstands waves up to 40 Gbps without data loss.

Let's be clear: Bitrix itself cannot protect against volumetric DDoS (L3/L4). That's infrastructure territory. But application-layer L7-DDoS—bots mimicking users—can be neutralized using platform's built-in tools and proper nginx configuration.

How L3/L4 and L7 DDoS differ

L3/L4 attacks (ICMP flood, SYN flood) overload the channel or network equipment—only a CDN or cloud WAF can repel them. L7 attacks (HTTP flood) mimic real visitors: opening pages, submitting forms, searching products. L7 is dangerous for Bitrix because it consumes PHP and database resources.

What can be blocked using 1C-Bitrix itself

Activity Control

The "Security → Activity Control" module limits the number of requests from a single IP over a time interval. Parameters:

• maximum requests per minute—blocking threshold;
• action—redirect to CAPTCHA or stop-list;
• block duration (usually 60–3600 seconds).

Blocked IPs are written to the b_security_stop_list table. Old entries are cleaned by the agent Bitrix\Security\Stoplist::clearOldRecords(). For high-load projects, we recommend setting a threshold of 30 req/min—this covers 95% of real visitors while cutting off bots.

Stop-list

Manual addition of IPs and subnets, supports masks (192.168.1.0/24). Useful for blocking known ranges, but not a silver bullet.

How nginx rate limiting works

Before a request reaches PHP, nginx counts the number of requests from an IP. If exceeded, it returns 503 without consuming server resources. Here's a typical configuration for Bitrix:

http { limit_req_zone $binary_remote_addr zone=bitrix:10m rate=30r/m; server { location / { limit_req zone=bitrix burst=10 nodelay; # ... standard processing } location ~ ^/(personal/|checkout/) { limit_req zone=bitrix burst=3 nodelay; } } } 

• zone=bitrix:10m — allocate 10 MB memory for counters (~320,000 IPs);
• rate=30r/m — no more than 30 requests per minute from a single IP;
• burst=10 nodelay — allow a short burst of up to 10 requests without delay.

For checkout and login pages, we set stricter limits: rate=10r/m, burst=3. This is critical because attackers often try to brute-force passwords or send spam orders there.

Which is better: built-in Bitrix control or nginx? — Comparison

The built-in module works at PHP level, blocking after request processing—consuming CPU. Nginx blocks at the transport level, saving up to 80% of server resources. In fact, nginx rate limiting reduces CPU load by 5 times compared to the Bitrix module (80% vs 0% savings). But the Bitrix module offers flexibility: CAPTCHA, selective blocking by URL, integration with monitoring. The best solution is a combination: nginx cuts off main traffic, the module handles suspicious ones.

External WAF and CDN

To protect against volumetric attacks (10+ Gbps), we always connect Cloudflare, DDoS-Guard, or Qrator. They filter traffic at their facilities, passing only "clean" traffic to the server. Bitrix works correctly behind a reverse proxy under one condition: the real client IP must be passed through.

Example in init.php:

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

Or via bitrix/.settings.php:

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

Why proper trusted_proxies configuration is important?

If trusted proxies are not specified, Bitrix will see the Cloudflare IP instead of the real visitor's IP. Activity control will start blocking itself—false positives are guaranteed. We check this parameter first.

Case study: search under DDoS

Once our team received an alert: an online store (catalog of 150K items) went down in 4 minutes. The attack targeted the search page—bots sent requests with random q=..., each triggering a full-text search on MySQL. Solution in three steps:

1. Cache search results using \Bitrix\Main\Data\Cache for 15 minutes;
2. Rate limiting in nginx — 5 req/min on /search/;
3. Minimum search query length — 3 characters (in the component).

After implementation, a similar attack went unnoticed—server CPU utilization was only 12%. Recovery time after crash — 0. Project administrator.

What's included in protection setup

Timeline: basic protection — from 3 hours; full suite with CDN — from 2 to 5 business days. Cost is project-based. We guarantee work under contract with SLA: access restoration within 30 minutes. Get a consultation on protecting your Bitrix project—we'll assess risks in 1 hour. Order a site security audit.

How we do it: technology and results

Over 5 years, we've implemented protection for 80+ projects on 1C-Bitrix. Average incident response time — 7 minutes. We use certified solutions: Cloudflare Enterprise, Bitrix VM with optimized configs.

Turnkey setup steps:

1. Log analysis — identify typical request patterns, pinpoint vulnerable points.
2. Design — determine thresholds, choose WAF, configure rules.
3. Implementation — modify nginx, Bitrix components, connect CDN.
4. Testing — simulate attacks using siege/wrk, measure response time and losses.
5. Deployment — roll out to production, monitor for 48 hours.
6. Support — train your team, hand over dashboards, answer questions.

Common mistakes in self-configuration: setting a single rate limit for the entire site (blocks real users); forgetting X-Forwarded-For (CAPTCHA hits the proxy IP); not testing under load (5 req/min is enough only for simple static sites). We check every point—the result works for years without false positives.

For a deep understanding of DDoS attacks, we recommend reading the Wikipedia article. Technical details of nginx rate limiting are described in the official documentation.

12+ years of experience, guarantee on configurations. Contact us for a consultation.