Защита инфраструктуры от DDoS на уровне хостинга

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

Разберём, как защитить инфраструктуру сайта на 1С-Битрикс от DDoS на уровне хостинга и сети: чем отличаются типы атак, как строить эшелонированную защиту, где помогает CDN и rate limiting, что даёт проактивная защита Битрикс и как подготовить план реагирования. Комплексную защиту мы настраиваем в рамках услуги защиты от DDoS-атак для Битрикс.

Почему DDoS — угроза для магазина

DDoS (распределённая атака на отказ в обслуживании) — это когда множество источников одновременно шлют запросы на ваш сервер, чтобы исчерпать его ресурсы и сделать сайт недоступным для реальных клиентов. В отличие от взлома, цель тут не украсть данные, а просто вывести магазин из строя.

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

Типы атак: L3/L4 и L7

Чтобы защищаться осмысленно, нужно понимать, что атаки бывают разными по уровню и требуют разных мер.

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

Эшелонированная защита по уровням

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

1. Провайдер и сеть. Фильтрация объёмных атак до того, как трафик дойдёт до сервера.
2. CDN. Распределение и поглощение трафика, сокрытие реального IP, кэш статики.
3. Веб-сервер и rate limiting. Ограничение частоты запросов и отсев аномалий на входе.
4. Приложение и WAF. Проактивная защита и фильтрация умных атак на веб-логику.
5. Запас ресурсов. Возможность выдержать остаточную нагрузку и масштабироваться.

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

Защита на уровне сети и провайдера

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

• Защита провайдера. Хостинг или дата-центр с услугой очистки трафика отсекает объёмные атаки на подходе.
• Специализированные сервисы. Внешние фильтры пропускают через себя трафик, отдавая серверу только чистый.
• Сокрытие реального IP. Прямой адрес сервера скрыт, атаковать «в лоб» сложнее.
• Фильтрация по географии. При атаке можно временно ограничить трафик из регионов, откуда клиентов нет.

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

CDN как буфер и щит

CDN (сеть доставки контента) обычно воспринимают как способ ускорить сайт, но это ещё и один из самых эффективных слоёв защиты от DDoS. Работает он на нескольких фронтах сразу.

• Распределение трафика. Запросы принимает множество узлов CDN, а не один ваш сервер.
• Поглощение атаки. Значительная часть паразитного трафика гасится на инфраструктуре CDN и не доходит до сервера.
• Сокрытие сервера. Реальный IP спрятан за CDN, атаковать напрямую сложнее.
• Кэш статики. Картинки, стили, скрипты отдаются с CDN, снимая нагрузку с сервера при любых запросах.

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

Rate limiting и ограничение частоты

Rate limiting — ограничение числа запросов с одного источника за единицу времени — это базовая и очень действенная мера. Она не даёт одному клиенту, боту или узлу атаки завалить сервер шквалом обращений.

Настраивают его так, чтобы отсечь аномальную активность, не задев нормальных пользователей:

• Лимит на источник. Превысил разумную частоту — запросы отбрасываются или замедляются.
• Разные лимиты для зон. Тяжёлые эндпоинты (поиск, корзина) защищают строже, чем статику.
• Защита форм и API. Ограничение частоты на формах и API против перебора и спама.
• Мягкая деградация. Вместо жёсткого отказа — замедление или проверка для подозрительных.

Rate limiting работает не только против DDoS, но и против агрессивных парсеров и перебора паролей. Он тесно связан с защитой API: как ограничивать доступ к программным интерфейсам, мы разбирали в статье про REST, вебхуки и безопасность в Битрикс.

Отсев ботов и подозрительного трафика

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

• Поведенческий анализ. Частота, однообразие и неестественность запросов выдают бота.
• Заголовки и user-agent. Подозрительные или подделанные признаки клиента.
• Проверки-испытания. Вызовы, которые легко проходит браузер и не проходит простой бот.
• Белые списки. Настоящие поисковые роботы ведут себя предсказуемо и их пропускают.

Проактивная защита и WAF Битрикс

