Уязвимость BGP и анализ трафика: как пентестеру читать аномалии маршрутизации в Wireshark

На аудите провайдерской сети я поймал в tcpdump серию BGP OPEN-сообщений с аномально длинным полем опций. Маршрутизатор FRRouting перезапускался каждые 4 минуты, а инженеры списывали это на «нестабильный линк к аплинку». Проблемой оказалась CVE-2022-40318 — out-of-bounds read через специально сформированный пакет. Логи bgpd показывали только «assertion failure», без контекста. Без вскрытия дампа трафика причина осталась бы загадкой на недели.

Здесь не пересказ RFC и не обзор «топ-5 атак на маршрутизацию». Разбираю конкретный подход: как пентестеру, который впервые работает с маршрутизацией, читать аномалии BGP прямо из захвата трафика и понимать, что перед ним — легитимный флап или попытка перехвата.

Что видно в Wireshark при нормальной BGP-сессии

Прежде чем искать аномалии, стоит разобраться, как выглядит здоровый BGP-трафик. BGP (Border Gateway Protocol) — протокол, по которому автономные системы обмениваются маршрутами в интернете. AS (Autonomous System) — сеть под управлением одной организации: провайдер, дата-центр, университет. Если совсем просто: BGP — система договорённостей между «почтовыми отделениями», которые решают, кто кому передаёт «письма» (пакеты данных) и каким путём.

BGP работает поверх TCP на порту 179. Перед обменом маршрутами между двумя маршрутизаторами устанавливается обычное TCP-соединение (SYN → SYN-ACK → ACK), и только потом начинается BGP-диалог.

Нормальная BGP-сессия в Wireshark содержит четыре типа сообщений:

• BGP OPEN — каждая сторона отправляет версию протокола (всегда 4), номер своей AS, Hold Time (максимальное время ожидания между сообщениями — обычно 90 или 180 секунд) и Router ID
• BGP KEEPALIVE — короткие сообщения по 19 байт каждые 30–60 секунд, подтверждение что сессия жива
• BGP UPDATE — маршрутная информация: какие IP-префиксы доступны через эту AS с каким путём (AS_PATH — последовательность AS, через которые прошёл анонс)
• BGP NOTIFICATION — сообщение об ошибке, после которого сессия закрывается

Зачем это знать: когда в дампе появляется что-то за пределами этой последовательности — лишние NOTIFICATION, нетипичные размеры OPEN, UPDATE с чужими префиксами — это сигнал копать дальше.

Захват BGP-трафика запускается одной командой на маршрутизаторе или зеркальном порту (SPAN): tcpdump -i eth0 -w bgp_capture.pcap 'tcp port 179'. Фильтруем только TCP-трафик на порту 179 и сохраняем результат в файл для разбора в Wireshark.

Атака на маршрутизацию BGP: анатомия CVE-2022-40318 и CVE-2022-43681

FRRouting (FRR) — открытая реализация BGP-маршрутизатора для Linux. Стоит в сотнях дата-центров, включая российские. В FRR обнаружены две уязвимости, которые обнаруживаются именно через анализ трафика. Обе связаны с некорректной обработкой BGP OPEN.

CVE-2022-40318: чтение за пределами буфера

При обработке BGP OPEN с опцией типа 0xff (Extended Length из RFC 9072) демон bgpd читает 3 байта вместо ожидаемых 2, выходит за границы буфера пакета и падает с SIGABRT. Результат — перезапуск демона и разрыв всех BGP-сессий.

CVSS (стандартная шкала оценки критичности уязвимостей, диапазон от 0 до 10): 6.5 (MEDIUM). Вектор CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H — если встречаете эту запись впервые, вот расшифровка:

CWE-125 (Out-of-bounds Read) — тип программной ошибки: чтение за пределами выделенного буфера. Проблема в функции bgp_open_option_parse файла bgp_open.c.

Затронутые версии: FRRouting до 8.4 включительно. Red Hat выпустил исправление в пакете frr-0:8.3.1-11.el9_3 для RHEL 9 (RHSA-2023:6434). RHEL 8 не затронут.

CVE-2022-43681: out-of-bounds read при обрыве OPEN

Если BGP OPEN обрывается ровно на байте длины опции (или на слове длины в extended OPEN), FRR читает за пределами пакета, получает SIGABRT и перезапускается. Результат тот же — Denial of Service.

CVSS: 6.5 (MEDIUM), вектор идентичен CVE-2022-40318. CWE-125. Те же версии FRR, то же исправление.

EPSS (Exploit Prediction Scoring System) — оценка от 0 до 1, показывающая вероятность эксплуатации уязвимости в ближайшие 30 дней. CVE-2022-40318 = 0.0198 (перцентиль 80.89%), CVE-2022-43681 = 0.0213 (перцентиль 82.20%). Оба значения выше медианы, но активная эксплуатация в дикой природе не зафиксирована. CISA (Агентство по кибербезопасности США) присвоило родственной CVE-2022-40302 решение SSVC «Track» — мониторить, но не патчить экстренно.

