Сбой интернета в Венесуэле: что случилось с маршрутизацией BGP 2 января?

На фоне новостей о задержании и аресте венесуэльского лидера Николáса Мадуро США, кибербезопасный новостной дайджест изучил данные Cloudflare Radar и отметил утечку маршрутов в Венесуэле 2 января.

Мы углубились в данные. С начала декабря произошло одиннадцать инцидентов с утечками маршрутов, затрагивающих несколько префиксов, где AS8048 выступает источником утечки. Хотя невозможно точно определить, что произошло в день события, эта закономерность утечек маршрутов позволяет предположить, что у сети CANTV (AS8048), популярного интернет-провайдера в Венесуэле, недостаточно строгие политики экспорта и импорта маршрутов. Другими словами, аномалии BGP, обнаруженные исследователем, могут быть связаны не со злонамеренными действиями, а с плохой технической практикой со стороны провайдера.

В этой статье мы кратко обсудим протокол BGP (Border Gateway Protocol) и утечки BGP-маршрутов, а затем углубимся в наблюдавшуюся аномалию и её возможные причины.

Для начала вспомним, что такое утечка BGP-маршрута. Утечки маршрутов BGP вызывают поведение, похожее на съезд не на тот выход с автомагистрали. Вы всё ещё можете добраться до пункта назначения, но путь, вероятно, окажется медленнее и будет сопряжён с задержками, которых не было бы при движении по более прямому маршруту.

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

• клиент-провайдер: клиент платит сети-провайдеру за подключение себя и своих собственных нижестоящих клиентов к остальной части Интернета.

• пир-пир: две сети решают обмениваться трафиком между собой и клиентами друг друга без расчётов (без оплаты).

В отношениях клиент-провайдер провайдер будет анонсировать все маршруты клиенту. Клиент, с другой стороны, будет рекламировать только маршруты от своих собственных клиентов и те, которые исходят непосредственно из его сети.

В отношениях пир-пир каждый пир будет сообщать другому только свои собственные маршруты и маршруты своих нижестоящих клиентов.

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

Валидный путь, соответствующий правилу свободной от долин маршрутизации (valley-free routing), выглядел бы следующим образом:

Утечка маршрута — это нарушение правила свободной от долин маршрутизации, при котором автономная система принимает маршруты от провайдера или пира и распространяет их другому провайдеру или пиру. Например, путь BGP никогда не должен проходить через «долину», где трафик поднимается к провайдеру, спускается к клиенту, а затем снова поднимается к провайдеру. В RFC7908 определены разные типы утечек маршрутов, но простейшая — это утечка типа 1 (Type 1: Hairpin route leak) между двумя сетями-провайдерами через клиента.

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

Теперь, когда мы вспомнили, что такое утечка маршрутов в BGP, давайте рассмотрим гипотезу, выдвинутую в посте дайджеста. В посте обращалось внимание на несколько аномалий утечек маршрутов в Cloudflare Radar с участием AS8048. На странице Radar, посвящённой этой утечке, мы видим следующую информацию:

Мы видим автономную систему — источник утечки, AS8048 — CANTV, государственную телефонную и интернет-компанию Венесуэлы. Мы наблюдаем, что маршруты были приняты от одного из её провайдеров, AS6762 (Sparkle, итальянская телекоммуникационная компания), а затем распространены на AS52320 (V.tal GlobeNet, колумбийский сетевой сервис-провайдер). Это определённо утечка маршрутов.

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

Хотя мы не можем с уверенностью сказать, что вызвало эту утечку маршрутов, наши данные указывают на то, что её вероятная причина была более прозаичной. Отчасти это связано с тем, что утечки BGP-маршрутов происходят постоянно и всегда были частью Интернета — чаще всего по немalicious причинам.

Чтобы понять больше, давайте внимательнее посмотрим на затронутые префиксы и сети. Префиксы, вовлечённые в утечку, все были анонсированы AS21980 (Dayco Telecom, венесуэльская компания):

Как отметил автор дайджеста, все эти префиксы также принадлежат одной подсети 200.74.224.0/20. Однако гораздо интереснее отношения между исходной сетью AS21980 и сетью-источником утечки AS8048: AS8048 является провайдером для AS21980.

Отношения клиент-провайдер между AS8048 и AS21980 видны как в данных о выведенных связях AS в Cloudflare Radar, так и в bgp.tools. Мы также можем получить оценку достоверности связи AS с помощью инструмента monocle от BGPKIT, как показано здесь:

➜  ~ monocle as2rel 8048 21980 Explanation: - connected: % of 1813 peers that see this AS relationship - peer: % where the relationship is peer-to-peer - as1_upstream: % where ASN1 is the upstream (provider) - as2_upstream: % where ASN2 is the upstream (provider)

Data source: https://data.bgpkit.com/as2rel/as2rel-latest.json.bz2

╭──────┬───────┬───────────┬──────┬──────────────┬──────────────╮ │ asn1 │ asn2  │ connected │ peer │ as1_upstream │ as2_upstream │ ├──────┼───────┼───────────┼──────┼──────────────┼──────────────┤ │ 8048 │ 21980 │ 9.9%   │ 0.6% │ 9.4%    │ 0.0%         │ ╰──────┴───────┴───────────┴──────┴──────────────┴──────────────╯

Хотя только 9,9% сборщиков маршрутов видят эти две AS смежными, почти все пути, содержащие их, отражают AS8048 как восходящего провайдера для AS21980, что означает высокую достоверность отношений провайдер-клиент между ними.

