DDoS: от алерта до выбора модели: диагностика DDoS и Always-On vs On-Demand / Хабр

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

На самом деле DDoS-защита начинается не с выбора сервиса и не с настройки правил — она начинается с диагностики. В этой статье мы разберём полный цикл: от момента появления алерта до выбора между Always-On и On-Demand моделями защиты.

Часть 1. Диагностика и реагирование

А точно ли это DDoS?

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

Типичные причины ложной тревоги

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

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

Изменения на сайте, привлекающие ботов. Обновление структуры URL, добавление открытых API-эндпоинтов, изменение robots.txt или публикация большого объёма нового контента могут спровоцировать волну трафика от поисковых роботов, парсеров и скраперов. Трафик при этом технически ботовый, но это не атака — это естественная реакция экосистемы на изменения.

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

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

Как отличить DDoS от легитимного всплеска активности

Ключ к правильной диагностике — анализ логов на первом же этапе. Эти признаки помогут отличить реальную атаку:

Однородные запросы: одни и те же URL, повторяющиеся User-Agent, подозрительно ровное распределение по времени.
Источники трафика: атака часто идёт из нетипичных для целевой аудитории проекта.
Корреляция с событиями: всплеск не совпадает с запуском рекламы, публикацией в СМИ, началом распродажи или праздниками.
Поведение на сайте: боты-атакеры не выполняют JavaScript, не загружают CSS/изображения, не ходят по внутренним ссылкам. Реальные пользователи генерируют сопутствующий трафик: загрузку статики, AJAX-запросы, события аналитики.
Паттерны по времени: DDoS часто демонстрирует неестественно стабильный уровень запросов (например, ровно 500 RPS). Живой трафик имеет характерные волны с подъёмами и спадами.

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

Порядок действий при подтверждённой DDoS-атаке

Допустим, в мониторинге что-то полыхает: трафик резко вырос, CPU улетел, пользователи жалуются на таймауты. Что делать прямо сейчас?

Шаг 1. Атака подтверждена — действуем

Если у вас подключён внешний анти-DDoS-сервис с моделью «по требованию» (On-Demand) — сейчас самое время его активировать. Трафик переключается на фильтрующие узлы провайдера, и дальше он берёт работу на себя. Чем быстрее переключитесь, тем меньше окно, в котором сайт остаётся под ударом. Заранее подготовленные шаблоны фильтрации и резервные каналы здесь критически важны — без них переключение растягивается.
Если у вас Always-On — трафик и так постоянно проходит через фильтрующие узлы, атака митигируется автоматически. Ваша задача — проверить, что фильтрация корректна и не блокирует легитимных пользователей. При необходимости — скорректировать белые списки совместно с провайдером.
Если внешней защиты нет, всё ложится на вас. Дальнейшие действия зависят от сложности атаки.

Шаг 2. Отбиваемся серверными средствами (если нет внешней защиты)

Простая атака обычно характеризуется предсказуемым паттерном: ограниченный набор IP, один и тот же URL, одинаковые User-Agent. С подобной можно справиться штатными средствами:

Ограничение частоты запросов в nginx: директивы limit_req_zone и limit_req задают максимальное число запросов в единицу времени с одного IP. Превышение отклоняется с кодом 503.
Фильтрация по User-Agent на уровне nginx через директиву map и условие if.
Блокировка IP через iptables — самый быстрый способ, если адресов немного.
Автоматизация через fail2ban — фильтрация и блокировка по правилам: количество запросов, паттерны в логах, аномальные заголовки.
Блокировка ботов с ответом 444 — nginx разрывает соединение без ответа. Эффективно, но агрессивные правила нередко задевают реальных пользователей, поэтому метод используется всё реже.

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

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

Шаг 3. Завершение атаки

Процесс восстановления, как правило, проходит автономно и зависит от двух факторов:

Чем мощнее атака, тем больше времени на нормализацию: очистка очередей, восстановление пулов соединений, перезапуск процессов. Если защиты не было и отбивались вручную — объём работ по восстановлению зависит от того, что пострадало, и требуется участие инженеров.
Если был подключён сервис защиты: при Always-On сервис продолжает фильтровать трафик автоматически. При On-Demand возможна небольшая задержка на ручную деактивацию защиты. При отражённой атаке ничего делать не нужно.

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

Часть 2. Always-On и On-Demand: детальный разбор

Что такое Always-On и On-Demand — базовое сравнение

В широком смысле существует две схемы защиты: Always-On (защита активна непрерывно) и On-Demand (защита работает «по требованию»). Ключевое отличие между ними кроется в режиме работы: в модели Always-On весь трафик всегда проходит фильтрацию, тогда как при On-Demand защита включается только во время атаки.

У каждой из схем есть свои плюсы и минусы.

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

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

Разные провайдеры могут вкладывать свой смысл в эти определения. Например, у компании DDoS-Guard это ещё и разделение на типы тарификации защиты сети: Always-On — это непрерывная фильтрация с ежемесячной оплатой, а On-Demand — это защита по необходимости, с оплатой по пакетам на 24 часа.

Риски и уязвимости On-Demand

On-Demand-подход к защите от DDoS нередко воспринимается как оптимальное решение с точки зрения экономии. Однако на практике такой метод таит в себе серьёзные риски, способные нанести ощутимый ущерб бизнесу.

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

Существует также вероятность того, что ресурс окажется недоступен. Например, при DDoS-атаках инфраструктура может быть перегружена ещё до того, как запустится фильтрация. Например, если On-Demand-решение при атаке типа HTTP-флуд, генерирующей 10 000 запросов в секунду, срабатывает лишь через 5 секунд, сервер, скорее всего, уже будет перегружен.

При атаках большой мощности — например, популярные у злоумышленников pulse wave, при которых вредоносный трафик направлен на ресурс короткими мощными всплесками — On-Demand может быть неэффективной моделью защиты. Если атака начинается сразу с максимальной мощности, её первая волна сойдёт на нет к моменту, когда трафик будет перенаправлен на узлы фильтрации, а как только защита «по требованию» выключится, может начаться следующий всплеск, и цикл повторится.

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

Сильные и слабые стороны Always-On

Always-On DDoS-защита предполагает непрерывную фильтрацию всего трафика через инфраструктуру провайдера защиты. Такой подход создаёт надёжную «броню» от атак, но одновременно порождает ряд компромиссов, которые важно учитывать при выборе решения.

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

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

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

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

Ещё один минус — цена. Хотя минус спорный: у высокой стоимости Always-On-решений есть обоснование: постоянная фильтрация всего трафика требует значительных ресурсов со стороны провайдера, что напрямую отражается на цене услуги. В сравнении с моделями «по требованию» Always-On обходится существенно дороже, особенно для проектов, которые редко сталкиваются с DDoS-атаками или имеют ограниченный бюджет.

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

Подходящие сценарии: где какая модель лучше

Выбор между On-Demand и Always-On — не просто вопрос абстрактных преимуществ. От него напрямую зависит, выстоит ли бизнес под атакой и сколько потеряет. On-Demand при этом остаётся разумным выбором для 70–80 % проектов, которые атакуют реже одного раза в квартал.

Сервисы/бизнесы с выраженной сезонностью

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

Денис Сивцов, руководитель направления защиты сети на уровне L3-4 в DDoS-Guard:
Не стоит, однако, думать, что защита «по требованию» подходит лишь для малого бизнеса — крупные компании также могут использовать On-Demand в качестве страховки. Так происходит, например, если крупный бизнес в состоянии сам фильтровать атаки до определённого объёма трафика, а всё, что превышает это пороговое значение, делегирует специализированному провайдеру защиты, с которым заключён договор на защиту «по требованию».

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

Среды с непрерывным циклом транзакций

