IPv6 Flood и IPv6 Neighbor Discovery Flood: атаки на IPv6-инфраструктуру

IPv6 Flood — общее название DDoS-атак, использующих IPv6-трафик для перегрузки интернет-канала, маршрутизатора, межсетевого экрана, балансировщика, сервера или приложения. Вредоносный поток может состоять из TCP, UDP, ICMPv6, фрагментов, пакетов с extension headers либо комбинации нескольких протоколов.

IPv6 Neighbor Discovery Flood — более узкая категория атак на протокол обнаружения соседей NDP. Такие атаки направлены на Neighbor Cache, обработку Neighbor Solicitation и Neighbor Advertisement, механизмы Router Solicitation и Router Advertisement либо на проверку доступности IPv6-адресов.

Объединять эти понятия полностью нельзя. Обычный IPv6 Flood может поступать из интернета и быть направлен на публичный веб-сервер. Большинство сообщений Neighbor Discovery имеет локальную область действия и не маршрутизируется через интернет. Следовательно, классический NDP Flood обычно создаётся устройством в том же канальном сегменте, скомпрометированной виртуальной машиной, арендатором общей сети либо возникает на маршрутизаторе при массовом обращении к несуществующим адресам подключённого IPv6-префикса.

Почему IPv6 требует отдельной модели защиты

IPv6 — не просто IPv4 с более длинными адресами. Протокол отличается структурой заголовков, обработкой фрагментации, использованием ICMPv6, механизмами автоконфигурации и обнаружения соседей.

Особенности, имеющие значение для DDoS-защиты:

• 128-битное адресное пространство;
• extension headers между основным IPv6-заголовком и транспортным протоколом;
• отсутствие обычной фрагментации на промежуточных маршрутизаторах;
• критическая роль ICMPv6;
• использование Neighbor Discovery вместо ARP;
• автоматическая настройка адресов через Router Advertisement;
• одновременная работа IPv4 и IPv6 в dual-stack-сетях;
• отдельные таблицы firewall и маршрутизации;
• возможность наличия нескольких IPv6-адресов у одного интерфейса.

Распространённая ошибка — тщательно защитить IPv4, но оставить IPv6 с базовыми или разрешающими правилами. В этом случае атакующий выбирает менее контролируемый протокол.

Рекомендации по эксплуатации IPv6 прямо указывают, что политика безопасности должна охватывать обе части dual-stack-инфраструктуры, включая host firewalls.

Что такое IPv6 Flood

IPv6 Flood — массовая отправка IPv6-пакетов к одному или нескольким адресам. Цель определяется структурой потока:

• переполнение пропускной способности;
• превышение пакетной производительности;
• перегрузка IPv6 firewall;
• исчерпание таблиц соединений;
• нагрузка на обработку extension headers;
• переполнение очередей фрагментов;
• истощение Neighbor Cache;
• перегрузка control plane маршрутизатора;
• атака на публичное приложение по IPv6;
• обход правил, настроенных только для IPv4.

Основные виды IPv6 Flood

Вид атаки	Механизм	Основная цель
IPv6 UDP Flood	Большое количество UDP-дейтаграмм	Канал, pps, приложение
IPv6 TCP Flood	SYN, ACK, RST, FIN или другие TCP-сегменты	Conntrack, firewall, TCP stack
ICMPv6 Flood	Массовые ICMPv6-сообщения	Канал, CPU, control plane
IPv6 Fragment Flood	Большое количество фрагментов	Память и reassembly queues
Extension Header Flood	Пакеты с цепочками дополнительных заголовков	Парсер, firewall, маршрутизатор
Random IPv6 Address Flood	Поток на множество адресов одного префикса	Neighbor Cache и адресное разрешение
NDP Flood	NS, NA, RS или RA в локальном сегменте	NDP, Neighbor Cache, хосты и маршрутизаторы
IPv6 HTTP Flood	Валидные HTTP/HTTPS-запросы по IPv6	Reverse proxy и приложение

IPv6 UDP Flood

IPv6 UDP Flood по механике похож на IPv4 UDP Flood: злоумышленник направляет большое количество UDP-дейтаграмм на один или разные порты. UDP не требует предварительного установления соединения, поэтому поток легко распределяется по адресам и портам.