1С-Битрикс несёт собственный слой защиты на уровне приложения — проактивную защиту и веб-файрвол (WAF). Это важная часть обороны, но нужно понимать её границы.

Проактивная защита и WAF работают там, где трафик уже дошёл до приложения: они фильтруют подозрительные запросы, ограничивают активность, защищают от атак на веб-логику, инъекций и злоупотреблений. Это ценный слой против L7-атак и множества веб-угроз. Но объёмную сетевую атаку, забивающую канал, они не остановят — до приложения такой трафик уже доходит, и его нужно было отсечь раньше, на сети и CDN.

Вывод: встроенная защита Битрикс — обязательный, но не единственный слой. Её включают и настраивают, но дополняют мерами на уровне хостинга и сети. Именно связка «сеть + CDN + rate limiting + WAF» даёт эшелонированную оборону, а не любая из этих мер по отдельности.

Запас ресурсов и масштабирование

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

• Запас по ресурсам. Процессор, память и канал с резервом, а не «впритык».
• Оптимизация тяжёлых страниц. Кэш и композит снижают стоимость каждого запроса, в том числе паразитного.
• Возможность масштабирования. Способность быстро добавить ресурсов при росте нагрузки.
• Изоляция компонентов. База, приложение и статика разнесены, чтобы удар по одному не ронял всё.

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

План реагирования на атаку

Технические меры снижают риск, но в момент активной атаки решает подготовленность. Импровизация под давлением, когда сайт уже лежит, почти всегда хуже готового регламента.

1. Обнаружение. Мониторинг ловит аномальный всплеск трафика и оповещает команду.
2. Оценка. Определяют тип атаки — объёмная сетевая или на приложение — и её масштаб.
3. Реакция. Включают усиленную фильтрацию, защиту провайдера, при необходимости ограничения по географии и проверки.
4. Коммуникация. Оповещают бизнес и, при длительном простое, клиентов.
5. Разбор. После атаки анализируют, что сработало, и усиливают слабые места.

Заранее известные роли, критерии и порядок действий превращают атаку из паники в управляемый инцидент. План реагирования на DDoS — часть более широкой культуры готовности к сбоям, наравне с планом отката и резервным копированием.

Частые ошибки

• Один слой защиты. Ставка только на WAF или только на CDN — прорывается атакой другого типа.
• Защита только на приложении. Объёмную сетевую атаку встроенный WAF не остановит.
• Сервер работает впритык. Нет запаса ресурсов — ляжет от любого всплеска.
• Открытый реальный IP. Сервер атакуют напрямую в обход CDN и фильтров.
• Агрессивная фильтрация. Блокируют поисковых роботов и реальных клиентов вместе с ботами.
• Нет мониторинга. Об атаке узнают из жалоб, а не из метрик, теряя время.
• Нет плана реагирования. Меры придумывают в момент, когда сайт уже недоступен.

Чек-лист защиты

1. Сетевой уровень закрыт. Есть защита провайдера или специализированного сервиса от объёмных атак.
2. CDN подключён. Трафик распределён, реальный IP скрыт, статика кэшируется.
3. Rate limiting настроен. Частота запросов ограничена, тяжёлые эндпоинты защищены строже.
4. Боты отсеиваются. Поведенческий анализ и проверки при сохранении доступа для поисковиков.
5. WAF и проактивная защита включены. Приложение фильтрует L7-атаки и веб-угрозы.
6. Запас ресурсов есть. Инфраструктура с резервом и возможностью масштабирования.
7. Мониторинг работает. Аномалии трафика фиксируются и оповещают команду.
8. План реагирования готов. Роли, критерии и порядок действий описаны заранее.

Вывод

Защита от DDoS — это не одна кнопка, а эшелонированная оборона из нескольких слоёв. Объёмные сетевые атаки отсекают на уровне провайдера и CDN, ещё до сервера; умные атаки на приложение фильтруют rate limiting, отсевом ботов и WAF Битрикс. Встроенная проактивная защита — обязательный, но не единственный слой: сама по себе она не остановит атаку, забивающую канал.

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