Random Packet Flood и Garbage Packet Flood: атаки случайными и некорректными пакетами

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

Названия этих атак часто используются как синонимы, но между ними есть практическое различие. В Random Packet Flood злоумышленник постоянно меняет характеристики пакетов, чтобы создать большое количество вариантов трафика и затруднить построение статического правила. В Garbage Packet Flood акцент делается на бессмысленных, противоречивых, повреждённых или не соответствующих ожидаемому протоколу данных.

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

Что такое сетевой пакет

Сетевой пакет состоит из нескольких уровней заголовков и полезной нагрузки. Конкретная структура зависит от используемых протоколов, но типичный пакет может включать:

1. канальный заголовок Ethernet;
2. заголовок IPv4 или IPv6;
3. заголовок TCP, UDP, ICMP либо другого транспортного протокола;
4. данные прикладного протокола;
5. контрольные и служебные поля.

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

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

Что такое Random Packet Flood

Random Packet Flood — поток сетевых пакетов, в которых массово изменяются один или несколько параметров. Рандомизация позволяет атакующему создавать большое количество комбинаций, не повторяющих один очевидный шаблон.

Изменяться могут:

• IP-адрес источника;
• порт источника;
• порт назначения;
• номер IP-протокола;
• TTL или Hop Limit;
• идентификатор IP-пакета;
• DSCP и ECN;
• TCP-флаги;
• sequence number и acknowledgment number;
• размер TCP-окна;
• длина UDP-дейтаграммы;
• размер пакета;
• параметры фрагментации;
• содержимое полезной нагрузки;
• комбинация IPv4- и IPv6-трафика.

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

Основные цели рандомизации

Обход простых сигнатур. Если все пакеты имеют одинаковый размер, порт и флаги, их сравнительно легко описать одним правилом. Постоянное изменение полей затрудняет такую фильтрацию.

Распределение по таблицам. Разные комбинации адресов и портов создают множество уникальных потоков. Stateful firewall, NAT или система мониторинга могут воспринимать их как отдельные соединения.

Увеличение стоимости анализа. Оборудование не может ограничиться сравнением с одним шаблоном и вынуждено разбирать больше полей.

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

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

Что такое Garbage Packet Flood

Garbage Packet Flood — не название одного стандартизированного протокольного механизма, а практический термин для потока «мусорных» пакетов. Под ним могут понимать пакеты с бессмысленной нагрузкой, противоречивыми полями, повреждёнными заголовками или структурой, не соответствующей заявленному протоколу.

К этой категории могут относить:

• пакеты с некорректной длиной;
• пакеты с недопустимыми комбинациями полей;
• TCP-сегменты с необычными сочетаниями флагов;
• UDP-дейтаграммы с неверной ненулевой контрольной суммой;
• пакеты с неизвестным или неожиданным номером протокола;
• фрагменты, которые невозможно корректно собрать;
• пакеты с обрезанными заголовками;
• случайные данные, отправленные на порт реального приложения;
• псевдо-HTTP, не соответствующий синтаксису HTTP;
• повреждённые TLS-записи;
• неожиданные IPv6 extension headers;
• противоречие между фактической и заявленной длиной данных.

RFC 1122 требует от получателя отбрасывать UDP-дейтаграмму с ненулевой, но неверной контрольной суммой. Однако до отбрасывания пакет уже должен быть принят и проверен. При миллионах таких пакетов сама процедура проверки становится измеримой нагрузкой.

Чем Random Packet Flood отличается от Garbage Packet Flood

Random Payload и Random Packet — не одно и то же

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

Необходимо различать:

• random payload — меняются данные внутри пакета;
• random headers — меняются поля сетевых и транспортных заголовков;
• random flows — создаются разные комбинации адресов, портов и протоколов;
• random packet sizes — постоянно меняется длина пакетов;
• random protocol flood — поток распределяется между несколькими протоколами.

Изменение полезной нагрузки чаще предназначено для обхода сигнатур IDS, IPS или прикладного фильтра. Рандомизация адресов и портов сильнее воздействует на flow tables, conntrack и системы агрегации статистики.