Специфика IPv6 заключается в следующем:

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

Если UDP-поток направлен на закрытый порт, сервер может генерировать ICMPv6 Destination Unreachable. Ответный трафик создаёт дополнительную нагрузку, поэтому скорость сообщений об ошибках необходимо ограничивать.

IPv6 TCP Flood

TCP работает поверх IPv6 по тем же основным принципам установления и ведения соединения. Возможны SYN Flood, ACK Flood, RST Flood, FIN Flood, SYN-ACK Flood и атаки с полноценными соединениями.

Главная эксплуатационная проблема — неравенство защитных политик. Например:

• IPv4 SYN cookies включены, а IPv6-путь не протестирован;
• IPv4 проходит через anti-DDoS, а AAAA-запись ведёт напрямую на origin;
• IPv4 firewall имеет строгие правила, а IPv6 разрешён по умолчанию;
• rate limiting применяется только к IPv4-адресам;
• мониторинг не агрегирует IPv6-префиксы;
• блокировка одного IPv6-адреса не учитывает доступную атакующему подсеть.

Защита должна одинаково охватывать A- и AAAA-маршруты сайта.

ICMPv6 Flood

ICMPv6 используется не только для диагностики. Он обеспечивает критически важные функции IPv6, включая:

• сообщения Destination Unreachable;
• Packet Too Big;
• Time Exceeded;
• Parameter Problem;
• Echo Request и Echo Reply;
• Neighbor Solicitation и Neighbor Advertisement;
• Router Solicitation и Router Advertisement;
• Redirect;
• часть механизмов Multicast Listener Discovery.

Поэтому правило «заблокировать весь ICMPv6» нарушает работу IPv6. Например, Path MTU Discovery зависит от сообщений Packet Too Big. Без них TCP-соединение может установиться, но зависнуть при передаче более крупных данных.

RFC 4890 содержит отдельные рекомендации по фильтрации ICMPv6 и перечисляет сообщения, которые должны или могут проходить через firewall.

Варианты ICMPv6 Flood

• Echo Request Flood;
• Echo Reply Flood;
• Destination Unreachable Flood;
• Packet Too Big Flood;
• Time Exceeded Flood;
• Parameter Problem Flood;
• Neighbor Solicitation Flood;
• Neighbor Advertisement Flood;
• Router Solicitation Flood;
• Router Advertisement Flood;
• Redirect Flood;
• смешанный поток разных типов ICMPv6.

Каждый тип необходимо оценивать отдельно. Echo Request можно ограничивать сравнительно жёстко, а безусловная блокировка Packet Too Big способна нарушить легитимный трафик.

IPv6 Extension Header Flood

Основной IPv6-заголовок имеет фиксированный размер, а дополнительные функции реализуются через extension headers. Между IPv6 и TCP, UDP или ICMPv6 могут находиться:

• Hop-by-Hop Options;
• Routing Header;
• Fragment Header;
• Destination Options;
• Authentication Header;
• Encapsulating Security Payload;
• другие поддерживаемые заголовки.

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

Основные риски

• повышенная нагрузка на парсер;
• передача пакета из аппаратного forwarding plane в CPU;
• разное понимание пакета firewall и конечным сервером;
• обход правила, ожидающего TCP/UDP сразу после IPv6;
• увеличение числа исключительных ситуаций;
• перегрузка IDS и IPS;
• рост количества журналируемых ошибок.

Это не означает, что любые extension headers вредоносны. Некоторые из них нужны легитимным протоколам. Политика должна учитывать фактические сервисы, а не запрещать всё без анализа.

IPv6 Fragment Flood

Промежуточные IPv6-маршрутизаторы не фрагментируют пакет. Если пакет слишком велик для следующего участка, он отбрасывается, а отправителю возвращается ICMPv6 Packet Too Big. Фрагменты создаёт отправитель, используя Fragment Header.

При атаке могут поступать:

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

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

Neighbor Discovery не должен зависеть от IPv6-фрагментации. RFC 6980 рассматривает риски использования фрагментации вместе с NDP и запрещает её для ряда сообщений Neighbor Discovery.

Что такое IPv6 Neighbor Discovery

