GRE, ESP и IP-in-IP Flood: атаки через туннельные протоколы

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

Такие атаки отличаются от классического UDP Flood или SYN Flood. Во внешнем IP-заголовке пакета указывается не TCP или UDP, а отдельный номер протокола: 47 для GRE, 50 для ESP и 4 для IPv4-in-IPv4. Следовательно, у пакета может не быть привычных портов источника и назначения. Фильтрация только по TCP- и UDP-портам такую активность не контролирует.

GRE предназначен для переноса одного сетевого протокола внутри другого, ESP применяется в IPsec, а IP-in-IP помещает один IP-пакет внутрь другого. Это легитимные технологии, используемые в VPN, операторских сетях, облачной инфраструктуре и связях между дата-центрами. Само присутствие такого трафика не означает атаку. Проблемой становится аномальный объём, чрезмерная пакетная скорость либо поступление туннельных пакетов от неразрешённых источников.

Что такое инкапсуляция

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

Элемент	Назначение
Внешний IP-заголовок	Доставляет пакет от одного туннельного узла к другому
Заголовок GRE, ESP или другой инкапсуляции	Описывает способ обработки вложенных данных
Внутренний пакет	Содержит исходный IPv4-, IPv6- или иной сетевой трафик
Полезная нагрузка	Может содержать TCP, UDP, ICMP или данные другого протокола

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

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

Почему GRE, ESP и IP-in-IP рассматриваются вместе

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

• не обязательно используют TCP- или UDP-порты;
• могут поступать непосредственно на маршрутизатор или VPN-шлюз;
• требуют анализа поля Protocol в IPv4 либо Next Header в IPv6;
• создают дополнительную нагрузку на декапсуляцию;
• могут скрывать от промежуточного оборудования структуру внутреннего пакета;
• требуют отделять разрешённые туннели от постороннего трафика;
• могут сопровождаться фрагментацией и проблемами MTU.

При этом объединять их в один технический механизм нельзя: GRE, ESP и IP-in-IP имеют разное назначение, структуру заголовка и требования к защите.

Характеристика	GRE	ESP	IP-in-IP
Номер IP-протокола	47	50	4 для IPv4-in-IPv4
Основное назначение	Универсальная инкапсуляция сетевых протоколов	Защита трафика в IPsec	Перенос одного IP-пакета внутри другого
TCP/UDP-порты во внешнем пакете	Нет	Нет у нативного ESP	Нет
Шифрование	Сам GRE не шифрует данные	Зависит от согласованной конфигурации IPsec	Не предусмотрено
Типичная цель атаки	GRE-шлюз, маршрутизатор, канал	IPsec-шлюз, VPN-концентратор, канал	Туннельный endpoint, маршрутизатор, канал
Особая нагрузка	Разбор GRE и внутреннего протокола	Поиск SA, проверка целостности, защита от повторов и возможная расшифровка	Декапсуляция и маршрутизация внутреннего IP-пакета

IANA закрепляет за IP-in-IP, GRE и ESP номера 4, 47 и 50 соответственно. Эти значения находятся в поле Protocol IPv4 или соответствующем поле Next Header для IPv6.

Что такое GRE

GRE, или Generic Routing Encapsulation, — протокол универсальной инкапсуляции. Он позволяет переносить пакет одного сетевого протокола через сеть другого протокола. Базовое устройство GRE описано в RFC 2784.

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

1. внешний IP-заголовок;
2. GRE-заголовок;
3. инкапсулированный пакет;
4. данные внутреннего протокола.

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

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

Что такое GRE Flood

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

На практике атака может воздействовать сразу на несколько ресурсов:

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

Основные варианты GRE Flood

Вариант	Как проявляется	Основной риск
Объёмный GRE Flood	Передаётся большое количество байтов в секунду	Переполнение внешнего канала
Высокоскоростной GRE Packet Flood	Много небольших пакетов	Перегрузка CPU и таблиц обработки
Flood неизвестных туннелей	Пакеты приходят от посторонних адресов или с неожиданными параметрами	Расход ресурсов на классификацию и отбрасывание
GRE с некорректной нагрузкой	Структура внешнего или внутреннего пакета не соответствует ожидаемой	Нагрузка на парсер и защитные системы
Фрагментированный GRE Flood	Пакеты разбиты на IP-фрагменты	Очереди сборки, память и усложнение фильтрации
Многовекторная атака	GRE сочетается с UDP, TCP или ICMP Flood	Одновременная перегрузка нескольких компонентов