Какими могут быть мусорные пакеты

Формально корректные пакеты с бессмысленной нагрузкой

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

Эти пакеты опасны тем, что проходят базовую сетевую проверку и могут быть переданы приложению. Уже приложение должно определить, что запрос недопустим.

Пакеты с некорректной контрольной суммой

Такие пакеты обычно отбрасываются сетевым стеком. Они редко достигают приложения, но потребляют:

• пропускную способность;
• ресурсы сетевого интерфейса;
• время обработки драйвера;
• CPU на проверку заголовков и checksum;
• ресурсы firewall или системы мониторинга.

Часть вычислений контрольных сумм может выполняться сетевой картой, но результат зависит от оборудования, драйвера, виртуализации и настроек offload.

Пакеты с неверной длиной

Заявленный размер IP-, UDP- или другого заголовка может не соответствовать фактически полученным данным. Корректный стек должен обнаружить противоречие и отбросить пакет.

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

Неожиданные TCP-флаги

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

Здесь Garbage Packet Flood пересекается с Random TCP Flag Flood. Цель заключается не только в объёме, но и в распределении пакетов между различными ветвями TCP state machine.

Неполные и противоречивые фрагменты

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

Такая активность может расходовать:

• память очередей reassembly;
• время ожидания недостающих фрагментов;
• CPU на сопоставление частей;
• лимиты одновременной сборки;
• ресурсы IPS, пытающейся восстановить исходный пакет.

Фрагментация считается хрупким механизмом: она усложняет прохождение пакетов через современные сети и защитное оборудование. RFC 8900 отдельно рассматривает практические проблемы IP-фрагментации.

На каких уровнях работает атака

Публичный сайт через интернет обычно сталкивается прежде всего с L3–L7-вариантами. Чистый L2 Flood ограничен одним канальным доменом и не передаётся обычной интернет-маршрутизацией.

Как Random Packet Flood выводит инфраструктуру из строя

1. Переполнение пропускной способности

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

2. Перегрузка по packets per second

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

Оборудование может выдерживать заявленную пропускную способность в Gbit/s на крупных пакетах, но достигать предела pps на минимальных пакетах.

3. Рост количества уникальных потоков

Если изменяются адреса, порты и протоколы, система наблюдения видит большое количество уникальных flow records. Это создаёт нагрузку на:

• conntrack;
• таблицы NAT;
• NetFlow или IPFIX exporter;
• систему хранения телеметрии;
• IDS и IPS;
• аналитическую базу данных;
• систему агрегации метрик.

4. Дорогая обработка исключений

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

Это особенно опасно для сетевого оборудования, если редкий тип пакета переводится из аппаратного forwarding plane в control plane.

5. Нагрузка на парсеры

Firewall, IPS, VPN-шлюз и reverse proxy могут разбирать несколько вложенных протоколов. Если структура постоянно меняется или содержит ошибки, устройство выполняет больше проверок и чаще обрабатывает исключительные ситуации.

6. Перегрузка журналирования

Если каждый некорректный пакет создаёт отдельное событие, система может генерировать миллионы записей. Это приводит к:

• росту нагрузки на CPU;
• заполнению диска;
• перегрузке syslog-сервера;
• увеличению затрат на SIEM;
• потере действительно важных событий;
• замедлению поиска по журналам.

7. Воздействие на приложение

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

Например, сервер может выполнять:

• разбор заголовков протокола;
• выделение буферов;
• поиск разделителей;
• проверку кодировки;
• разбор TLS ClientHello;
• формирование сообщения об ошибке;
• запись события в журнал;
• закрытие соединения.

Можно ли считать Garbage Packet Flood атакой на уязвимость

Не обязательно. В большинстве случаев это ресурсная DDoS-атака: корректная система распознаёт неправильные пакеты и отбрасывает их, но тратит ресурсы на приём и проверку.

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

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

Random Packet Flood по протоколам

Random UDP Flood

