Время реакции на DDoS-атаку: почему у этой цифры нет одного значения

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

Продолжительность инцидентов увеличивается. По нашим данным за II квартал 2026 года, средняя длительность сетевых атак на финансовые компании выросла за год на 452%, а самые мощные атаки на телеком- и хостинг-провайдеров повторялись неделями. Поэтому при подключении antiDDoS-сервиса важно понимать, сколько времени может пройти от начала инцидента до того, как вредоносный трафик начнёт отфильтровываться на 100%. 

Коротко о главном

Реакция на DDoS-атаку включает в себя три основных этапа. У каждого своя точка отсчёта:

1. Обнаружение — срабатывание порога, который задан в личном кабинете.
2. Ответ поддержки — скорость может меняться в зависимости от тарифа. У нас это от 15 минут до 3 часов в соответствии с выбранным уровнем обслуживания.
3. Подавление — зависит от сложности атаки. 

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

Что подразумевают под временем реакции 

Обычно при нейтрализации DDoS-атаки реализуются несколько сценариев, которые могут быть независимы друг от друга:

1. До атаки уже было создано правило, которое отрабатывает при начале инцидента, и вредоносный трафик начинает фильтроваться. 
2. Сервис стал недоступным, клиент обращается в поддержку antiDDoS-провайдера, где создают новые правила. 
3. Атаку первым замечает инженер, который проводит мониторинг трафика. Он  исправляет правила с учётом характеристик нового инцидента, фильтрация становится более эффективной.   

Метрика	Что измеряет	От какого события отсчёт	Где клиент это видит
TTD (Time to Detect)	Время от начала атаки  до первого оповещения. Показывает, как быстро системы мониторинга зафиксировали атаку	Фактическое начало атаки (рост трафика на графике)	От момента в графике, когда начался рост трафика, до времени в поле «Начало» отчёта или в уведомлении об атаке
TTR (Time to Respond)	Время до ответа инженера	Регистрация обращения	Тикет или сообщение в мессенджер
TTM (Time to Mitigate), время митигации DDoS	Время до подавления атаки	От момента обнаружения атаки (поле «Начало» в отчёте), а в режиме on-demand — от перенаправления трафика на очистку	На графике трафика: от времени в поле «Начало» до момента, когда трафик к серверу вернулся к обычному уровню, даже если атака продолжается

Эти числа могут быть разными — от секунд до часов. Часто в договоре с antiDDoS-провайдером закреплена только вторая метрика. Первая зависит от ваших настроек, третья — от действий техподдержки и мощности или сложности атаки. 

Если речь идёт о скорости реагирования, важно уточнять, какое событие и на каком тарифе подразумевается. Разберём все три по очереди.

1. Время обнаружения атаки

Начало атаки отсчитывается с момента, когда превышен порог трафика и/или сработало одно либо несколько правил. Какие именно, можно увидеть в отчёте об атаке в поле «Причина».  

Скорость обнаружения и включения фильтрации зависит от режима защиты:

• от 1 секунды — в режиме always-on (постоянная очистка трафика, правила применяются сразу);
• от 30 секунд — on-demand (включение фильтрации по требованию). Здесь возможны два варианта: либо клиент вручную анонсирует префиксы (тогда время реакции зависит от его действий), либо используется DDoS-сенсор и защита включается автоматически, обычно за 30–60 секунд после срабатывания порога.

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

• для сетей — во сколько раз вырос поток пакетов; 
• для сайтов — доля ответов с ошибками и превышение порога RPS.

У нас основная часть работ по мониторингу трафика клиентов выполняется в автоматическом режиме. Помимо этого, наши инженеры круглосуточно контролируют множество метрик с помощью специальных инструментов. 

2. Время ответа поддержки

Оно может отличаться как у разных antiDDoS-провайдеров, так и на разных тарифах одного подрядчика. Сравним время ответа поддержки на разных тарифах StormWall:

Продукт	Тариф	Время реакции на запрос	Гарантируемая доступность по SLA
StormWall для сайта	Personal	3 часа	не менее 98%
	Business ONE	30 минут	не менее 99,2%
	Enterprise ONE	15 минут	не менее 99,5%
StormWall для сетей и StormWall для сервисов	Standard	до 60 минут	99,2%
	Business	до 30 минут	99,5%
	Enterprise	до 15 минут	99,9%

Как устроены линии поддержки 

Часто службы технической поддержки у antiDDoS-провайдера имеют свою иерархию, от которой зависят их функции:

1. Первая линия принимает и регистрирует обращения, а затем решает, куда их направить дальше — на вторую линию или сразу профильному отделу, например сетевым инженерам. 
2. Вторая решает типовые задачи. 
3. На третьей работают инженеры с разной специализацией и более глубокими знаниями продукта, которые могут найти оптимальный способ решения нестандартной проблемы. Им передают самые сложные задачи. 

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

Другое дело, что иногда в неурочное время недоступны специалисты клиента. В полночь некому подтвердить, что всплеск трафика вызван распродажей, а не атакой. 

3. Подавление атаки: правила и итерации

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

Если атака сложная или меняет вектор, инженеры добавляют и уточняют правила. Каждая такая итерация отсекает ещё часть вредоносного трафика, поэтому подавление может идти в несколько этапов.

Правила бывают двух классов:

1. Безусловные отрабатывают сразу. Такие правила проверяют каждый пакет с момента, когда трафик попал на очистку. Если правило блокирует пакеты с определённым заголовком, то соответствующий пакет будет отброшен мгновенно. 
2. Пороговые ждут выполнения условия. Допустим, правило должно отсекать трафик с IP-адреса, с которого пришло 100 пакетов за 10 секунд. Если злоумышленник отправит 99 пакетов за первую секунду, а потом сотый пакет на 10-й секунде, трафик будет заблокирован только на 10-й секунде. По этой причине от пороговых значений зависит и время обнаружения атак.

Защита может быть двух типов.

Неинтерактивной, то есть не требующей ответа от браузера пользователя:

• статический и динамический анализ трафика;
• разбор кодов ответов сервера;
• контроль всплесков запросов к конкретным URL-адресам;
• геофильтрация;
• поведенческий анализ;
• JA3/JA4-отпечатки (методы создания уникального «отпечатка» клиента на основе характеристик его TLS-рукопожатия, позволяют идентифицировать браузер, HTTP-библиотеку, инструмент автоматизации или бота по тому, как они инициируют защищённое соединение);
• анализ подозрительных запросов с помощью машинного обучения.

Интерактивной, когда используются:

• капча (тест, который проходит сам пользователь: выбрать картинки, ввести символы или передвинуть ползунок; существуют и «невидимые» варианты, которые оценивают поведение посетителя в фоне и показывают задание только при подозрении на бота);
• JavaScript-тесты (браузер должен выполнить небольшой скрипт, например вычислить значение и вернуть его в куки. Настоящий браузер справляется незаметно для пользователя, а большинство ботов — нет);
• HTTP-редирект (механизм в протоколе HTTP, который автоматически перенаправляет пользователя с одного URL-адреса на другой — примитивные боты не переходят по ссылке перенаправления).

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

Когда подавление атаки может затянуться

• Сложные и многовекторные атаки. Если нужно изменить правило вручную, в простом случае его настраивают в веб-интерфейсе за пару минут, и оно за секунды распространяется по узлам фильтрации. При сложных атаках сначала нужно понять, с чем мы имеем дело, — собрать данные, определить векторы и скорректировать настройки защиты. Если первое правило не помогло, проводятся дополнительный анализ и настройка: всё это может увеличить время подавления. При многовекторной атаке каждый вектор приходится отсекать отдельно. Если злоумышленник меняет вектор на ходу, правила корректируют несколько раз.
• Низкоинтенсивные (мелкие) атаки на прикладном уровне L7 (например, около 100 RPS), которые маскируются под легитимный трафик и требуют детального анализа. Здесь растёт в первую очередь время обнаружения.

В нашей практике был случай бот-атаки на форму. Крупная компания получала через приложение множество запросов на отправку СМС. За ними скрывался вредоносный бот-трафик: в поле «Телефон» отправители указывали случайные несуществующие номера. Количество таких запросов в секунду (RPS) составляло всего 100 и было незаметно на общем графике. Атаку обнаружили после жалобы клиента, который заметил, что количество попыток отправить СМС резко выросло.  

Что входит в SLA 

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

В SLA StormWall обозначены основные определения:

• DDoS-атака — событие, которое приводит к перегрузке или недоступности защищаемого ресурса и требует применения мер защиты;
• недоступность — состояние, при котором пользователи не могут получить доступ к сервису или его ключевым функциям;
• качество очистки — эффективность фильтрации вредоносного трафика при минимальном влиянии на легитимный.

Нарушением не считается простой по причинам вне зоны ответственности провайдера, например, неработоспособность сервисов на стороне клиента или его интернет-провайдера. 

При невыполнении SLA предусмотрена компенсация.

Обычно в этом документе прямо указывается время ответа поддержки. Отдельного норматива на TTD и TTM (время до обнаружения и до подавления атаки) в SLA нет, но они косвенно входят в гарантию доступности. Если атаку подавляют слишком медленно, ресурс будет недоступен, а время недоступности идёт в зачёт SLA. Обнаружение и подавление атак можно отслеживать в Личном кабинете в реальном времени и проверять по отчётам.

