Сайт на Bitrix24 падает не из-за ошибки в коде, а из-за чужого трафика. Пока маркетинг считает лиды, а разработчик правит шаблон, кто-то за тысячи километров отправляет на ваш домен десятки тысяч запросов в секунду. Сервер отвечает, очередь растёт, и через пять минут страница не открывается ни у клиента, ни у менеджера. Именно в этот момент бизнес начинает искать российский аналог Cloudflare, потому что стандартные «мы закроемся файрволом на хостинге» не работают.

Дальше начинается путаница. Владельцы уверены, что раз портал живёт в облаке Bitrix24, то защита уже включена в тариф. Это верно ровно до того момента, пока вы не привязали собственный домен или не поставили лендинг на отдельном сервере. Облачный портал защищён на стороне вендора, ваш публичный сайт – нет. Атака на него бьёт по доступности, по позициям в поиске и по конверсии сайта, потому что клиент, увидевший таймаут, не возвращается через час.

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

Что такое DDoS-атака и почему она опасна для сайта на Bitrix24

DDoS-атака это попытка сделать сайт недоступным за счёт перегрузки его ресурсов. Тысячи или миллионы запросов отправляются одновременно с разных устройств, и сервер перестаёт успевать обрабатывать легитимный трафик. Для сайта на Bitrix24 это означает не просто „страница не открывается“. Это остановка продаж, потеря заявок и удар по репутации в поисковых системах.

Bitrix24 работает на типовом LAMP-стеке: веб-сервер, PHP, MySQL. Каждый запрос к странице запускает десятки SQL-запросов, подгружает компоненты, кэш, шаблоны. При обычной нагрузке это занимает 100-300 миллисекунд. При атаке в 10 000 запросов в секунду очередь соединений растёт быстрее, чем сервер успевает их обрабатывать. Итог: таймауты, ошибки 502 и 504, полная недоступность через 30-60 секунд после начала атаки.

Атаки бывают разные, и защита от каждой требует своих мер:

• Объёмные (volumetric) – забивают канал связи. 10-50 Гбит/с трафика выводят из строя даже выделенный сервер, если у провайдера нет запаса пропускной способности.
• L7-атаки (прикладной уровень) – имитируют поведение реальных пользователей. Запросы идут на конкретные URL: поиск, корзину, формы обратной связи. Сервер тратит ресурсы на генерацию страниц и выполнение запросов к базе данных.
• Атаки на формы и API – боты забивают заявки, комментарии, регистрации. Даже если сайт работает, база данных засоряется мусором, а менеджеры тратят время на обработку фальшивых лидов.

Последствия для бизнеса считаются просто. Если интернет-магазин на Bitrix24 приносит 200 000 рублей в сутки, шесть часов простоя это минус 50 000 рублей выручки. Плюс потеря позиций в поиске: Google и Яндекс фиксируют недоступность сайта, и восстановление трафика занимает от двух недель. Плюс репутационные издержки: клиенты, которые не смогли оформить заказ, уходят к конкурентам и редко возвращаются.

Отдельная проблема – лидогенерация. Лендинги на Bitrix24 часто собирают заявки через веб-формы. Атака на форму может быть незаметной: сайт открывается, но 90% заявок приходят от ботов. Отдел продаж обрабатывает мусор, реальные клиенты ждут ответа, конверсия падает. По данным отраслевых отчётов, до 30% трафика на открытые формы без защиты составляют автоматизированные запросы.

Стоит учитывать и регуляторные требования. Если сайт обрабатывает персональные данные, при атаке возможна утечка или нарушение доступности сервиса, что создаёт риски по 152-ФЗ. Простой по вине DDoS не освобождает от ответственности перед клиентами и надзорными органами.

Вывод простой: сайт на Bitrix24 без внешней защиты уязвим к атакам любого масштаба. Даже слабая атака в 500 запросов в секунду способна положить сайт на виртуальном хостинге. Дальше разберём, какие элементы архитектуры Bitrix24 уже защищены, а какие остаются открытыми.

Архитектура Bitrix24: что уже защищено, а что требует внимания

Первое, что стоит разделить, это облачный портал Bitrix24 и ваш собственный сайт или лендинг на Bitrix. Это два разных объекта с разной моделью ответственности за безопасность, и путаница между ними приводит к ложному чувству защищённости.

Облачный портал Bitrix24 работает на инфраструктуре вендора. Отказоустойчивость, фильтрация трафика, обновления платформы, физическая безопасность дата-центров лежат на стороне сервиса. Вы не управляете этими уровнями и не можете их настроить. Если портал недоступен из-за атаки, это зона ответственности Bitrix24, а не вашей ИТ-команды. Собственно, в этом и смысл SaaS: вы платите за подписку и получаете работающий сервис без администрирования серверов.