Neighbor Discovery Protocol, или NDP, выполняет в IPv6 сразу несколько функций. Он используется для обнаружения маршрутизаторов, определения параметров сети, разрешения IPv6-адресов в канальные адреса, проверки доступности соседей, обнаружения дублирующихся адресов и перенаправления трафика.

NDP определён в RFC 4861. Протокол использует сообщения ICMPv6 Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement и Redirect.

Основные сообщения NDP

Сообщение	Сокращение	ICMPv6 Type	Назначение
Router Solicitation	RS	133	Запрос информации у локальных маршрутизаторов
Router Advertisement	RA	134	Объявление маршрутизатора, префиксов и параметров сети
Neighbor Solicitation	NS	135	Определение link-layer-адреса соседа и проверка доступности
Neighbor Advertisement	NA	136	Ответ на NS или самостоятельное объявление информации о соседе
Redirect	—	137	Указание более подходящего next hop

Как работает Neighbor Solicitation

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

1. проверяет Neighbor Cache;
2. если записи нет, отправляет Neighbor Solicitation;
3. целевой хост отвечает Neighbor Advertisement;
4. полученная информация сохраняется в Neighbor Cache;
5. после этого передаётся ожидающий IPv6-пакет.

Это похоже на роль ARP в IPv4, но NDP является более широким механизмом и работает через ICMPv6.

Что такое Neighbor Cache

Neighbor Cache хранит соответствие IPv6-адресов соседей их канальным адресам и информацию о доступности. Записи проходят различные состояния, например:

• INCOMPLETE;
• REACHABLE;
• STALE;
• DELAY;
• PROBE.

Если направить трафик на множество адресов в подключённом префиксе, маршрутизатор может попытаться определить MAC-адрес каждого назначения. Для этого создаются записи INCOMPLETE, отправляются NS и ожидаются ответы.

Что такое IPv6 Neighbor Discovery Flood

NDP Flood — атака, вызывающая чрезмерную обработку сообщений Neighbor Discovery или массовое создание записей Neighbor Cache.

Основные варианты:

• Neighbor Solicitation Flood;
• Neighbor Advertisement Flood;
• Neighbor Cache Exhaustion;
• Router Solicitation Flood;
• Router Advertisement Flood;
• Redirect Flood;
• Duplicate Address Detection Flood;
• атака случайными адресами подключённого IPv6-префикса.

Neighbor Solicitation Flood

При NS Flood злоумышленник отправляет большое количество Neighbor Solicitation. Пакеты могут запрашивать разные адреса либо многократно обращаться к одному узлу.

Цель атаки:

• загрузить CPU хоста или маршрутизатора;
• заставить устройство генерировать Neighbor Advertisement;
• перегрузить локальный multicast;
• занять полосу сегмента;
• переполнить очереди control plane;
• ухудшить обработку легитимного NDP.

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

Neighbor Advertisement Flood

При NA Flood в сегмент поступает множество Neighbor Advertisement. Они могут содержать разные IPv6- и link-layer-адреса либо пытаться изменить существующие записи.

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

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

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

Neighbor Cache Exhaustion

Neighbor Cache Exhaustion — один из наиболее важных сценариев. Атакующий направляет трафик на большое количество несуществующих или ещё неизвестных адресов в префиксе, который маршрутизатор считает непосредственно подключённым.

Например, маршрутизатор обслуживает большой on-link-префикс. Для каждого нового адреса он:

1. создаёт или пытается создать запись Neighbor Cache;
2. помещает исходный пакет в ожидание;
3. отправляет Neighbor Solicitation;
4. ожидает Neighbor Advertisement;
5. повторяет запрос согласно таймерам;
6. удаляет запись после неуспеха.

Если адресов поступают тысячи или миллионы, ресурсы тратятся на заведомо несуществующих соседей.

RFC 6583 подробно рассматривает операционные проблемы Neighbor Discovery и варианты смягчения DoS, связанного с большим числом записей и процедур разрешения адресов.

Почему большое IPv6-пространство усиливает проблему

Типичный IPv6 LAN использует префикс /64, содержащий огромное число адресов. Злоумышленнику не нужно просканировать всё пространство. Достаточно постоянно генерировать новые адреса назначения быстрее, чем маршрутизатор удаляет незавершённые записи.

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

