Jumbo Frame Flood и Oversized Packet Flood: атаки крупными пакетами

Jumbo Frame Flood — сетевая атака, при которой на коммутатор, маршрутизатор, гипервизор, сервер или другое устройство направляется большое количество Ethernet-кадров увеличенного размера. Цель — занять пропускную способность, увеличить нагрузку на буферы и сетевые интерфейсы, спровоцировать отбрасывание кадров либо использовать различия в поддерживаемом MTU.

Термин нередко применяется слишком широко. В публикациях Jumbo Frame Flood могут называть почти любую атаку крупными пакетами, включая oversized IP packets, фрагментированные дейтаграммы и IPv6 jumbograms. Технически это разные механизмы:

• jumbo frame — увеличенный кадр канального уровня Ethernet;
• oversized IP packet — IP-пакет, размер которого превышает MTU конкретного канала;
• IP fragmentation flood — поток фрагментов, полученных при разделении IP-пакетов;
• IPv6 jumbogram — специальный IPv6-пакет с полезной нагрузкой более 65 535 байт;
• malformed length attack — пакет, в котором значения длины противоречат фактическому содержимому.

Главная особенность Jumbo Frame Flood заключается в ограниченной области действия. Настоящий Ethernet jumbo frame обычно не проходит через весь публичный интернет как один неизменный кадр. На границе каждого L2-сегмента Ethernet-заголовок снимается и формируется заново, а следующий канал может иметь другой MTU. Поэтому классический Jumbo Frame Flood чаще актуален внутри локальной сети, дата-центра, облачной инфраструктуры, виртуального коммутатора или туннеля.

Что такое MTU

MTU, или Maximum Transmission Unit, — максимальный размер блока данных, который конкретный сетевой канал способен передать без разделения на меньшие части.

Значение MTU относится к определённому уровню и интерфейсу. В повседневной практике под Ethernet MTU часто понимают максимальный размер IP-пакета, который помещается в Ethernet-кадр без фрагментации.

Понятие	Что ограничивает	Практическое значение
Ethernet frame size	Размер всего кадра канального уровня	Включает Ethernet-заголовок и служебные поля
Ethernet MTU	Размер передаваемой полезной нагрузки Ethernet	Обычно соответствует максимальному размеру IP-пакета на интерфейсе
Path MTU	Минимальный MTU на всём сетевом пути	Определяет максимальный пакет без фрагментации по данному маршруту
TCP MSS	Максимальный объём TCP-данных в одном сегменте	Обычно рассчитывается с учётом IP- и TCP-заголовков
Tunnel MTU	Размер внутреннего пакета с учётом внешней инкапсуляции	Должен учитывать GRE, IPsec, VXLAN и другие заголовки

Для обычного Ethernet широко используется MTU 1500 байт. Технологии туннелирования добавляют внешние заголовки, поэтому эффективный MTU для внутреннего пакета становится меньше, если физическая сеть не поддерживает кадры большего размера.

RFC 4638 рассматривает передачу IP-пакетов размером 1500 байт через PPPoE и отмечает, что кадры с MTU больше 1500 обычно называют jumbo frames. При этом универсального единого размера jumbo frame для всех Ethernet-реализаций нет.

Что такое Jumbo Frame

Jumbo frame — Ethernet-кадр увеличенного размера по сравнению с обычной конфигурацией MTU 1500. На практике многие серверные и дата-центровые сети используют MTU около 9000 байт, однако конкретный максимум зависит от сетевой карты, коммутатора, прошивки, гипервизора и конфигурации.

Jumbo frames применяются для:

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

Крупный кадр переносит больше данных за одну операцию. Это может снижать относительные накладные расходы и нагрузку на CPU при легитимной передаче больших объёмов. Но преимущество появляется только тогда, когда jumbo frames согласованно поддерживаются всеми участками пути.

Почему jumbo frames не являются обычным интернет-трафиком

Ethernet-кадр существует только в пределах конкретного канального сегмента. Когда IP-пакет проходит через маршрутизатор:

1. маршрутизатор принимает Ethernet-кадр;
2. удаляет его L2-заголовок;
3. обрабатывает IP-пакет;
4. выбирает следующий маршрут;
5. создаёт новый кадр для следующего интерфейса.