Чем GRE Flood опаснее обычного потока пакетов

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

Кроме того, инкапсуляция увеличивает размер пакета. Если исходный пакет близок к MTU канала, добавление внешнего IP- и GRE-заголовков может привести к фрагментации или отбрасыванию пакета. Фрагментация не является обязательной частью GRE Flood, но может усиливать нагрузку и затруднять анализ. Проблемы фрагментации GRE рассматриваются, в частности, в RFC 7588.

Что такое ESP

ESP, или Encapsulating Security Payload, — компонент архитектуры IPsec. Он предназначен для предоставления набора защитных функций, в который в зависимости от настроек могут входить конфиденциальность, целостность, аутентификация источника, защита от повторной передачи и ограниченная защита конфиденциальности потока.

Актуальная базовая спецификация ESP описана в RFC 4303. Важно учитывать, что ESP не следует упрощённо называть «протоколом, который всегда шифрует всё»: фактический набор услуг зависит от выбранных алгоритмов, режима и Security Association.

Типовой ESP-пакет может включать:

• внешний IP-заголовок;
• Security Parameters Index — идентификатор Security Association;
• порядковый номер;
• защищённую полезную нагрузку;
• служебные поля заполнения;
• данные контроля целостности или аутентификации, если они предусмотрены выбранным преобразованием.

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

Что такое ESP Flood

ESP Flood — массовая отправка пакетов IP-протокола 50 в сторону VPN-шлюза, межсетевого экрана, маршрутизатора или другого доступного узла. Целью может быть заполнение канала либо исчерпание ресурсов, связанных с обработкой IPsec.

Не каждый полученный ESP-пакет вызывает дорогостоящую расшифровку. Например, пакет с неизвестным SPI может быть отброшен после поиска Security Association. Поэтому утверждение, что любой случайный ESP-трафик обязательно перегружает процессор криптографией, некорректно.

Реальный эффект определяется несколькими факторами:

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

Возможные цели ESP Flood

Пропускная способность. Даже если каждый пакет быстро отбрасывается, он уже прошёл по внешнему каналу. Локальный firewall не освободит полосу, занятую до сервера.

VPN-концентратор. Устройство тратит ресурсы на разбор ESP, поиск SPI, проверку параметров и учёт ошибок.

Легитимные IPsec-туннели. Из-за очередей и потерь пакетов корпоративные VPN-соединения становятся нестабильными.

Межсетевой экран. Устройство может достигнуть лимита пакетной обработки раньше, чем будет заполнен канал.

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

ESP и UDP-порт 4500 — не одно и то же

Нативный ESP использует IP-протокол 50 и не имеет внешнего TCP- или UDP-порта. Но при прохождении через NAT IPsec часто использует NAT Traversal: ESP инкапсулируется в UDP, обычно с портом 4500.

Форма трафика	Что видно во внешнем заголовке	Как классифицируется
Нативный ESP	IP protocol 50	ESP-трафик
IPsec NAT-T	UDP, обычно порт 4500	UDP-трафик с инкапсулированным ESP
IKE	Обычно UDP 500, а при NAT-T также используется UDP 4500	Управляющий обмен IPsec

Следовательно, правила, блокирующие только IP protocol 50, не охватывают IPsec через NAT-T. И наоборот, блокировка UDP 4500 не остановит нативный ESP. Для корректной защиты нужно учитывать фактическую архитектуру VPN.

Что такое IP-in-IP

IP-in-IP — простой способ поместить один IP-пакет внутрь другого. Внешний заголовок доставляет пакет до конца туннеля, после чего удаляется, а внутренний пакет обрабатывается как обычный IP-трафик.

RFC 2003 описывает инкапсуляцию IP-дейтаграммы внутри другой IP-дейтаграммы. Для IPv4-in-IPv4 во внешнем IPv4-заголовке используется номер протокола 4.