Router Solicitation Flood

Хост отправляет Router Solicitation, чтобы запросить Router Advertisement и быстрее получить параметры сети. При RS Flood маршрутизатор получает массовый поток запросов и может формировать большое количество ответов.

Риски:

• нагрузка на control plane;
• рост исходящих Router Advertisement;
• перегрузка локального сегмента;
• задержка легитимной автоконфигурации;
• засорение журналов.

Router Advertisement Flood

Router Advertisement содержит критически важную информацию:

• наличие маршрутизатора;
• IPv6-префиксы;
• маршрут по умолчанию;
• время жизни параметров;
• флаги автоконфигурации;
• MTU;
• дополнительные параметры, включая DNS в соответствующих расширениях.

При RA Flood злоумышленник из локального сегмента отправляет множество поддельных или конфликтующих Router Advertisement. Это может привести к:

• появлению ложного default gateway;
• частому изменению сетевой конфигурации хостов;
• добавлению посторонних префиксов;
• перехвату или blackholing трафика;
• сбоям SLAAC;
• переполнению таблиц параметров;
• росту CPU на конечных устройствах;
• потере сетевой доступности.

RA Flood может быть не только DDoS, но и частью атаки посредника. Поэтому защита должна учитывать как объём, так и доверенность источника.

Почему NDP Flood обычно является локальной атакой

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

Практическими источниками атаки могут быть:

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

Но Neighbor Cache Exhaustion может быть спровоцирован удалённо. Если интернет-трафик поступает к множеству адресов on-link-префикса, пограничный маршрутизатор сам начнёт выполнять NDP в локальном сегменте.

Как IPv6 Flood перегружает инфраструктуру

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

При достаточном объёме IPv6-трафик занимает всю доступную полосу так же, как IPv4. Локальный firewall не способен восстановить канал, если он находится после точки переполнения.

Перегрузка по pps

Большое количество небольших IPv6-пакетов превышает пакетную производительность маршрутизатора, firewall или сервера.

Перегрузка control plane

NDP, некоторые extension headers, ошибки и исключительные пакеты могут передаваться CPU сетевого устройства. Без policing это влияет на маршрутизацию и управление.

Исчерпание Neighbor Cache

Большое количество незавершённых или динамически изменяемых записей занимает память и время процессора.

Перегрузка multicast в локальном сегменте

NDP использует multicast вместо широковещательного ARP. Хотя solicited-node multicast уменьшает область доставки, массовый поток всё равно создаёт нагрузку на сегмент и устройства.

Истощение таблиц состояний

IPv6 TCP и UDP Flood может создавать множество записей conntrack, особенно если правила firewall настроены на отслеживание всех входящих потоков.

Асимметрия dual stack

Сервис может оставаться доступным по IPv4, но не работать по IPv6. Пользователи с предпочтением IPv6 сначала пытаются подключиться по AAAA, сталкиваются с таймаутом и воспринимают сайт как медленный или недоступный.

Как обнаружить IPv6 Flood

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

• резкий рост IPv6 bps и pps;
• увеличение доли IPv6 относительно обычного уровня;
• рост TCP, UDP или ICMPv6 одного типа;
• трафик на множество адресов одного префикса;
• рост IPv6 fragments;
• аномальные цепочки extension headers;
• рост CPU firewall при стабильном IPv4;
• переполнение IPv6 conntrack;
• недоступность сайта только по AAAA;
• различие между IPv4- и IPv6-задержкой;
• рост ICMPv6 errors;
• увеличение packet drops на IPv6-интерфейсах.

Признаки NDP Flood

• резкий рост NS и NA;
• много Neighbor Cache entries в состоянии INCOMPLETE;
• частая смена записей REACHABLE, STALE и PROBE;
• появление множества неизвестных IPv6-адресов;
• рост CPU маршрутизатора;
• перегрузка очереди control plane;
• массовые запросы к несуществующим адресам;
• необычное количество RS или RA;
• несколько источников Router Advertisement;
• изменение default gateway на хостах;
• конфликты IPv6-адресов;
• сбои SLAAC и Duplicate Address Detection.

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