Если входящий кадр имел размер около 9000 байт, это не означает, что такой же Ethernet-кадр будет передан через каждый промежуточный операторский сегмент. Следующий интерфейс может поддерживать только MTU 1500.

Поэтому удалённый злоумышленник из интернета обычно не может просто отправить произвольный Ethernet jumbo frame непосредственно сетевой карте веб-сервера. Он может отправить крупный IP-пакет, поток обычных пакетов, фрагменты или данные через туннель, но формат L2-кадра на последнем участке будет определяться сетевой инфраструктурой.

Что такое Jumbo Frame Flood

Jumbo Frame Flood — массовая передача увеличенных Ethernet-кадров внутри сети, где такие кадры поддерживаются или частично принимаются. Атака может быть направлена на:

• физический коммутатор;
• виртуальный коммутатор;
• сетевой интерфейс сервера;
• гипервизор;
• межсетевой экран;
• систему хранения данных;
• туннельный endpoint;
• канал между стойками или дата-центрами.

Эффект зависит не только от размера кадров, но и от их количества, общего объёма, способа обработки и согласованности MTU.

Основные сценарии атаки

1. Объёмный Jumbo Frame Flood

Злоумышленник передаёт максимально крупные кадры с высокой скоростью. Основная цель — быстро занять доступную пропускную способность.

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

2. Flood в сети с частичной поддержкой jumbo frames

Одна часть инфраструктуры настроена на MTU 9000, а другая — на 1500 или меньше. Крупные кадры проходят первый коммутатор, но отбрасываются дальше.

Результатом могут быть:

• input errors;
• giant frame counters;
• packet drops;
• повторные передачи TCP;
• нестабильность туннелей;
• неочевидные «чёрные дыры» для крупных пакетов;
• нагрузка на диагностику и журналирование.

3. Oversized Frame Flood

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

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

4. Oversized IP Packet Flood

Вместо настоящих Ethernet jumbo frames злоумышленник отправляет крупные IP-пакеты. Если размер превышает Path MTU, возможны:

• фрагментация IPv4;
• отбрасывание IPv4-пакета с DF;
• возврат ICMP Fragmentation Needed;
• отбрасывание IPv6-пакета и ICMPv6 Packet Too Big;
• предварительная фрагментация IPv6 отправителем;
• передача через туннель с последующей обработкой на endpoint.

5. Fragmentation-assisted Flood

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

Такой поток способен расходовать:

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

6. Tunnel Jumbo Flood

Крупный внутренний пакет помещается внутрь GRE, IP-in-IP, IPsec, VXLAN или другой инкапсуляции. Внешние заголовки дополнительно увеличивают размер.

Если физическая сеть не рассчитана на такой overhead, возникают:

• фрагментация внешнего пакета;
• отбрасывание на промежуточном интерфейсе;
• снижение эффективного tunnel MTU;
• повторная сборка на tunnel endpoint;
• увеличение нагрузки на декапсуляцию.

7. IPv6 Jumbogram Flood

IPv6 jumbogram — специальный IPv6-пакет с полезной нагрузкой более 65 535 байт. Его длина передаётся через Jumbo Payload option в заголовке Hop-by-Hop Options.

RFC 2675 определяет jumbogram именно как IPv6-пакет с payload больше 65 535 байт.

Такие пакеты предназначены для сетей с очень большим MTU и не являются обычным трафиком публичного сайта. Если инфраструктура не поддерживает jumbograms, их рекомендуется отбрасывать предсказуемо и как можно раньше.

8. Malformed Jumbo Payload Flood

Атакующий может создавать пакеты, в которых заявленная длина, Jumbo Payload option и фактическое содержимое не согласуются. Это уже не просто поток крупных пакетов, а разновидность Garbage Packet Flood.

В корректной реализации такие пакеты должны отклоняться. Основной риск связан с объёмом проверок и возможными ошибками устаревших парсеров.

Jumbo frame и IPv6 jumbogram — не одно и то же