Значения SLA зависят от тарифа. Например, у StormWall для защиты сайта — от 98% доступности и 3 часов на ответ на Personal, до 99,5% и 15 минут на Enterprise ONE.

Как рассчитать своё время реакции по данным личного кабинета

Чужая статистика мало что скажет о вашем сервисе. Профиль трафика, пороги детектирования и набор атак у каждого свои, поэтому надёжнее посчитать своё время реакции по собственным инцидентам. Данные для этого можно найти в Личном кабинете.

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

Учитывайте, что графики строятся с адаптивным семплированием — при превышении 95-го перцентиля показывается максимум за период, при обычном трафике — среднее. Поэтому по графику удобно оценивать пик атаки, а точные метки времени и цифры лучше брать из таблицы или выгружать через API для использования в собственных системах.

Три сценария: что происходит после начала атаки

Точные значения зависят от инцидента, поэтому покажем, какая из метрик растёт в каждом случае.

Объёмная атака (L3-L4). Поток пакетов растёт в разы, пороги срабатывают быстро, а участие инженера обычно не требуется. В режиме always-on задержки почти нет. В режиме on-demand к подавлению добавляется время на переключение трафика: автоматически через DDoS-сенсор или вручную, когда клиент сам анонсирует префиксы.

Низкоинтенсивная атака (L7). Боты шлют небольшое количество запросов и маскируются под пользователей, поэтому пороги по объёму могут не сработать. Атаку выявляют ML-детекции по аномалиям в IP-адресах, URL и TLS-отпечатках. Основное время уходит на обнаружение (TTD), и оно во многом зависит от настроек чувствительности.

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

Когда к подавлению атаки подключается инженер

Когда автоматика не справляется со сложной DDoS-атакой в рамках текущих настроек. Инженер собирает данные, анализирует структуру атаки и корректирует правила защиты.

Обычно он реагирует на инцидент в двух случаях:

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

Что делать во время атаки и чего делать не нужно

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

Обратиться в поддержку стоит в таких случаях:

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

Не меняйте настройки сервера и защиты в Личном кабинете, если знаете, что с атакой уже работает инженер. Если что-то поменяли, сообщите об этом в обращении. 

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

В форме обращения укажите приоритет, категорию, продукт и тему, опишите проблему и приложите файл. Приоритет и категория помогают быстрее передать обращение нужному специалисту, а подробное описание со скриншотом ускорит разбор. 

В описании пригодятся временные метки с часовым поясом. Укажите защищаемый объект и то, как проблема выглядит со стороны пользователя. Если есть возможность, приложите больше информации. Например, для сайта — фрагмент логов веб-сервера за этот интервал, для сети и TCP/UDP-сервисов — дамп трафика (запись сетевого обмена между устройствами) или данные мониторинга. По этим материалам инженер составляет дополнительные правила фильтрации. 

Ответы на частые вопросы

Сколько времени занимает отражение DDoS-атаки?

Оно складывается из обнаружения и подавления атаки. Если нужна помощь инженера, добавляется время ответа поддержки.

С какого момента отсчитывается время обнаружения атаки и время подавления?

Время обнаружения отсчитывается от фактического начала атаки до срабатывания правила (поле «Начало» в отчёте). Время подавления — от обнаружения до момента, когда очищенный трафик к серверу вернулся к обычному уровню.  Для сложных и многовекторных атак между этими моментами может пройти несколько итераций подбора правил.

Нужно ли обращаться в поддержку, когда началась атака?

Обычно нет, атака чаще всего фильтруется автоматически. Обращаться стоит, если сервер перегружен или если пользователи жалуются на недоступность ресурса. Низкоинтенсивные атаки на L7 сложнее заметить по объёму трафика. В StormWall ML-детекции выявляют большинство таких DDoS-атак, но атаки на бизнес-логику иногда первым замечает сам клиент. 

Как быстро отвечает поддержка?

У каждого провайдера свои гарантии, которые отличаются в зависимости от продукта и тарифа. У нас время ответа — от 15 минут до 3 часов.

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

В Личном кабинете. В отчёте StormWall будет график с количеством атак по дням (цветом отмечено, по какой метрике зафиксирована атака: PPS, BPS или RPS). Также в Личном кабинете вы можете посмотреть таблицу атак, где прописаны объект, детектор, пик, начало, конец, сработавшее правило и тип (L3 или L7). Наши отчёты  выгружаются в PDF или приходят на почту по расписанию.

Автор: Юлия Ильина, технический эксперт StormWall