Угон префикса: BGP, утечки и обход RPKI

BGP — единственный протокол, который связывает независимые сети в Интернет ⁷. Он не вычисляет кратчайший путь и не знает о загрузке каналов: он распространяет объявления о том, какие префиксы доступны через какую автономную систему. Доверие здесь не между людьми, а между операторами: если сеть объявила префикс, остальные сети обязаны рассмотреть это объявление.

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

Тема 10 основной программы разбирала BGP как протокол: сессии, атрибуты, политики, выбор маршрута. Здесь те же механизмы рассматриваются со стороны доверия и проверяемости: что именно проверяется, чего не хватает и какие фильтры работают. Границы: IGP и внутренняя маршрутизация — тема 09 основной программы.

Тень базового курса: объявление как факт

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

Это свойство — не дефект, а основа масштабирования. В Интернете нет единого реестра, которому все доверяют; есть реестры (RIR, IRR) и подпись происхождения (RPKI), но их поддержка добровольна. Поэтому BGP по умолчанию доверяет соседу, а сосед — своему соседу.

Атака начинается там, где это доверие пересекает границу организации. Угон префикса — не взлом, а ложное объявление; утечка — не атака, а ошибка политики, которая распространяется по цепочке.

Как устроена сессия и маршрут

Конечный автомат и сообщения

Сессия BGP устанавливается по TCP/179 и проходит состояния Idle, Connect, Active, OpenSent, OpenConfirm, Established ¹. В Established стороны обмениваются сообщениями KEEPALIVE, UPDATE и NOTIFICATION.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast"

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
192.0.2.1       4      64500      1024      1030        0    0    0 01:12:44          12
198.51.100.1    4      64501       980       990        0    0    0 00:58:12           8

State/PfxRcd показывает число полученных префиксов; если там Active или Idle, сессия не установлена. Up/Down — время в текущем состоянии.

UPDATE содержит withdrawn-маршруты, атрибуты и NLRI. Главные атрибуты: AS_PATH (список пройденных AS), NEXT_HOP, LOCAL_PREF, MED, COMMUNITY. Выбор маршрута идёт по порядку: наибольший LOCAL_PREF, кратчайший AS_PATH, наименьший origin, наименьший MED, eBGP предпочтительнее iBGP, наименьший IGP-метрик, старейший маршрут, наименьший router ID.

Политики импорта и экспорта

Политика — это фильтр и набор действий. На импорте отбрасываются нежелательные префиксы и меняются атрибуты; на экспорте — что и с какими атрибутами объявлять.

router bgp 64500
 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.1 route-map FROM-ISP in
 neighbor 198.51.100.1 route-map TO-ISP out
!
ip prefix-list OUR-NETS seq 10 permit 203.0.113.0/24
!
route-map TO-ISP permit 10
 match ip address prefix-list OUR-NETS
!
route-map FROM-ISP permit 10
 set local-preference 200

Здесь TO-ISP разрешает объявлять только свой префикс, а FROM-ISP повышает приоритет маршрутов от этого провайдера. Практические требования к таким фильтрам собраны в RFC 7454 ⁴. Без первого фильтра сеть может объявить всё, что знает.

Угон префикса

More-specific и subprefix hijack

Самый простой угон — объявить более специфичный префикс: если жертва объявляет 203.0.113.0/24, атакующий объявляет 203.0.113.128/25. Правило longest prefix match отправит половину адресов атакующему, и трафик пойдёт через него.

router bgp 64502
 network 203.0.113.128/25
 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.1 route-map HIJACK out
!
route-map HIJACK permit 10

Более сложный вариант — объявить тот же /24, но с лучшим AS_PATH (короче или с поддельным origin). Тогда выбор маршрута может уйти к атакующему даже без more-specific.

Anycast и route reflector