Критерий	Jumbo frame	IPv6 jumbogram
Уровень	Ethernet, L2	IPv6, L3
Область действия	Один канальный сегмент	IP-путь, поддерживающий необходимый MTU
Размер	Зависит от оборудования и конфигурации	Полезная нагрузка больше 65 535 байт
Стандартизированный механизм длины	Нет одного универсального размера для всех реализаций	Jumbo Payload option по RFC 2675
Обычность в публичном интернете	Не передаётся end-to-end как один Ethernet-кадр	Крайне редок и требует соответствующего Path MTU

Как крупные пакеты влияют на инфраструктуру

Переполнение канала

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

Переполнение буферов

Коммутаторы, маршрутизаторы, сетевые карты и гипервизоры используют очереди. Крупные пакеты занимают больше места в буфере, поэтому очередь может вместить меньше пакетов.

При перегрузке возрастает вероятность:

• tail drop;
• роста задержки;
• микровсплесков;
• потерь легитимного трафика;
• повторных передач TCP;
• нестабильной работы приложений реального времени.

Head-of-line blocking

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

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

Нагрузка на фрагментацию и сборку

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

Для IPv6 промежуточные маршрутизаторы не выполняют обычную фрагментацию: отправитель должен учитывать Path MTU, а маршрутизатор сообщает о слишком крупном пакете через ICMPv6 Packet Too Big. IPv6 требует, чтобы каждый канал поддерживал MTU не менее 1280 байт.

Нагрузка на виртуализацию

В облачной среде крупный пакет может пройти через:

• виртуальную сетевую карту;
• виртуальный коммутатор;
• overlay-туннель;
• гипервизор;
• распределённый firewall;
• виртуальный маршрутизатор;
• физический NIC.

Дополнительно используются механизмы offload: TSO, GSO, GRO и LRO. Из-за них пакет, наблюдаемый внутри операционной системы, может выглядеть крупнее реального кадра на проводе. Это важно учитывать при анализе PCAP и метрик.

Почему большой пакет не всегда создаёт большую нагрузку на CPU

При одинаковом объёме данных крупные пакеты обычно означают меньший pps. Сетевому стеку требуется обработать меньше заголовков, прерываний и дескрипторов. Поэтому легитимные jumbo frames часто используются именно для повышения эффективности.

Следовательно, нельзя утверждать, что Jumbo Frame Flood всегда сильнее нагружает CPU, чем поток небольших кадров. Воздействие зависит от механизма:

Характер потока	Основной риск
Крупные корректные кадры с высоким bps	Переполнение канала и буферов
Крупные неподдерживаемые кадры	Ошибки интерфейса и аппаратное отбрасывание
Фрагментированные крупные пакеты	Память и CPU на reassembly
Malformed jumbo packets	Парсеры, исключительные ветви и журналирование
Большое число обычных малых пакетов	Пакетная производительность и pps

Какие устройства могут быть целью

• Top-of-Rack-коммутаторы;
• маршрутизаторы дата-центра;
• межсетевые экраны;
• серверные сетевые карты;
• виртуальные коммутаторы;
• гипервизоры;
• системы хранения данных;
• балансировщики нагрузки;
• VPN-шлюзы;
• GRE- и IP-in-IP endpoints;
• VXLAN VTEP;
• контейнерные overlay-сети;
• IDS и IPS;
• устройства с ошибочно согласованным MTU.

Как распознать Jumbo Frame Flood

Признаки необходимо искать на сетевом оборудовании и интерфейсах, а не только в логах веб-сервера.

Основные индикаторы

• резкий рост входящего bps;
• увеличение среднего размера кадра;
• преобладание пакетов, близких к максимальному MTU;
• рост counters giant, oversized или jabber frames;
• увеличение input errors;
• рост packet drops в очередях;
• частые ICMP Fragmentation Needed;
• рост ICMPv6 Packet Too Big;
• увеличение числа IP-фрагментов;
• ошибки reassembly;
• повторные передачи TCP;
• снижение скорости приложений при нормальном CPU;
• нестабильность только для крупных запросов или файлов;
• различное поведение на разных участках сети;
• рост MTU-related ошибок в туннелях.

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