Бизнес-логика атаки

Зачем это атакующему. Имея BGP-пиринг (или скомпрометировав маршрутизатор с пирингом), он отправляет специально сформированный OPEN и роняет bgpd на целевом маршрутизаторе. Все маршруты через эту AS исчезают из таблиц соседей. Трафик перенаправляется по альтернативным путям — возможно, через AS, контролируемую атакующим.

В терминах MITRE ATT&CK (открытая база тактик и техник атак; T-коды вроде T1498 — её идентификаторы): это Network Denial of Service (T1498, тактика Impact) с потенциальным переходом в Adversary-in-the-Middle (T1557, тактики Credential Access и Collection). Сначала ломаем маршрутизацию — потом ловим трафик, который пошёл «в обход».

Пентест сетевой инфраструктуры BGP: лаборатория на FRRouting

Чтобы увидеть эти уязвимости своими глазами и научиться распознавать аномалии, нужна лаборатория. Предпосылки: Linux-машина (Kali, Ubuntu, Debian) с минимум 2 ГБ RAM, правами root и установленным FRRouting версии 8.4 или ниже (уязвимая — только для лабораторных целей). Wireshark или tshark для анализа.

Делай раз: два виртуальных маршрутизатора

Создаём два network namespace — изолированные сетевые пространства в Linux — и связываем их виртуальным линком. Каждый namespace ведёт себя как отдельный маршрутизатор.

# Создаём два namespace — два "маршрутизатора"
ip netns add router1
ip netns add router2
# Виртуальная линковая пара
ip link add veth1 type veth peer name veth2
ip link set veth1 netns router1
ip link set veth2 netns router2
# IP-адреса и поднятие интерфейсов
ip netns exec router1 ip addr add 10.0.0.1/30 dev veth1
ip netns exec router2 ip addr add 10.0.0.2/30 dev veth2
ip netns exec router1 ip link set veth1 up
ip netns exec router2 ip link set veth2 up

Ожидаемый результат: команда ip netns exec router1 ping 10.0.0.2 показывает ответы — маршрутизаторы видят друг друга. Если пинг не проходит — проверьте, что интерфейс loopback поднят в каждом namespace (ip link set lo up).

Делай два: BGP-пиринг

В каждом namespace запускаем FRRouting с конфигурацией BGP. Конфигурация router1 (AS 65001 — номер из приватного диапазона 64512–65534, который используют в лабораториях):

router bgp 65001
 neighbor 10.0.0.2 remote-as 65002
 network 192.168.1.0/24

Для router2 — зеркально: AS 65002, neighbor 10.0.0.1 remote-as 65001, network 192.168.2.0/24. После запуска bgpd в обоих namespace команда vtysh -c "show bgp summary" в router1 должна показать соседа 10.0.0.2 в состоянии Established. Видите Idle или Active — проверьте, что TCP 179 не блокируется и remote-as совпадает с реальным номером AS соседа.

Делай три: захват и разбор трафика

Запускаем захват до установления сессии: ip netns exec router1 tcpdump -i veth1 -w /tmp/bgp_lab.pcap 'tcp port 179'. Ждём 2–3 минуты, останавливаем (Ctrl+C), открываем файл в Wireshark.

Что проверяем:

• Фильтр bgp — все BGP-сообщения. Должны быть видны OPEN от обеих сторон, серия KEEPALIVE, один или несколько UPDATE
• Фильтр bgp.type == 1 — только OPEN. Смотрим Hold Time, AS Number, Optional Parameters Length
• Фильтр bgp.type == 2 — UPDATE с маршрутной информацией. В Withdrawn Routes Length должен быть 0 (никто ничего не отзывает), в NLRI — анонсируемые prefix
• Фильтр bgp.type == 3 — NOTIFICATION. В здоровой сессии их быть не должно. Появление NOTIFICATION — первый признак проблемы

Если всё сделано верно, дамп содержит чистую последовательность: TCP handshake → OPEN → KEEPALIVE → UPDATE → периодические KEEPALIVE. Это ваш baseline — нормальный BGP-трафик, от которого вы будете отталкиваться при поиске аномалий.

Анализ аномалий BGP трафика: что именно искать в дампе

BGP hijacking обнаружение в UPDATE-сообщениях

BGP hijacking (перехват маршрутов) — ситуация, когда чужая AS анонсирует ваши IP-префиксы как свои. Согласно исследованию Scott et al. (2024, PMC), атаки на префиксы делятся на три категории:

• Prefix hijacking — атакующий анонсирует тот же prefix, что и легитимный владелец
• Subprefix hijacking — атакующий анонсирует более узкий prefix (192.168.1.0/25 против 192.168.1.0/24). BGP предпочитает длинную маску, и трафик уходит к атакующему. Это самый частый вариант, потому что его сложнее отфильтровать автоматически
• AS Path Forgery — подделка AS_PATH, чтобы маршрут казался короче и предпочтительнее