Совсем другая история начинается, когда у вас есть собственный домен, привязанный к сайту на Bitrix, интернет-магазин, корпоративный портал в коробочной версии или лендинг для лидогенерации. Такой сайт размещён либо на вашем сервере, либо у хостера, либо в арендованном облаке. Здесь защита от L7 DDoS, фильтрация ботов, WAF-блокировки и SSL-сертификат целиком на вас. Вендор Bitrix поставляет платформу, но не закрывает внешний периметр.

Что уже защищено в облачном портале: сетевой уровень, базовая фильтрация аномального трафика, отказоустойчивость кластера, резервное копирование. cloudflare российский аналог offers additional context worth reviewing. Что остаётся уязвимым в вашем собственном контуре:

• Веб-сервер и приложение, принимающие HTTP-запросы напрямую из интернета.
• Формы обратной связи, авторизация, поиск, корзина, которые можно нагрузить ботами.
• API и вебхуки, если они открыты наружу без ограничений по частоте запросов.
• Административная панель Bitrix, доступная по стандартному URL.
• DNS-записи домена, которые указывают на ваш реальный IP и раскрывают инфраструктуру.

Практический вывод простой: если вы используете только облачный портал по адресу вида company.bitrix24.ru, отдельная защита от DDoS вам, скорее всего, не нужна. Как только появляется собственный домен с сайтом или лендингом на Bitrix, внешний контур защиты становится обязательным элементом ИТ-инфраструктуры. Без него любой конкурент или просто скучающий атакующий может положить сайт за несколько минут, а восстановление доступа займёт часы.

Внешний контур защиты: почему не нужно защищать облако изнутри

Типичная ошибка при попытке защитить сайт на Bitrix24 – искать кнопку „включить защиту от DDoS“ внутри самой платформы. Её там нет и быть не может. Облачный портал Bitrix24 работает на инфраструктуре вендора, и трафик до вашего домена идёт не через его серверы, а напрямую к вашему хостингу. Значит, любые настройки внутри админки влияют только на то, что уже дошло до приложения. Отсечь атаку на подлёте они не способны.

Защита должна стоять на внешнем периметре: между интернетом и вашим сервером. В этой точке трафик фильтруется до того, как он коснётся веб-сервера, базы данных и PHP-процессов. Если фильтр находится внутри облака или на том же сервере, что и сайт, атакующий пакет всё равно расходует ресурсы вашей инфраструктуры. При L7-атаке, когда запросы выглядят как обычные визиты, это означает, что каждая „легитимная“ сессия запускает тяжёлые компоненты Bitrix: инициализацию ядра, запросы к MySQL, отрисовку шаблона. Сервер падает не от объёма трафика, а от количества одновременных соединений.

Что даёт внешний контур на практике

Внешний reverse proxy принимает соединение на себя, анализирует запрос и только потом решает, пропускать его к origin-серверу. Ключевые механики, которые при этом работают:

• Фильтрация на уровне L7 с эвристиками: аномальная частота запросов с одного IP, отсутствие cookies, подозрительные User-Agent.
• GeoIP-фильтрация: если ваша аудитория сосредоточена в России, нет смысла принимать трафик из регионов, откуда идут атаки.
• WAF-блокировки: отсечение эксплуатации известных уязвимостей CMS и компонентов до того, как запрос дойдёт до Bitrix.
• Кэширование статики на периметре: часть нагрузки снимается с origin-сервера автоматически.

Практический критерий простой: если при атаке загрузка CPU на вашем сервере растёт, значит, защита стоит не там, где нужно. Правильно настроенный внешний контур при отражении атаки не должен увеличивать нагрузку на origin ни на процент. Это и есть разница между защитой периметра и её имитацией внутри облака.

Как выбрать сервис защиты от DDoS: российские аналоги Cloudflare

До 2022 года выбор сервиса защиты для сайта на Bitrix сводился к одному пункту: Cloudflare, бесплатный тариф и 15 минут на смену NS-записей. Сейчас этот путь закрыт. Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры, в свою очередь, ограничивают доступ к сайтам на Cloudflare. Для бизнеса это означает не просто неудобство, а прямую потерю трафика: посетитель из Москвы может вообще не увидеть ваш лендинг, даже если сервер работает исправно.

Рынок отреагировал, и сегодня можно выделить четыре типа решений. Первый – российские CDN и облачные провайдеры с собственной защитой от L7 DDoS. Второй – специализированные WAF-сервисы, подключаемые через reverse proxy. Третий – зарубежные аналоги, которые формально работают, но зависят от внешних каналов и могут отвалиться в любой момент. Четвертый – российский аналог Cloudflare, сервис TrafficVeil, который объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре.

