IGMP Flood: атака на multicast-сети и способы защиты

IGMP Flood — это атака или аномальная активность, при которой сеть получает большое количество сообщений Internet Group Management Protocol. Поток может перегрузить маршрутизатор, коммутатор, управляющую плоскость сетевого оборудования или таблицы multicast-состояний. В результате нарушается доставка группового трафика, растёт нагрузка на инфраструктуру, а в отдельных случаях ухудшается работа всей локальной сети.

В отличие от HTTP Flood, IGMP Flood не направлен на страницы сайта, API или форму авторизации. Атака происходит на сетевом уровне и обычно затрагивает инфраструктуру, где используется IPv4 multicast: корпоративные сети, IPTV, системы видеонаблюдения, трансляции, финансовые потоки данных, промышленное оборудование, голосовые сервисы и другие приложения «один ко многим».

IGMP-трафик обычно имеет локальную область действия и не маршрутизируется через интернет так же свободно, как обычный TCP или UDP. Поэтому классический IGMP Flood чаще возникает внутри сетевого сегмента, через скомпрометированное устройство, ошибочно подключённый узел, уязвимый туннель, виртуальную сеть или неправильно настроенную границу multicast-домена.

При этом последствия могут затронуть и веб-сервисы. Если сайт, API, DNS, VPN и multicast-инфраструктура используют общий маршрутизатор, firewall, коммутатор или канал, перегрузка сетевого оборудования способна ухудшить доступность всех сервисов.

Что такое multicast

Multicast — способ передачи данных группе получателей. Отправитель передаёт один поток на специальный групповой IP-адрес, а сеть доставляет его только тем сегментам и устройствам, которые сообщили о желании получать соответствующий трафик.

RFC 1112 определяет IP multicast как передачу IP-датаграммы группе узлов, идентифицируемой единым групповым адресом. Датаграмма доставляется участникам группы по модели best effort.

Multicast занимает промежуточное положение между unicast и broadcast.

Режим	Получатели	Принцип доставки
Unicast	Один конкретный узел	Один отправитель — один получатель
Broadcast	Все устройства сегмента	Один отправитель — все узлы
Multicast	Участники определённой группы	Один отправитель — выбранная группа

Главное преимущество multicast — экономия ресурсов. Если тысяче пользователей необходимо передать одинаковый видеопоток, серверу не нужно создавать тысячу независимых копий. Он отправляет один multicast-поток, а сеть размножает данные там, где это необходимо.

Что такое IGMP

IGMP расшифровывается как Internet Group Management Protocol. Он используется в IPv4-сетях, чтобы хосты сообщали соседним multicast-маршрутизаторам о членстве в multicast-группах.

RFC 2236 описывает назначение IGMP так: IPv4-хосты используют протокол, чтобы сообщать непосредственно соседним multicast-маршрутизаторам о своём участии в группах.

IGMP не переносит сам видеопоток, аудио или другие прикладные данные. Его задача — управление членством.

Упрощённо протокол помогает ответить на вопросы:

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

Как работает IGMP

Допустим, в сети транслируется видеопоток на multicast-адрес. Пользователь запускает приложение и выбирает канал.

Упрощённая последовательность выглядит так:

1. приложение присоединяется к multicast-группе;
2. операционная система отправляет IGMP Membership Report;
3. маршрутизатор узнаёт, что в сегменте появился заинтересованный получатель;
4. multicast-поток начинает передаваться в этот сегмент;
5. коммутатор с IGMP Snooping направляет трафик только на нужные порты;
6. после выхода из группы информация о членстве обновляется;
7. если получателей больше нет, передача потока в сегмент прекращается.

Для проверки наличия участников маршрутизатор периодически отправляет Membership Query. Хосты отвечают Membership Report. В IGMPv2 также используется Leave Group, позволяющее быстрее сообщить о выходе из группы.

Версии IGMP

IGMPv1

Первая широко применявшаяся версия определена RFC 1112. Она поддерживает базовые механизмы запроса и отчёта о членстве.

IGMPv1 не содержит отдельного сообщения Leave Group. Маршрутизатор определяет отсутствие получателей после истечения тайм-аутов и отсутствия отчётов.

IGMPv2

IGMPv2 описан RFC 2236. Он добавил механизмы, позволяющие быстрее определять выход последнего участника из группы.

К основным сообщениям относятся:

• Membership Query;
• Version 2 Membership Report;
• Leave Group;
• совместимые сообщения предыдущей версии.

IGMPv3