Метрика	Назначение
IPv6 bps и pps	Оценка общей нагрузки
Соотношение IPv4 и IPv6	Выявление аномального изменения
Распределение Next Header	Определение TCP, UDP, ICMPv6 и других протоколов
Типы ICMPv6	Разделение Echo, ошибок и NDP
Размер Neighbor Cache	Контроль исчерпания таблицы
Состояния NCE	Выявление роста INCOMPLETE и PROBE
NS и NA в секунду	Определение Neighbor Discovery Flood
RS и RA в секунду	Выявление аномалий маршрутизаторов
Число RA-источников	Поиск посторонних маршрутизаторов
Extension headers	Контроль необычных цепочек
IPv6 fragments	Оценка фрагментационной атаки
CPU control plane	Определение фактической точки перегрузки

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

1. Создать одинаково строгую политику для IPv4 и IPv6

Для каждого разрешённого IPv4-сервиса необходимо определить IPv6-эквивалент:

• публичные порты;
• административный доступ;
• правила firewall;
• rate limiting;
• anti-DDoS-маршрутизацию;
• мониторинг;
• журналирование;
• доступ к origin;
• проверку DNS A и AAAA.

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

2. Не блокировать весь ICMPv6

Следует разрешить необходимые типы ICMPv6 и ограничить их скорость. Особое значение имеют:

• Packet Too Big;
• Destination Unreachable;
• Time Exceeded;
• Parameter Problem;
• NDP в локальном сегменте.

Echo Request можно ограничивать отдельно. NDP не следует пропускать между сегментами как обычный маршрутизируемый трафик.

3. Фильтровать extension headers

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

При этом правила должны учитывать, что транспортный заголовок не всегда следует сразу за основным IPv6-заголовком.

4. Ограничить IPv6-фрагментацию

Полезные меры:

• ограничение количества reassembly queues;
• ограничение памяти под фрагменты;
• короткие безопасные таймауты;
• отбрасывание недопустимых фрагментов;
• контроль наличия транспортного заголовка в первом фрагменте;
• rate limiting аномального фрагментированного потока.

5. Использовать агрегацию по IPv6-префиксам

Блокировка одного IPv6-адреса может быть малоэффективной, если атакующий способен менять адрес внутри своего префикса. Системы защиты должны уметь оценивать:

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

Размер агрегации нельзя выбирать механически: слишком широкая блокировка затронет большое количество легитимных пользователей.

6. Подключить upstream IPv6-защиту

Необходимо заранее проверить, очищает ли anti-DDoS-провайдер IPv6, а не только IPv4. Отдельно следует протестировать:

• анонс IPv6-префикса;
• маршрутизацию через scrubbing center;
• фильтрацию TCP, UDP и ICMPv6;
• работу при extension headers;
• защиту AAAA-адресов;
• время переключения;
• доступность сайта после очистки.

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

1. Изолировать L2-сегменты

Чем больше недоверенных устройств находится в одном канальном домене, тем выше риск локальной NDP-атаки. Следует использовать:

• отдельные VLAN;
• изоляцию клиентов Wi-Fi;
• private VLAN;
• изоляцию арендаторов;
• ограничение взаимодействия виртуальных машин;
• сегментацию management-сети;
• разделение публичных и storage-сегментов.

2. Включить RA Guard

RA Guard блокирует Router Advertisement на портах, где не должны находиться маршрутизаторы. Разрешение RA следует оставить только доверенным uplink-портам.

Важно использовать актуальную реализацию, корректно обрабатывающую IPv6 extension headers и фрагментацию. Простая проверка фиксированного смещения может быть недостаточной.

3. Ограничить NS, NA, RS и Redirect

Control-plane policing должен отдельно учитывать разные типы NDP. Нельзя устанавливать один слишком низкий общий лимит: легитимное Neighbor Discovery должно сохранять приоритет.

Полезно разделить очереди для:

• NS к собственным адресам маршрутизатора;
• проверки уже известных соседей;
• разрешения новых адресов;
• RS;
• неожиданных RA;
• Redirect;
• аномальных сообщений.

4. Защитить Neighbor Cache

Маршрутизатор должен иметь:

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

Простое увеличение таблицы может лишь увеличить объём памяти, доступный для исчерпания.

5. Не считать весь префикс on-link без необходимости

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

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

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

