Bitrix: защита от DDoS-атак шаг за шагом — настройка и проверка

Bitrix‑проекты с денежным трафиком — интернет‑магазины, подписочные SaaS‑сервисы, личные кабинеты, CRM‑панели — регулярно ловят DDoS атак, и простой перенос на «битрикс‑хостинг» или галочка «Проактивная защита» работают лишь до первого серьёзного всплеска нагрузки. Чтобы сайт не превращался в лотерею «откроется / не откроется», нужно сочетать настройки Bitrix, веб‑сервера и внешних фильтров. Ниже разберём, что именно включить в админке, какие сервисы использовать, какие файлы и конфиги править и дадим чек‑лист, по которому можно пройтись вместе с админом, разработчиком или приглашённым специалиста по безопасности.

Какие DDoS-атаки типичны для Bitrix‑проектов и как их распознать

Для сайтов на битрикс чаще всего прилетают не гигабитные UDP‑флуды, а вполне «умные» сценарии на уровне HTTP‑запросов. Ботов направляют на тяжёлые страниц, которые нагружают PHP и базу: каталог с фильтрацией, поиск по товарам, сложные отчёты в CRM‑модуле, формы регистрации и авторизации. Скрипт генерирует тысячи обращений в минуту, и сервер начинает задыхаться даже при обычной полосе интернета.

Второй частый вариант — атаки по API и личному кабинету. Мобильное приложение или внешняя система интеграции дергаются через REST, и злоумышленник имитирует такую же активность пользователей, но с десятков или сотен IP. Третий сценарий — медленные запросы наподобие Slowloris: соединения к веб‑серверу открываются и подвешиваются, из‑за чего Apache или PHP‑FPM держат процессы занятыми, а живые клиенты получают ошибки или бесконечный «крутится» в браузере.

Со стороны владельца проекта это выглядит так: часть клиентов жалуется, что сайт или блог компании не открывается, хотя мониторинг «пингуется»; время ответа вырастает до 20–30 секунд; всплывают 502/503 ошибки на отдельных разделах — корзина, личный кабинет, страница оформления заказа. При этом рекламные кампании не менялись, а число заказов и регистраций не растёт, хотя количество сессий и подключений резко увеличилось.

• в логах видны тысячи однотипных запросов к 2–3 одинаковым URL;
• повторяются одни и те же подсети и User‑Agent (часто — скриптовые или пустые);
• нагрузки на CPU и БД растут, но в логике Bitrix не прибавляется целевых действий пользователей.

Если картина совпадает хотя бы наполовину, имеет смысл воспринимать ситуацию как DDoS и перейти к системному укреплению защиты, а не просто «увеличить тариф» на хостинге.

Варианты защиты: что даёт Bitrix, хостинг и внешние сервисы

bitrix защита от ddos никогда не должна упираться только в настройки модуля безопасности. Важно выстроить цепочку фильтров от провайдера до PHP‑кода. На уровне инфраструктуры хороший провайдер предлагает L3–L4‑защиту: отбрасывание volumetric‑атак до веб‑сервера, ограничение подключений на балансировщике, фильтрацию «мусорных» пакетов. Если провайдер честно говорит, что анти‑DDoS отсутствует, любые усилия на уровне PHP и .htaccess быстро упрётся в предел по соединениям.

Следующий слой — веб‑сервер (Nginx/Apache). Здесь играют роль два простых, но эффективных механизма: rate limiting (ограничение частоты запросов) и ограничение одновременных соединений. Nginx позволяет задать лимиты по IP, подсети, даже по ключу сессии; Apache — использовать модуль mod_evasive и аналоги. Дополнительно можно настроить фильтр по странам и подсетям, если проект заведомо не работает с определёнными регионами. Такой уровень работает грубо, но дешево, и отлично снимает до 70–80% примитивных атак.

Встроенная система безопасности 1C‑Bitrix даёт ещё один важный уровень. Проактивная защита и Web Application Firewall (WAF) анализируют параметры запросов и блокируют типичные атаки на уровне кода приложения: SQL‑инъекции, подозрительные URL, слишком частые обращения к скриптам. Там же настраивается ограничение активности пользователей — ограничение числа действий (логинов, отправки форм, восстановления пароля) в минуту с одного IP. Плюс, композитный режим и кеширование позволяют отдавать большую часть страниц (каталог, статьи блога, контентные разделы) без каждый раз обращения к базе, тем самым уменьшая влияние всплесков полу‑легитимного трафика.

Наконец, внешний WAF/CDN/анти‑DDoS сервисы (Cloudflare, DDoS‑Guard, Яндекс DDoS и другие) берут на себя фильтрацию HTTP‑трафика ещё до сервера. Они позволяют с помощью готовых правил и сертификаты TLS сделать прозрачный прокси: включите JS‑челленджи для подозрительных ботов, гео‑ограничения, поведенческие фильтры. Для крупных магазинов и SaaS это уже не опция, а базовая часть архитектуры.

Практический ориентир простой: небольшие Bitrix‑сайты и интернет‑проекты — достаточно хостинга с базовой защитой, настроенного Nginx и проактивной защиты. Крупным магазинам, CRM‑системы и нагруженным веб‑сервисам понадобится связка «провайдер с анти‑DDoS → внешний WAF/CDN → грамотно настроенный Bitrix и сервер».

Практический чек-лист: настройка фильтров и защиты Bitrix от DDoS

