Защита от DDoS-атак на 1С-Битрикс: сайт доступен под нагрузкой

Защита от DDoS-атак на 1С-Битрикс — это набор мер, который удерживает сайт доступным в момент, когда на него обрушивают поток искусственного трафика. DDoS-атака не пытается ничего купить или украсть: её единственная цель — завалить сервер таким числом запросов, чтобы он перестал отвечать живым пользователям. Для бизнеса это оборачивается простоем магазина, потерей заказов и заявок, падением позиций в поиске и ударом по репутации. Наша задача — сделать так, чтобы атака разбивалась о фильтрацию на подходе к сайту, а покупатели и менеджеры даже не замечали, что в этот момент по сайту бьют.

Атаки на сайты Битрикс приходят на двух уровнях, и закрывать нужно оба. Атаки уровней L3 и L4 бьют по сети и транспорту: сервер заваливают пакетами и соединениями, забивая канал и таблицы соединений, пока он не захлебнётся. Атаки уровня L7 устроены тоньше — они имитируют живых пользователей и долбят по самым дорогим страницам приложения: каталогу с фильтрами, поиску, формам заявок и корзине. Именно L7-атаки опаснее всего для Битрикса, потому что их трудно отличить от настоящего трафика, а каждая тяжёлая страница обходится серверу дорого. Малым числом грамотно нацеленных запросов можно положить сервер, который выдержал бы куда больший поток простых обращений.

Из чего складывается защита

Фундамент защиты — облачная фильтрация трафика. Весь поток к сайту мы заводим через сеть провайдера фильтрации: чаще всего это Cloudflare, DDoS-Guard или Qrator. Облако принимает удар на себя своими мощными каналами и оборудованием, отсекает паразитный трафик и пропускает к серверу только живых пользователей. Сервер, который в одиночку не выдержал бы атаку в сотни гигабит, видит лишь очищенный поток и спокойно его обслуживает. Второй обязательный шаг — скрытие реального IP сервера и закрытие прямого доступа, чтобы атакующий не мог ударить в обход облака.

Ключевые элементы защиты от DDoS на Битрикс:

• облачная фильтрация атак уровней L3/L4 и L7 через Cloudflare, DDoS-Guard или Qrator;
• скрытие реального IP сервера и закрытие прямого доступа в обход облака;
• защита тяжёлых страниц и форм Битрикса лимитами частоты и проверками трафика;
• кеширование под атакой, при котором страницы отдаются из кеша, минуя PHP и базу;
• эластичное масштабирование ресурсов на пике нагрузки и возврат к норме после атаки;
• мониторинг трафика 24/7 и быстрое реагирование в первые минуты атаки.

Почему важна настройка именно под Битрикс

Просто включить облако поверх сайта недостаточно. Битрикс — тяжёлая система с собственным кешированием: композитный кеш, кеш компонентов, кеш меню и блоков. Если фильтрацию и облачный кеш настроить грубо, можно либо сломать личные кабинеты и корзину, либо оставить тяжёлые страницы беззащитными. Поэтому мы настраиваем защиту слоями: статика и кешируемые страницы отдаются из облака, персональные страницы корректно доходят до сервера, а тяжёлый каталог под атакой работает из кеша почти бесплатно по ресурсам. Формы заявок и корзину защищаем отдельно — лимитами и проверками, которые отсекают ботовый поток до того, как он нагрузит обработчики.

Отдельное внимание — точкам, по которым бьют чаще всего. Каталог с фильтрами, поиск, страницы с большой выборкой товаров и формы — это самые дорогие по ресурсам разделы, и атакующие целятся именно в них. Мы заранее находим эти точки на аудите, ставим на них лимиты частоты запросов и кеширование и проверяем под тестовой нагрузкой, что защита держит и не ломает работу сайта. Так атака на каталог, которая раньше клала сервер за минуты, упирается в фильтр и кеш и не доходит до базы.

Как мы подключаем защиту

