Как защитить BGP от угонов маршрутов: внедрение проверки первого AS в AS_PATH

Недавние перехваты маршрутов, о которых сообщил Spamhaus, привлекли наше внимание. Во многих из этих попыток перехвата, очевидно, злоумышленник воспользовался неиспользуемыми номерами автономных систем (ASN). Примечательно, что в этих перехватах злоумышленник, похоже, создает поддельные AS_PATH к пунктам назначения, направляя трафик по неожиданному пути.

Создавая поддельные AS_PATH, злоумышленник пытается направить трафик туда, куда он обычно не должен идти, а также скрыть свою личность. Злоумышленник может удалить достаточно информации из сетевого пути, чтобы выдать себя за источник префикса Border Gateway Protocol (BGP). Атакующие могут использовать этот перехваченный маршрут для перехвата трафика и в других злонамеренных целях.

Для этих случаев есть простое решение: базовая проверка того, что одноранговая автономная система (AS) BGP всегда включает свою сеть как «Первую AS» в объявленном маршруте. Чтобы понять, насколько хорошо реализованы эти меры защиты, мы провели стресс-тест нескольких крупных сетей и изучили их BGP-реализации. Читайте дальше, чтобы узнать, что мы выяснили.

Идея о том, что злоумышленник создает поддельные AS_PATH, подтверждается, если мы внимательнее посмотрим на неправдоподобные отношения между AS в пути. Например, давайте рассмотрим один из перехватов, о которых сообщил Spamhaus, связанный с префиксом, принадлежащим Orange S.A., французской телекоммуникационной компании. Используя инструмент monocle, мы можем легко найти BGP UPDATE сообщение, связанное с перехватом:

➜  ~ monocle search --start-ts 2026-04-13T00:20:00Z --end-ts 2026-04-13T00:23:59Z --prefix 90.98.0.0/15 --collector rrc26 --json
{
  "aggr_asn": null,
  "aggr_ip": null,
  "as_path": "48237 1299 199524 270118 17072 41128",
  "atomic": false,
  "collector": "rrc26",
  "communities": null,
  "local_pref": 0,
  "med": 0,
  "next_hop": "185.1.8.3",
  "origin": "IGP",
  "peer_asn": 48237,
  "peer_ip": "185.1.8.3",
  "prefix": "90.98.0.0/15",
  "timestamp": 1776039612.0,
  "type": "ANNOUNCE"
}

Мы знаем, что AS1299 (Arelion) — это сеть уровня 1 (Tier 1), что означает, что каждая AS справа в пути описывает отношения «вверх по течению» (клиент-провайдер). Это подразумевает, что AS17072 является транзитным провайдером для AS41128, AS270118 для AS17072, а AS199524 для AS270118. Если мы подробнее рассмотрим эти сети:

• AS41128 — это неиспользуемый ASN, принадлежащий Orange France

• AS17072 — интернет-провайдер, базирующийся в основном в Мексике

• AS270118 — хостинг-провайдер, базирующийся в Мексике

• AS199524 — это Gcore, провайдер с глобальным пирингом

Порядок AS в сообщении выше предполагал бы, что неиспользуемая AS Orange France покупает транзит у мексиканских интернет-провайдеров, которые затем передают данные Gcore и провайдерам уровня 1, что было бы довольно странно.

В другом случае, о перехвате префиксов 47.1.0.0/16 и 47.2.0.0/16 от исходной AS36429 сообщалось, что он даже включал основной ASN Cloudflare, 13335, в AS_PATH: «199524 270118 17072 13335 36429». Примеры этих BGP UPDATE можно увидеть в MRT Explorer от Cloudflare Radar:

Мы можем с уверенностью подтвердить, что мы (Cloudflare, AS13335) не имеем смежности с ныне неиспользуемой AS36429, принадлежащей Charter. Это означает, что злоумышленник подделал путь, включив ASN Cloudflare в качестве одной из фиктивных вышестоящих сетей в объявлениях, распространяемых в сторону Gcore (AS199524). Кроме того, Spamhaus правильно указал, что все маршруты перехвата вели к сети за пирингом Gcore в Чикаго, фактически никогда не проходя через мексиканских интернет-провайдеров или сеть Cloudflare на пути пересылки.

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

1. Инициация BGP-объявлений для «припаркованных» префиксов

2. Полная подделка AS_PATH, без включения собственного локального ASN злоумышленника

3. Объявление этих маршрутов для Gcore, AS199524