1. Проверить поддержку анти‑DDoS у хостинга или провайдера
2. Задайте конкретные вопросы: какие типы ddos атак провайдер реально фильтрует на своей стороне, есть ли защита L3–L4, как происходит установка и подключение к их «зонтику» (смена IP, изменение DNS, какие SLA по доступности). Узнайте, можно ли быстро поднять защищённую версию сервера в случае эскалации атаки. Если в ответ слышите «не знаем» или предложения «просто увеличить тариф», стоит рассмотреть переезд, потому что любые локальные способы защиты будут ограничены возможностями сети.
3. Настроить лимиты и фильтры на веб‑сервере
4. Для Nginx используйте директивы limit_req и limit_conn в конфигурационных файлов. Они позволяют задать максимум запросов в секунду с одного IP и ограничение одновременных соединений. Вынесите административные разделы, /bitrix/admin и API в отдельные location с более жёсткими лимитами и логированием. Обязательно добавьте исключения для интеграций — 1С, внешней CRM, мобильных приложений, чтобы не отрубить собственные сервисы.
5. В Apache проверьте, что модуль mod_evasive включён и настроен: пороги количества одинаковых запросов, автоматическое добавление IP в временный чёрный список. Это простой фильтр, который не требует правки кода Bitrix, но ощутимо снижает нагрузку.
6. Включить и грамотно настроить «Проактивную защиту» Bitrix
7. В админке перейдите: «Настройки → Проактивная защита». Включите модуль, выберите режим WAF: для начала «Обучающий» или «Средний», чтобы не нарваться на ложные срабатывания. Настройте лимиты активности: число запросов к скриптам авторизации, восстановления пароля, регистрации в минуту с одного IP. Это сильно режет попытки брутфорса и DDoS‑скриптов по формам.
8. Создайте белый список IP и подсетей: офис, VPN вашей команды, адреса мониторинговых сервисов. В чёрный список оперативно заносите источники явных атак. Журнал WAF в Bitrix позволяет фиксировать шаблоны атак и постепенно уточнять правила, не внося изменения в PHP‑кода.
9. Использовать кеширование и композит как «буфер» для нагрузки
10. Для публичных разделов включите «Композитный сайт» и настройте кеширование компонентов: каталога, списка статей, страниц блога. Это позволяет серверу отдавать уже собранные HTML‑версии страниц без постоянного обращения к базе. В результате одна и та же железка выдерживает в разы больше запросов, а многие полулегитимные всплески активности пользователей не приводят к падению.
11. При этом стоит помнить: корзина, личный кабинет, REST‑API кешируются ограниченно и остаются целью атак. Там акцент надо делать на лимитах и WAF, а не только на композите.
12. Подключить внешний WAF / анти‑DDoS‑сервисы
13. Для средних и крупных проектов настройка только внутри Bitrix — компромисс. Подключите Cloudflare, DDoS‑Guard или аналогичный сервис: измените NS‑записи домена, проверьте корректную установка SSL‑сертификаты, убедитесь, что прямой доступ по IP закрыт фаерволом. На уровне правил включите гео‑фильтры, ограничения по аномальным User‑Agent, поведенческие фильтры типа JS‑челленджа.
14. Частая ошибка — оставить часть доменов или поддоменов в обход WAF (например, api.example.ru на прямой IP). В момент атак именно они становятся входной точкой, поэтому вся внешняя маршрутизация должна идти через единый защитный контур.
15. Настроить мониторинг и алерты
16. В Bitrix включите «Монитор производительности», следите за временем генерации страниц и счётчиком запросов к базе. В модуле безопасности активируйте уведомления о срабатывании WAF и блокировках. На сервере подключите простые метрики: CPU, RAM, количество активных соединений, среднее время ответа веб‑сервера.
17. Даже если нет сложной системы мониторинга, элементарные скрипты, отправляющие алерты в Telegram или почту при резком росте запросов или появлении большого числа ошибок 5xx, уже позволяют быстрее реагировать и включать подготовленные решения.
18. Подготовить «план B» на случай сильной атаки
19. Заранее продумайте, какие разделы проекта можно временно отключить или ограничить по доступу: тяжёлые отчёты, массовый экспорт файлов, часть API для партнёров. Создайте упрощённую статическую версию ключевых страниц («о компании», контакты, базовое описание услуг) и храните её на отдельном CDN или в виде готового набора HTML‑страниц. При крайней нагрузке вы сможете быстро переключить DNS или Nginx на эту версию, сохранив минимальное присутствие в интернете для клиентов.

Как понять, что защита настроена адекватно, и когда привлекать разработчиков

Считайте базовую bitrix защита от ddos приведённой в порядок, если у вас есть чёткая цепочка: провайдер с фильтрацией → настроенный веб‑сервер с лимитами → включённый и обученный WAF Bitrix → кеширование и композитный режим. Все правила и исключения документированы: известно, какие IP в белом списке, какие подсети под постоянным фильтром, какие модули системы заведомо более уязвимы к нагрузке.

Мини‑проверка: имитация пикового трафика (например, интенсивная рекламная кампания) не валит сервер, а критичные сценарии — оформление заказа, работа личного кабинета, интеграции с CRM и мобильными приложениями — остаются доступными без лавины ошибок. Если же любой всплеск активности тут же превращается в 502/503, а попытки «подкрутить» настройки заканчиваются правкой кода на продакшене, пора звать команду.

Когда проект — интернет‑магазин, CRM или SaaS‑сервис с API для мобильных клиентов, часто нужны нестандартные решения: разделение фронта и API, кастомные правила WAF, оптимизация SQL и PHP‑кода, детальная настройка Nginx и PHP‑FPM под конкретный паттерн нагрузки. Если вам нужен аудит текущей конфигурации Bitrix, настройка защиты от атак и помощь в создании устойчивой архитектуры, наша команда по разработке мобильных приложений, веб‑сервисов, CRM‑систем, игр и интернет‑магазинов готова подключиться к вашему проекту и предложить практичные решения, а не теоретические советы из статьи.