IGMPv3 добавляет source filtering — возможность сообщить, что узел хочет получать multicast-трафик только от определённых источников либо от всех, кроме указанных. Эта модель используется для Source-Specific Multicast и более точного управления потоками.

RFC 9776 представляет пересмотренную спецификацию IGMPv3, уточняет прежний RFC 3376 и сохраняет обратную совместимость.

IGMPv3 Membership Report может содержать записи о нескольких группах и списки источников. Это увеличивает функциональность, но также создаёт больше структур, которые оборудование должно разобрать, проверить и сохранить.

Основные типы IGMP-сообщений

Сообщение	Назначение	Как может использоваться при атаке
General Membership Query	Запрос информации обо всех группах	Создание массовых ответов и нагрузки на хосты
Group-Specific Query	Проверка участников конкретной группы	Частые запросы к большому числу групп
Group-and-Source-Specific Query	Проверка группы и источников	Увеличение сложности обработки
Membership Report	Сообщение о членстве в группах	Создание множества ложных состояний
Leave Group	Выход из multicast-группы	Частое изменение состояния и перестроение пересылки

Что такое IGMP Flood

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

Целью атаки могут быть:

• multicast-маршрутизатор;
• коммутатор с IGMP Snooping;
• IGMP Querier;
• multicast proxy;
• firewall;
• виртуальный коммутатор;
• сетевой контроллер;
• таблицы членства;
• управляющая плоскость оборудования;
• пропускная способность локального сегмента.

В отличие от UDP Flood, основной ущерб может быть связан не с объёмом полезной нагрузки, а с количеством управляющих сообщений и изменением состояний. Один небольшой IGMP Report способен заставить оборудование создать или обновить запись о multicast-группе.

Почему IGMP Flood опасен

IGMP — протокол управления состоянием multicast. Маршрутизатору и коммутатору приходится помнить:

• какие группы существуют;
• на каких интерфейсах есть участники;
• какие источники разрешены или исключены;
• когда истекают тайм-ауты;
• какая версия IGMP используется;
• какой узел выполняет роль Querier;
• куда необходимо направлять multicast-поток.

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

Возможны три основных эффекта:

1. Перегрузка control plane. Процессор оборудования тратит ресурсы на разбор IGMP и обновление состояний.
2. Истощение таблиц. Ложные группы, источники и порты занимают ограниченную память.
3. Избыточная передача multicast. Ошибочные состояния заставляют сеть отправлять потоки туда, где настоящих получателей нет.

Основные разновидности IGMP Flood

IGMP Membership Report Flood

Устройство отправляет большое количество сообщений о присоединении к multicast-группам.

Варианты:

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

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

IGMP Query Flood

В сеть отправляется большое количество Membership Query. Хосты воспринимают их как запросы маршрутизатора и готовят ответы.

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

Последствия:

• рост IGMP-ответов;
• нагрузка на конечные устройства;
• нагрузка на Wi-Fi и слабые сегменты;
• частые обновления таймеров;
• дополнительная обработка на коммутаторах;
• заполнение журналов и систем мониторинга.

Group-Specific Query Flood

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

Такой поток заставляет сеть выполнять операции проверки и обновления членства значительно чаще нормального.

Group-and-Source-Specific Query Flood

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

Большое количество запросов с многочисленными источниками повышает стоимость разбора и проверки. Оборудование должно сопоставлять пары «группа — источник» и управлять более сложным состоянием.

IGMP Leave Flood

Атакующий отправляет поток Leave Group, имитируя массовый выход из multicast-групп.

В зависимости от версии и настройки сеть может:

• запускать дополнительные проверки участников;
• отправлять Group-Specific Query;
• обновлять таймеры;
• удалять и повторно создавать записи;
• прерывать доставку потока при ошибочном определении отсутствия получателей.

Join/Leave Flapping

Узел быстро присоединяется к группе и покидает её. Такое чередование заставляет инфраструктуру постоянно менять состояние.

Flapping может быть атакой, ошибкой приложения, неисправностью клиента или нестабильностью сети. В любом случае он требует расследования.

Multicast Group Exhaustion

Создаётся большое количество подписок на разные multicast-адреса. Цель — заполнить таблицы IGMP Snooping, multicast forwarding или аппаратную память коммутатора.

После исчерпания ресурсов возможны:

• отказ в создании новых записей;
• удаление старых состояний;
• переход к менее эффективной обработке;
• передача multicast на лишние порты;
• перегрузка CPU;
• сбой легитимных трансляций.

IGMPv3 Source List Exhaustion

Атакующий использует большое число записей INCLUDE или EXCLUDE и длинные списки источников. Вместо одной записи для группы оборудование вынуждено учитывать множество комбинаций «источник — группа — интерфейс».

