Поведенческий ML-анализ и адаптивное митигирование DDoS-атак

Почему DDoS-защита пропускает поведенческие атаки

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

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

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

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

Что даёт адаптивное митигирование трафика

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

Время обнаружения и автоматическое срабатывание

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

Ложные блокировки реальных пользователей

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

Устойчивость сервиса под нагрузкой перестаёт зависеть от ручных действий дежурной смены: модель держит базовую линию и обновляет её по мере роста продукта.

Режимы DDoS-защиты: постоянный, по требованию, гибридный

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

Постоянный режим и режим по требованию

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

Когда гибридная схема оправдана

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

Этапы внедрения поведенческого анализа трафика

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

Аудит трафика и построение базовой линии

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

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

Настройка порогов и проверка на реальной нагрузке

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

Схемы фильтрации, регламенты и передача команде

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

Что входит в передаваемый пакет документов

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

Документы ведём в вашем контуре и на вашем языке описаний — после передачи ничего не остаётся «в голове» подрядчика. Отдельно проводим передачу настроек команде: разбираем реальные срабатывания на ваших данных, показываем, как правило меняется и как проверяется результат.

Кейс: снижение ложных блокировок при пиковых атаках

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

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

Метрики до и после внедрения

Снятие блокировок перестало быть отдельной задачей смены: автоматика отрабатывает типовые пики сама, а ручное вмешательство осталось для нестандартных сценариев. Высвободившееся время дежурные тратят на разбор попыток обхода защиты, а не на восстановление доступа покупателям.

Чем поведенческий анализ отличается от сигнатурного?

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

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

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

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

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

Технические сомнения перед внедрением

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

Сколько данных нужно, чтобы модель обучилась?

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

Вырастет ли время отклика сервиса?

Признаки снимаются асинхронно, вне обработки бизнес-логики, поэтому время ответа приложения не меняется. Если канал с телеметрией перегружен, вердикт берётся из последних рассчитанных профилей, а не блокирует запрос в ожидании пересчёта.

Что придётся менять в архитектуре?

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