Не следует произвольно заменять стандартные /64 на более длинные LAN-префиксы без проверки SLAAC, оборудования и требований конкретной архитектуры.

6. Фильтровать трафик к неиспользуемым адресам upstream

Если публично назначена только часть адресов, трафик к остальному пространству можно направлять в discard или фильтровать до маршрутизатора, который выполняет NDP.

Это предотвращает создание записи Neighbor Cache для каждого случайного назначения.

7. Использовать DHCPv6 Guard и port security

RA Guard защищает Router Advertisement, но не решает все проблемы. В корпоративной сети могут потребоваться:

• DHCPv6 Guard;
• port security;
• контроль разрешённых MAC-адресов;
• ограничение числа IPv6-адресов на порт;
• source address validation;
• привязка адреса к порту или арендатору;
• телеметрия first-hop-коммутаторов.

8. Проверять Hop Limit сообщений NDP

Корректные сообщения Neighbor Discovery используют Hop Limit 255. Значение помогает обнаружить пакет, прошедший через маршрутизатор, поскольку промежуточная маршрутизация уменьшила бы Hop Limit.

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

Почему блокировка ICMPv6 ломает сеть

В IPv4 ICMP иногда воспринимают как необязательную диагностику. Для IPv6 это особенно опасное упрощение.

Полная блокировка ICMPv6 может нарушить:

• Neighbor Discovery;
• Router Discovery;
• SLAAC;
• Duplicate Address Detection;
• Path MTU Discovery;
• диагностику недоступности;
• корректное завершение неуспешной доставки;
• работу отдельных переходных механизмов.

Защита должна фильтровать ICMPv6 по типу, области действия, интерфейсу, источнику и скорости, а не запрещать протокол целиком.

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

WAF анализирует HTTP- и HTTPS-запросы. Neighbor Discovery работает ниже IP-маршрутизации — между узлами локального сегмента. NDP-пакет не содержит HTTP-запроса и не поступает в WAF.

Даже обычный внешний IPv6 UDP или ICMPv6 Flood может закончиться на firewall, маршрутизаторе или сетевом интерфейсе до установления TCP-соединения.

WAF участвует только тогда, когда атакующий:

1. успешно проходит IPv6-маршрутизацию;
2. устанавливает TCP-соединение;
3. при HTTPS завершает TLS-handshake;
4. отправляет HTTP-запрос.

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

TrafficVeil защищает веб-сайты как HTTP/HTTPS reverse proxy. Он отделяет внешнее соединение посетителя от origin, применяет WAF, L7 DDoS-фильтрацию, rate limiting и анализ автоматизированного трафика.

Для защиты dual-stack-сайта необходимо убедиться, что:

• все публичные A- и AAAA-записи ведут в защищённый контур;
• AAAA-запись не раскрывает прямой IPv6-адрес origin;
• origin ограничен по IPv4 и IPv6;
• firewall разрешает веб-трафик только от доверенных proxy-адресов;
• старые AAAA-записи удалены;
• почтовые, тестовые и служебные поддомены не раскрывают origin;
• мониторинг проверяет доступность обеих версий IP.

Особенно опасна ситуация, когда IPv4 origin закрыт, а глобальный IPv6-адрес сервера доступен напрямую. Тогда атакующий обходит reverse proxy через IPv6.

TrafficVeil не заменяет RA Guard, Neighbor Cache protection, control-plane policing и L2-сегментацию. Эти механизмы должны внедряться на коммутаторах, маршрутизаторах, гипервизорах и у хостинг-провайдера.

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

1. Подтвердить IPv6-вектор. Сравнить нагрузку IPv4 и IPv6.
2. Определить Next Header. Выделить TCP, UDP, ICMPv6, фрагменты и extension headers.
3. Измерить bps и pps. Разделить объёмную и пакетную перегрузку.
4. Проверить AAAA. Убедиться, что адрес не ведёт напрямую на origin.
5. Найти точку перегрузки. Проверить канал, firewall, control plane, conntrack и сервер.
6. Применить фильтрацию по типу. Не блокировать весь ICMPv6.
7. Ограничить аномальные extension headers и фрагменты.
8. Агрегировать источники по префиксам. Не ограничиваться отдельными IPv6-адресами.
9. Связаться с оператором. Запросить IPv6 upstream-фильтрацию.
10. Перенаправить IPv6 на очистку. Если канал или оборудование перегружены.
11. Проверить IPv4. Атака может быть многовекторной.
12. Контролировать L7. После фильтрации сетевого потока проверить HTTP Flood.

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