Даже при небольшом объёме трафика число логических состояний может стать критическим.

Spoofed IGMP Flood

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

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

Может ли IGMP Flood быть объёмной DDoS-атакой

IGMP Flood часто включают в список объёмных атак, но это не всегда точно. Возможны два сценария.

Объёмный IGMP Flood

Отправляется настолько много пакетов, что заполняется канал или достигается предел PPS оборудования. В этом случае атака действительно похожа на ICMP или UDP Flood.

Атака на состояния и управляющую плоскость

Объём трафика остаётся относительно небольшим, но каждый пакет вызывает изменение таблиц, таймеров или маршрутов multicast. Узким местом становится CPU или память control plane.

Для диагностики важно смотреть не только BPS и PPS, но и:

• число групп;
• число источников;
• число IGMP-состояний;
• частоту Join и Leave;
• нагрузку control plane;
• заполнение аппаратных таблиц;
• изменение multicast forwarding.

IGMP Flood и Multicast Flood — не одно и то же

IGMP Flood состоит преимущественно из управляющих сообщений о членстве в группах.

Multicast Flood может означать массовую передачу самого multicast-контента: видео, аудио или произвольных IP-датаграмм на групповые адреса.

Параметр	IGMP Flood	Multicast Data Flood
Основной трафик	Управляющие сообщения IGMP	Прикладные multicast-данные
Главная цель	Состояния и control plane	Канал и порты получателей
Типичный размер пакета	Небольшой	Зависит от приложения
Ключевая метрика	Сообщения, группы и изменения состояний	BPS и PPS multicast-трафика
Защита	Контроль IGMP и членства	Ограничение multicast forwarding и полосы

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

Что такое IGMP Snooping

IGMP Snooping — функция коммутатора, при которой он анализирует IGMP-сообщения и определяет, на каких портах находятся участники multicast-группы.

Без Snooping коммутатор может передавать multicast-трафик на множество портов аналогично broadcast. С включённым Snooping поток направляется только туда, где есть получатели.

RFC 4541 содержит рекомендации для коммутаторов, реализующих IGMP и MLD Snooping.

При IGMP Flood таблица Snooping становится одной из целей. Атакующий может создавать множество ложных подписок и заставлять коммутатор:

• часто изменять записи;
• добавлять новые группы;
• перенаправлять multicast на дополнительные порты;
• использовать CPU при исчерпании аппаратных ресурсов;
• переходить к flooding неизвестного multicast.

Что такое IGMP Querier

Querier — устройство, отправляющее IGMP Query и контролирующее наличие участников multicast-групп в сегменте.

В сети с несколькими потенциальными Querier выполняется выбор активного устройства. Ошибочные или поддельные сообщения способны влиять на этот процесс.

Если атакующий имитирует Querier или создаёт нестабильность выбора, возможны:

• слишком частые Query;
• конфликт таймеров;
• изменение источника управляющих сообщений;
• неправильное истечение членства;
• нестабильная доставка multicast.

Где встречается IGMP Flood

Наибольший риск возникает в инфраструктуре, активно использующей IPv4 multicast:

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

Обычный публичный веб-сайт, не использующий multicast, редко становится прямой целью IGMP Flood. Но атака может затронуть общую сетевую инфраструктуру хостинга или локального дата-центра.

Может ли IGMP Flood прийти из интернета

IGMP предназначен для взаимодействия между IPv4-хостами и непосредственно соседними multicast-маршрутизаторами. Его сообщения обычно имеют ограниченную сетевую область действия и не должны произвольно маршрутизироваться через интернет.

Поэтому прямой глобальный IGMP Flood из тысяч удалённых сетей менее типичен, чем UDP Flood или ICMP Flood.

Удалённое воздействие всё же возможно через:

• неправильно настроенные туннели;
• VPN и overlay-сети;
• виртуальные L2-сегменты;
• скомпрометированный узел внутри периметра;
• уязвимый сетевой шлюз;
• ошибочную маршрутизацию;
• облачные виртуальные сети;
• доступ к управляющему сегменту;
• вредоносного клиента провайдерской multicast-сети.

При расследовании важно искать не только внешний IP, но и точку, через которую трафик попал в локальный multicast-домен.

Как выглядит IGMP Flood в трафике

Общие признаки