Anycast объявляет один и тот же префикс из нескольких точек; трафик идёт в ближайшую. Угон anycast-префикса перенаправляет пользователей в точку атакующего, и обнаружить это сложно, потому что «ближайшая» точка формально легитимна.

Route reflector пересылает маршруты внутри AS. Если он скомпрометирован или настроен без фильтров, он распространяет неверные маршруты на всех клиентов. Отравление RR — атака на доверие внутри автономной системы, а не между ними.

Утечки и valley-free

Route leak

Утечка — объявление маршрутов, полученных от одного провайдера, другому. Если сеть C получает маршрут от A и объявляет его B, трафик B может пойти через C, хотя у C нет на это права. Последствия — перегрузка, асимметрия, потеря связности.

Правило valley-free описывает допустимые отношения: клиент — провайдер, пиринг, провайдер — клиент. Маршрут не должен проходить из «долины» обратно в «гору» через пиринг. Утечка нарушает это правило и распространяется быстро, потому что BGP не имеет механизма «отозвать чужую ошибку».

Подмена AS_PATH и origin

AS_PATH можно дополнить (prepend), чтобы удлинить путь и сделать маршрут менее предпочтительным. Это штатный инструмент. Подделка origin — объявление префикса с чужим номером AS в конце пути; конструкции с AS_SET, которые раньше это упрощали, сегодня не рекомендуются ⁶ — обходит фильтры, которые проверяют только длину пути.

Атаки на сессию

TCP MD5, GTSM и RST-инъекция

BGP-сессия — это TCP-соединение, и к ней применимы атаки на TCP. Историческая RST-инъекция 2004 года обрывала сессии, подделывая RST с угаданным номером последовательности.

Защита: TCP MD5 (RFC 2385), TTL security (GTSM, RFC 5082) и BGPsec для подписи атрибутов. MD5 защищает от подделки сегментов, но не от слабых паролей; GTSM проверяет, что TTL равен 255, и отбрасывает пакеты, пришедшие издалека.

neighbor 198.51.100.1 password s3cret
neighbor 198.51.100.1 ttl-security hops 1

RPKI и ROV

ROA и валидатор

RPKI — инфраструктура открытых ключей для префиксов ². Владелец префикса выпускает ROA (Route Origin Authorization): какой AS имеет право объявлять префикс ⁵. Валидатор собирает ROA и отдаёт маршрутизатору статус: valid, invalid, notfound.

routinator --http 127.0.0.1:8323
vtysh -c "show bgp ipv4 unicast 203.0.113.0/24"

Маршрут со статусом invalid должен отбрасываться (ROV, RFC 6811) ³. Проблема в том, что notfound — это большинство: ROA выпущены не для всех префиксов, и политика «отбрасывать всё, что не valid» ломает связность.

Почему подделка проходит

ROV проверяет только origin: совпадает ли AS, объявившая префикс, с той, что указана в ROA. Если атакующий объявляет префикс от имени правильной AS (подделав origin в AS_PATH), проверка проходит. Если префикс не имеет ROA, проверка бессильна.

ASPA (Autonomous System Provider Authorization) — следующий шаг: подпись того, какие провайдеры могут объявлять маршруты через данную AS. На момент написания ASPA разворачивается частично, и полной защиты от утечек нет.

Числа: таблица, сходимость и цена ошибки

Полная таблица IPv4 в 2024 году содержит около миллиона префиксов. Каждый маршрут занимает память в FIB и TCAM; на бюджетном оборудовании переполнение TCAM приводит к тому, что часть маршрутов уходит в медленный путь или отбрасывается.

Сходимость после изменения анонса занимает секунды: BGP рассылает UPDATE, соседи применяют политику, FIB пересчитывается. Для угонщика это окно, в котором трафик уже пошёл по новому пути, а защита ещё не среагировала.

maximum-prefix задаёт порог по числу маршрутов. Если провайдер обычно получает 800 префиксов от клиента, порог 1000 оставляет запас и при этом ловит утечку, которая добавляет десятки тысяч. Слишком низкий порог рвёт сессию при легитимном росте; слишком высокий пропускает утечку.