UDP удобен для генерации stateless-трафика. Атакующий может постоянно менять порты, размеры пакетов и полезную нагрузку. Если используется подмена адресов, список наблюдаемых источников становится ещё менее стабильным.

UDP не устанавливает соединение, поэтому фильтрация должна опираться на разрешённые сервисы, соответствие ответному трафику, допустимые порты, объёмы и поведение источника.

Random TCP Flood

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

Random ICMP Flood

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

Random IP Protocol Flood

В поле Protocol IPv4 или Next Header IPv6 используются разные значения. Поток может включать TCP, UDP, ICMP, GRE, ESP и неизвестные протоколы. Цель — распределить нагрузку между обработчиками и затруднить единое правило блокировки.

Random Application Payload Flood

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

Как распознать Random Packet Flood

Ключевой признак — резкое увеличение энтропии и разнообразия трафика. Вместо одного повторяющегося шаблона появляется множество комбинаций параметров.

Сетевые признаки

• рост количества уникальных пятикомпонентных потоков;
• резкое увеличение числа портов назначения;
• аномальное разнообразие TCP-флагов;
• необычное распределение размеров пакетов;
• появление множества редко используемых IP-протоколов;
• большое количество пакетов без ответного трафика;
• рост трафика на закрытые порты;
• много источников с единичными пакетами;
• хаотичное распределение TTL или Hop Limit;
• отсутствие нормальной последовательности TCP;
• необычное сочетание IPv4 и IPv6;
• резкое увеличение записей NetFlow.

Признаки Garbage Packet Flood

• рост checksum errors;
• увеличение malformed или truncated packets;
• несоответствие длины заголовков фактическому размеру;
• большое количество invalid conntrack;
• рост ошибок reassembly;
• появление неизвестных заголовков или протоколов;
• частые protocol decode errors в IDS/IPS;
• рост отброшенных пакетов до приложения;
• массовые ошибки TLS или HTTP parsing;
• увеличение журналов некорректных запросов.

Какие метрики собирать

Как отличить атаку от повреждений сети

Некорректные пакеты не всегда означают DDoS. Они могут возникать из-за:

• неисправного оборудования;
• ошибки драйвера;
• проблемы сетевой карты;
• неправильного MTU;
• ошибки туннелирования;
• повреждения данных на канале;
• неверно настроенного checksum offload;
• ошибки анализатора трафика;
• несовместимости реализаций протокола.

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

Как защититься от Random Packet Flood

1. Использовать allowlist протоколов и сервисов

На внешнем периметре должны быть разрешены только протоколы и порты, необходимые для работы инфраструктуры. Неизвестные IP-протоколы и трафик к неиспользуемым сервисам следует отбрасывать как можно раньше.

Для обычного сайта публично требуются прежде всего HTTP и HTTPS через защищённый proxy-контур. Административные интерфейсы, базы данных, внутренние API и панели управления не должны быть доступны всему интернету.

2. Выполнять раннее отбрасывание

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

Приоритетная последовательность:

1. проверка базовой корректности L2/L3;
2. проверка разрешённого IP-протокола;
3. проверка адреса и порта назначения;
4. проверка состояния соединения;
5. rate limiting;
6. глубокий анализ;
7. передача приложению.

3. Ограничивать неизвестные протоколы

Если инфраструктура не использует GRE, ESP, IP-in-IP или другие специальные протоколы, их поступление из интернета следует блокировать. Это значительно сокращает пространство вариантов Random Protocol Flood.

4. Применять stateful-фильтрацию выборочно

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

Необходимо:

• отбрасывать явно недопустимые пакеты до conntrack;
• контролировать размер таблицы;
• настраивать разумные таймауты;
• не создавать состояния для запрещённых сервисов;
• отслеживать скорость появления новых flows;
• проверять производительность firewall в pps.

5. Ограничивать скорость ошибок

Rate limiting можно применять к:

• invalid-пакетам;
• трафику на закрытые порты;
• неизвестным IP-протоколам;
• ошибкам фрагментации;
• неожиданным TCP-флагам;
• ICMP-ответам на мусорный поток;
• журналированию однотипных событий.