Always-On-модель жизненно необходима для организаций, где даже кратковременные сбои приводят к серьёзным потерям. Это прежде всего финансовые учреждения — банки и платёжные системы, для которых даже минута простоя может обернуться миллионными убытками.

Сервисы реального времени и высокой доступности

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

Always-On-модель исключает «окно уязвимости» при переключении. Крайне важно выбирать провайдера с географически распределёнными очистительными центрами — это позволяет минимизировать задержки. Кроме того, необходим регулярный аудит правил фильтрации, чтобы снизить риск ложных срабатываний, например, блокировки легитимных транзакций из-за подозрительного IP-адреса.

Критерии выбора типа защиты

При выборе модели защиты следует обращать внимание на несколько ключевых критериев.

Стоимость простоя — один из главных факторов: если час недоступности обходится ресурсу в значительную сумму, предпочтительно Always-On-решение; если убытки терпимы, можно остановиться на On-Demand.

Тип трафика — играет существенную роль. Для API с жёсткими таймингами (например, биржевых торгов) оптимальна Always-On-защита с узлами, обеспечивающими минимальные задержки. Для статического контента (блогов, лендингов) подойдёт On-Demand в сочетании с CDN.

Ресурсы команды — наличие DevOps-специалистов, способных мониторить угрозы и вручную активировать защиту, позволяет использовать On-Demand. Если выделенного персонала нет, лучше выбрать Always-On для обеспечения автономности.

Примеры для отдельных отраслей

Какому бизнесу можно рекомендовать защиту Always-On? Такая модель довольно универсальна. В основном, в сторону Always-On разумно склониться тем компаниям, для которых простой критичен и которые часто подвергаются атакам.

Хостеры

Они размещают у себя сотни, тысячи клиентов (сайты всех типов и масштабов, игровые проекты, сервисы и многое другое). Большое количество разных клиентов = большое количество проектов = выше вероятность атаки. При таких вводных логичной будет постоянная защита.

Интернет-провайдеры

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

Финансовый сектор

Здесь Always-On — это базовая модель, которая дополняется работой центра мониторинга безопасности (SOC) и системами AI-детекции аномалий. Такая комплексная архитектура обусловлена исключительной критичностью данных: утечка финансовой информации может привести к многомиллионным судебным искам и потере лицензии.

Регуляторные требования — такие как ФЗ-152, нормативы Центрального банка РФ и европейские PSD2 и GDPR — предписывают непрерывный мониторинг и оперативное реагирование на инциденты. При этом характер угроз в финтехе отличается высокой сложностью: фишинг, мошеннические транзакции, атаки продвинутых постоянных угроз (APT) требуют обнаружения в режиме реального времени. Системы на основе искусственного интеллекта позволяют выявлять нетипичные паттерны — например, аномальные переводы — значительно быстрее, чем ручные правила.

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

Защита «по требованию» наиболее востребована у компаний с сезонной активностью, некритической инфраструктурой и ограниченным бюджетом. On-Demand подходит также в случае, когда ресурс атакуют редко.

Ивент-сервисы

Защита «по требованию» актуальна на время продажи билетов. Образовательные платформы могут пострадать от пиковых нагрузок во время набора студентов или экзаменов. СМИ и новостные ресурсы могут привлечь внимание злоумышленников или большое количество посетителей в периоды громких событий, которые они освещают.

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

Выбор между моделями Always-On и On-Demand должен зависеть от рисков, характерных конкретно для вашего проекта, а не от того, «что лучше в принципе». Для критичных систем с высокими требованиями к доступности оправдан Always-On. Для большинства остальных проектов, которые подвергаются атакам редко или нерегулярно, On-Demand остаётся разумным компромиссом между рисками и стоимостью инструмента.

Интересные мелочи и новости компании ITSumma — в нашем ТГ-канале.

DDoS: от алерта до выбора модели: диагностика DDoS и Always-On vs On-Demand