Работа начинается с аудита: смотрим архитектуру сайта, тяжёлые страницы и формы, текущую защиту и историю атак. На основе этого подбираем провайдера фильтрации и заводим через него весь трафик. Затем скрываем реальный IP, закрываем прямой доступ к серверу и настраиваем правила фильтрации, лимиты и кеширование под специфику Битрикса. После настройки прогоняем нагрузочную проверку по каталогу, поиску и формам, чтобы убедиться, что защита эффективна и сайт работает корректно. Финал — мониторинг трафика 24/7 и реагирование: при новых атаках инженер ужесточает правила в первые минуты, а не вслепую в разгар инцидента.

Если сайт уже лежит под атакой, мы делаем экстренное подключение в течение суток: заводим трафик через облако, скрываем сервер и включаем жёсткие правила, чтобы стабилизировать сайт в первые часы, а тонкую настройку завершаем после острой фазы. Результат во всех случаях один — управляемый риск вместо постоянной угрозы простоя. Сайт остаётся доступным под мощной атакой, заказы и заявки продолжают приходить, а вы знаете заранее, во сколько обойдётся защита и какую доступность она держит.

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

Почему сервер в одиночку не отобьёт атаку

У любого сервера есть потолок: ширина канала, число одновременных соединений, объём памяти и процессорного времени. Атака как раз и рассчитана на то, чтобы упереться в этот потолок. Объёмная L3/L4-атака забивает канал мусорными пакетами, и даже идеально настроенный Битрикс не поможет — трафик не доходит до приложения, потому что захлёбывается сеть. L7-атака бьёт по приложению: имитирует пользователей и нагружает тяжёлые страницы, пока PHP и база не встанут. В обоих случаях один сервер проигрывает, потому что у атакующего распределённая сеть из тысяч устройств, а у вас — одна машина. Поэтому фильтровать атаку нужно там, где есть запас по мощности, — в облаке провайдера фильтрации, чьи каналы рассчитаны на атаки в сотни гигабит.

Именно поэтому облачная фильтрация — не опция, а основа защиты. Весь трафик идёт через сеть провайдера, она гасит объёмные атаки своими ресурсами и пропускает к серверу только очищенный поток. Сервер видит нагрузку, которую способен обслужить, и продолжает отдавать страницы живым пользователям. Но облако работает лишь при одном условии: реальный IP сервера должен быть скрыт, а прямой доступ к нему закрыт. Иначе атакующий, узнав адрес, ударит напрямую в обход всей фильтрации.

Скрытие IP — шаг, который чаще всего забывают

Подключить облако и оставить сервер доступным по старому IP — самая частая ошибка. Адрес легко вычисляется по истории DNS, почтовым заголовкам, поддоменам или утечкам в коде. Как только атакующий его находит, облако становится бесполезным: удар идёт мимо. Поэтому мы всегда меняем IP при необходимости, прячем его за облаком и закрываем доступ к серверу на уровне сети, разрешая подключения только из подсетей провайдера фильтрации. После этого ударить в обход физически нельзя — сервер просто не отвечает никому, кроме облака. Этот неприметный шаг отделяет защиту, которая держит, от защиты, которую обходят за полчаса.

Где Битрикс особенно уязвим

Битрикс — мощная, но тяжёлая система. Каталог с фильтрами, поиск, страницы с большой выборкой, формы заявок и корзина генерируются на лету и обращаются к базе, поэтому каждая из них дорога по ресурсам. Атакующие это знают и целятся именно туда: им не нужен огромный поток, достаточно методично долбить по тяжёлой странице. Грамотная защита закрывает эти точки в первую очередь. Мы кешируем то, что можно отдавать из кеша, ставим лимиты частоты на дорогие разделы и проверки на формы, чтобы ботовый поток отсекался до обработчиков. При этом важно не сломать персональные сценарии — авторизацию, корзину, личные кабинеты, — поэтому кеширование настраивается слоями, а не одной грубой настройкой на весь сайт. Если вам нужна и более глубокая защита приложения, мы настраиваем правила WAF на ModSecurity и Cloudflare для Битрикс в связке с фильтрацией DDoS.

