Термин hyper-volumetric DDoS обозначает атаки, которые давят предельной пропускной способностью каналов — насыщают трафиком так, что инфраструктура не успевает обрабатывать запросы. В сентябре 2025 года планка вновь подскочила: автоматические фильтры на периметре провайдера отразили волны до 22,2 Тбит/с и 10,6 млрд пакетов/с — без ручного вмешательства.
И это не просто цифры из пресс-релиза, это тенденция: пики трафика быстро растут, всплески становятся короче, а география — шире. Хороший срез даёт этот материал. В нём же кратко объясняется, почему «гиперобъёмные» — это уже отдельный класс инцидентов, а не просто «очень большие флуды».
Поставим точку в терминологии. Cloudflare, один из крупнейших игроков рынка, формально относит к гиперобъёмным атакам всё, что на сетевом уровне L3/L4 превышает 1 Тбит/с или 1 млрд пакетов/с, а на прикладном уровне L7 — свыше 1 млн HTTP-запросов/с. Это важно: на L7 «объёмность» измеряется в запросах, а не в битах, потому что там упираются в CPU, пулы соединений и базы.
С чего вообще начинается «гипер»
Гиперобъём возникает из сочетания трёх факторов: доступного «плеча» для амплификации, масштабируемых генераторов трафика и согласованной оркестрации атаки. Упрощённо — это (а) протоколы и сервисы, которые по природе отдают больше, чем получают; (б) управляемые площадки, способные синхронно толкнуть гигапакетный вал; (в) тактика, которая обходит простые пороговые правила.
Амплификация и отражение: когда маленькая просьба рождает огромный ответ
Классический путь к терабитам — UDP-рефлексия и амплификация. Атакующий подделывает IP-адрес жертвы, шлёт небольшой запрос на открытый в интернете сервис (DNS, NTP, CLDAP, memcached), а крупный ответ уходит на адрес жертвы. Коэффициент усиления — ключ: у memcached он достигал десятков тысяч (в пиках наблюдалось ~51 200×), у CLDAP — ~56–70×, у NTP — порядка десятков раз. Этим и объясняется феномен «из ничего — гора трафика».
Ботнеты нового образца: не камеры и роутеры, а контейнеры и облака
Классические IoT-армии по-прежнему в строю, но на сцене появился другой источник тяги — облачные и контейнерные мощности. Исследователи описали кампанию ShadowV2, которая заражает плохо защищённые Docker-окружения и сдаёт их «в аренду» как DDoS-as-a-Service. Такая модель снимает старые ограничения по полосе и pps, а ещё упрощает логистику: одна панель — тысячи инстансов с прямым аплинком.
Тонкая режиссура: короткие всплески, смешанные векторы и «ковровые» атаки
Гиперобъёмные инциденты всё чаще выглядят как короткие всплески на 20–60 секунд: пока системы сигнатур успевают среагировать, цель уже перегружена; следом — новая волна с другой географии. Параллельно растёт доля атак типа «ковровая бомбардировка» — когда бьют не в одну цель, а в десятки или сотни адресов префикса одновременно. Это обход простых триггеров: на каждом хосте вроде бы «всего по 20–30 Мбит/с», а суммарно — сотни гигабит на агрегации. Отраслевые обзоры фиксируют устойчивый рост таких «горизонтальных» атак.
Почему важен не только Тбит/с, но и pps
Когда говорят «22,2 Тбит/с», легко забыть о втором параметре — миллиардах пакетов в секунду. Для маршрутизаторов и межсетевых экранов именно pps — убийца: каждый пакет порождает прерывания, lookup в таблицах, обновления счётчиков, иногда — создание состояния. Поэтому атака с небольшими UDP-датаграммами на 10+ млрд пакетов/с может «высушить» CPU маршрутизатора и контрольную плоскость даже при умеренном bps. Рекордный инцидент как раз сочетал оба пика — 22,2 Тбит/с и 10,6 млрд пакетов/с.
Гиперобъём на L7: миллионы HTTP-запросов вместо терабитов
На прикладном уровне «гипер» проявляется иначе. В 2023-м сети пережили волны HTTP/2 Rapid Reset, когда пиковые значения доходили до сотен миллионов запросов в секунду. Здесь тяжелеют очереди, воркеры и пул БД, падают лимиты соединений и истощаются токены на API-шлюзах — и это может случиться даже при нормальной загрузке каналов. Поэтому в определении hyper-volumetric для L7 логично фигурируют млн запросов/с, а не Тбит/с.
Как строят такие атаки: разбор по слоям
L3/L4: отражение, амплификация, спуфинг
- Подмена исходных адресов. Без спуфинга рефлексия невозможна. Именно поэтому внедрение BCP 38/84 (ingress-фильтрация, uRPF) — краеугольный камень оздоровления интернета.
- Выбор вектора. CLDAP, NTP, DNS, memcached — смотрят на текущую «экосистему открытых сервисов» и доступные коэффициенты усиления. memcached исторически давал усиление в десятки тысяч раз — достаточно нескольких сотен рефлекторов, чтобы сгенерировать терабит.
- Тактика. Короткие всплески, рассинхронизация регионов, ковровая бомбардировка по префиксу, смена UDP-портов, чтобы запутать статические ACL.
L7: истощение состояния и «дешёвые» запросы
- Многопоточность протоколов. HTTP/2/3 позволяют проводить множество логических потоков в одном соединении и эффективно упираться в серверные лимиты.
- «Дешёвые» эндпоинты. Целятся в лёгкие для клиента и дорогие для сервера пути: поиск, сортировки, отчёты, запросы с холодными кешами.
- Имитаторы легитимного трафика. Фингерпринты TLS/JA3, заголовки User-Agent и куки подбираются по статистике реальных пользователей региона.
Пейзаж источников: от IoT и прошивок до «облаков как сервиса»
Бытовые роутеры и камеры по-прежнему составляют большую часть арсенала атакующих. Но мы уже видим атаки, связанные с компрометацией инфраструктуры обновлений и со всплесками заражений после таких инцидентов. Параллельно растут «арендные» ботнеты, которые монетизируют выставленные наружу контейнеры. В хронике последних месяцев — рекордные терабитные пики и новые истории про облачные DDoS-фермы.
Как защищаться: стратегия, архитектура и рутина
Против гиперобъёмов не работают точечные «пластыри». Нужны согласованные решения на нескольких уровнях — от маршрутизации до приложений. Ниже — рабочая «карта действий», которую можно адаптировать под свою роль: провайдер, корпоративная сеть, продуктовая платформа.
Сетевой периметр и провайдеры
- Антиспуфинг. На границах включите uRPF и другие механизмы BCP 38/84. Это не панацея, но уменьшает класс отражений с поддельными исходниками. Не ограничивайтесь лозунгом — пройдите по всем edge-роутерам.
- Координация RTBH/FlowSpec. Отработанные плейбуки для remotely triggered blackhole и BGP FlowSpec экономят минуты. Пропишите, кто и при каких сигналах даёт команды, какие community использовать, как отменять.
- Anycast и распределение приёма. Разнесение точек присутствия разгружает один канал и увеличивает путь атаки. Речь не только про CDN-край, но и про ваши сервисы авторизации, API-шлюзы, брокеры событий.
- CoPP и защита control plane. Политики для ICMP, TTL-expired, маршрутизаторных протоколов. Планируйте CoPP-профили на «мирное время» и «шторм», тестируйте их на стенде.
- Скруббинг как процесс. Скрубберы эффективны, когда заранее отработаны маршруты отвода и критерии срабатывания. Не держите всё в одном узле фиксированной ёмкости — распределяйте очистку ближе к источникам.
Владельцы приложений и платформ
- Готовьте L7 к млн запросов/с. Ограничивайте конкуренцию за тяжёлые ресурсы (пулы БД, очереди), применяйте ограничения конкурентности и fair queuing по ключам. Для API полезны токены-«ведёрки» и лимиты «на клиента», а не «на IP».
- Интеллектуальные проверки. Классические CAPTCHA ухудшают UX и автоматизируются. Предпочтительнее бесшовные проверки: вычислительные или временные пазлы, одноразовые маркеры, TLS-фингерпринтинг и поведенческие сигналы.
- Распределённый кеш. Дешёвые ответы при атаке критичнее: кешируйте вариации дорогих запросов, используйте отрицательный кеш, применяйте «ответы-заглушки» для дорогих эндпоинтов при деградации.
- Исключайте рефлекторы у себя. Не держите memcached по UDP 11211 наружу, CLDAP без ACL, «говорливые» NTP. Проверьте экспозицию: это спасает не только вас, но и чужие цели.
- Дизайн деградации. «Лёгкая версия» сайта, отключаемые виджеты, очереди ожидания, принудительная статичность.
Облака и контейнеры
- Нулевая экспозиция по умолчанию. Для Docker/K8s — явные security groups, запреты на 0.0.0.0/0 для UDP-сервисов, регулярный инвентарь открытых портов.
- Харднинг базовых образов. Уберите ненужные демоны, отключите автозапуск служб и UPnP-подобные механизмы, следите за supply chain. Истории про массовые заражения экспонированных контейнеров — не теория.
- Сигналы раннего обнаружения. Аномалии egress-трафика, пачки коротких UDP-датаграмм к странным портам, обращения к известным рефлекторам — триггер для автоизоляции инстанса.
Чек-лист готовности к гиперобъёму
- Включён и проверен антиспуфинг на всех edge-устройствах (uRPF/ingress-ACL по BCP 38/84). Раз в квартал — сплошной аудит.
- Плейбуки для RTBH/FlowSpec/Anycast-переключений. Указаны конкретные ASNs, communities, контактные лица 24/7.
- Синтетика: регулярные учения — короткие pps-всплески на стенде, проверка CoPP и деградационных сценариев.
- Набор метрик: не только bps, но и pps/cps, время ответа, состояние пулов, утилизация control plane.
- Инвентаризация экспозиции: DNS/NTP/CLDAP/memcached недоступны извне; Docker/K8s — наружу только нужные сервисы.
- Контракты и SLA с провайдерами и площадками — с целевыми показателями по pps и сценариями эскалации.
Частые ошибки и опасные заблуждения
- «У нас 200 Гбит канала — этого хватит». Не хватит, если прилетит 500 Гбит и 3 млрд пакетов/с, или если атака распределится по префиксу и упрётся в агрегацию.
- «Сделаем лимит по IP — и порядок». При рефлексии IP-адресов тысячи, при L7 атакующий имитирует пользователей и меняет транспорт.
- «Скруббер в одном ЦОД — как бронированная дверь». Фиксированная ёмкость перегорает; очистка должна быть распределённой и автоматической.
- «Мы не держим ничего критичного — можно не заморачиваться». DDoS бьёт не только по доступности, но и по бюджету (оверейджи, аварийные работы, штрафы по SLA).
Немного истории и контекста
Путь к «гиперу» наглядно показывают два сюжета. Первый — 2018 год, когда GitHub получил удар в 1,35 Тбит/с без всяких ботнетов: всё сделал memcached-рефлекс. Второй — 2023–2025, когда к терабитам добавились сотни миллионов L7-запросов в секунду и новая волна терабитных UDP-пиков — от 7,3 до 11,5 Тбит/с, а затем до 22,2 Тбит/с.
Практика внедрения: с чего начать завтра
- Разверните антиспуфинг. Проверьте и задокументируйте uRPF/ingress-фильтры на всех внешних интерфейсах. Опирайтесь на BCP 38 и BCP 84.
- Соберите контактную карту. У кого из ваших аплинков включается RTBH? Кто принимает FlowSpec? Какие communities использовать? Где 24/7-контакты?
- Проведите инвентаризацию экспозиции. Просканируйте наружу: нет ли у вас «говорливых» NTP/DNS/CLDAP/memcached. Это и защита, и «не навреди другим».
- Определите деградационные режимы. Что отключается первым, как меняется кеш-политика, как выглядит «лёгкая» версия приложения.
- Репетируйте. Учения с короткими pps-пиками, проверка CoPP и очередей, тесты L7 с имитацией реального фингерпринта клиента.
Итоги
Гиперобъёмные DDoS — это уже не экзотика. Это фон, на котором приходится работать: терабиты и миллиарды пакетов в секунду, короткие всплески, распределённые удары по префиксу, смешанные векторы. Источники тоже меняются: от свалки IoT-железа интернет шагает к облачным фермам и конвейеру «DDoS по подписке».
Универсального оружия нет, но есть рабочие практики: антиспуфинг по BCP 38/84, распределённый приём и очистка трафика, отлаженные плейбуки маршрутизации, продуманная деградация приложений и системная работа с экспозицией протоколов-усилителей. Чем раньше это станет рутиной, тем меньше шанс, что следующий шторм трафика окажется последним.
