Компания Cloudflare сообщила о нейтрализации крупнейшей на сегодняшний день DDoS‑атаки. По данным провайдера, защитные системы зафиксировали и заблокировали пик 11,5 Тбит/с и до 5,1 млрд пакетов в секунду (pps). Инцидент, судя по представленной диаграмме, продолжался порядка 35 секунд, что характерно для «ударных» гиперобъемных кампаний, ориентированных на исчерпание пропускной способности и ресурсов сетевой обработки.
Новый рекорд: 11,5 Тбит/с и 5,1 млрд pps
По информации Cloudflare, атака была реализована в виде UDP‑флуда — потока неинициируемых соединением пакетов, нацеленного на насыщение каналов и устройств L3/L4. Ключевой показатель в 5,1 млрд pps указывает на экстремальную нагрузку на сетевые стеки и маршрутизаторы, тогда как 11,5 Тбит/с демонстрирует масштаб попытки перегрузить каналы передачи данных.
Почему важны метрики Tbps и pps
В DDoS‑контексте Tbps описывает общий объём трафика, влияющий на пропускную способность и аплинки, а pps — интенсивность обработки пакетов сетевыми устройствами и балансировщиками. Высокий pps критичен для оборудования и систем фильтрации, поскольку повышает нагрузку на CPU и таблицы состояний, даже когда объём в битах кажется умеренным. В данном случае оба показателя оказались предельно высокими.
Откуда шёл трафик: облака и IoT‑провайдеры
Cloudflare отмечает, что источник атакующего трафика прослеживался к ряду облачных и IoT‑провайдеров, среди которых упоминается Google Cloud. Такой профиль подтверждает устойчивый тренд: злоумышленники комбинируют мощности скомпрометированных «умных» устройств и аккаунтов/инстансов в публичных облаках, чтобы быстро нарастить пропускную способность и минимизировать время подготовки.
Короткие «ударные» атаки и их цель
Продолжительность около 35 секунд хорошо вписывается в тактику «hit‑and‑run»: короткие всплески на максимальной мощности трудно отфильтровывать традиционными средствами, если у жертвы нет постоянного и распределённого по периметру экранирования на базе Anycast и автоматического скраббинга. Целью становится не только отказ в обслуживании, но и тестирование порогов SLA и реакций защитных систем.
Как меняется ландшафт DDoS: сравнение с предыдущими рекордами
Предыдущий ориентир в отрасли был зафиксирован в июне 2025 года: тогда Cloudflare заявляла о нейтрализации атаки мощностью 7,3 Тбит/с. Ещё раньше, в январе 2025‑го, фиксировался рубеж в 5,6 Тбит/с. Отраслевые тренды указывают на ускорение роста пиков: разрыв между рекордами сокращается, а амплитуда — растёт. В похожих инцидентах за считанные десятки секунд передавались десятки терабайт данных, что наглядно демонстрирует потенциал современных ботнетов и злоупотребления облачными ресурсами.
Технические выводы и практические рекомендации
Cloudflare сообщила, что её защитные механизмы регулярно отражают «сотни гиперобъёмных атак», а подробный отчёт по этому инциденту будет опубликован позднее. Уже сейчас видно, что эффективная защита от UDP‑флудов требует сочетания Anycast‑архитектуры, автоматического скраббинга трафика, адаптивных rate‑limit политик и глубокой телеметрии для быстрого детектирования всплесков.
Организациям имеет смысл: 1) согласовать с провайдером связи маршрутизацию через центры очищения (scrubbing centers) и готовность к BGP‑анонсам при перегрузке; 2) внедрить BCP 38/uRPF для противодействия подмене исходных адресов; 3) ограничить или фильтровать ненужные UDP‑службы по умолчанию, применяя порт‑ и протокол‑ориентированные ACL; 4) обеспечить резервы полосы и договорные SLA на митигирование; 5) настроить телеметрию pps/Tbps и пороги тревог, учитывающие «ударные» сценарии длительностью в десятки секунд.
Для многоуровневой защиты полезны изоляция критических сервисов за прокси с любымкаст‑растяжением, сегментация по зонам отказоустойчивости, а также тесты готовности (DDoS‑дриблинг/игры хаоса) с оценкой времени детектирования и переключения маршрутов. Для компаний, использующих облако и IoT, ключевы также регулярные аудиты учётных записей и политик egress‑фильтрации, чтобы их собственные ресурсы не стали «частью проблемы».
Гиперобъёмные DDoS‑атаки продолжают устанавливать новые рекорды, и инцидент с 11,5 Тбит/с показывает: окно реагирования сжимается до секунд, а защита должна работать проактивно и распределённо. Пересмотрите планы реагирования, убедитесь в наличии маршрутов к скраббинг‑центрам и включите мониторинг pps/Tbps. Чем раньше зафиксирован всплеск и активированы фильтры, тем выше вероятность сохранить доступность сервисов и выполнить SLA.