IP-in-IP проще GRE: он предназначен прежде всего для переноса IP внутри IP и не содержит универсального заголовка GRE. При этом он также:

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

Что такое IP-in-IP Flood

IP-in-IP Flood — поток пакетов с IP-протоколом 4, направленный на сервер, маршрутизатор или туннельный endpoint. Внутри могут находиться корректные, случайные, поддельные либо намеренно неудобные для обработки IP-пакеты.

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

Сценарии воздействия IP-in-IP Flood

• Переполнение канала. Массовый трафик занимает входящую полосу независимо от результата декапсуляции.
• Перегрузка tunnel endpoint. Узел классифицирует внешний пакет, сопоставляет его с туннелем и разбирает внутренний заголовок.
• Нагрузка на маршрутизацию. После декапсуляции внутренний пакет может потребовать дополнительного поиска маршрута и применения политик.
• Обход недостаточных ACL. Проверка только внешних адресов без контроля внутреннего пакета может пропустить нежелательный трафик глубже в сеть.
• Фрагментация. Внешний заголовок увеличивает размер пакета, что создаёт дополнительные риски при неверно настроенном MTU.
• Засорение журналов. Некорректные или неизвестные туннельные пакеты могут генерировать большое число событий.

Чем GRE Flood отличается от IP-in-IP Flood

Критерий	GRE Flood	IP-in-IP Flood
Внешний номер протокола	47	4
Дополнительный заголовок	Есть GRE-заголовок	Отдельного GRE-подобного заголовка нет
Переносимые протоколы	GRE рассчитан на разные сетевые протоколы	Внутри переносится IP-пакет
Накладные расходы	Внешний IP плюс GRE и возможные расширения	Внешний IP-заголовок
Типичная защита	ACL по внешним адресам и параметрам GRE-туннеля	ACL по разрешённым IP-in-IP endpoints

Каким образом эти атаки выводят инфраструктуру из строя

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

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

2. Перегрузка пакетной обработкой

Небольшие пакеты создают высокое значение packets per second. Устройство может справляться с нужным количеством гигабит в секунду, но не выдерживать требуемого количества пакетов. Поэтому оценивать DDoS только в Gbit/s недостаточно.

3. Нагрузка на декапсуляцию

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

4. Нагрузка на криптографический контур

Для части ESP-трафика могут выполняться проверка целостности, защита от повторов и расшифровка. Насколько далеко пройдёт вредоносный пакет, зависит от его корректности и конфигурации IPsec.

5. Истощение очередей и памяти

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

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

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

Как распознать GRE, ESP или IP-in-IP Flood

Первый признак — резкий рост трафика с определённым значением поля IP Protocol:

• 4 — IPv4-in-IPv4;
• 47 — GRE;
• 50 — ESP.

Дополнительные признаки:

• пакеты приходят от большого количества незнакомых адресов;
• источники не совпадают с разрешёнными сторонами туннелей;
• одновременно растут bps и pps либо только pps;
• увеличивается загрузка CPU маршрутизатора или VPN-шлюза;
• появляются потери пакетов на внешнем интерфейсе;
• растёт число ошибок неизвестного туннеля, SPI или политики;
• легитимные VPN-соединения теряют пакеты;
• возникают очереди и сбросы на интерфейсах;
• увеличивается доля IP-фрагментов;
• наблюдаются нетипичные размеры пакетов;
• снижается доступность всех сервисов, использующих тот же канал.

Какие метрики необходимо анализировать

Метрика	Что показывает
Биты в секунду	Степень загрузки пропускной способности
Пакеты в секунду	Нагрузку на пакетную обработку
Распределение по IP Protocol	Рост GRE, ESP или IP-in-IP относительно базового уровня
Адреса источников	Соответствие разрешённым tunnel peers
Размеры пакетов	Характер потока и преобладание мелких или крупных пакетов
Фрагменты в секунду	Наличие фрагментированного туннельного трафика
CPU и packet drops	Способность устройства обрабатывать поток
Ошибки IPsec или туннеля	Пакеты с неизвестными параметрами либо неуспешной проверкой
Задержка и потери легитимных туннелей	Фактическое влияние на пользователей

Как отличить атаку от легитимного туннельного трафика

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