1. Проверить типы ICMPv6. Определить NS, NA, RS, RA или Redirect.
2. Найти входной интерфейс. NDP-атака обычно связана с конкретным L2-сегментом.
3. Определить источник. Сопоставить MAC, IPv6, порт коммутатора, VLAN и виртуальную машину.
4. Проверить Neighbor Cache. Оценить размер и долю INCOMPLETE.
5. Изолировать источник. Ограничить порт, VLAN, VM или арендатора.
6. Включить RA Guard. Разрешить RA только доверенным маршрутизаторам.
7. Применить control-plane policing. Сохранить приоритет легитимного NDP.
8. Фильтровать неиспользуемые назначения. Остановить удалённый address spray до NDP.
9. Снизить логирование. Сохранить агрегацию и sampling.
10. Проверить доступность шлюза. Защитные меры не должны блокировать NS и NA собственных адресов.

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

• время начала, пика и окончания;
• затронутые IPv6-префиксы;
• целевые IPv6-адреса;
• пиковые bps и pps;
• распределение Next Header;
• типы и коды ICMPv6;
• число фрагментов;
• extension header chains;
• размер Neighbor Cache;
• число INCOMPLETE, REACHABLE и STALE;
• NS, NA, RS и RA в секунду;
• источники Router Advertisement;
• MAC-адреса источников;
• входные порты и VLAN;
• CPU control plane;
• packet drops;
• NetFlow, sFlow или IPFIX с IPv6;
• ограниченный PCAP;
• изменения правил во время инцидента;
• влияние на IPv4 и IPv6-доступность.

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

Защищать только IPv4

AAAA-запись и глобальный IPv6-адрес могут создать прямой обход защищённого IPv4-контура.

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

Это ломает NDP, Path MTU Discovery и другие обязательные функции IPv6.

Считать NDP удалённым интернет-протоколом

Классические NDP-сообщения имеют локальную область действия, хотя удалённый трафик к случайным on-link-адресам способен косвенно вызвать NDP-нагрузку на маршрутизатор.

Лимитировать весь NDP одной очередью

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

Блокировать отдельные IPv6-адреса

Атакующий может быстро менять адреса внутри доступного префикса, поэтому нужна осторожная агрегация.

Увеличивать Neighbor Cache без устранения причины

Большая таблица откладывает отказ и позволяет атаке занять больше памяти.

Разрешать RA на всех портах

Любое устройство в сегменте получает возможность объявить себя маршрутизатором.

Отключать IPv6 только в приложении

Сетевой стек, link-local-адреса и NDP могут продолжать работать, поэтому политика должна охватывать интерфейсы и оборудование.

Не мониторить AAAA отдельно

Сайт может быть доступен по IPv4 и недоступен по IPv6, что создаёт выборочные проблемы у пользователей.

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

• IPv4- и IPv6-политики firewall согласованы.
• Все AAAA-записи инвентаризированы.
• AAAA не раскрывает origin.
• Origin ограничен одновременно по IPv4 и IPv6.
• Мониторинг собирает отдельные IPv6 bps и pps.
• Контролируются ICMPv6 types.
• Необходимые ICMPv6-сообщения разрешены.
• Настроена фильтрация extension headers.
• Ограничены IPv6 fragments и reassembly.
• Anti-DDoS-провайдер поддерживает IPv6.
• Источники анализируются по адресам и префиксам.
• Включён RA Guard.
• RA разрешены только доверенным портам.
• Настроены DHCPv6 Guard и port security, если они нужны.
• Контролируется размер Neighbor Cache.
• Есть алерт на рост INCOMPLETE.
• Разделены очереди критического и нового NDP.
• Защищён control plane маршрутизаторов.
• Неиспользуемые IPv6-адреса фильтруются до NDP.
• Сегменты арендаторов и клиентов изолированы.
• Публичный сайт работает через TrafficVeil.
• Регламент IPv6-реагирования протестирован отдельно от IPv4.