При выборе стоит смотреть на три вещи. Первое: тарифицируются ли боты и атаки. У Cloudflare и большинства аналогов всплеск трафика означает рост счета, что в момент атаки превращает защиту в дополнительный убыток. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, поэтому стоимость предсказуема. Второе: работает ли сервис на территории РФ без потери зарубежной аудитории. TrafficVeil обеспечивает работу сайтов и внутри России, и по всему миру. Третье: сложность миграции. Если для подключения нужен отдельный инженер и неделя на согласования, это не подходит для сайта на Bitrix, который нужно закрыть сегодня.

Отдельно проверьте совместимость с вашей платформой. Решения, которые корректно работают с WordPress, не всегда дружат с Bitrix: свои правила кэширования, свои заголовки, свои особенности админки. TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix, включая защиту формы лидогенерации и админ-панели от брутфорса.

Практические шаги по настройке защиты для сайта на Bitrix24

Настройка защиты внешнего контура для домена или лендинга на Bitrix занимает от 20 до 40 минут, если DNS-записи домена находятся под вашим контролем. Порядок действий выглядит так.

1. Инвентаризация. Выпишите все домены и поддомены, которые указывают на ваш Bitrix: основной сайт, лендинги, формы, вебхуки для интеграций с CRM и платежными системами. Отдельно отметьте статические IP-адреса, если они используются во внешних интеграциях: их смена потребует правок на стороне партнеров.
2. Выбор сервиса. Критерии простые: наличие российского юридического лица или представительства, точки присутствия в РФ, поддержка L7-фильтрации, WAF и GeoIP-фильтрации, прозрачный тариф без наценки за объем атак. TrafficVeil закрывает эти пункты и не тарифицирует ботов, атаки и WAF-блокировки, что предсказуемо для бюджета.
3. Перенос DNS. Делегируйте домен на NS-серверы сервиса или, если делегирование невозможно, настройте CNAME для нужных поддоменов. TTL записей снизьте до 300 секунд за сутки до переноса, чтобы откат занял минуты, а не часы.
4. Получение SSL. Выпустите сертификат на стороне сервиса. Оригинальный сертификат на вашем сервере остается, но трафик до него уже будет шифрованным на периметре.
5. Настройка правил. Включите базовый профиль WAF, задайте пороги rate limiting для форм обратной связи и авторизации в административной панели Bitrix, настройте GeoIP-фильтрацию, если аудитория ограничена Россией и СНГ. Whitelist для IP офиса и интеграционных партнеров добавьте до включения блокировок.
6. Проверка. Прогоните сайт через тестовые запросы, проверьте работу форм, корзины и вебхуков. Смотрите логи блокировок первые 48 часов: ложные срабатывания на легитимных пользователях случаются, особенно если боты имитируют поведение покупателей.
7. Переключение трафика. Только после успешной проверки меняйте A-записи на адреса сервиса. Держите старый сервер доступным для отката в течение недели.

Что проверить через месяц после подключения

Сравните конверсию до и после включения защиты. Если показатель просел, причина обычно в агрессивных правилах WAF или в блокировке поисковых ботов. Второй момент: убедитесь, что аналитика видит реальные IP посетителей, а не адреса reverse proxy, иначе отчеты по лидогенерации будут искажены. Третий: проверьте, что нагрузка на ваш сервер снизилась. Если запросы по-прежнему доходят до Bitrix в прежнем объеме, фильтрация настроена формально, и смысла в таком контуре немного.

Защита работает только тогда, когда вы понимаете, что именно она отсекает. Логи блокировок стоит просматривать регулярно, а не один раз при подключении.

Начните с инвентаризации: выпишите все домены и поддомены, которые указывают на ваш Bitrix, включая лендинги на Bitrix24, тестовые окружения и админку. Для каждого проверьте, куда резолвится A-запись и кто держит DNS. Если DNS у регистратора без защиты, а сервер отвечает напрямую на IP, любой конкурент за 5 минут найдёт этот IP через исторические DNS-базы и ударит по нему, минуя любые фильтры на домене. Пока IP не спрятан за reverse proxy, все остальные настройки вторичны.

Дальше действуйте по шагам. Первое: заведите домен в защитный сервис, смените NS-записи у регистратора и дождитесь обновления (обычно 2-24 часа в зависимости от TTL). Второе: настройте SSL на периметре, чтобы сертификат не висел на вашем сервере. Третье: включите базовый набор правил: rate limiting на формы и поиск, GeoIP-фильтрацию, если аудитория локальная, и challenge для подозрительных User-Agent. Четвёртое: закройте прямой доступ к origin по IP на уровне firewall, разрешив трафик только с адресов провайдера защиты. Пятое: прогоните тестовую нагрузку и проверьте, что формы заявок и оплата работают, а боты на них не проходят. Заведите отдельный поддомен для админки и ограничьте его по IP или VPN. Пересматривайте правила раз в квартал: схемы атак меняются, а конфигурация, собранная год назад, часто уже не отражает реальный трафик.