В этих перехватах похоже, что Gcore (AS199524) пропускает проверку и принудительное применение правила, согласно которому Первая AS должна соответствовать ожидаемому ASN клиента. (Мы рассмотрим, почему этот шаг может быть пропущен, позже в этом посте.) В результате поддельный путь принимается, и перехваченные префиксы распространяются вышестоящим провайдерам и пирам.

Хотя авторизация провайдера автономной системы (ASPA) поможет признать эти поддельные пути недействительными, атакующие могут обойти ее, включив только исходную AS, проверенную через RPKI-ROV, или законную вышестоящую AS через ASPA. Чтобы остановить эти конкретные перехваты, мы должны полагаться на другой механизм защиты, уже встроенный в BGP: проверку и принудительное применение Первой AS.

Маршрутизация трафика через Интернет немного похожа на отправку посылки. Когда посылка отправляется, ведется журнал каждого курьера, который ее обрабатывает. В BGP это называется AS_PATH (путь автономной системы), и он отслеживает каждую сеть на пути этого маршрута.

Атрибут AS_PATH в BGP используется для выбора пути. Этот алгоритм выбора определяет, какой маршрут к пункту назначения проходит через наилучший список переходов, где «наилучший» определяется несколькими переменными. Он также используется для предотвращения петель, где сети могут решить не принимать пути, которые уже прошли через их собственную сеть. Помимо ведения учета сетей, через которые пройдет BGP UPDATE и, следовательно, маршрут, AS_PATH также может анализироваться политиками маршрутизации, настроенными оператором, чтобы обходить или намеренно проходить через данную AS — например, чтобы избежать неожиданного воздействия BGP-аномалий.

BPG был построен на доверии, и AS_PATH можно легко манипулировать — будь то для, казалось бы, законных целей, таких как добавление префиксов AS (AS prepending) для перемещения трафика, или для злонамеренных целей, таких как его сокращение для искусственного привлечения трафика или выполнения атак на источник.

Давайте посмотрим, как выполняются эти два типа вредоносных BGP-манипуляций.

• AS64506 криптографически подписывает свои маршруты записью RPKI ROA (Route Origin Authorization), чтобы предотвратить перехват источника маршрута.

• AS64506 также создает объект ASPA, указывая только AS64503 в качестве допустимого провайдера

• AS64505 манипулирует своим AS_PATH, чтобы удалить AS64505 и указать источник AS64506

• AS64502 не применяет правило Первой AS

Маршрут выглядит действительным с точки зрения RPKI-ROV и является кратчайшим путем, что фактически перехватывает трафик с помощью этого маршрута. AS64506 сделала все правильно, указав действительный ROA для объявления префикса, и даже настроила объект ASPA, состоящий из своего единственного провайдера AS64503.

К сожалению, злоумышленник, управляющий AS64505, все еще может привлекать трафик, предназначенный для AS64506. Даже если AS64501 (клиент) и AS64502 (их провайдер) выполнят проверку ASPA, они не обнаружат недействительный путь, потому что в пути «64502 64506» нет «долины». Другими словами, AS64505, не включая даже свой собственный ASN в AS_PATH, может выдать себя за AS64506 без промежуточного перехода AS.

Правильный способ предотвратить этот перехват с помощью существующих инструментов — это принудительно применять правило Первой AS в AS_PATH. При применении этого правила AS64502 должным образом отклонила бы маршрут от AS64505.

• AS64506 имеет двух транзитных провайдеров: AS64503 и AS64505.

• AS64505 выставляет счета своему клиенту AS64506 на основе коэффициентов использования трафика.

• AS64505 удаляет себя из пути, а их пир AS64504 не применяет правило First AS (первый автономный номер в пути).

Алгоритм выбора пути BGP теперь выбирает маршрут через AS64504 как наилучший путь от AS64501. AS64506 платит обоим своим провайдерам, AS64503 и AS64505, за доставку трафика из Интернета. Однако теперь AS64505 предлагает более короткий путь BGP от удаленных источников, что означает, что AS64505 будет обрабатывать весь трафик в сторону AS64506 и получать за это оплату, а AS64503 не получит ничего.

Эти уязвимости BGP можно очень просто устранить, применяя правило First AS (первый AS в пути) для соответствия пировому AS в полученном AS_PATH.

Когда оператор настраивает BGP-соседа, он должен указать удаленный AS сети, с которой устанавливается соединение. Если первый AS в AS_PATH не соответствует этому значению, значит, путь был изменен. Процедура применения правила First AS четко описана в разделе 6.3 RFC 4271:

«Если сообщение UPDATE получено от внешнего пира, локальная

система МОЖЕТ проверить, равен ли крайний слева (относительно

расположения октетов в протокольном сообщении) AS в атрибуте AS_PATH

номеру автономной системы пира, отправившего сообщение. Если

проверка показывает, что это не так, код ошибки (Error Subcode)

ДОЛЖЕН быть установлен как Malformed AS_PATH (неверный AS_PATH).»

RFC 7606 позже уточняет, как вендоры должны реализовывать обработку ошибок, предлагая отбрасывать маршруты, содержащие неверные AS_PATH, с помощью метода treat-as-withdraw (рассматривать как отзыв). Это позволяет маршрутизаторам отбрасывать определенные префиксы с некорректными атрибутами, не нарушая работу всего BGP-сеанса.

Текущий черновик ASPA явно подчеркивает важность применения правила First AS, указывая, что ASPA не может обрабатывать пути, где из-за некорректных объявлений отсутствует достаточная информация об AS_PATH. Применение правила First AS в AS_PATH является обязательным для безопасности интернет-маршрутизации.

Вместо того чтобы полагаться на теоретические случаи сбоев и прошлые публичные инциденты, связанные с нарушением правила First AS, мы решили самостоятельно измерить, насколько широко такие нарушения AS_PATH могут приниматься в Интернете. Для этого мы настроили BGP-объявления соседям, в которых сами нарушили это правило. Вот что мы сделали:

1. Выделили два IP-префикса — один для IPv4 и один для IPv6 — для анонсирования внешним BGP-пирам (EBGP) уровня Tier 1

2. Преднамеренно добавили к тестовым префиксам перед анонсированием пирам Tier 1 собственный ASN Cloudflare, отличный от 13335 (AS402542), поставив его перед 13335

Например, мы анонсировали префиксы для AS1299 из нашего обычного BGP-сеанса в Женеве. Наш локальный AS — AS13335, но мы явно включили AS402542 как первый AS в AS_PATH.

bryton@edge01.gva01> show configuration policy-options policy-statement 4-TELIA-ACCEPT-EXPORT term ADV-FIRST-AS-PROBE-CR-1695522
from {
    community ANYCAST-ROUTE;
    prefix-list fl_first_as_prober;
    route-type internal;
}
then {
    origin igp;
    as-path-prepend 402542;
    next-hop self;
    accept;
}

bryton@edge01.gva01> show route advertising-protocol bgp <redacted_1299_ip> 162.159.82.0/24 detail | grep "AS path: "
     AS path: 402542 [13335] I

При такой конфигурации наши ожидания были следующими:

1. Сети, которые применяют правило First AS, незаметно отбросят маршрут в соответствии с методом отзыва из RFC 7606.

2. Сети, которые не применяют правило First AS, примут маршрут и установят его для пересылки трафика к нашим тестовым префиксам.

Любой из этих результатов будет виден в публичных представлениях BGP-маршрутов. Первоначально мы планировали реализовать непрерывное анонсирование префиксов всем пирам с намеренным нарушением правила First AS и предоставить всем инструмент для проверки, какие интернет-провайдеры проверяют First AS, а какие — нет. Однако мы обнаружили, что некоторые сети до сих пор не реализовали рекомендации, опубликованные в RFC 7606, при получении неверных BGP AS_PATH, и сбрасывают BGP-сеансы вместо поведения treat-as-withdraw. Это означало, что мы не могли безопасно реализовать непрерывный набор объявлений, нарушающих правило First AS, не влияя на реальный трафик к Cloudflare, что, очевидно, недопустимо.

Но мы можем более детально изучить сети, чьи политики оказывают наибольшее влияние: сети Tier 1. Эти сети составляют основу Интернета и имеют самые большие клиентские конусы (customer cones), поэтому перехваты или некорректные пути от этих пиров имеют самое широкое значение. Начнем с изучения нормального распространения anycast-префикса 1.1.1.0/24 через сети Tier 1.

Распространение 1.1.1.0/24 выглядит так, как и ожидалось — он напрямую доступен каждой сети Tier 1, с которой у Cloudflare в настоящее время есть прямое пиринговое соединение.

Теперь сравним это с нашим намеренно некорректным объявлением префикса 162.159.82.0/24:

^{Примечание: AS5511 (Orange S.A.) не показан на рисунке выше из-за его ограниченного присутствия в публичных представлениях маршрутов, но он участвовал в наших тестах и измерениях.}