router bgp 64500
 neighbor 198.51.100.1 maximum-prefix 1000 80

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

Обнаружение и защита

neighbor 198.51.100.1 maximum-prefix 1000 80
neighbor 198.51.100.1 prefix-list ISP-IN in

maximum-prefix ограничивает число принимаемых маршрутов и защищает от утечки, которая раздувает таблицу. Порог подбирается по базовой линии: 1000 префиксов от одного провайдера — норма для одного, катастрофа для другого.

Итоги темы

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

RPKI и ROV закрывают часть проблемы: они проверяют origin, но не путь и не право объявлять. ASPA и BGPsec дополняют картину, но развёрнуты не полностью. Поэтому защита строится на нескольких слоях: фильтры префиксов, max-prefix, MD5 и GTSM, мониторинг и детекторы аномалий.

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

Литература

1. Rekhter Y., Li T., Hares S. A Border Gateway Protocol 4 (BGP-4). — RFC 4271, IETF, 2006. https://www.rfc-editor.org/rfc/rfc4271
2. Lepinski M., Kent S. An Infrastructure to Support Secure Internet Routing. — RFC 6480, IETF, 2012. https://www.rfc-editor.org/rfc/rfc6480
3. Mohapatra P., Scudder J., Ward D., Bush R., Austein R. BGP Prefix Origin Validation. — RFC 6811, IETF, 2013. https://www.rfc-editor.org/rfc/rfc6811
4. Durand J., Pepelnjak I., Doering G. BGP Operations and Security. — RFC 7454, IETF, 2015. https://www.rfc-editor.org/rfc/rfc7454
5. Huston G., Michaelson G., Loomans R. A Profile for Route Origin Authorizations (ROAs). — RFC 6482, IETF, 2012. https://www.rfc-editor.org/rfc/rfc6482
6. Kumari W., Sriram K. Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP. — RFC 6472, IETF, 2012. https://www.rfc-editor.org/rfc/rfc6472
7. Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.

Дополнительные материалы

Вопросы для самопроверки

1. Почему BGP называют протоколом доверия, а не протоколом маршрутизации?
2. Какие атрибуты UPDATE влияют на выбор маршрута и в каком порядке?
3. Чем угон более специфичным префиксом отличается от подмены origin?
4. Почему утечка маршрутов может возникнуть без злого умысла?
5. Что означает правило valley-free и кто его нарушает?
6. Почему route reflector — удобная цель для отравления?
7. Что проверяет RPKI и чего он не проверяет?
8. Почему политика «отбрасывать всё, что не valid» опасна?
9. Что такое ASPA и какую проблему он решает?
10. Зачем нужен GTSM, если уже есть MD5?
11. Почему BGPsec не развёрнут повсеместно?
12. Какие метрики мониторинга первыми указывают на угон?

Глоссарий темы

AS — автономная система, набор сетей под единым управлением.

AS_PATH — список AS, через которые прошёл маршрут.

NLRI — Network Layer Reachability Information, объявляемые префиксы.

LOCAL_PREF — атрибут предпочтения внутри AS.

MED — атрибут подсказки для выбора входа в AS.

Route leak — объявление маршрутов в обход политики.

ROA — Route Origin Authorization, подписанное разрешение на объявление префикса.

ROV — Route Origin Validation, проверка объявления по ROA.

RPKI — инфраструктура открытых ключей для маршрутизации.

ASPA — Autonomous System Provider Authorization.

Шпаргалка по инструментам

Что почитать и посмотреть

• RFC 4271 — BGP-4: сообщения, атрибуты, конечный автомат.
• RFC 6480 — архитектура RPKI: что подписывается и кем.
• RFC 6811 — ROV: как маршрутизатор применяет результат проверки.
• RFC 7454 — операционные практики безопасности BGP: фильтры, лимиты, MD5.
• RFC 6482 — формат ROA: какие поля проверяются.
• Kurose, Ross — глава о междоменной маршрутизации: экономика и политика.