Метрика	Что показывает
Входящий и исходящий bps	Загрузку пропускной способности
Входящий и исходящий pps	Количество операций пакетной обработки
Распределение размеров кадров	Рост доли крупных кадров
Interface giants	Кадры, превышающие допустимый размер
Input errors	Ошибки при приёме
Queue drops	Переполнение очередей
IP fragments per second	Нагрузку, связанную с фрагментацией
Reassembly failures	Неуспешную сборку исходных пакетов
ICMP PTB сообщения	Несоответствие размера Path MTU
TCP retransmissions	Потери крупных пакетов и деградацию соединений
CPU и buffer utilization	Фактическую точку истощения ресурсов

Как отличить атаку от ошибки MTU

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

Признак	Ошибка MTU	Jumbo Frame Flood
Время возникновения	После изменения сети или туннеля	Может начаться резко без изменений
Объём трафика	Обычно соответствует обычной нагрузке	Наблюдается аномальный рост bps
Источники	Легитимные узлы	Посторонние или скомпрометированные узлы
Размеры	Проблема возникает выше конкретного порога	Может преобладать максимальный размер
Packet drops	На определённом участке пути	На нескольких перегруженных компонентах
Продолжительность	Сохраняется до исправления конфигурации	Меняется вместе с активностью атакующего

Как Path MTU влияет на атаку

Path MTU — минимальный MTU среди всех участков между отправителем и получателем. Даже если обе конечные системы поддерживают MTU 9000, один промежуточный участок с MTU 1500 ограничивает размер пакета без фрагментации.

Для определения ограничения используются механизмы Path MTU Discovery. Они зависят от доставки ICMP или ICMPv6 сообщений. Если такие сообщения полностью заблокированы, возникает PMTUD black hole: отправитель продолжает передавать слишком крупные пакеты, которые не доходят до получателя.

Поэтому рекомендация «заблокировать весь ICMP» вредна. Фильтровать необходимо нежелательные типы и аномальную скорость, сохраняя сообщения, необходимые для работы Path MTU Discovery.

Jumbo Frame Flood и фрагментация

Фрагментация не является обязательной частью Jumbo Frame Flood. Если весь L2-путь поддерживает размер кадра, он передаётся без фрагментации. Если крупный IP-пакет сталкивается с меньшим MTU, дальнейшее поведение зависит от версии IP и настроек.

IPv4

• маршрутизатор может фрагментировать пакет, если флаг DF не установлен;
• при установленном DF пакет отбрасывается;
• отправителю возвращается ICMP Fragmentation Needed;
• получатель собирает фрагменты.

IPv6

• промежуточный маршрутизатор не фрагментирует пакет обычным способом;
• слишком крупный пакет отбрасывается;
• отправителю возвращается ICMPv6 Packet Too Big;
• при необходимости фрагментацию выполняет отправитель;
• получатель выполняет reassembly.

Современные рекомендации рассматривают IP-фрагментацию как хрупкий механизм и советуют по возможности предотвращать её с помощью корректного packetization и Path MTU Discovery.

Как защититься от Jumbo Frame Flood

1. Определить, где jumbo frames действительно нужны

Использование большого MTU должно быть осознанным. Для каждого сегмента необходимо определить:

• рабочее значение MTU;
• поддерживаемый максимум оборудования;
• назначение jumbo frames;
• список разрешённых VLAN;
• допустимые источники и получатели;
• параметры туннельной инкапсуляции;
• требования систем хранения и виртуализации.

Если jumbo frames не нужны, интерфейсы не следует без причины настраивать на увеличенный MTU.

2. Согласовать MTU по всему пути

На одном пути должны быть согласованы:

• серверные NIC;
• виртуальные интерфейсы;
• виртуальные коммутаторы;
• физические коммутаторы;
• маршрутизаторы;
• firewall;
• туннельные endpoints;
• overlay-сети;
• системы хранения.

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

3. Отбрасывать oversized frames аппаратно

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

• где выполняется проверка размера;
• нагружает ли она control plane;
• создаёт ли каждое событие запись в журнале;
• можно ли настроить допустимый максимум по интерфейсам;
• доступны ли аппаратные policer и storm control.