Префикс распространяется совершенно иначе, чем 1.1.1.0/24 — гораздо меньше сетей Tier 1 принимают объявление напрямую от Cloudflare (в данном случае от AS13335 с добавленным AS402542). Основываясь на критериях нашего теста, упомянутых ранее, мы получили следующие результаты.

Сети Tier 1, которые применяют правило First AS (отбрасывая некорректные объявления):

• AS174 (Cogent)

• AS1299 (Arelion)

• AS3257 (GTT)

• AS3491 (PCCW)

• AS5511 (Orange S.A.)

• AS6453 (Tata)

• AS7018 (AT&T)

Сети Tier 1, которые не применяют правило First AS (принимая и устанавливая префиксы):

• AS701 (Verizon)

• AS2914 (NTT)

• AS3356 (Lumen/Colt/Cirion)

• AS6461 (Zayo)

• AS6762 (Sparkle)

• AS6830 (Liberty Global)

• AS12956 (Telefonica)

С помощью нашего тестирования мы обнаружили тревожную реальность: половина сетей Tier 1 уязвимы для перехватов, нарушающих правило First AS.

Хотя в данном исследовании мы тестировали только сети Tier 1, несомненно, существует множество сетей, не относящихся к Tier 1, которые также нарушают правило First AS.

Мы отметили, что большинство сетей Tier 1, не прошедших тест на нарушение First AS, используют маршрутизаторы Juniper Networks, что было определено по MAC-адресам пиров.

Это подчеркивает, что поведение по умолчанию у вендоров определяет, насколько безопасна сеть «из коробки» против атак, основанных на нарушении First AS. Давайте рассмотрим некоторые реализации BGP и их настройки по умолчанию, чтобы лучше понять, кто защищен по умолчанию, а кто — нет.

В таблице ниже перечислены основные вендоры маршрутизирующего/сетевого оборудования и их политики BGP. «Да» означает, что реализация BGP по умолчанию применяет правило First AS (это хорошо). «Нет» означает, что реализация BGP уязвима по умолчанию.

применять first as

OpenBGPD

Да

применять neighbor-as

FRR

Да (с патча октября 2023)

bgp применять-first-as

Отсутствие применения по умолчанию у некоторых вендоров может быть связано с единственным допустимым случаем использования, когда Первый AS не должен применяться на сессиях External BGP (EBGP): маршрутные серверы интернет-обменов (IX).

Маршрутный сервер отвечает за прозрачную (без добавления своего AS в AS_PATH) дистрибуцию маршрутов между пирами в сети. Это гарантирует, что пирам не нужно настраивать новые BGP-сессии каждый раз, когда новая сеть подключается к сети – вместо этого они могут пиринговать только с маршрутным сервером.

В реальности большинство производственных сетей имеют гораздо больше сессий с соседями, которые не являются прозрачными IX-маршрутными серверами, чем с соседями, которые являются. Гораздо более разумно настроить "no enforce-first-as" на нескольких сессиях с маршрутными серверами, чем включать "enforce-first-as" вручную для каждого пира в вашей сети.

Хотя подход "безопасный по умолчанию" лучше всего подходит для защиты от нарушений Первого AS, обычно это крутой подъем, чтобы убедить вендоров изменить давно установленные настройки по умолчанию. Вендорам также нужно будет внедрить метод плавного перехода, чтобы не затронуть BGP-сессии IX-маршрутных серверов, которым требуются настройки "no enforce-first-as" для успешного получения маршрутов.

Злоумышленники будут намеренно искажать AS_PATH, чтобы обойти механизмы безопасности BGP. Даже проверка пути ASPA на основе RPKI не сможет защитить нас от угонов поддельного происхождения, когда путь полностью очищен от всего, кроме AS происхождения, не оставляя ASPA ничего для признания недействительным.

Хорошая новость в том, что у нас уже есть смягчение для этих случаев: мы можем проверить, что Первый AS соответствует AS пира BGP, и всегда применять его. Обратитесь к соответствующему столбцу "Документация" в таблице выше, которую мы предоставили. Должно быть безопасно применять Первый AS на любой внешней BGP-сессии (EBGP), кроме тех, которые обращены к соседнему IX-маршрутному серверу.

Если вы сетевой оператор, пожалуйста, применяйте Первый AS на ваших маршрутизаторах сегодня, чтобы защитить вашу сеть и весь Интернет.

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