Для каждого легитимного туннеля должны быть определены:

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

Например, если GRE-туннель должен принимать пакеты только от одного адреса оператора, поток GRE от тысяч других адресов является явной аномалией. Если ESP используется сотрудниками с динамическими адресами, одной статической allowlist может быть недостаточно: потребуется защита VPN-концентратора, ограничение скорости, контроль IKE и сервис очистки.

Последствия атак

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

Как защититься от GRE, ESP и IP-in-IP Flood

1. Запретить неиспользуемые протоколы

Если организация не использует GRE, нативный ESP или IP-in-IP, их следует блокировать на внешнем периметре. Правило должно проверять номер IP-протокола, а не только TCP- и UDP-порты.

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

2. Разрешать трафик только от известных tunnel peers

Для статических GRE- и IP-in-IP-туннелей наиболее эффективна строгая allowlist внешних адресов. Пакеты нужного протокола от любых других источников должны отбрасываться до декапсуляции.

Необходимо контролировать не только внешний источник. После декапсуляции следует проверять:

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

3. Использовать антиспуфинг

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

4. Ограничить пакетную скорость

Rate limiting может снизить нагрузку от аномального количества GRE, ESP или IP-in-IP пакетов. Но лимиты должны учитывать нормальные пики. Слишком низкое ограничение самостоятельно нарушит работу VPN или межсетевого туннеля.

Отдельно желательно контролировать:

• общий pps каждого туннельного протокола;
• pps от одного внешнего адреса;
• pps неизвестных туннелей;
• долю фрагментированных пакетов;
• ошибки IPsec и неизвестные SPI;
• трафик, направляемый в control plane.

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

Маршрутизаторы и L3-коммутаторы должны иметь отдельные политики защиты управляющего процессора. Важно убедиться, что GRE, ESP, фрагменты и неизвестные протоколы обрабатываются в аппаратном тракте либо ограничиваются до попадания на CPU.

6. Настроить MTU

Инкапсуляция добавляет заголовки и уменьшает размер доступной полезной нагрузки. Некорректный MTU увеличивает количество фрагментов, потерь и повторных передач. Необходимо учитывать накладные расходы конкретного туннеля и проверять Path MTU Discovery.

Современные рекомендации подчёркивают хрупкость IP-фрагментации и советуют по возможности избегать зависимости от неё.

7. Разделить внешние сервисы и туннельные шлюзы

Не рекомендуется без необходимости размещать публичный сайт, VPN-концентратор и туннельный endpoint за одним незащищённым каналом или на одном сервере. Атака на IPsec способна сделать недоступным сайт, даже если сам веб-сервер не обрабатывает ни одного ESP-пакета.

8. Подключить операторскую фильтрацию

Если атака превышает ёмкость канала, фильтрация должна происходить до него. Возможные меры:

• ACL на стороне оператора;
• фильтрация по номеру IP-протокола;
• разрешение только известных tunnel peers;
• перенаправление трафика в scrubbing center;
• RTBH для экстренного прекращения трафика к атакуемому адресу;
• FlowSpec или эквивалентное распространение точечных правил;
• смена маршрутизации на защищённый контур.

RTBH делает адрес недоступным полностью, поэтому это аварийная мера, а не полноценная очистка.

Почему WAF не останавливает GRE, ESP и IP-in-IP Flood

WAF анализирует веб-запросы HTTP и HTTPS: URI, заголовки, cookies, параметры, тело запроса и поведение клиента. GRE, ESP и IP-in-IP работают ниже прикладного уровня и могут вообще не содержать доступного для WAF HTTP-запроса.

Если поток направлен на реальный IP-адрес сервера, он может заполнить канал ещё до HTTP-прокси. Поэтому защита от таких атак должна включать сетевую фильтрацию L3/L4 и, при крупных объёмах, операторскую очистку.

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

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

TrafficVeil может снизить риск прямой атаки на сайт, если выполнены два условия:

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

Но HTTP/HTTPS reverse proxy не заменяет защиту GRE-, ESP- или IP-in-IP-шлюза. Если атакующий знает настоящий IP origin и отправляет на него протокол 47, 50 или 4, такой поток необходимо блокировать на пограничном оборудовании, у хостинг-провайдера либо в сервисе L3/L4-очистки.

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