Углубление

Инцидент 2008 года. Pakistan Telecom объявила более специфичный префикс YouTube, и трафик ушёл в Пакистан. Это классический пример: ошибка конфигурации, а не атака, но последствия глобальные.

Мониторинг. Проекты вроде BGPStream и RIPE RIS собирают обновления от множества коллекторов. Детектор угона ищет новый origin для известного префикса или появление more-specific, которого раньше не было.

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

RPKI и приватность. ROA раскрывают связь префиксов и AS; это публичные данные, но они позволяют точнее картировать инфраструктуру. Поэтому RPKI полезен и защитникам, и разведке.

Лабораторная работа 7. Угон префикса

• Раздел курса: апокриф 7 «Угон префикса: BGP, утечки и обход RPKI»

Введение

Работа собирает четыре автономные системы: два провайдера, клиента с двумя апстримами и пиринг между провайдерами. На этой топологии проверяются три сценария: угон более специфичным анонсом, утечка маршрутов и защита фильтрами. Каждый сценарий наблюдается с двух сторон — что видит жертва и что видит защитник.

Топология поднимается в Containerlab с FRRouting. Если Containerlab недоступен, та же схема собирается в пространствах имён с vtysh в каждом узле; команды FRR не меняются.

Цель работы

После выполнения работы получится:

• поднять четыре AS с eBGP-сессиями и проверить обмен префиксами;
• разобрать show bgp по атрибутам и объяснить выбор маршрута;
• выполнить угон префикса более специфичным анонсом и увидеть смену пути;
• смоделировать утечку маршрутов и объяснить, почему она распространяется;
• настроить prefix-list и max-prefix и проверить, что атака ломается;
• проверить ROA для реального префикса через RIPEstat и объяснить статус;
• защитить сессию MD5 и GTSM и проверить, что RST-инъекция не проходит;
• найти и исправить ошибку в конфигурации фильтра.

Теоретический минимум

Разделы теории «Как устроена сессия и маршрут», «Угон префикса», «Утечки и valley-free», «RPKI и ROV».

Перечень оснащения

Уровень воспроизводимости: 2 — Containerlab и FRRouting.

Linux с Docker, Containerlab, образом FRRouting (frrouting/frr), traceroute, curl. Для части с RPKI — routinator (опционально). Если Docker недоступен, используется сценарий с пространствами имён и статически собранным FRR.

Порядок выполнения работы

sudo containerlab deploy -t bgp.clab.yml

Пример описания топологии:

name: bgp-lab
topology:
  nodes:
    isp-a:
      kind: linux
      image: frrouting/frr:latest
      exec:
        - sysctl -w net.ipv4.ip_forward=1
        - ip link add dummy0 type dummy
        - ip link set dummy0 up
        - ip addr add 192.0.2.1/30 dev eth1
        - ip addr add 198.51.100.1/30 dev eth2
    isp-b:
      kind: linux
      image: frrouting/frr:latest
      exec:
        - sysctl -w net.ipv4.ip_forward=1
        - ip link add dummy0 type dummy
        - ip link set dummy0 up
        - ip addr add 192.0.2.5/30 dev eth1
        - ip addr add 198.51.100.5/30 dev eth2
    client:
      kind: linux
      image: frrouting/frr:latest
      exec:
        - sysctl -w net.ipv4.ip_forward=1
        - ip link add dummy0 type dummy
        - ip link set dummy0 up
        - ip addr add 203.0.113.2/24 dev dummy0
        - ip addr add 192.0.2.2/30 dev eth1
        - ip addr add 192.0.2.6/30 dev eth2
    attacker:
      kind: linux
      image: frrouting/frr:latest
      exec:
        - ip link add dummy0 type dummy
        - ip link set dummy0 up
        - ip addr add 203.0.113.130/25 dev dummy0
        - ip addr add 198.51.100.2/30 dev eth1
        - ip addr add 198.51.100.6/30 dev eth2
  links:
    - endpoints: ["isp-a:eth1", "client:eth1"]
    - endpoints: ["isp-b:eth1", "client:eth2"]
    - endpoints: ["isp-a:eth2", "attacker:eth1"]
    - endpoints: ["isp-b:eth2", "attacker:eth2"]