Признаки в Wireshark:

Признаки эксплуатации CVE-2022-40318 и CVE-2022-43681

Конкретные паттерны в дампе при эксплуатации этих уязвимостей:

1. BGP OPEN с option type 0xff — Extended Length из RFC 9072. В легитимном трафике встречается редко. OPEN с 0xff от пира, который раньше слал обычные OPEN — повод разбираться
2. Обрезанный OPEN — сообщение обрывается на байте длины опции. Wireshark пометит такой пакет как [Malformed Packet]
3. Серия TCP RST после OPEN — bgpd упал (SIGABRT), TCP-соединение сбросилось. Через секунды — новый SYN (демон перезапустился)
4. Цикл OPEN → RST → SYN → OPEN → RST — повторяющийся паттерн persistent DoS. Именно его я видел на том провайдерском аудите

Wireshark-фильтр для обнаружения: bgp.type == 1 && frame.len < 29 отсечёт подозрительно короткие OPEN (нормальный OPEN — минимум 29 байт). Комбинация с tcp.flags.reset == 1 в соседних пакетах подтвердит падение демона.

Route leak против hijack: различия в дампе

Route leak (утечка маршрутов) — AS передаёт маршруты не тому соседу. В отличие от hijacking, leak обычно непреднамерен, но последствия сопоставимы.

Как различить: при hijack AS_PATH содержит неавторизованную AS в origin, маршрут появляется внезапно. При route leak AS_PATH выглядит валидно, origin AS правильная, но маршрут приходит от пира, от которого его не ожидают.

Верификация через внешние коллекторы — RIPE RIS и RouteViews (публичные сервисы, собирающие BGP-анонсы со всего мира): если ваш prefix виден от AS, с которой нет отношений — это leak или hijack. Leak обычно длится минуты и исчезает после правки конфигурации; hijack может быть устойчивым.

Эксплуатация уязвимостей BGP: привязка к MITRE ATT&CK

Привязка техник к MITRE ATT&CK превращает абстрактное «BGP плохо настроен» в конкретное описание вектора атаки для отчёта. Без этой привязки заказчик видит «проблему с маршрутизацией», с ней — цепочку атаки с тактиками и техниками, которую можно приоритизировать.

Чеклист аудита BGP-инфраструктуры

Согласно RFC 4272 (BGP Security Vulnerabilities Analysis, Murphy, 2006), основные защитные меры: RPKI/ROV (Resource Public Key Infrastructure — криптографическая проверка того, что AS имеет право анонсировать данный prefix), строгие prefix-фильтры на каждом пиринге, max-prefix limit и актуальные данные в IRR (Internet Routing Registry). Для CVE-2022-40318 и CVE-2022-43681 — обновление FRR до версии 8.4.1+ или установка пакета frr-0:8.3.1-11.el9_3 на RHEL 9.

На бумаге всё логично, но отработать весь цикл — от захвата дампа до написания рекомендаций — по-настоящему получается только на стенде. Если хочется потренироваться на задачах с сетевой инфраструктурой, на HackerLab.pro есть категория network — российская CTF-платформа с 12 категориями, нужна регистрация, после неё доступны таски всех уровней.

За три года аудитов провайдерских сетей я пришёл к неудобному наблюдению: подавляющее большинство инженеров, ежедневно работающих с BGP, ни разу не открывали Wireshark на порту 179. Они мониторят сессии через show bgp summary, видят Established — и считают, что всё в порядке. Malformed OPEN, который роняет bgpd раз в час, проходит мимо: демон рестартует за секунды, сессия восстанавливается, мониторинг фиксирует только кратковременный flap. Без захвата трафика такой DoS невидим неделями.

Русскоязычные материалы по BGP-безопасности застряли на уровне академических статей 2018 года — общие слова про RPKI и ни одного скриншота из Wireshark. Англоязычные источники уходят в другую крайность — PMC-обзоры на 24 000 слов с классификацией 178 методов детектирования, но без единой команды tcpdump.

BGP не сменят в ближайшие 10 лет, несмотря на проекты вроде SCION. FRRouting стоит в сотнях дата-центров, включая российские. Если ваш провайдер использует FRR версии 8.3 без патча RHSA-2023:6434, он уязвим прямо сейчас — и не потому что не хочет обновиться, а потому что обновление BGP-маршрутизатора — это planned downtime для всех клиентов.

Навык читать BGP-аномалии из дампа — не нишевая экзотика, а базовый инструмент сетевого пентестера. Поднимите лабораторию из раздела 3, поймайте свой первый OPEN в Wireshark и попробуйте отличить штатный от malformed. Если вы в начале пути в инфраструктурной безопасности — IB Basics на codeby.school закрывает фундамент, после которого работа с протоколами вроде BGP приходит быстрее, чем кажется.