Диагностика DDoS и выбор защиты: Always-On или On-Demand

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

Шаг 0. А точно ли это DDoS?

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

Частые причины ложной тревоги

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

• Инфраструктура не тянет рост. Трафик растёт органически, но в какой-то момент сервер перестаёт справляться: запросы копятся в очереди, время ответа растёт, нагрузка лавинообразно увеличивается. Это маркер необходимости масштабирования, а не атака.

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

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

• Каскадные сбои. Некорректные cron-задачи, бесконечные редиректы, циклические вызовы между микросервисами, утечки соединений к БД — внутренний трафик перегружает сервер изнутри. На графиках аномалия, но источник не снаружи.

Как отличить атаку от живого трафика

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

• Однородность. Одни и те же URL, повторяющиеся User-Agent, подозрительно ровное распределение по времени.

• Источники. Трафик из нетипичных для вашей аудитории регионов и сетей.

• Нет корреляции с событиями. Всплеск не совпал с запуском рекламы, публикацией в СМИ, распродажей или праздниками.

• Поведение на сайте. Боты не выполняют JavaScript, не грузят CSS и картинки, не ходят по внутренним ссылкам. Живой пользователь тянет статику, AJAX-запросы, события аналитики.

• Паттерн по времени. Неестественно стабильный уровень (например, ровно 500 RPS) — маркер атаки. Живой трафик идёт волнами с подъёмами и спадами.

И только убедившись, что это атака, переходите к митигации.

Что делать при подтверждённой атаке

Шаг 1. Если есть внешняя защита

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

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

• Защиты нет — всё ложится на вас, дальше действуем по сложности атаки.

Шаг 2. Если защиты нет — серверные средства

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

• limit_req_zone + limit_req в nginx — лимит запросов с одного IP, превышение отклоняется кодом 503.

• Фильтрация по User-Agent через директиву map и условие if.

• Блокировка IP через iptables — самый быстрый способ, если адресов немного.

• fail2ban — автоматизация по правилам: число запросов, паттерны в логах, аномальные заголовки.

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

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

Шаг 3. После атаки

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

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

Always-On vs On-Demand: в чём разница

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

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

Слабые места On-Demand

Экономия оборачивается рисками:

• Окно уязвимости. Системе нужно время распознать атаку и развернуть защиту. Если решение при HTTP-флуде в 10 000 запросов в секунду срабатывает лишь через 5 секунд, сервер, скорее всего, уже ляжет в даунтайм.

• Pulse wave. Короткие мощные всплески: первая волна сходит на нет к моменту переключения на фильтрацию, а как только защита выключится — начинается следующая, и цикл повторяется.

• L7-атаки. Запросы, имитирующие легитимных пользователей, малый объём трафика, смена паттернов — могут долго оставаться незамеченными, пока не приведут к последствиям от утечки данных до полной остановки сервиса.

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

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

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

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

Денис Сивцов, руководитель направления защиты сети на уровне L3-4, DDoS-Guard

Какую модель выбрать

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

On-Demand подойдёт

• стартапам и малому бизнесу с эпизодическими всплесками, не входящим в приоритетные цели злоумышленников;

• корпоративным порталам с ограниченным доступом и узкоспециализированным сервисам, где постоянная защита избыточна;

• сезонным нагрузкам: продажа билетов, набор студентов и экзамены, освещение громких событий в СМИ.

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

Денис Сивцов, DDoS-Guard

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

Always-On нужен

• сервисам с непрерывным циклом транзакций, где недопустим даже кратковременный простой;

• финтеху и госпорталам: регуляторные требования (ФЗ-152, нормативы ЦБ РФ, PSD2 и GDPR) предписывают непрерывный мониторинг и оперативное реагирование, а цена сбоя — штрафы, отзыв лицензии, потеря доверия — выше стоимости защиты.

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

Чек-лист: 7 правил DDoS-защиты

1. Не ждите первой атаки. Закладывайте защиту в архитектуру на этапе планирования — аварийное подключение это стресс и потенциальные ошибки.

2. Сначала диагностика, потом блокировки. Убедитесь, что всплеск — это атака, а не маркетинг, рост аудитории или проблемы инфраструктуры.

3. Держите наготове план Б. Скрипты статических страниц, шаблоны правил nginx и iptables, настроенный fail2ban.

4. Выбирайте модель по профилю рисков. Always-On — для критичных проектов с частыми атаками, On-Demand — для ограниченного бюджета и редких инцидентов.

5. Учитывайте эволюцию атак. Повторяются — значит, усложняются. После каждого инцидента разбирайте логи, раз в квартал пересматривайте пороги rate-limit и правила WAF.

6. Следите за ложными срабатываниями. Обновление белых списков, корректировка порогов, анализ блокировок — постоянная задача.

7. Не блокируйте трафик вслепую. Агрессивные методы (например, 444-й код nginx) отсекают реальных пользователей.

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

FAQ

Материал подготовлен ITSumma совместно с DDoS-Guard.