Каждый день в рунете происходят десятки DDoS-атак на интернет-магазины. Особенно уязвимы сайты на 1С-Битрикс: их архитектура с тяжёлыми компонентами (каталог, поиск, корзина) становится лёгкой мишенью. Мы видим, как клиенты теряют до 50 000 рублей за минуту простоя в час пик. Но остановить атаку можно ещё до того, как она дойдёт до PHP — на уровне nginx и CDN. За 12 лет мы собрали конфигурацию, которая выдерживает волны до 40 Гбит/с без потери данных.
Сразу разочаруем: сам Битрикс не умеет защищать от объёмных DDoS (L3/L4). Это зона инфраструктуры. Но прикладной L7-DDoS — боты, которые имитируют пользователей — можно нейтрализовать штатными инструментами платформы и грамотным nginx.
Чем различаются L3/L4 и L7 DDoS?
Атаки L3/L4 (ICMP flood, SYN flood) перегружают канал или сетевое оборудование — их отражает только CDN или облачный WAF. L7-атаки (HTTP flood) имитируют обычных посетителей: открывают страницы, отправляют формы, ищут товары. Именно L7 опасен для Битрикс, потому что утилизирует PHP и базу данных.
Что можно закрыть средствами 1С-Битрикс
Контроль активности
Модуль «Безопасность → Контроль активности» ограничивает число запросов с одного 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. Это критично, потому что именно там злоумышленники пытаются перебирать пароли или отправлять спам-заказы.
Что лучше: штатный контроль Битрикс или nginx — сравнение
Штатный модуль работает на PHP, блокирует после обработки запроса — это тратит CPU. Nginx блокирует на транспортном уровне, экономя до 80% ресурсов сервера. Фактически, nginx rate limiting снижает нагрузку на CPU в 5 раз по сравнению с модулем Битрикс (80% против 0% экономии). Но модуль Битрикс даёт гибкость: CAPTCHA, выборочная блокировка по URL, интеграция с мониторингом. Лучшее решение — комбинация: nginx режет основной трафик, модуль дорабатывает подозрительных.
| Параметр | Контроль активности Битрикс | Nginx rate limiting |
|---|---|---|
| Уровень блокировки | PHP (после выполнения) | Транспортный (до PHP) |
| Экономия CPU | 0% (наоборот, тратит) | до 80% |
| Гибкость (CAPTCHA, URL) | Да | Нет |
| Защита от L3/L4 | Нет | Нет |
| Рекомендация | Вторая линия | Первая линия |
Внешние 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. Решение в три шага:
- Кэширование результатов поиска через
\Bitrix\Main\Data\Cacheна 15 минут; - Rate limiting в nginx — 5 запросов/мин на
/search/; - Минимальная длина поискового запроса — 3 символа (в компоненте).
После внедрения аналогичная атака прошла незаметно — сервер утилизировал лишь 12% CPU. Время восстановления после падения — 0.Администратор проекта.
Что входит в настройку защиты
| Этап | Длительность | Результат |
|---|---|---|
| Аудит текущей конфигурации | 1–2 часа | Отчёт с уязвимостями и рекомендациями |
| Настройка контроля активности | 1 час | Рабочие пороги, CAPTCHA, стоп-лист |
| Настройка nginx rate limiting | 1–2 часа | Конфиги для всех критичных URL |
| Интеграция CDN/WAF | 1–2 дня | Готовые дашборды, тест под нагрузкой |
| Документация и обучение | 1 час | Инструкция по мониторингу и снятию блокировок |
Сроки: базовая защита — от 3 часов; полный комплекс с CDN — от 2 до 5 рабочих дней. Стоимость рассчитывается под проект. Гарантируем работу по договору с фиксацией SLA: восстановление доступа за 30 минут. Получите консультацию по защите вашего Битрикс-проекта — мы оценим риски за 1 час. Закажите аудит безопасности сайта.
Как мы это делаем: технология и результаты
За 5 лет реализовали защиту для 80+ проектов на 1С-Битрикс. Среднее время реакции на инцидент — 7 минут. Используем сертифицированные решения — Cloudflare Enterprise, Битрикс VM с оптимизированными конфигами.
Шаги по настройке под ключ:
- Анализ логов — выясняем типичные паттерны запросов, выделяем уязвимые точки.
- Проектирование — определяем пороги, выбираем WAF, настраиваем правила.
- Реализация — меняем nginx, компоненты Битрикс, подключаем CDN.
- Тестирование — имитируем атаку через siege/wrk, меряем время отклика и потери.
- Деплой — выкатываем на прод, мониторим 48 часов.
- Поддержка — обучаем вашу команду, передаём дашборды, отвечаем на вопросы.
Типичные ошибки самостоятельной настройки: ставят единый rate limit на весь сайт (блокируют реальных пользователей); забывают про X-Forwarded-For (CAPTCHA бьёт по IP прокси); не тестируют под нагрузкой (5 запросов хватает только для простого статика). Мы проверяем каждый пункт — результат работает годами без ложных срабатываний.
Для глубокого понимания DDoS-атак рекомендуем ознакомиться со статьёй на Wikipedia. Технические детали nginx rate limiting описаны в официальной документации.
Опыт 12+ лет, гарантия на настройки. Свяжитесь с нами для консультации.