Адреса на dummy0 нужны не для связности, а для BGP: команда network объявляет только тот префикс, который уже есть в таблице маршрутизации с точным совпадением длины. Без подключённого 203.0.113.0/24 на клиенте анонс молча не появится — это первая типовая ошибка лаборатории.

Часть 1. Сессии и таблица

Задание

Настроить BGP: client — AS 64500, isp-a — AS 64501, isp-b — AS 64502, attacker — AS 64503. Клиент объявляет 203.0.113.0/24, провайдеры — свои подключённые префиксы /30. Конфигурация вводится в vtysh внутри контейнера и живёт до перезапуска: docker exec -it clab-bgp-lab-client vtysh.

! client
router bgp 64500
 neighbor 192.0.2.1 remote-as 64501
 neighbor 192.0.2.5 remote-as 64502
 network 203.0.113.0/24

! isp-a
router bgp 64501
 neighbor 192.0.2.2 remote-as 64500
 neighbor 198.51.100.2 remote-as 64503
 network 192.0.2.0/30

! isp-b
router bgp 64502
 neighbor 192.0.2.6 remote-as 64500
 network 192.0.2.4/30

Проверить:

docker exec -it clab-bgp-lab-client vtysh -c "show bgp summary"
docker exec -it clab-bgp-lab-client vtysh -c "show bgp ipv4 unicast"
docker exec -it clab-bgp-lab-client vtysh -c "show bgp ipv4 unicast 203.0.113.0/24"

Что должно получиться

Все сессии в состоянии Established. У клиента 203.0.113.0/24 виден как локальный маршрут (next hop 0.0.0.0, пустой AS_PATH), у провайдеров — выученный от клиента с AS_PATH 64500; провайдеры обмениваются подключёнными /30. Разобрать по show bgp атрибуты: AS_PATH, NEXT_HOP, LOCAL_PREF, origin. Объяснить, почему клиент не получает собственный префикс обратно и что изменилось бы при наличии второго origin.

Часть 2. Угон более специфичным анонсом

Задание

На attacker объявить 203.0.113.128/25 и проверить, куда пойдёт трафик:

router bgp 64503
 network 203.0.113.128/25
 neighbor 198.51.100.1 remote-as 64501

docker exec -it clab-bgp-lab-isp-a vtysh -c "show bgp ipv4 unicast 203.0.113.128/25"
docker exec -it clab-bgp-lab-isp-a vtysh -c "show ip route 203.0.113.128"

Что должно получиться

Маршрут /25 идёт через attacker, маршрут /24 — через клиента. Половина адресов ушла атакующему. Объяснить, почему longest prefix match важнее длины AS_PATH.

Часть 3. Утечка маршрутов

Задание

attacker подключён к обоим провайдерам. Он узнаёт клиентский префикс от isp-a и объявляет его обратно isp-b, хотя не является транзитной AS. Это имитируется разрешением экспорта всего:

route-map LEAK permit 10
!
router bgp 64503
 neighbor 198.51.100.1 remote-as 64501
 neighbor 198.51.100.5 remote-as 64502
 neighbor 198.51.100.5 route-map LEAK out

Проверить таблицу на isp-b и путь:

docker exec -it clab-bgp-lab-isp-b vtysh -c "show bgp ipv4 unicast"
docker exec -it clab-bgp-lab-isp-b vtysh -c "show ip route 203.0.113.0/24"

Что должно получиться