4. Ограничить крупный трафик на недоверенных портах

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

5. Использовать QoS и управление очередями

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

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

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

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

7. Ограничить сборку фрагментов

Следует установить безопасные лимиты:

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

8. Сохранять необходимый ICMP и ICMPv6

Нельзя бездумно блокировать сообщения Packet Too Big и Fragmentation Needed. Они необходимы для определения Path MTU. Допустимо ограничивать их скорость и проверять соответствие существующему трафику.

9. Отключить избыточное журналирование

Во время Flood миллионы записей о giant frames способны перегрузить систему мониторинга. Лучше использовать:

• счётчики интерфейсов;
• агрегацию событий;
• rate limit журналирования;
• sampling;
• алерты по превышению порога.

10. Изолировать storage и management networks

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

11. Использовать upstream-защиту для IP Flood

Оператор связи не сможет доставить Ethernet jumbo frame через весь интернет в исходном виде, но может поступать крупный объём IP-пакетов, фрагментов или туннельного трафика. Если он заполняет внешний канал, фильтрация должна выполняться до инфраструктуры клиента.

Защита от IPv6 Jumbogram Flood

Если jumbograms не используются, устройства могут отклонять Jumbo Payload option в соответствии с политикой безопасности. При этом необходимо учитывать, что Hop-by-Hop Options обрабатываются особым образом и не все маршрутизаторы анализируют их содержимое.

Рекомендуемые меры:

• разрешать IPv6 Jumbo Payload только в специально предназначенных сегментах;
• проверять согласованность заявленной и фактической длины;
• отбрасывать недопустимые комбинации заголовков;
• ограничивать Hop-by-Hop Options на внешнем периметре;
• обновлять IPv6-парсеры и прошивки;
• не передавать необычные пакеты в control plane без лимитов;
• отдельно контролировать IPv6-трафик, а не полагаться на правила IPv4.

Рекомендации по фильтрации IPv6 отмечают, что специфический риск Jumbo Payload option связан прежде всего с неправильной проверкой опции и связанных с ней значений длины.

Почему WAF не останавливает Jumbo Frame Flood

WAF работает на уровне HTTP. До передачи запроса в WAF пакет должен пройти:

1. физический интерфейс;
2. Ethernet-обработку;
3. IP-обработку;
4. фрагментацию или reassembly;
5. TCP;
6. TLS при HTTPS;
7. формирование HTTP-запроса.

Jumbo Frame Flood воздействует на первые уровни этой цепочки. Пакет может быть отброшен интерфейсом или маршрутизатором задолго до появления HTTP. Поэтому WAF не является основным средством защиты от атак крупными L2/L3-пакетами.

Какую роль играет TrafficVeil

TrafficVeil защищает веб-сайты на уровне reverse proxy, WAF, анализа ботов и L7 DDoS-фильтрации. Посетитель устанавливает соединение с защищённым прокси-контуром, а origin получает отдельное разрешённое соединение.

Такая архитектура помогает, если:

• публичный DNS направлен на TrafficVeil;
• настоящий IP origin не опубликован;
• origin принимает HTTP/HTTPS только от разрешённых адресов TrafficVeil;
• старые DNS-записи и сторонние сервисы не раскрывают origin;
• веб-сервер не доступен напрямую по альтернативному адресу.

Но TrafficVeil как HTTP/HTTPS reverse proxy не заменяет защиту локальной сети от Ethernet jumbo frames. Он также не может самостоятельно устранить атаку, направленную на физический канал дата-центра, storage VLAN, гипервизор или внешний адрес origin.

Для полной защиты необходимы разные уровни:

Уровень	Задача
Коммутатор и NIC	Контроль размера кадров и аппаратное отбрасывание oversized frames
Маршрутизатор и firewall	Фильтрация IP-пакетов, фрагментов и необычных IPv6-опций
Оператор или scrubbing center	Удаление объёмного трафика до внешнего канала
TrafficVeil	Защита HTTP/HTTPS, WAF, L7 DDoS и фильтрация ботов
Origin-сервер	Приём веб-трафика только из защищённого контура

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

