Атаки ICMP Redirect: отравление маршрутов LAN и защита туннелей VPN

В сегментах локальных сетей Ethernet и Wi-Fi клиентские устройства полагаются на шлюз по умолчанию (default gateway) для отправки пакетов во внешние сети. При штатной работе рабочая станция направляет трафик первичному маршрутизатору, который осуществляет дальнейшую передачу. Однако в базовой спецификации стека IPv4 с 1981 года присутствует вспомогательный протокол управления: Internet Control Message Protocol (ICMP), стандартизированный в документе RFC 792.

Одним из служебных механизмов RFC 792 является сообщение ICMP Redirect (тип 5). Оно разрабатывалось для оптимизации маршрутов, позволяя маршрутизатору уведомить хост о наличии более прямого пути к узлу назначения. Если в пределах общего широковещательного домена находится злоумышленник, данный механизм может быть применен для атаки типа отравления локальной таблицы маршрутизации (ICMP Route Poisoning).

Структура пакета ICMP Type 5 по спецификации RFC 792

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

Двоичная структура кадра ICMP Redirect имеет следующий формат:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type (5)  |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Gateway Internet Address                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Internet Header + 64 bits of Original Data Datagram      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Основные поля сообщения:

Поле Type: Содержит значение 5, обозначающее перенаправление ICMP.
Поле Code: Указывает область действия изменения:
- Code 0: Перенаправление для всей целевой подсети.
- Code 1: Перенаправление для конкретного хоста назначения.
- Code 2: Перенаправление с учетом типа обслуживания (ToS) для сети.
- Code 3: Перенаправление с учетом ToS для отдельного хоста.
Gateway Internet Address: 32-битный IPv4-адрес нового промежуточного шлюза, которому рекомендуется адресовать последующие пакеты.
Полезная нагрузка: Включает исходный заголовок IPv4 и первые 64 бита (8 байт) данных, вызвавших формирование перенаправления.

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

Вектор атаки "человек посередине" в локальной сети

Уязвимость обусловлена полным отсутствием криптографической аутентификации в спецификации RFC 792. Любое устройство в том же канальном сегменте L2 (например, в публичной сети Wi-Fi или сегменте офисного коммутатора без изоляции портов) способно сгенерировать поддельный пакет ICMP Type 5.

Сценарий атаки включает три этапа:

Анализ сетевого трафика: Атакующий перехватывает исходящие кадры жертвы для извлечения адресов активных соединений.
Формирование поддельного пакета: Создается кадр ICMP Type 5 Code 1. В качестве адреса рекомендуемого шлюза указывается IP-адрес атакующего, отправителем указывается реальный шлюз, а в конец добавляются заголовки исходного соединения жертвы.
Внедрение записи в кэш ядра: Операционная система жертвы воспринимает сообщение как достоверную директиву сетевого оборудования и создает в системном кэше временный хостовый маршрут /32, направляя трафик на узел атакующего.

Этап атаки	Действия атакующего	Реакция ядра ОС жертвы	Итоговое состояние
Сбор данных	Перехват исходящей сессии	Обычная передача данных	Выявлены параметры сокета
Инъекция кадра	Отправка пакета ICMP Type 5	Сверка 64-битного фрагмента заголовка	Подтверждено совпадение сессии
Изменение FIB	Подстановка своего адреса шлюза	Установка хостового маршрута `/32`	Маршрут перенаправлен на атакующего
Перехват	Прием исходящего потока жертвы	Ретрансляция трафика реальному шлюзу	Полный контроль над потоком данных

Векторы угроз для виртуальных частных сетей (VPN)

Использование VPN организует виртуальный адаптер (например, tun0 или wg0), инкапсулируя трафик в зашифрованный канал. Тем не менее подделка маршрутов ICMP представляет риски при недостаточной изоляции физических интерфейсов:

1. Перенаправление конечной точки туннеля

Для связи с внешним сервером VPN клиентский узел отправляет UDP-пакеты через физический интерфейс (eth0 или wlan0) на локальный шлюз. Если атакующий внедряет ICMP Redirect для внешнего IP-адреса VPN-сервера, операционная система перенаправляет поток туннеля через узел злоумышленника. Несмотря на стойкость шифрования ChaCha20-Poly1305, перехватчик получает возможность анализировать тайминги, объем передаваемых данных или провоцировать обрыв связи.

2. Утечка данных при раздельном туннелировании

В конфигурациях без жесткой изоляции таблиц маршрутизации добавление маршрута /32 обладает большим приоритетом, чем общие маршруты вроде 0.0.0.0/1. Злоумышленник может точечно перенаправить трафик к критическим сетевым адресам напрямую через локальный интерфейс в открытом виде.

Отключение обработки ICMP Redirect в операционных системах

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

Настройка параметров ядра Linux через Sysctl

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

sysctl -a | grep -E "accept_redirects|send_redirects"

Для блокировки обработки входящих и генерации исходящих перенаправлений создайте файл /etc/sysctl.d/99-disable-icmp-redirects.conf:

# Отключение приема ICMP Redirect для IPv4
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.secure_redirects = 0

# Отключение генерации сообщений ICMP Redirect
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Отключение приема ICMPv6 Redirect (RFC 4861)
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

Применение изменений без перезагрузки:

sudo sysctl --system

Настройка в macOS и операционных системах семейства BSD

В системах BSD и macOS управление выполняется через параметры подсистемы net.inet.icmp:

sudo sysctl -w net.inet.icmp.drop_redirect=1

Конфигурация в ОС Windows

В среде Windows поведение стека TCP/IP задается через системный реестр. Отключение выполняется командой PowerShell с правами администратора:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "EnableICMPRedirect" -Value 0 -Type DWord

Защита сетевого контура с помощью маршрутизации RiceGuard

Для защиты от сетевых аномалий в незащищенных сегментах VPNRice использует архитектуру RiceGuard с политиками маршрутизации Policy-Based Routing (PBR):

Выделенные таблицы маршрутизации и метки пакетов (fwmark): Трафик приложений помечается специальной меткой межсетевого экрана. Системные правила ip rule направляют такие пакеты строго в таблицу 51820, исключая влияние инъекций в основную таблицу маршрутизации.
Фильтрация на физических интерфейсах: Правила nftables блокируют любые входящие пакеты ICMP Type 5 на физических адаптерах до их передачи стеку ядра.
Криптографическая защита от повторов: Механизмы протокола WireGuard Noise IK и 64-битный скользящий счетчик предотвращают манипуляции с зашифрованными пакетами в локальной среде.

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