• резкий рост количества IGMP-пакетов;
• большое число Membership Report;
• частые Membership Query;
• постоянное чередование Join и Leave;
• рост числа уникальных multicast-групп;
• необычно длинные source lists в IGMPv3;
• IGMP от портов, где не должно быть multicast-клиентов;
• частая смена Querier;
• увеличение control-plane CPU;
• заполнение таблиц IGMP Snooping;
• передача multicast на неожиданные порты;
• рост unknown multicast flooding.

Признаки на маршрутизаторе

• рост CPU управляющей плоскости;
• частые изменения multicast routing state;
• большое число групп и источников;
• ускоренное истечение и создание состояний;
• увеличение IGMP input rate;
• ошибки обработки IGMP;
• потери управляющих пакетов;
• нестабильность Querier.

Признаки на коммутаторе

• рост IGMP Snooping entries;
• частые изменения портов членства;
• заполнение аппаратных таблиц;
• повышение CPU;
• multicast-трафик на ненужных портах;
• переход к обработке через software path;
• замедление управления устройством;
• потери легитимного multicast.

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

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

Какие метрики контролировать

Метрика	Что показывает
IGMP packets per second	Общую интенсивность управляющего трафика
Queries per second	Аномальную активность Querier
Reports per second	Интенсивность подписок и обновлений
Leaves per second	Частоту выхода из групп
Join/Leave ratio	Flapping и нестабильное членство
Unique multicast groups	Попытку исчерпания таблиц
Unique source records	Нагрузку IGMPv3 source filtering
Snooping table utilization	Заполнение аппаратных таблиц
Control-plane CPU	Нагрузку на процессор оборудования
Unknown multicast rate	Поток для групп без известного состояния
Multicast BPS/PPS	Нагрузку от самого группового контента
Querier changes	Нестабильность или подмену Querier

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

Аномальный IGMP-трафик не всегда является злонамеренной атакой. Его могут вызвать:

• ошибка multicast-приложения;
• неисправная IPTV-приставка;
• цикл в сети;
• некорректный IGMP proxy;
• ошибка виртуального коммутатора;
• неверные таймеры;
• конфликт версий IGMP;
• нестабильный беспроводной клиент;
• ошибка после обновления сетевого оборудования;
• неправильная работа Snooping Querier;
• массовое включение устройств после сбоя питания.

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

Последствия IGMP Flood

• перегрузка CPU маршрутизатора;
• заполнение IGMP Snooping table;
• исчерпание multicast forwarding state;
• недоступность легитимных групп;
• потеря IPTV и видеотрансляций;
• перенаправление multicast на лишние порты;
• рост нагрузки на конечные устройства;
• деградация локальной сети;
• потеря управляющих пакетов;
• нестабильность Querier;
• рост объёма unknown multicast;
• нарушение работы соседних сервисов;
• перезагрузка или зависание оборудования;
• нарушение SLA.

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

1. Ограничить IGMP доверенными сегментами

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

2. Настроить IGMP Snooping

Корректный Snooping уменьшает ненужное распространение multicast. Однако необходимо также установить лимиты, чтобы атакующий не заполнил таблицу множеством ложных групп.

Следует контролировать:

• максимальное число групп на порт;
• максимальное число source records;
• доверенные router ports;
• поведение при переполнении таблицы;
• обработку unknown multicast;
• совместимость IGMPv2 и IGMPv3.

3. Защитить роль Querier

Query должны поступать от ожидаемого маршрутизатора или специально назначенного Snooping Querier. Необходимо отслеживать появление нового Querier и блокировать недоверенные источники управляющих сообщений.

4. Ограничить частоту IGMP

Rate Limiting может применяться:

• на физический порт;
• на VLAN;
• на source IP;
• по типу IGMP-сообщения;
• на количество групп;
• на количество записей источников;
• на частоту Join/Leave;
• на общий control-plane PPS.

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

5. Использовать Control Plane Policing

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

При настройке важно оставить достаточный ресурс для:

• легитимного IGMP;
• протоколов маршрутизации;
• ARP и Neighbor Discovery;
• управления устройством;
• критически важных ICMP-сообщений.

6. Ограничить количество групп на порт

Пользовательскому порту редко требуется членство в тысячах multicast-групп. Per-port limit уменьшает ущерб от скомпрометированного устройства.

После достижения лимита оборудование может:

• отклонить новую подписку;
• создать событие безопасности;
• ограничить порт;
• перевести его в карантинную VLAN;
• уведомить систему мониторинга.

7. Применять Port Security и контроль доступа

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

Полезны:

• 802.1X;
• Network Access Control;
• Port Security;
• привязка устройств;
• изоляция клиентов;
• сегментация VLAN;
• контроль виртуальных машин;
• мониторинг новых MAC-адресов.