1. Определить уровень. Установить, наблюдаются Ethernet jumbo frames, крупные IP-пакеты, фрагменты или IPv6 jumbograms.
2. Проверить интерфейсные счётчики. Найти giants, oversized, jabber, input errors и queue drops.
3. Измерить bps и pps. Определить, является ли атака объёмной или пакетной.
4. Построить распределение размеров. Установить, какой размер преобладает.
5. Проверить MTU по пути. Сравнить сервер, VLAN, коммутаторы, туннели и внешние интерфейсы.
6. Определить источники. Понять, находится ли генератор внутри L2-сегмента или трафик поступает через маршрутизатор.
7. Изолировать внутренний порт. Если источник находится в локальной сети, ограничить или отключить конкретный интерфейс.
8. Отбросить oversized frames. Настроить аппаратную фильтрацию на ближайшем входном устройстве.
9. Ограничить фрагменты. Снизить нагрузку на reassembly без нарушения необходимого трафика.
10. Защитить control plane. Не допустить передачи всего аномального потока центральному процессору.
11. Обратиться к оператору. Если IP-поток заполняет внешний канал, перенести фильтрацию upstream.
12. Проверить origin. Закрыть прямой веб-доступ в обход TrafficVeil.

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

• время начала и завершения;
• затронутые VLAN и интерфейсы;
• источник трафика;
• пиковые bps и pps;
• распределение размеров кадров;
• рабочий MTU каждого участка;
• giant и oversized counters;
• input errors и queue drops;
• число IP-фрагментов;
• ошибки reassembly;
• ICMP Fragmentation Needed;
• ICMPv6 Packet Too Big;
• TCP retransmissions;
• загрузку CPU и память устройств;
• конфигурацию туннелей;
• ограниченный PCAP или packet sample;
• применённые защитные правила;
• влияние на сайт и внутренние сервисы.

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

Считать любой большой IP-пакет jumbo frame

Jumbo frame относится к Ethernet, а большой IP-пакет — к сетевому уровню. Они связаны, но не идентичны.

Считать Jumbo Frame Flood типичной удалённой атакой на сайт

Настоящие Ethernet jumbo frames действуют в конкретном L2-сегменте. Через публичный интернет чаще поступает объёмный IP-трафик или фрагменты.

Устанавливать MTU 9000 только на серверах

Увеличенный MTU должен поддерживаться всем путём. Иначе возникают потери и скрытые black holes.

Блокировать весь ICMP

Это нарушает Path MTU Discovery и может сделать крупные пакеты недоставляемыми даже без атаки.

Считать крупные пакеты всегда более тяжёлыми для CPU

При одинаковом объёме крупные пакеты обычно дают меньший pps, поэтому основным риском может быть канал, а не CPU.

Игнорировать offload

TSO, GSO, GRO и LRO способны изменить видимый размер пакетов в локальном захвате, из-за чего анализатор может показывать не фактические кадры на проводе.

Логировать каждый oversized frame

При Flood это перегружает систему журналирования, не добавляя полезной информации.

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

WAF получает трафик после Ethernet, IP, TCP и TLS и не предназначен для фильтрации L2-кадров.

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

• Документирован MTU каждого сетевого сегмента.
• Известен максимальный размер кадра каждого устройства.
• Jumbo frames включены только там, где они необходимы.
• MTU согласован на всём пути.
• Учтены заголовки туннелей и overlay-сетей.
• На недоверенных портах ограничены oversized frames.
• Аппаратное отбрасывание выполняется до control plane.
• Собираются counters giants и input errors.
• Контролируются bps, pps и размеры кадров.
• Настроены лимиты reassembly.
• Сохраняются необходимые ICMP и ICMPv6 сообщения.
• Ограничено журналирование повторяющихся ошибок.
• Storage VLAN изолирована от публичных сетей.
• Проверены настройки гипервизоров и виртуальных коммутаторов.
• Обновлены драйверы, прошивки и сетевой стек.
• Подготовлена upstream-фильтрация IP Flood.
• Публичный сайт работает через TrafficVeil.
• Origin закрыт от прямого доступа.
• Регламент реагирования протестирован.