DDoS и боты — близкие, но разные задачи

Часто под DDoS на самом деле прячется ботовый трафик: парсеры, накрутка, перебор форм. Он не валит сайт лавиной, но создаёт постоянную паразитную нагрузку и мусор в базе. Полная картина защиты включает и фильтрацию ботов, поэтому защиту от DDoS логично рассматривать вместе с защитой от DDoS и ботов как единый контур. Мы настраиваем правила так, чтобы и лавинообразные атаки, и ползучий ботовый поток отсекались до того, как дойдут до сервера. Тогда и пиковые атаки не кладут сайт, и в спокойное время база не забивается мусорными заявками, а PHP не тратит ресурсы на обслуживание парсеров.

Как не получить непредсказуемый счёт

Главный страх под долгой атакой — что эластичное масштабирование разгонит ресурсы и принесёт огромный счёт. Мы решаем это двумя способами. Во-первых, основную нагрузку снимает не масштабирование, а фильтрация и кеш: до сервера доходит малая доля трафика, поэтому добавлять ресурсы почти не приходится. Во-вторых, масштабирование настраивается с жёстким потолком — система не уходит в бесконечный рост, а упирается в заданную границу, за которой работает фильтр. В итоге затраты под атакой остаются предсказуемыми, а стоимость наших работ по настройке фиксируется заранее и от мощности атаки не зависит. Вы знаете цифру до начала, а не получаете сюрприз после инцидента.

Как мы ведём подключение

Старт — аудит. Мы смотрим архитектуру сайта, находим тяжёлые страницы и формы, изучаем текущую защиту и историю атак. На основе этого подбираем провайдера фильтрации под ваш профиль атак и аудиторию, заводим трафик через облако, скрываем IP и закрываем прямой доступ. Затем настраиваем правила фильтрации, лимиты и кеширование под специфику Битрикса и прогоняем нагрузочную проверку по каталогу, поиску и формам. Только убедившись, что защита держит и сайт работает корректно, переходим к мониторингу и сопровождению. Так подключение получается предсказуемым, а не превращается в эксперимент на живом сайте.

Если сайт уже под атакой, порядок другой: сначала экстренно стабилизируем. В течение суток заводим трафик через облако, скрываем сервер и включаем жёсткие правила, чтобы поднять сайт в первые часы. Тонкую настройку под Битрикс завершаем, когда острая фаза пройдена. Параллельно стоит проверить, не оставила ли атака следов и не было ли попытки взлома под её прикрытием — для этого есть отдельный аудит DDoS-защиты Битрикс, который оценивает готовность сайта к следующей волне.

Возражения, которые мы слышим чаще всего

«Нас никогда не атаковали, защита не нужна». Атаки приходят внезапно, часто их заказывают конкуренты или вымогатели, и подключаться под ударом дороже и нервознее, чем заранее. Защита в спокойном режиме почти не влияет на сайт и работает как страховка. «Мы поставили бесплатный тариф облака, этого хватит». Базовый тариф ловит объёмные L3/L4-атаки, но L7 по тяжёлым страницам часто проходит насквозь, и сайт всё равно падает. Нужна настройка лимитов, проверок и кеша под Битрикс, а не одна галочка. «Защита замедлит сайт». Наоборот: облачный кеш и CDN обычно ускоряют отдачу страниц, а фильтрация почти не добавляет задержки. Правильно настроенная защита делает сайт и быстрее, и устойчивее одновременно.

Сценарии, под которые мы настраиваем защиту

Защита подстраивается под характер бизнеса и атак. Для интернет-магазина критичны сезонные пики и распродажи, когда атаку заказывают именно в самый прибыльный день, поэтому упор делаем на кеширование каталога и устойчивость корзины под нагрузкой. Для B2B-портала важна доступность личных кабинетов и форм при том, что трафик предсказуемее, — здесь акцент на скрытии IP и защите форм от перебора. Для сервисов заявок и бронирования главное — чтобы формы продолжали принимать обращения, поэтому ботовый поток отсекаем особенно тщательно, не задевая живых пользователей.

