Настройка DDoS protection: что ломается без защиты периметра
Пиковый всплеск запросов редко выглядит как атака в логах: канал забивается подпиской, очередь соединений на балансировщике растёт, и приложение начинает отвечать по остаточному принципу. Перегрузка канала запросами съедает тот запас, который закладывали под распродажу или утренний пик, — отказ приходит раньше, чем мониторинг успевает подать внятный сигнал.
Дальше срабатывает эффект домино: недоступность сервиса под нагрузкой бьёт именно по тем клиентам, которые приносят выручку, — по оплате, оформлению заказа, личному кабинету. Дежурная смена в этот момент тушит следствие: перезапускает узлы, расширяет пул, подкручивает лимиты. Причина — вредный трафик, дошедший до приложения, — остаётся на месте и возвращается на следующем пике.
Самодельные фильтры на этом фоне бывают опаснее самой атаки: ложные срабатывания фильтра отсекают живых пользователей по геолокации или по поведению, и вместе с мусором уходят реальные заказы. Защита периметра — например, на Cloudflare — устроена иначе: вредный трафик гасится на границе, до того как займёт канал и очередь приложения.
Настройка ddos protection — это не включённая галочка, а набор порогов, режимов и правил под профиль вашего трафика: где включать проверку, какие источники считать доверенными, при каких уровнях поднимать чувствительность, чтобы не задеть своих. Ниже разбираем, как это закрывается — от схемы фильтрации до порядка действий в момент атаки.
Что меняется после включения фильтрации: пять измеримых эффектов
Фильтрация трафика — не тумблер «включить и забыть»: эффект проявляется в метриках, которые дежурная смена смотрит каждое утро. Ниже пять показателей, которые сдвигаются предсказуемо, если правила фильтрации и пороги выставлены под профиль вашего трафика, а не оставлены по умолчанию.
Доступность под пиковой нагрузкой
Мусорные запросы отсекаются на периферии и до приложений не доходят — сервис перестаёт проваливаться в часы пик. Вместо минут недоступности на графике остаётся ровная полка, а расширять пул по каждому всплеску больше не нужно. Проверяем это синтетическим залпом с внешних точек, а не по отчётам самого фильтра.
Время восстановления после всплеска
Атака обрывается на входе, внутренние сервисы не накапливают очередь и не теряют соединения. Время восстановления измеряется десятками секунд вместо минут ручных переключений, и в большинстве случаев дежурный узнаёт о попытке уже после её отражения — по журналу.
Доля отбитого мусорного трафика
Настроенные сигнатуры и поведенческие правила снимают основную часть паразитной нагрузки — на бэкенд доходит только трафик с осмысленными запросами. Разница видна по числу обращений к приложению при неизменном объёме входящего потока: внутренняя инфраструктура перестаёт быть узким местом.
Устранённый класс отказов
Уходит целый класс аварий, где причина — исчерпание соединений или переполнение очереди под наплывом ботов. Инциденты такого типа просто перестают открываться, и разбор идёт не по «почему упало», а по «сколько отбили». Это меняет и характер дежурства: ночные подъёмы по однотипной причине исчезают.
Нагрузка на дежурную смену
Объём ручных разбирательств перестаёт расти вместе с числом попыток: типовые сценарии закрыты правилами, а не реакцией инженера. Смена тратит время на тюнинг порогов и разбор аномалий, а не на тушение одного и того же отказа. Отдельно проверяем, что легитимные пики — распродажи, кампании, партнёрские интеграции — проходят без ложных блокировок. Схему защиты строим на Cloudflare или встроенных средствах облака — выбор завит от того, где живёт трафик и кто отвечает за правила.
Сравнение режимов защиты периметра: когда какой подходит
Режим защиты выбирают не по мощности сервиса, а по классу атак и по тому, что происходит с трафиком в спокойное время. Отсюда три развилки: на каком уровне принимается решение об отбрасывании пакетов, где физически стоит фильтр и как быстро переключается маршрут при атаке.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Встроенная защита облачного провайдера | Сервис живёт в облаке, атаки сетевые и объёмные | Фильтрация прикладного уровня ограничена шаблонами, тонкая логика под свой протокол недоступна |
| Внешний фильтр на периметре | Нужны правила под собственное приложение и единая точка для нескольких площадок | Трафик идёт через третью сторону: задержка, шифрование, юридическая сторона |
| Локальный фильтр на своей площадке | Есть собственная сеть и канал, важна суверенность данных | Пропускная способность канала — потолок: при переполнении атака ложится на аплинк |
| Гибрид с аварийным переключением | Нужен постоянный фильтр плюс дежурный контур на пиковые атаки | Два набора правил, согласованные пороги, регулярные учения на переключение |
Постоянный фильтр против дежурного режима
Постоянный фильтр держит трафик через защитный контур всегда: правила обкатаны, поведение предсказуемо, но задержка добавляется к каждому запросу. Дежурный режим включают только при атаке — переключением DNS с малым TTL или анонсом адресов, — в остальное время трафик идёт напрямую.
Пороги дежурного режима настраивают по обычному профилю трафика и прогоняют на учениях: иначе в момент атаки выясняется, что часть правил блокирует легитимных клиентов. Ограничение любого режима — не мощность фильтра, а точность правил: слишком широкий запрет бьёт по доступности сильнее самой атаки.
Порядок внедрения: от аудита трафика до передачи в эксплуатацию
Работы идут так, чтобы защита включилась без остановки сервиса и без блокировки живого трафика: сначала фиксируем, как запросы доходят до приложения, потом выбираем точку включения фильтра, и только затем настраиваем пороги.
Аудит и схема трафика
Собираем карту: домены, реальные источники запросов, балансировщики, прокси, внешние сервисы по обратным вызовам. Отдельно проверяем, сохраняется ли адрес клиента на всём пути — от этого зависит, отличит ли фильтр бота от человека и не заблокирует ли добросовестных посетителей.
- Снимаем схему прохождения трафика — от точки входа до приложения, с указанием, какой узел что принимает и где видны настоящие адреса клиентов.
- Выбираем точку включения фильтра: внешний периметр очистки (Cloudflare, AWS Shield, Cloud Armor), балансировщик или участок перед конкретным сервисом. Фиксируем, что фильтруется всегда, а что — по расписанию.
- Настраиваем пороги срабатывания и правила: базовую линию запросов на пользователя, лимиты по частоте, признаки аномалий, исключения для мониторинга и партнёрских интеграций.
- Проверяем защиту на учебной атаке — управляемом всплеске из тестового контура: какие правила сработали и не ушёл ли в блокировку обычный трафик.
- Обучаем смену: как читать панель, что делать при срабатывании, как временно ослабить фильтр, не открывая периметр целиком.
- Вводим защиту в эксплуатацию: включаем режим блокировки, закрепляем регламент дежурства и точку быстрого отката.
Проверка на учебном всплеске
Всплеск показывает, при каком профиле нагрузки срабатывает правило и за какое время восстанавливается обычная работа сервиса. По итогам корректируем пороги: снимаем лишние блокировки и ужесточаем то, что пропустило нагрузку. На выходе защита включена, проверена и передана смене — с регламентом и точкой отката.
Документы и артефакты, которые передаём после внедрения
Внедрение защиты заканчивается не включением фильтрации, а передачей комплекта, по которому ваша команда работает дальше без нас: разбирается в схеме, меняет пороги, вводит в курс дежурного. Ниже — что остаётся у вас на руках.
- Схема прохождения трафика — путь запроса от внешнего контура до балансировщика и приложений, точки фильтрации, участки, которые защита не покрывает.
- Конфигурация правил фильтрации и порогов: сигнатуры, ограничения по частоте запросов, списки исключений, режим наблюдения для новых правил.
- Политики доступа к панели управления — раздельные учётные записи вместо общей, обязательная двухфакторная аутентификация, границы прав по ролям.
- Журнал изменений настроек — что, когда и зачем правили, кто согласовал, как откатить: без него разбор инцидента превращается в догадки.
- Инструкция по самостоятельной правке порогов — где безопасный предел, а где начинаются блокировки живых клиентов.
- Чек-лист проверки после изменений — набор запросов и сценариев, которыми дежурный убеждается, что легитимный трафик проходит.
Регламент действий при атаке
Это документ на одну-две страницы, который читают в момент инцидента, а не в спокойный день. В нём — признаки атаки и пороги срабатывания, порядок эскалации с именами и каналами связи, первые действия дежурной смены, критерии перехода на усиленный профиль защиты и возврата к обычному. Отдельно — что фиксировать в журнале по итогам.
Кейс: как убрали всплески отказов на пике нагрузки
Клиент — сервис с выраженным суточным пиком: вечерние часы и старт распродаж давали кратный рост обращений, а вместе с ним приходил мусорный трафик — сканеры, боты, повторы запросов к динамическим страницам. Периметр пропускал всё подряд, и приложение упиралось в предел раньше, чем приходила настоящая нагрузка.
Что было до
Пик длился 40–60 минут. Доля запросов, дошедших до приложения, проседала до 55% — остальное терялось на ожидании ответа. Время недоступности в пик доходило до 12 минут за вечер: часть пользователей видела ошибки и уходила. Инженеры разбирали 5–7 ночных инцидентов в месяц, каждый — с ручным расширением мощностей и разбором журналов.
Что стало после
Защиту периметра собрали на Cloudflare и развели правила по слоям: сначала отсев по поведению и репутации адресов, затем ограничение частоты для чувствительных маршрутов, и только после этого — очередь к приложению. Доля отбитого мусора — около 30% входящего потока, а доля полезных запросов, дошедших до приложения, выросла до 97%.
За месяц наблюдений недоступности в пик не зафиксировано, ошибки на входе исчезли из отчётов. Ночные разбирательства сменились плановым разбором аномалий раз в неделю. Статика и кеш отдаются с периметра, поэтому рост пика перестал перекладываться на приложение.
Чем отличается фильтрация DDoS на сети от защиты приложения
Сетевой фильтр работает с потоком, а не с содержимым запроса: он оценивает объём, адрес источника, частоту новых соединений и распределение по портам. Такой фильтр гасит объёмные всплески — амплификации, SYN-флуд, ботовые сети — до того, как трафик займёт канал до серверов. Но вредный запрос от полезного он не отличает, если тот выглядит как обычный.
Защита приложения смотрит внутрь запроса: маршрут, заголовки, тело, частоту обращений к конкретной форме, поведение сессии. Здесь отбиваются целевые атаки — всплеск на страницу авторизации, перебор учётных данных, медленные запросы, которые держат соединение открытым и почти незаметны по объёму.
| Уровень защиты | Что отбивает | Что остаётся незакрытым |
|---|---|---|
| Сеть и транспорт | Объёмные потоки, амплификации, SYN-флуд | Медленные атаки и «легитимный» трафик с полезной формой запроса |
| Приложение | Всплески на конкретный маршрут, перебор, аномалии сессий | Объём, который забивает канал ещё до разбора запроса |
| Совмещённая схема | Объём на входе плюс аномалии по смыслу на выходе | Требует согласованных порогов, иначе режется полезный трафик |
Ни один уровень не самодостаточен. Без сети канал и балансировщик упираются в потолок раньше, чем сработают правила приложения, и до них просто не доходит запрос. Без приложения всё, что похоже на нормальное обращение, проходит насквозь — фильтр видит ровный поток и не реагирует.
Инструменты вроде Cloudflare дают обе плоскости в одном контуре: сначала включаются сетевые правила, затем правила приложения с порогами под реальный профиль трафика. Совмещение уровней и есть рабочая схема — фильтр держит объём, приложение режет аномалии, а пороги настраиваются по факту, а не на глаз.
Технические сомнения: ложные срабатывания, задержки, обходы
Ложные срабатывания — не свойство защиты, а следствие порогов, выставленных на глаз. Поэтому правила сначала идут в режиме наблюдения: накапливаем логи, разбираем по эндпоинтам, добавляем исключения для колбэков платёжных систем, мобильных клиентов и проверок доступности. Блокировка включается, только когда ложных попаданий в логе не остаётся.
Задержку определяет не фильтрация, а место проверки. Проверку ботов ставим на кэшируемые ответы на краю, чтобы до серверов доходил очищенный трафик; для API оставляем поведенческий анализ без challenge. Время ответа на 95-м процентиле замеряем до и после — разница обычно в пределах погрешности.
Что делать при смене схемы развёртывания?
Правила привязываем к именам и меткам, а не к адресам, поэтому при переезде или добавлении балансировщика меняется только точка приёма трафика. Порядок фиксируем заранее: поднимаем новый контур, проверяем фильтрацию на тестовом потоке, затем переключаем боевой.
Мешает ли защита защищённому каналу?
Нет: анализ идёт по метаданным соединения, содержимое разбирается после терминации. Внутренние вызовы оставляем на взаимной аутентификации — фильтр не блокирует доверенный трафик и не пропускает подмену.
Кто отвечает за пороги после передачи?
Настройки передаём с документацией: что за правило, на какую метрику реагирует, что происходит при срабатывании и как откатить. Дальше пороги живут у вашей команды, мы остаёмся на поддержке и пересматриваем правила при росте нагрузки.
Обсудим вашу задачу: что прислать для оценки и плана
Чтобы оценка и план внедрения опирались на вашу инфраструктуру, а не на общие соображения, хватит нескольких вводных. По ним мы определяем точку фильтрации трафика, режимы работы защиты и порядок включения без простоя.
- Схема прохождения трафика. Где стоит балансировщик, где расшифровывается трафик, какие каналы и внешние точки входа задействованы. От этого зависит, встаёт защита перед балансировщиком или после него.
- Перечень сервисов на периметре. Какие приложения и порты смотрят наружу, что критично, а что можно временно закрыть на время атаки.
- История инцидентов. Что уже происходило: всплески на канале, флуд на прикладной уровень, попытки исчерпать соединения. Прошлые атаки описывают профиль трафика точнее любой анкеты.
- Требования к доступности. Допустимое время реакции, поведение при ложных срабатываниях, какие легитимные источники блокировать нельзя — партнёрские интеграции, мобильные клиенты, офисные сети.
- Ожидаемый профиль нагрузки. Во сколько раз пик превышает обычный трафик, есть ли сезонные всплески и разовые события, к которым готовимся заранее.
- Ответственные на вашей стороне. Кто даёт доступы к панели управления защитой и к доменным записям, кто согласует окно работ и с кем мы эскалируем ночью во время атаки.
С таким набором мы возвращаемся с оценкой и планом внедрения: где встаёт защита, какие пороги выставляем, как проверяем правила на живом трафике и как откатываемся одной правкой. Опишите задачу защиты — дальше уточним детали вопросами.