8. Фильтровать недопустимые multicast-группы

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

9. Контролировать IGMPv3 source lists

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

10. Сегментировать multicast-инфраструктуру

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

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

Почему простая блокировка IGMP не всегда подходит

Если сеть не использует multicast, IGMP можно ограничить на соответствующем периметре. Но в IPTV, видеонаблюдении и корпоративных трансляциях полная блокировка разрушит механизм членства.

Возможные последствия полного запрета:

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

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

Поможет ли WAF или reverse proxy

Обычный WAF анализирует HTTP и HTTPS. IGMP не является веб-протоколом и не содержит URL, заголовков браузера, cookies или тела HTTP-запроса.

Поэтому WAF не способен самостоятельно остановить IGMP Flood. Атака должна блокироваться:

• на коммутаторе;
• на маршрутизаторе;
• в виртуальной сети;
• на firewall с поддержкой IGMP;
• на уровне управляющей плоскости;
• на границе multicast-домена.

Reverse proxy также обычно не участвует в IGMP. Он защищает веб-трафик, а IGMP обслуживается сетевой инфраструктурой.

Как IGMP Flood связан с TrafficVeil

TrafficVeil принимает и фильтрует HTTP/HTTPS-запросы к подключённым сайтам. IGMP Flood находится ниже прикладного веб-уровня и обычно направлен на сетевое оборудование, а не на веб-приложение.

TrafficVeil может косвенно снизить риск для origin, если:

• настоящий IP веб-сервера скрыт;
• origin принимает HTTP/HTTPS только от адресов reverse proxy;
• публичная инфраструктура отделена от внутренней multicast-сети;
• DNS и вспомогательные сервисы защищены отдельно.

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

Что делать во время IGMP Flood

1. Определить точку входа. Найти физический порт, VLAN, туннель или виртуальную сеть.
2. Определить тип сообщений. Query, Report, Leave или IGMPv3 source records.
3. Проверить Querier. Убедиться, что управляющие запросы отправляет доверенное устройство.
4. Оценить число групп. Найти резкий рост или перебор адресов.
5. Проверить Join/Leave. Выявить flapping.
6. Измерить control-plane CPU. Определить реальное узкое место.
7. Проверить Snooping table. Оценить заполнение и поведение при исчерпании.
8. Ограничить атакующий порт. Применить Rate Limiting или временную изоляцию.
9. Сохранить данные. Зафиксировать PCAP, счётчики и таблицы до их очистки.
10. Проверить оборудование. Исключить ошибку прошивки, приложения или конфигурации.

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

• время начала и окончания;
• физический или виртуальный интерфейс;
• VLAN;
• source MAC и source IP;
• версию IGMP;
• типы сообщений;
• количество Query, Report и Leave;
• список multicast-групп;
• списки источников IGMPv3;
• частоту Join/Leave;
• изменения Querier;
• заполнение Snooping table;
• нагрузку control plane;
• объём multicast-трафика;
• применённые правила;
• небольшой репрезентативный PCAP.

Типичные ошибки защиты

• Считать IGMP обычным UDP. IGMP является отдельным IP-протоколом и требует собственной политики.
• Следить только за BPS. Небольшие управляющие пакеты могут перегрузить состояния и CPU.
• Разрешать IGMP на всех портах. Это увеличивает поверхность атаки.
• Не ограничивать число групп. Один клиент может заполнить таблицу.
• Не защищать Querier. Поддельные Query создают нестабильность.
• Включить Snooping без контроля ресурсов. Таблица остаётся уязвимой для exhaustion.
• Полностью блокировать IGMP в multicast-сети. Легитимные потоки перестают работать.
• Игнорировать виртуальные сети. Источник может находиться внутри overlay или гипервизора.
• Не анализировать исходящий multicast. Ложные подписки способны размножить поток.
• Полагаться на WAF. IGMP не относится к HTTP.

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

• IGMP разрешён только в необходимых сегментах;
• определён доверенный Querier;
• недоверенные Query блокируются;
• включён и проверен IGMP Snooping;
• установлен лимит групп на порт;
• ограничено число IGMPv3 source records;
• контролируется частота Join и Leave;
• настроен Rate Limiting IGMP;
• настроен Control Plane Policing;
• проверено поведение при переполнении таблиц;
• unknown multicast не распространяется бесконтрольно;
• пользовательские порты защищены через NAC или Port Security;
• multicast-приложения разделены по VLAN;
• контролируются туннели и виртуальные сети;
• собираются метрики групп, источников и состояний;
• подготовлен порядок изоляции атакующего порта.