Уровень	Задача
Оператор или scrubbing center	Поглощение объёмных L3/L4-атак до канала клиента
Пограничный маршрутизатор	ACL, антиспуфинг, ограничение pps и защита control plane
Firewall или VPN-шлюз	Проверка tunnel peers, IPsec-политик и внутреннего трафика
TrafficVeil	Защита HTTP/HTTPS, фильтрация L7-атак, ботов и вредоносных веб-запросов
Origin	Приём соединений только из доверенного защищённого контура

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

1. Подтвердить сетевой уровень. Определить, какие IP-протоколы создают поток: 4, 47, 50 или их сочетание с TCP/UDP.
2. Измерить bps и pps. Это покажет, атакован канал или пакетная производительность оборудования.
3. Проверить легитимность. Сопоставить источники с утверждёнными tunnel peers.
4. Отключить неиспользуемые протоколы. Если GRE, ESP или IP-in-IP не нужны, заблокировать их на самом внешнем доступном рубеже.
5. Сузить правила разрешения. Для действующих туннелей оставить только известные внешние адреса.
6. Ограничить аномальный pps. Применить безопасные лимиты к неизвестным источникам и ошибочным пакетам.
7. Связаться с оператором. Если канал заполнен, передать ему адрес назначения, протокол, объём, pps и время начала.
8. Перенаправить поток на очистку. Использовать заранее подготовленный scrubbing-маршрут.
9. Проверить origin. Убедиться, что реальный адрес сайта не принимает произвольный трафик из интернета.
10. Контролировать побочные эффекты. Следить за VPN, маршрутизацией, DNS, журналами и веб-сервисами.

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

• точное время начала и окончания атаки;
• целевые IP-адреса;
• номера IP-протоколов;
• пиковый и средний bps;
• пиковый и средний pps;
• распределение размеров пакетов;
• список основных внешних источников;
• долю IP-фрагментов;
• данные NetFlow, sFlow или IPFIX;
• короткую репрезентативную запись пакетов;
• загрузку CPU и память сетевых устройств;
• счётчики drops и ошибок интерфейсов;
• события неизвестного туннеля или SPI;
• изменения правил, выполненные во время инцидента;
• время обращения к оператору и применённые им меры.

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

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

Фильтрация только по портам

Нативные GRE, ESP и IP-in-IP не используют внешние TCP/UDP-порты. Правила вида «закрыть все ненужные порты» сами по себе их не блокируют.

Блокировка всего ESP без проверки инфраструктуры

Это может отключить корпоративные VPN. Сначала необходимо определить, используется ли нативный ESP, NAT-T или оба варианта.

Разрешение GRE от любого источника

Для статического туннеля обычно известны обе стороны. Универсальное разрешение protocol 47 расширяет поверхность атаки.

Фильтрация только на сервере

Если внешний канал уже заполнен, локальный firewall не восстановит доступность.

Отсутствие базового профиля

Без нормальных значений pps, bps и списка tunnel peers трудно быстро отличить атаку от планового изменения трафика.

Неограниченное журналирование

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

Игнорирование внутреннего пакета

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

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

• Составлен список всех GRE-, ESP- и IP-in-IP-туннелей.
• Зафиксированы внешние адреса каждой стороны.
• Неиспользуемые номера IP-протоколов запрещены на периметре.
• Статические туннели ограничены allowlist.
• После декапсуляции проверяются внутренние адреса и протоколы.
• Настроены антиспуфинг и ingress filtering.
• Измеряются bps и pps отдельно по IP Protocol.
• Есть алерты на неизвестные GRE/IP-in-IP peers и ESP SPI.
• Ограничено журналирование повторяющихся ошибок.
• Проверена защита control plane маршрутизаторов.
• Учтены накладные расходы туннеля и MTU.
• Согласована схема операторской фильтрации.
• Подготовлен маршрут через scrubbing center.
• Origin сайта закрыт от прямого публичного доступа.
• HTTP/HTTPS опубликован через TrafficVeil.
• Есть контакты оператора и регламент реагирования.
• Регулярно проводятся безопасные нагрузочные проверки.