Лимиты должны применяться до дорогой обработки. Ограничение после прикладного парсинга уже не экономит большую часть ресурсов.

6. Обновлять сетевой стек и прошивки

Маршрутизаторы, firewall, сетевые драйверы, ядро операционной системы, гипервизоры, VPN-шлюзы и IDS должны получать исправления безопасности. Garbage Packet Flood особенно опасен для устаревших парсеров, поскольку необычный пакет может попасть в редко используемую ветвь кода.

7. Защитить control plane

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

8. Контролировать фрагментацию

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

• на число одновременных очередей reassembly;
• на объём памяти;
• на время ожидания;
• на количество фрагментов от одного источника;
• на перекрывающиеся и противоречивые фрагменты.

9. Отключить логирование каждого события

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

• счётчиков по типам ошибок;
• NetFlow, sFlow или IPFIX;
• распределения по протоколам;
• небольшого репрезентативного PCAP;
• примеров каждого уникального шаблона.

10. Использовать операторскую очистку

Если поток занимает входящий канал, локальный firewall получает трафик слишком поздно. Оператор или scrubbing center должен отфильтровать мусор до узкого участка.

Возможные критерии фильтрации:

• номер IP-протокола;
• адрес назначения;
• порт назначения;
• размер пакета;
• TCP-флаги;
• фрагментация;
• допустимость заголовка;
• принадлежность к установленному соединению;
• аномальная скорость потока.

Почему сигнатуры недостаточны

Random Packet Flood специально создаёт большое количество вариантов. Правило, основанное на одном размере, порте или шаблоне полезной нагрузки, может остановить только часть потока.

Эффективная защита сочетает:

• валидацию протокола;
• контроль состояния;
• ограничение pps;
• базовый профиль нормального трафика;
• поведенческое обнаружение аномалий;
• агрегацию по подсетям и ASN;
• распределённую очистку;
• изоляцию origin-сервера.

Почему WAF не останавливает все мусорные пакеты

WAF анализирует HTTP- и HTTPS-запросы. Большая часть некорректных IP-, TCP- или UDP-пакетов отбрасывается до формирования HTTP-запроса, поэтому обычный WAF их не видит.

Путь может выглядеть следующим образом:

1. пакет поступает на внешний интерфейс;
2. проверяется IP-заголовок;
3. проверяется транспортный протокол;
4. TCP связывается с существующей сессией;
5. при HTTPS выполняется TLS-обработка;
6. только затем формируется HTTP-запрос;
7. HTTP-запрос передаётся WAF.

Если пакет отбрасывается на первых пяти этапах, WAF не участвует в его обработке. Поэтому защита должна начинаться на L3/L4.

Как TrafficVeil помогает при Random Packet Flood

TrafficVeil принимает HTTP- и HTTPS-трафик на reverse proxy и передаёт origin-серверу только разрешённые веб-запросы. При правильной настройке случайные пакеты, направленные на публичный адрес сайта, не достигают сетевого стека origin.

TrafficVeil полезен на следующих этапах:

• скрывает настоящий IP веб-сервера за прокси-контуром;
• отделяет сетевое соединение посетителя от соединения с origin;
• не передаёт некорректные HTTP-запросы на backend;
• фильтрует L7 DDoS и автоматизированный трафик;
• применяет WAF и ограничения частоты;
• анализирует поведение клиента после прохождения сетевых проверок.

Для этого origin должен принимать HTTP/HTTPS только от разрешённых адресов TrafficVeil. Если настоящий IP сервера остаётся доступен всему интернету, атакующий сможет отправить Random Packet Flood напрямую, минуя reverse proxy.

При переполнении канала дата-центра или прямой атаке на сетевую инфраструктуру требуется отдельная L3/L4-защита у хостинг-провайдера, оператора либо в scrubbing center. WAF и прикладная фильтрация не могут освободить канал, который уже заполнен входящими пакетами.

Что делать во время атаки