Отдельная история — сайты, которые уже пережили атаку. Им мало просто подключить облако: нужно понять, как именно их били, не утёк ли IP снова, выдержат ли тяжёлые страницы следующую волну. Для таких проектов мы делаем разбор прошлого инцидента, закрываем точки, через которые прошла атака, и настраиваем мониторинг так, чтобы новый всплеск ловился заранее. Защита перестаёт быть реакцией на пожар и становится постоянным контуром, который работает в фоне и не требует от вас внимания, пока всё спокойно.

Что вы получаете в итоге

По завершении вы получаете сайт, доступный под DDoS-атакой: со скрытым IP, настроенной фильтрацией L3/L4 и L7, защитой тяжёлых страниц и форм, кешированием под нагрузкой и при необходимости эластичным масштабированием и мониторингом 24/7. Мы передаём доступы к панелям, описание правил и рекомендации, чтобы решение оставалось вашим и его могла сопровождать как наша команда, так и ваши инженеры. DDoS из угрозы, способной в любой момент остановить продажи, превращается в управляемый и предсказуемый риск.

Как отличить настоящую атаку от обычного наплыва трафика

Не каждый всплеск посетителей — это DDoS, и реагировать на любой рост нагрузки жёсткой фильтрацией значит рисковать живыми клиентами. Поэтому перед тем как закручивать гайки, мы смотрим на характер трафика. У настоящей атаки есть узнаваемые черты: запросы идут с множества адресов короткими сериями, бьют по одним и тем же тяжёлым страницам, у них однотипные заголовки и подозрительная география, а доля обращений к статике и картинкам неестественно низкая. Обычный наплыв, наоборот, распределён по сайту, ведёт себя как люди и приносит просмотры карточек, переходы по меню и заказы. Мониторинг, который мы настраиваем, как раз и нужен, чтобы различать эти два сценария автоматически и поднимать тревогу только тогда, когда трафик действительно паразитный.

Эта разница важна и экономически. Если защита включает усиленный режим на каждый рекламный всплеск или сезонный пик, страдают конверсия и репутация: живых пользователей встречают проверки и капчи там, где их быть не должно. Грамотно настроенные правила работают мягко в спокойное время и резко ужесточаются только под подтверждённой атакой. Мы задаём пороги по числу запросов, по доле подозрительных обращений и по нагрузке на тяжёлые страницы, чтобы переход в боевой режим происходил по факту атаки, а не по любому колебанию трафика. Так распродажа и рекламная кампания проходят гладко, а атака встречает стену.

Что входит в сопровождение после подключения

Подключить защиту один раз недостаточно: профили атак меняются, появляются новые техники, растёт сам сайт. Поэтому мы предлагаем сопровождение, в рамках которого следим за трафиком 24/7, разбираем каждый инцидент и донастраиваем правила под новые волны. Если атакующие меняют тактику — переходят с объёмной атаки на L7 по новой странице или начинают перебирать формы, — мы корректируем фильтрацию, не дожидаясь, пока сайт ляжет. В сопровождение входит и регулярная проверка, что IP по-прежнему скрыт и не утёк через новые поддомены или интеграции, и обновление списков подсетей провайдера, и контроль того, что кеширование работает на свежих разделах сайта. Такой постоянный контур обходится дешевле, чем разовое тушение пожара под каждой новой атакой, и держит сайт устойчивым в фоне, не требуя вашего внимания, пока всё спокойно.

С чего начать

Начните с разговора. Расскажите о сайте, аудитории и о том, были ли атаки, — мы проведём бесплатный аудит защиты, найдём уязвимые точки и предложим уровень защиты под вашу задачу с понятной сметой и сроками. Если сайт уже под атакой, подключаемся экстренно и стабилизируем его в первые часы. Обсудим ваш проект — и сделаем так, чтобы следующая атака осталась незаметной для ваших клиентов.