Многие из утёкших маршрутов также были сильно «препендингнуты» (добавлен AS-номер) с AS8048, что означало бы, что они стали потенциально менее привлекательными для маршрутизации при получении другими сетями. Препендинг (Prepending) — это добавление номера AS более одного раза в исходящем анонсе клиентом или пиром, чтобы попытаться перенаправить трафик с определённого канала связи на другой. Например, многие пути во время утечки от AS8048 выглядели так: «52320,8048,8048,8048,8048,8048,8048,8048,8048,8048,23520,1299,269832,21980».

Вы можете видеть, что AS8048 отправила свой номер AS несколько раз в анонсе для AS52320, потому что, в силу механизма предотвращения петель BGP, путь никогда фактически не будет проходить внутрь и наружу AS8048 несколько раз подряд. Путь без препендинга выглядел бы так: «52320,8048,23520,1299,269832,21980».

Если бы AS8048 намеренно пыталась стать «человеком посередине» (man-in-the-middle, MITM) для трафика, зачем бы ей делать BGP-анонс менее привлекательным, а не более привлекательным? Кроме того, зачем устраивать утечку префиксов, чтобы попытаться перехватить трафик, если вы уже являетесь провайдером для нижестоящей AS? В этом не было бы особого смысла.

Утечки от AS8048 также проявлялись в нескольких отдельных анонсах, каждый примерно с часовым интервалом 2 января 2026 года между 15:30 и 17:45 по UTC, что позволяет предположить, что у них могли быть сетевые проблемы, которые вылились в проблему с политикой маршрутизации или сбой, связанный со схождением маршрутов.

Также стоит отметить, что эти утечки начались более чем за двенадцать часов до военных ударов США в Венесуэле. Утечки, затрагивающие сети Южной Америки, являются обычным явлением, и у нас нет оснований полагать, исходя из времени или других факторов, которые я обсудил, что утечка связана с захватом Мадуро несколькими часами позже.

На самом деле, оглядываясь на последние два месяца, мы можем увидеть множество утечек от AS8048, подобных этой, что означает, что это не новая аномалия BGP:

Вы можете видеть выше в истории системы оповещения об утечках маршрутов Cloudflare Radar, что AS8048 не новичок в утечках маршрутов типа 1 (hairpin). Только с начала декабря произошло одиннадцать событий утечки маршрутов, где AS8048 является источником утечки.

Из этого мы можем сделать более невинное возможное объяснение утечки маршрута: AS8048, возможно, настроил слишком свободные политики экспорта по отношению как минимум к одному из своих провайдеров, AS52320. И из-за этого перераспределенные маршруты принадлежат их клиенту, даже когда прямые клиентские BGP-маршруты отсутствовали. Если их политика экспорта для AS52320 соответствовала только сгенерированному IRR списку префиксов, а не тегу BGP сообщества клиента, например, тогда понятно, почему косвенный путь к AS6762 был передан обратно вверх по течению AS8048. 

Подобные ошибки политик значительно уменьшились бы с помощью RFC9234 и атрибута Only-to-Customer (OTC), которые более тесно связывают BGP с ролями клиент-провайдер и пир-пир, когда поддержаны всеми вендорами маршрутизации. Более технические детали по RFC9234 я оставлю для последующей записи в блоге.

В рассылке также отмечается как «примечательное», что Sparkle (AS6762) не реализует RPKI (Инфраструктура открытых ключей ресурсов) проверку происхождения маршрутов (ROV). Хотя верно, что у AS6762, по-видимому, неполное развертывание ROV, и она помечена как «небезопасная» на isbgpsafeyet.com из-за этого, проверка происхождения не предотвратила бы эту аномалию BGP в Венесуэле. 

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

Зная это, нам нужна проверка на основе пути. Именно это обеспечит Авторизация провайдеров автономных систем (ASPA), готовящийся стандарт в IETF. Идея похожа на ROA и ROV в RPKI: создать объект ASPA, который определяет список авторизованных провайдеров (вышестоящих) для нашего AS, и все будут использовать это для признания недействительными утечек маршрутов в Интернете с различных точек зрения. На конкретном примере, AS6762 — это сеть уровня Tier-1 без транзита, и они использовали бы специальный зарезервированный член «AS0» в своем подписанном объекте ASPA, чтобы сообщить миру, что у них нет вышестоящих провайдеров, только боковые пиры и клиенты. Затем AS52320, другой провайдер AS8048, увидел бы маршруты от своего клиента с «6762» в пути и отклонил бы их, выполнив процесс проверки ASPA.

ASPA основан на RPKI и именно то, что помогло бы предотвратить утечки маршрутов, подобные той, что мы наблюдали в Венесуэле.

Мы посчитали важным предложить альтернативное объяснение утечке BGP-маршрута от AS8048 в Венесуэле, которая была наблюдена на Cloudflare Radar. Полезно понимать, что утечки маршрутов — это ожидаемый побочный эффект того, что BGP исторически полностью основан на доверии и тщательно исполняемом намерении, driven by бизнес-отношения. 

Хотя утечки маршрутов могут совершаться со злым умыслом, данные позволяют предположить, что это событие могло быть случайностью, вызванной отсутствием политик экспорта и импорта маршрутизации, которые предотвратили бы его. Именно поэтому для более безопасного BGP и Интернета нам нужно работать вместе и продвигать внедрение основанного на RPKI ASPA, для которого RIPE недавно выпустил создание объектов, в широком Интернете. Это будет совместными усилиями, так же как RPKI было для проверки происхождения, но оно того стоит и предотвратит инциденты BGP, такие как в Венесуэле.