1. Измерить bps и pps. Определить, перегружен канал или обработка пакетов.
2. Разделить протоколы. Установить долю TCP, UDP, ICMP, GRE, ESP, IPv4 и IPv6.
3. Проверить корректность. Оценить checksum errors, malformed headers, invalid conntrack и ошибки reassembly.
4. Найти изменяемые поля. Определить, рандомизируются ли порты, адреса, флаги, размеры или полезная нагрузка.
5. Определить точку перегрузки. Проверить канал, маршрутизатор, firewall, гипервизор, сервер и приложение.
6. Заблокировать ненужные протоколы. Оставить только необходимые сервисы.
7. Включить early drop. Отбрасывать очевидно некорректные пакеты до conntrack и глубокой инспекции.
8. Ограничить pps. Применить лимиты к мусорным и неизвестным категориям.
9. Сократить логирование. Перейти на счётчики, sampling и агрегацию.
10. Связаться с оператором. Передать цель, протоколы, объём, pps и примеры пакетов.
11. Переключить трафик на очистку. Если локальное оборудование или канал близки к пределу.
12. Закрыть origin. Устранить возможность прямого обхода TrafficVeil.

Какие данные сохранить для расследования

• время начала, максимума и окончания атаки;
• целевые IP-адреса;
• целевые порты;
• пиковые и средние bps;
• пиковые и средние pps;
• распределение по IP-протоколам;
• распределение TCP-флагов;
• размеры пакетов;
• число уникальных flows;
• checksum errors;
• malformed и truncated packets;
• ошибки сборки фрагментов;
• долю invalid conntrack;
• распределение источников по ASN и подсетям;
• NetFlow, sFlow или IPFIX;
• небольшой репрезентативный PCAP;
• загрузку CPU и память устройств;
• счётчики packet drops;
• применённые правила фильтрации;
• влияние на сайт и другие сервисы.

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

Распространённые ошибки

Считать любой случайный payload повреждённым пакетом

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

Искать одну универсальную сигнатуру

При рандомизации поток состоит из множества вариантов. Защита должна учитывать поведение и допустимую модель сервиса.

Передавать весь поток в глубокий анализ

Глубокая инспекция дороже базовой фильтрации. Очевидно запрещённые протоколы и порты следует блокировать раньше.

Логировать каждый отброшенный пакет

Во время DDoS это может самостоятельно вызвать отказ диска, SIEM или сервера журналирования.

Фильтровать только по IP-адресам

Источники могут быть распределёнными или подменёнными. Блокировка отдельных адресов не описывает механизм атаки.

Оценивать только пропускную способность

Короткие пакеты способны перегрузить оборудование по pps при сравнительно небольшом количестве Gbit/s.

Считать checksum errors доказательством атаки

Ошибки могут появляться из-за оборудования, драйверов или особенностей checksum offload. Нужна корреляция с объёмом, источниками и нагрузкой.

Полагаться только на WAF

WAF работает после IP, TCP и TLS. Большинство мусорных пакетов должно блокироваться до прикладного уровня.

Оставлять origin общедоступным

Даже качественная proxy-защита не поможет, если злоумышленник знает настоящий IP и может атаковать его напрямую.

Чек-лист защиты

• Разрешены только необходимые IP-протоколы.
• Открыты только используемые TCP- и UDP-порты.
• Некорректные пакеты отбрасываются до conntrack.
• Контролируются bps и pps.
• Измеряется число уникальных flows.
• Собирается статистика TCP-флагов.
• Контролируются checksum errors.
• Настроены лимиты очередей reassembly.
• Защищён control plane маршрутизаторов.
• Проверена производительность firewall в pps.
• Ограничено журналирование повторяющихся ошибок.
• Обновлены ядро, драйверы и прошивки.
• Подготовлена операторская фильтрация.
• Есть возможность перенаправления в scrubbing center.
• Публичный сайт работает через TrafficVeil.
• Origin закрыт от прямого доступа.
• Старые DNS-записи не раскрывают origin.
• Сохраняется ограниченная выборка атакующего трафика.
• Есть базовый профиль нормального трафика.
• Регламент реагирования протестирован заранее.