У isp-b появился маршрут 203.0.113.0/24 через attacker с AS_PATH 64503 64501 64500, хотя клиент к isp-b отношения не имеет. Это утечка: attacker передал маршрут, полученный от одного провайдера, другому. Правило valley-free запрещает передавать маршрут от провайдера провайдеру, если AS не является транзитной; фильтры на isp-a и isp-b должны её остановить.

Часть 4. Фильтры префиксов и max-prefix

Задание

На isp-a разрешить от клиента только его префикс и ограничить число маршрутов:

ip prefix-list CLIENT-IN seq 10 permit 203.0.113.0/24
neighbor 192.0.2.2 prefix-list CLIENT-IN in
neighbor 192.0.2.2 maximum-prefix 10

На client — объявлять только свой префикс:

ip prefix-list OUR-NETS seq 10 permit 203.0.113.0/24
neighbor 192.0.2.1 prefix-list OUR-NETS out

Повторить части 2–3 и проверить, что анонсы не проходят.

Что должно получиться

Угон и утечка не работают: фильтр отбрасывает чужие префиксы, max-prefix ограничивает объём. Записать, что именно отброшено и в каком журнале это видно.

Часть 5. RPKI и ROV

Задание

Проверить ROA для реального префикса и настроить валидатор:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS15169&prefix=8.8.8.0/24"
routinator --http 127.0.0.1:8323 &

В FRR включить проверку:

rpki
 rpki cache 127.0.0.1 3323
!
router bgp 64501
 bgp bestpath prefix-validate

Что должно получиться

Маршрут с корректным origin получает статус valid; поддельный origin — invalid и отбрасывается. Объяснить, почему notfound не отбрасывается и что это значит для сети без ROA.

Часть 6. Защита сессии

Задание

Включить MD5 и GTSM на сессии между client и isp-a:

neighbor 192.0.2.1 password s3cret
neighbor 192.0.2.1 ttl-security hops 1

Попробовать оборвать сессию поддельным RST с attacker, зная номер последовательности из захвата:

docker exec -it clab-bgp-lab-attacker tshark -i eth1 -f "tcp port 179" -w bgp.pcap &

Что должно получиться

Без MD5 RST обрывает сессию; с MD5 поддельный сегмент отбрасывается, сессия сохраняется. Объяснить, что MD5 защищает и чего он не защищает.

Часть 7. Найти и исправить ошибку

Задание

Фильтр должен пропускать только префикс клиента, но пропускает всё:

ip prefix-list CLIENT-IN seq 10 permit 0.0.0.0/0
neighbor 192.0.2.2 prefix-list CLIENT-IN in

Найти ошибку и исправить: 0.0.0.0/0 разрешает любой префикс. Заменить на конкретный и добавить deny в конце, объяснив, как работает неявный deny.

Что должно получиться

Работающий фильтр, который пропускает 203.0.113.0/24 и отбрасывает остальное; проверка на попытке объявить чужой префикс.

Журнал работы

Контрольные вопросы

1. Почему BGP доверяет объявлению и что могло бы это изменить?
2. Как выбирается лучший маршрут и где в этом порядке находится длина AS_PATH?
3. Почему more-specific угон работает даже при более длинном AS_PATH?
4. Чем утечка отличается от угона по намерению и по последствиям?
5. Что такое valley-free и какое отношение нарушает утечка?
6. Почему RPKI проверяет origin, но не путь?
7. Что означает статус notfound и почему его не отбрасывают?
8. Как max-prefix защищает от утечки и что он ломает при ошибке порога?
9. Что защищает MD5 и почему он не заменяет BGPsec?
10. Зачем нужен GTSM и как он связан с TTL?
11. Почему anycast-угон сложнее обнаружить, чем обычный?
12. Какие признаки утечки видны в мониторинге BGP?

Уборка

sudo containerlab destroy -t bgp.clab.yml
pkill routinator
rm -f bgp.pcap