Утечка BGP-маршрутов Vodafone Idea 2021: проверка подотчётности

Резюме

Публичные анализы маршрутизации показали, что 16 апреля 2021 года Vodafone Idea AS55410 фигурировал как источник для десятков тысяч сетей. В анализе Catchpoint было зафиксировано более 34 000 сетей, тогда как инициатива Mutually Agreed Norms for Routing Security (MANRS) описала более 31 000 маршрутов. Эти показатели получены с помощью конкретных методов наблюдения, и их не следует считать единым универсальным числом [1][2].
Открытые данные подтверждают наличие крупных аномальных анонсов и их широкое распространение, но не устанавливают злого умысла. MANRS назвала событие перехватом (hijack); в других материалах и в этой статье используется термин «утечка маршрутов» (route leak) или «ошибочный анонс источника» (origin misannouncement), чтобы не превращать техническое наблюдение в неподтверждённое утверждение о мотивах [1][2][3].
Ответственность начиналась с AS55410, который контролировал, что именно его маршрутизаторы анонсируют и экспортируют. Но она на этом не заканчивалась. Апстрим-провайдеры контролировали авторизацию префиксов клиента, политику максимального числа префиксов, валидацию источника и дальнейшее распространение. MANRS в своём анализе связала наблюдавшиеся анонсы с путём через Bharti Airtel AS9498 и противопоставила это распространение поведению других апстримов, которые не передавали те же маршруты дальше [2].
Resource Public Key Infrastructure (RPKI) могла бы дать надёжные доказательства для той части анонсированных префиксов, которая покрыта авторизациями происхождения маршрутов (Route Origin Authorizations, ROA). И Catchpoint, и MANRS обнаружили, что у большинства затронутых сетей в их анализах не было полезных ROA. Поэтому валидация источника предоставляла мощный, но неполный контроль: она могла выявлять неавторизованные источники для покрытых префиксов, но не защищала ресурсы без ROA и не проверяла полный AS-путь [1][2][12][13].
RIPE Routing Information Service (RIPE RIS) и RouteViews — две публичные системы сбора маршрутов — сделали инцидент наблюдаемым со стороны участвующих пиров. Они не авторизовали маршруты, не управляли импортными политиками провайдеров и не доказывали, что каждая сеть выбрала один и тот же путь. Данные коллекторов — это фиксация открытого состояния маршрутизации, а не замена конфигурационным и форвардинговым данным, которые находятся у вовлечённых операторов [8][9].
Обоснованный анализ подотчётности разделяет предотвращение, приём, распространение, обнаружение, локализацию, отзыв маршрутов и доказательство устранения проблемы. У каждого этапа свой владелец и свой след доказательств. Восстановленная таблица маршрутизации необходима, но сама по себе не показывает, почему произошёл инцидент и может ли повториться тот же сбой контроля.

Что устанавливают открытые доказательства

Центральное событие ограничено 16 апреля 2021 года и публичными наблюдениями, связанными с Vodafone Idea AS55410. Catchpoint сообщила, что в 13:48:58 по Гринвичу эта автономная система фигурировала как источник для более чем 34 000 сетей. Изучение коллектора RIPE RISrrc00показало примерно 225 000 BGP-сообщений обновлений в период с 13:45 до 15:00 по Гринвичу. Catchpoint также сообщила, что 64 из 73 пиров, подключённых к этому коллектору, получили по крайней мере одну затронутую сеть, а большинство аномальных маршрутов было отозвано примерно через час [1].

Эти цифры описывают то, что Catchpoint получила из одного аналитического среза. Они не доказывают, что каждый интернет-маршрутизатор получил 34 000 маршрутов, что все затронутые префиксы были выбраны для передачи трафика или что все направления оставались недоступными одинаковое время. BGP-коллектор получает маршруты от определённого набора участвующих пиров. Разные пиры отражают разные политические решения, а счётчик обновлений включает и анонсы, и отзывы, а не прямое число пользователей или неудачных сессий.

Catchpoint также заявила, что событие нарушило работу более чем 3 500 компаний, и привела примеры из телекоммуникаций, доставки контента и финансовых услуг. Это серьёзное утверждение о последствиях, но его смысл следует связывать с методологией источника. Использованные здесь открытые материалы не содержат полный перечень сбоев по каждой компании, общее число потенциально затронутых сетей или проверенную сумму финансовых потерь. Такое утверждение полезно как свидетельство масштаба, но не даёт оснований приписывать одинаковый ущерб каждой названной организации [1].

MANRS опубликовала отдельный анализ, в котором сообщила, что AS55410 обычно анонсирует 824 маршрута, а во время инцидента анонсировала более 31 000 дополнительных маршрутов. MANRS назвала событие крупным перехватом BGP. В анализе сказано, что наблюдавшиеся анонсы выходили через Bharti Airtel AS9498, и утверждалось, что фильтрация клиентских маршрутов и лимиты префиксов на этой границе должны были ограничить распространение. Также отмечалось, что другие выявленные апстримы не распространяли тот же набор маршрутов [2].

Разница между более чем 34 000 сетей и более чем 31 000 маршрутов не обязательно является противоречием. Аналитики могут считать префиксы в разных точках наблюдения, применять разные временные окна, включать или не включать обычные анонсы исходной сети и по-разному дедуплицировать обновления. Ответственное изложение сохраняет источник и единицу измерения для каждого числа, а не сводит их в якобы точный глобальный итог.

The Register в материале для более широкой аудитории охарактеризовал событие как анонс более 30 000 ложных префиксов и привёл обеспокоенность специалистов по маршрутизации. Это подтверждает, что инцидент привлёк внимание всей отрасли, но не заменяет данные на уровне маршрутов и не раскрывает закрытые конфигурации маршрутизаторов. Публичная подотчётность должна использовать журналистские материалы для установления того, что было сообщено и что оспаривается, а технические выводы должны опираться на исходные наблюдения [3].

На основе этих материалов хорошо подтверждаются четыре утверждения. Необычно большой набор маршрутов был связан с AS55410 как источником. По крайней мере один апстрим распространил значительную часть этих анонсов. Публичные коллекторы и аналитики наблюдали событие на нескольких границах сетей. Аномальное состояние было в основном отозвано в течение ограниченного периода. Менее определёнными остаются мотив, исходное изменение конфигурации, полный набор принявших сети, точный эффект пересылки для каждого префикса и устойчивость последующих исправлений.

Почему терминология меняет претензии к подотчётности

Термины «утечка маршрутов» (route leak), «ошибочный анонс источника» (origin misannouncement) и «перехват» (hijack) описывают пересекающиеся, но разные понятия. RFC 7908 определяет утечки маршрутов через нарушение предполагаемой области распространения — как правило, перераспределение маршрутов способом, противоречащим ожидаемым деловым отношениям. Ошибочный анонс источника происходит, когда автономная система анонсирует префикс, который она не уполномочена или не должна анонсировать.

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

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

MANRS имела право использовать термин «перехват» в своём анализе, и эта формулировка является частью открытых материалов [2]. В этой статье в заголовке используется «утечка маршрутов», потому что вопрос подотчётности касается операционной локализации, а не мотива. Также используется «ошибочный анонс источника», когда речь идёт о конкретном механизме, из-за которого AS55410 оказался источником. Эти термины нельзя незаметно подменять. При расследовании после инцидента следует указывать, какое наблюдение подтверждает тот или иной ярлык и какие дополнительные доказательства нужны для вывода о намерении.

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

Поэтому подотчётность начинается с практического контроля. AS55410 отвечал за маршруты, которые его системы анонсировали и экспортировали, независимо от мотива. Апстрим отвечал за принятые и переданные дальше клиентские маршруты независимо от того, почему клиент их отправил. Другие сети отвечали за собственные решения по валидации и импорту. Такой подход позволяет не ждать окончательного психологического или юридического ярлыка, прежде чем изучать средства контроля, которые должны были ограничить событие.

Как локальный анонс приобрёл более широкий охват

BGP — это протокол, с помощью которого автономные системы обмениваются информацией о достижимости. Анонс сообщает соседу, что префикс назначения достижим через определённый AS-путь. Принимающий маршрутизатор применяет локальную импортную политику, проверяет атрибуты, сравнивает возможные пути и может установить выбранный маршрут и экспортировать его. RFC 4271 определяет поведение протокола, но каждый оператор управляет значительной частью политики, определяющей, что его маршрутизаторы принимают и распространяют [10].

Такая конструкция распределяет и устойчивость, и риск. Нет центрального органа маршрутизации, который одобрял бы каждый анонс до его использования. Оператор может задавать политику на основе отношений с соседом, префикса, исходной автономной системы, AS-пути, сообществ, состояния валидации и других атрибутов. Если эти политики слишком широкие или неточные, аномальный анонс клиента может пересечь первую границу и быть распространён на многие другие сети.

Исходная автономная система — это первая точка контроля. Маршрутизатор не должен анонсировать произвольный набор префиксов только потому, что они появились в импортированной таблице или объекте конфигурации. Предусмотренные исходные префиксы можно генерировать из утверждённого реестра, ограничивать максимальной длиной префикса и сверять с маршрутными реестрами или данными RPKI. Экспортные фильтры могут ограничивать, что разрешено анонсировать каждой eBGP-сессии. Проверка конфигурации может выявить резкий переход от сотен обычных маршрутов к десяткам тысяч.

Граница «клиент — провайдер» — вторая точка контроля. У провайдера, как правило, есть информация о префиксах, которые клиент уполномочен анонсировать. Эти сведения могут поступать из договоров, учётных записей о предоставлении услуг, объектов Internet Routing Registry (IRR), результатов валидации на основе RPKI и истории наблюдений. Ни один источник не идеален сам по себе, но провайдер может объединить их в узкую политику приёма. Клиент, который обычно анонсирует ограниченный набор сетей, не должен иметь возможность отправить десятки тысяч не связанных с ним префиксов без срабатывания отклонения или аварийного лимита.

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

Событие с AS55410 стало значимым, потому что аномальные маршруты не остались локальными. MANRS в своём материале связала наблюдаемое распространение с AS9498 и подчеркнула, что другие апстримы не распространяли те же маршруты [2]. Этот контраст — сигнал для подотчётности. Он показывает, что такой исход не был механически неизбежен после анонса AS55410. На разных границах были приняты разные решения о приёме и распространении.

Обязанности исходной сети по предотвращению

AS55410 контролировала системы, которые создали и экспортировали аномальное состояние источника. Самый прямой вопрос предотвращения — как был представлен и enforced утверждённый набор источников. Зрелый процесс различает префиксы, которые сеть может анонсировать, маршруты, которые она может нести для клиентов, полные таблицы маршрутов для пересылки и специальные маршруты для тестирования или защиты. Эти категории не должны сливаться в один экспортируемый пул.

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

Экспортный контроль должен быть специфичным для каждого соседа. Сессия, обращённая к провайдеру, должна получать только предусмотренные публичные анонсы. Маршрут, полученный от другого внешнего соседа, не должен становиться новым источником только из-за перераспределения между протоколами маршрутизации, ошибки в route map или слишком широкого оператора network. Кандидатные конфигурации следует тестировать на соответствие известному набору до применения, а фактические данные Adj-RIB-Out — сравнивать с этим набором после изменения.

Масштаб сам по себе является сигналом безопасности. Если AS55410 обычно анонсировала сотни маршрутов, скачок до десятков тысяч должен был превысить локальный бюджет изменений ещё до внешней валидации. Лимит префиксов на стороне источника отличается от настройки максимального числа префиксов у принимающего провайдера: он ограничивает, что собственный экспортный процесс сети имеет право создавать. Лимит можно настраивать под каждого соседа, а его превышение должно требовать осознанного разрешения с указанием причины и срока действия.

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

Открытые материалы не раскрывают, какие из этих средств контроля существовали в AS55410, какое из них отказало и устранило ли проблему последующее изменение. В выводах о подотчётности не следует додумывать эту информацию. Следует запросить различия конфигураций, версии маршрутных политик, утверждённые списки префиксов, заявки на изменения, журналы оповещений, снимки Adj-RIB-Out и записи об отзыве маршрутов. Эти артефакты покажут, был ли сбой в авторизации, генерации, экспорте, мониторинге или реагировании.

Фильтрация на апстриме была самостоятельной обязанностью

Ошибка исходной сети не снимает с апстрима контроля. Провайдер принимает операционное решение, когда принимает маршрут клиента. Клиент может предоставить данные, но именно провайдер определяет, попадут ли они в его систему маршрутизации и будут ли экспортированы другим. Это граница, на которой локальная ошибка может либо остановиться, либо стать событием масштаба всего интернета.

MANRS утверждала, что AS9498 должна была применить фильтрацию AS и лимиты префиксов к клиентскому соединению [2]. Этот принцип шире, чем один названный оператор. Провайдер должен знать, какая клиентская автономная система ожидается на сессии, какие источники могут появляться за ней, сколько маршрутов является нормой, какие длины префиксов допустимы и какие состояния валидации требуют отклонения или проверки. Сессию, которая внезапно предлагает огромное число не связанных между собой источников, не следует считать нормальной только потому, что синтаксис BGP корректен.

Фильтрация префиксов может быть строгой или адаптивной, но она должна опираться на доказательства. Строгий список разрешённого даёт сильную защиту, если рекламируемый набор клиента стабилен. Генерируемый фильтр может использовать проверенные данные реестра и RPKI при условии, что процесс генерации безопасно обрабатывает устаревшие или неполные записи. Адаптивная система обнаружения аномалий может сравнивать текущее число маршрутов и набор источников с историческими базовыми значениями. Какой бы метод ни использовался, оператор должен уметь объяснить правило, по которому был принят каждый маршрут.

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

Валидация источника добавляет криптографический сигнал для покрытых ресурсов. Маршрут, источник которого противоречит действующему ROA, может быть классифицирован как недействительный. Провайдер может отклонять недействительные маршруты, снижать их приоритет или направлять на проверку в соответствии со своей политикой. Решение о политике остаётся локальным, но состояние валидации даёт оператору чёткое и проверяемое основание отказаться от неавторизованного источника.

Покрытие RPKI в этом событии было неполным. Catchpoint сообщила, что только около 20 процентов затронутых сетей в её анализе имели ROA, и источник AS55410 делал эти покрытые маршруты недействительными [1]. MANRS также указала, что примерно 80 процентов не имели ROA, и описала более 7 000 покрытых маршрутов, для которых неавторизованный источник был бы недействительным [2]. Точные числа различаются в зависимости от анализируемого набора, но операционный вывод одинаков: валидация источника могла остановить значимую часть, но не всё событие.

Это ограничение не делает фильтрацию необязательной. Для префиксов без ROA провайдеры всё равно могут использовать авторизацию клиента, фильтры на основе Internet Routing Registry (IRR), лимиты префиксов, историю источников и обнаружение аномалий. RPKI — это один уровень в стеке контроля. Если считать отсутствие ROA разрешением принимать любой клиентский источник, издержки неполного внедрения перекладываются на каждую нижестоящую сеть.

Дальнейший экспорт требует отдельного решения. Провайдер может принять маршрут для ограниченной внутренней обработки, но не распространять его широко. Карантинные сообщества, низкий приоритет, настройки route server и проверка политики могут ограничивать неопределённые маршруты. После инцидента нужны доказательства как по Adj-RIB-In, так и по Adj-RIB-Out, потому что приём и усиление — разные действия.

Почему с текущими данными о топологии нужно обращаться осторожно

CAIDA ASRank, CIDR Report и RIPE Stat дают полезный публичный контекст для AS55410 [4][5][6][7]. Они помогают идентифицировать AS, изучить видимые в настоящее время связи, просмотреть анонсируемые префиксы и сравнить публичные маршрутные записи. Но они не являются полным и неизменным снимком сети на 16 апреля 2021 года.

Выводы о топологии особенно ограничены. Связь, отображаемая сегодня, могла измениться с момента инцидента. Предполагаемые отношения «провайдер — пир» могут не учитывать частные договоры, поведение route server, резервные сессии или исключения из политики. Текущие данные об анонсируемых префиксах показывают, что публичные коллекторы связывают с этой AS сейчас, но не доказывают точный список авторизованных источников в 2021 году.

Правильное использование этих сервисов — подтверждение. Они помогают исследователю сформулировать вопросы, проверить идентификаторы и найти аномалии, которые стоит проверить по архивным данным о маршрутах за конкретное время. Не следует утверждать, что конкретная сессия 2021 года имела конкретную политику, если это не подтверждается историческими записями.

Внутренние доказательства оператора должны быть точнее. Системы предоставления услуг, подписанные договоры, записи о клиентских префиксах, конфигурации маршрутизаторов, снимки валидатора RPKI и версии маршрутных политик позволяют восстановить, что граница должна была пропускать. Архивы коллекторов показывают, что граница фактически пропустила. Подотчётность зависит от разницы между этими двумя состояниями.

Поэтому запись в реестре — это не суверенное право на достижимость. Запись может документировать выделение ресурсов, контактные данные, намерение по маршруту или авторизацию источника. Работающие маршрутизаторы всё равно решают, использовать ли эти сведения. Точные записи необходимы, но непрерывность зависит от операционных политик, которые их используют, обновляют и безопасно отказывают, когда записи неполны или противоречивы.

Коллекторы маршрутов сохраняют доказательства, а не полномочия

RIPE RIS и RouteViews собирают BGP-данные от участвующих пиров и делают их доступными для анализа [8][9]. Их ценность при инцидентах значительна. Они проставляют временные метки анонсов и отзывов, показывают, какие пиры коллектора получили маршрут, выявляют изменения источника и AS-пути и позволяют независимым наблюдателям сравнивать распространение.

Использование Catchpoint коллектораrrc00показывает эту ценность. Анализ позволил оценить объём обновлений, определить пиров, которые видели затронутые сети, и проследить отзывы, потому что коллектор сохранил внешние наблюдения [1]. Без таких систем понимание ситуации публикой зависело бы гораздо сильнее от добровольных заявлений вовлечённых операторов.

Видимость коллекторов не универсальна. Пир может отправлять свой лучший маршрут, а не все альтернативы. Маршрут, видимый у одного коллектора, может никогда не быть выбран другой сетью. Маршрут, отсутствующий у коллектора, всё равно мог распространяться по путям, которые коллектор не видел. Пиринговые сессии могут перезапускаться, политики — меняться, а временные метки могут отражать и особенности сбора данных, и само событие.

По этим причинам счётчик обновлений — не счётчик пострадавших пользователей. Число пиров — не число всех автономных систем. Видимый маршрут — не доказательство того, что трафик пошёл по нему. Результаты пересылки требуют измерений плоскости данных, телеметрии трафика или записей операторов. Данные коллекторов следует объединять с этими источниками, а не растягивать за пределы их области применения.

Коллекторы также не авторизуют и не отзывают маршруты. RIPE NCC и Университет Орегона могут эксплуатировать инфраструктуру наблюдений с высокой целостностью, но они не управляют импортной политикой провайдеров. Их подотчётность — сохранять точные, хорошо документированные наблюдения и раскрывать ограничения сбора данных. Ответственность за операционное состояние остаётся на анонсирующих и распространяющих сетях.

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

RPKI даёт доказательства источника, а не разрешение на путь

Валидация источника маршрута (Route Origin Validation) сравнивает BGP-анонс с криптографически подписанными авторизациями происхождения маршрута (ROA). ROA может указывать, что определённая автономная система уполномочена анонсировать префикс до заданной максимальной длины. RFC 6811 и RFC 8893 определяют модель валидации и операционную терминологию [12][13].

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

Событие также выявляет три ограничения. Во-первых, у многих префиксов не было ROA. Их маршруты получали статус «не найдено», а не «недействителен», поэтому политика отклонения недействительных не остановила бы их. Во-вторых, валидация источника RPKI касается исходной AS, а не того, авторизована ли каждая связь между AS в пути. В-третьих, состояние валидации не заставляет маршрутизатор действовать. Политику выбирает оператор, который полагается на эти данные.

Эти ограничения — причины для многоуровневого контроля, а не аргументы против RPKI. Держатели префиксов могут создавать точные ROA и держать максимальные длины узкими. Региональные интернет-реестры (RIR) и репозитории могут поддерживать безопасные и доступные системы публикации. Сетевые операторы могут запускать независимые валидаторы, отслеживать устаревшие данные и применять понятную политику. Провайдеры могут сочетать валидацию со списками клиентских префиксов, проверками AS-путей и лимитами.

Доказательства внедрения RPKI должны быть привязаны ко времени. Действующий сейчас ROA не доказывает, что он существовал во время инцидента. Текущее заявление об отклонении недействительных маршрутов не доказывает, что политика была включена на нужном маршрутизаторе или сессии. Исследователям нужны кэши или журналы валидатора, версии политик, записи решений по маршрутам и временные метки.

Оценки покрытия ROA в публичных отчётах также требуют аккуратной формулировки. Примерно одна пятая у Catchpoint и примерно одна пятая у MANRS описывают их соответствующие наборы затронутых сетей [1][2]. Они не устанавливают глобальный уровень внедрения RPKI. Их значение привязано к инциденту: тысячи аномальных источников могли нести сигнал валидации, который могли использовать полагающиеся на него сети, но большинство всё равно требовало других механизмов авторизации.

Записи IRR и авторизация клиентов остаются необходимыми

Объекты Internet Routing Registry (IRR) могут описывать маршрутную политику и авторизованные источники. Провайдеры часто используют их для генерации фильтров. Они широко распространены и могут охватывать префиксы без ROA, но их точность зависит от сопровождения, аутентификации и практик ведения базы данных. Устаревший или слабо аутентифицированный объект маршрута может создавать ложную уверенность.

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

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

Сама генерация фильтров требует управления. У входных данных должны быть временные метки и сведения о происхождении. Изменения следует проверять, тестировать и безопасно внедрять. Оператор должен знать, когда обновление реестра изменило список разрешённого, и уметь откатить ошибочное изменение. Генерируемый фильтр, который никогда не обновляется, может устареть; фильтр, обновляемый без ограничений, может быстро распространить плохие данные.

В случае AS55410 открытые данные не раскрывают точные входные данные фильтров, использованные AS9498 или любым другим провайдером. Подотчётность требует их запросить. Вопрос не в том, может ли оператор назвать IRR или RPKI как общую практику. Вопрос в том, можно ли воспроизвести решение по маршруту на конкретной сессии исходя из доказательств и политики, действовавших в тот момент.

Явная политика, роли и контроль путей

RFC 7454 описывает практики операционной безопасности для BGP, включая фильтрацию и лимиты. RFC 8212 делает явную политику импорта и экспорта базовым принципом безопасности для eBGP. Эти стандарты направлены на повторяющийся вид сбоев: маршруты не должны распространяться только потому, что оператор забыл определить политику [14][15].

Явная политика необходима, но недостаточна. Политика, разрешающая все маршруты клиента, тоже явная и всё равно небезопасная. Правило должно отражать предусмотренные отношения и авторизацию. Вопрос аудита не только в том, существовала ли route map, но и в том, ограничивала ли она префиксы клиента, источники, длины и поведение пути.

RFC 9234 определяет BGP Roles и атрибут Only-to-Customer (OTC) как механизмы выражения отношений и выявления некоторых утечек маршрутов [16]. Роли помогают сетям различать отношения «провайдер», «клиент», «пир» и «route server». Атрибут OTC может нести информацию, предназначенную для предотвращения распространения маршрутов в нарушение ожиданий «без долин», связанных с этими ролями.

Эти механизмы — возможные варианты контроля, а не доказательство их внедрения в апреле 2021 года. Использованные здесь открытые данные не подтверждают, что AS55410, AS9498 или другие участники договорились о BGP Roles или обрабатывали OTC. Отчёт о подотчётности не должен превращать более поздний или необязательный стандарт в ретроспективное фактическое утверждение.

Контроль путей не заменяет авторизацию источника. Маршрут может иметь согласованный с отношениями путь и при этом указывать неавторизованный источник. И наоборот, маршрут может иметь действительный источник, но быть утёкшим по неавторизованному пути. Операторам нужны оба измерения. Событие с AS55410 поставило валидацию источника в центр, а различия в решениях апстримов о распространении также выявляют значимость контроля отношений и клиентских фильтров.

RFC 7999 определяет общеизвестное BGP-сообщество для blackholing [17]. Blackholing важно как общий операционный контекст, поскольку показывает, что BGP-анонсы могут намеренно вызывать отбрасывание трафика. Использованные для этого инцидента источники не показывают, что сообщество BLACKHOLE было частью события с AS55410. Поэтому его следует оставить примером средства контроля, а не вставлять в описание инцидента как факт.

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

Обнаружение должно выявлять отказавшую границу

Существенное изменение набора источников должно обнаруживаться внутри исходной сети до появления внешних сообщений. Полезные сигналы — изменения числа маршрутов, неожиданные источники, новые внешние префиксы в Adj-RIB-Out, недействительные состояния валидации и расхождения между утверждённым реестром и рекламируемым состоянием. Оповещение должно указывать конфигурацию или процесс, создавшие маршруты.

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

Внешнее наблюдение — ещё один уровень. Оператор может отслеживать RIS, RouteViews и коммерческие потоки маршрутов для собственных префиксов и клиентских маршрутов. Держатели префиксов могут оповещать о появлении неожиданного источника. Апстримы могут сравнивать публичное распространение со своими намеренными экспортами. Разнообразие источников снижает зависимость от видимости одного коллектора.

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

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

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

Локализация требовала большего, чем ожидание отзыва

Исходная сеть могла локализовать инцидент, остановив процесс анонсирования, применив блокировку экспорта и отправив отзывы маршрутов. Ей также нужно было убедиться, что неверные маршруты исчезли из собственного Adj-RIB-Out и из независимых наблюдений. Откат локальной конфигурации недостаточен, если устаревшие маршруты остаются активными где-то ещё.

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

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

Catchpoint сообщила, что большинство маршрутов было отозвано примерно через час, и отметила меньший остаточный набор в ходе анализа [1]. Ответственное завершение должно объяснить, какие отзывы исходили от AS55410, какие были отфильтрованы провайдерами и сохранялись ли какие-либо маршруты в отдельных коллекторах. Не следует считать исчезновение в одной точке наблюдения всеобщим восстановлением.

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

Устойчивая локализация требует повторного теста. Исходная сеть должна доказать, что неавторизованный префикс не может попасть в набор источников. Апстрим — что клиент не может превысить авторизованный набор или лимит префиксов. Валидация должна отклонять покрытый неавторизованный источник. Мониторинг должен срабатывать на контролируемый тест, не пропуская его наружу. Доказательства таких тестов сильнее общего заверения, что фильтры были проверены.

Оценка последствий без раздувания отчёта

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

Приведённые Catchpoint число компаний и примеры показывают, что событие пересекло множество организационных границ [1]. Они не дают полной причинной картины для каждой компании. Поэтому в публичной статье не следует утверждать, что каждая перечисленная организация пережила полный отказ. Можно точно сказать, что аналитики наблюдали аномальную маршрутизацию с участием сетей, связанных с широким набором сервисов, и что некоторые сервисы столкнулись со сбоями.

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

Асимметрия доказательств важна. Коллекторы маршрутов подробно показывают тысячи аномальных анонсов, тогда как поставщики услуг почти не раскрывают данные о последствиях для клиентов. Это не делает счётчики маршрутов заменой доказательствам ущерба. Это значит, что в отчёте о подотчётности нужно сохранять и то, что известно, и то, что остаётся недоступным.

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

Доказательства, необходимые для обоснованного вывода

Для AS55410 ключевые доказательства — утверждённый реестр префиксов, конфигурация и политика до и после события, записи об изменениях, входные данные генерации маршрутов, Adj-RIB-Out, внутренние временные метки оповещений, действия операторов и подтверждение отзывов. Записи о доступе и целостности помогут определить, была ли это ошибка, системный сбой или несанкционированная активность, не предполагая ответ заранее.

Для AS9498 и любого другого принимающего провайдера нужны: набор авторизации клиента, входные данные IRR и RPKI, состояние валидатора, настройка максимального числа префиксов, импортная политика, Adj-RIB-In, выбранные маршруты, Adj-RIB-Out, история оповещений и действия при инциденте. Провайдер должен показать, почему маршруты были приняты и почему распространены.

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

Для затронутых держателей префиксов полезны ROA и объекты маршрутов в том виде, в каком они существовали на тот момент, оповещения, измерения достижимости и переписка с провайдерами. Для коллекторов воспроизводимые параметры запросов и метаданные пиров определяют масштаб наблюдений. Для операторов сервисов телеметрия трафика и ошибок связывает изменения плоскости управления с последствиями для пользователей.

Все артефакты должны иметь стабильные временные метки и хэши. Время BGP, время журналов маршрутизатора, время системы изменений и время мониторинга должны быть синхронизированы или их смещения задокументированы. Иначе кажущаяся задержка обнаружения может оказаться расхождением часов. Хранение должно охватывать исходные доказательства, а не только скриншоты или сводные графики.

Публичное раскрытие может оставаться ограниченным, но всё же полезным. Операторам не нужно публиковать клиентские секреты или уязвимые конфигурации. Можно раскрыть класс сбоя, средство контроля, которое должно было его остановить, почему оно не сработало, график локализации, проверенное исправление и границы доказательств. Расплывчатое заявление о том, что проблема маршрутизации устранена, не позволяет пирам и клиентам оценить риск повторения.

Матрица подотчётности для инцидента

Vodafone Idea AS55410 как наблюдаемый источник.Её обязанность по предотвращению — ограничить генерацию и экспорт источников авторизованными префиксами. Обязанность по обнаружению — заметить резкое отклонение числа маршрутов и набора источников. Обязанность по локализации — остановить процесс и отправить отзывы. Открытые данные подтверждают наблюдаемое состояние источника, но не устанавливают внутренний триггер, намерение или полноту исправления. Самым сильным доказательством были бы различия конфигураций, данные об утверждённых источниках, снимки экспорта и повторный тест.

Bharti Airtel AS9498 как апстрим, указанный MANRS.Её обязанность по предотвращению — аутентифицировать клиентское соединение, ограничить принимаемые префиксы и источники, применять значимые лимиты и использовать доступные данные валидации. Обязанность по локализации — остановить дальнейшее распространение и отозвать переданные маршруты. Анализ MANRS указывает путь и рекомендует средства контроля, но эта статья не делает выводов о закрытой политике сверх этого отчёта [2]. Решающими доказательствами были бы политика сессии, входные данные маршрутов, принятые и экспортированные таблицы, время оповещений и исправленные фильтры.

Другие апстримы и принимающие сети.Их обязанности зависели от типа отношений и роли. Апстрим, не распространивший маршруты, является доказательством того, что локализация была возможна. Пир или нижестоящая сеть, получившие маршруты, контролировали собственную валидацию источника, импортную политику и выбор маршрута. Публичные коллекторы показывают часть результатов, но не каждое решение сети. Каждого оператора следует оценивать по маршрутам, видимым на его границе, и по доказательствам, которые он мог разумно использовать.

Держатели префиксов.Они определяли, существуют ли точные ROA и объекты маршрутов для их ресурсов. Эти записи могли помочь сетям отклонить источник AS55410, особенно для покрытых префиксов. Они не контролировали, использует ли каждый маршрутизатор эти данные. Их подотчётность — своевременные и точные данные авторизации, мониторинг неожиданных источников и эффективная координация с провайдерами.

RIR и системы публикации RPKI.Их обязанность — сохранять точные записи о номерных ресурсах и авторизациях, обеспечивать безопасную публикацию и операционную непрерывность. Они не принимали решения о пересылке от имени сетей. Действующий ROA — это доказательство, предоставляемое работающей политике, а не централизованная команда. Их работу следует оценивать по целостности репозитория, доступности и процедурам исправления.

Операторы IRR и системы генерации фильтров.Они контролировали целостность и доступность записей о маршрутной политике, а также механизмы превращения записей в фильтры. Эти данные могут дополнять RPKI и клиентские учётные записи, но устаревшие или слабо аутентифицированные объекты ослабляют контроль. Провайдеры по-прежнему отвечают за то, как они проверяют и внедряют сгенерированные фильтры.

RIPE RIS и RouteViews.Их обязанность — целостность наблюдений, сбор с временными метками, документация и доступ к доказательствам. Они сделали внешнее состояние маршрутов доступным для проверки и поддержали независимый анализ. Они не авторизовали AS55410, не выбирали маршруты для пользователей и не принуждали к отзыву. Их роль — слой доказательств.

MANRS и технические аналитики.Их роль — интерпретировать наблюдения, разъяснять нормы и рекомендовать операционные средства контроля. Материалы MANRS подчёркивают важность фильтрации, защиты от подмены адресов, координации и информации о маршрутизации [18]. Это важные операционные ожидания, а не судебное заключение или предписание регулятора. Аналитики должны раскрывать методы и отличать доказательства от предположений.

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

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

Как выглядит проверяемое устранение проблемы

Исправление на стороне источника должно привязать анонсирование маршрутов к утверждённому реестру, отклонять неожиданное перераспределение, ограничивать масштаб экспорта и сравнивать фактические анонсы с намерениями. Тест должен попытаться ввести неавторизованный префикс в контролируемой среде и подтвердить, что он не может попасть во внешнюю сессию.

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

Исправление в области отношений должно определить роль «клиент», «пир» и «провайдер» для каждой сессии и применить явную политику импорта и экспорта. Там, где это поддерживается, BGP Roles и OTC могут добавить доказательства на уровне протокола. Тест должен подтвердить, что маршрут не может пересечь отношение способом, запрещённым политикой.

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

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

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

Проверка подотчётности фильтрации на апстримах

Инцидент с AS55410 — прямая проверка подотчётности сетевой инфраструктуры, потому что весь разбор теряет смысл, если убрать BGP, отношения между AS, маршрутные реестры, RPKI, фильтрацию транзита и данные коллекторов. Это не общая история о корпоративных рисках. Речь о том, кто контролировал решения маршрутизации, превратившие аномальный источник в достижимое или недостижимое состояние сети.

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

Вторая проверка — применение правил: использовали ли работающие маршрутизаторы данные о префиксе, источнике, длине, отношениях и валидации для отклонения маршрутов вне авторизации?

Третья проверка — соразмерность: были ли лимиты префиксов и пороги аномалий достаточно близки к обычному масштабу клиента, чтобы остановить событие с десятками тысяч маршрутов, а не просто защитить память маршрутизатора?

Четвёртая проверка — наблюдение: могли ли операторы и независимые коллекторы показать, когда маршруты анонсировались, принимались, распространялись, выбирались и отзывались, с документированием ограничений каждой точки наблюдения?

Пятая проверка — локализация: мог ли каждый оператор остановить собственный вклад, не дожидаясь всех остальных, и мог ли он связаться с владельцем оставшегося неверного состояния?

Шестая проверка — устранение: доказало ли контролируемое тестирование, что тот же неавторизованный источник или ненормальный набор маршрутов теперь будет заблокирован, и сохранено ли это доказательство?

Эти проверки распределяют ответственность, не делая вид, что один реестр или стандарт управляет интернетом. Записи о номерных ресурсах устанавливают факты. RPKI усиливает доказательства источника. Данные IRR и клиентские записи сужают набор принимаемых маршрутов. BGP Roles выражают отношения. Коллекторы сохраняют наблюдения. Ничто из этого не работает, пока операторы не встроят это в работающие системы.

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

Событие также показывает, что ответственность может быть распределённой, не становясь расплывчатой. AS55410 контролировала анонсирование. AS9498 контролировала клиентскую границу, указанную в анализе MANRS. Другие сети контролировали собственный приём. Держатели префиксов контролировали записи авторизации. Коллекторы контролировали качество доказательств. У каждой роли есть ограниченный вопрос и соответствующий артефакт.

Заключение

Маршрутный инцидент Vodafone Idea 2021 года не следует сводить к одному впечатляющему числу префиксов или одному спорному ярлыку. Его значение — в цепочке средств контроля, которую он обнажил. Исходная AS анонсировала необычный набор источников. По крайней мере один апстрим распространил их достаточно широко, чтобы они стали видны в публичных системах наблюдения. Другие апстримы приняли иные решения. Тысячи покрытых префиксов могли нести доказательства RPKI, но большинство всё равно зависело от клиентских фильтров, лимитов и операционных решений.

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

Поэтому подотчётность следует измерять воспроизводимыми решениями. Какие префиксы источнику было разрешено анонсировать? Что апстрим разрешил отправлять клиенту? Какие сигналы валидации и отношений использовались? Когда мониторинг обнаружил противоречие? Какие маршруты были отозваны, где они оставались видимыми и какой тест доказывает устранение?

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

Утечка маршрутов Vodafone Idea в 2021 году сделала фильтрацию апстримов проверкой подотчётности

Почему это важно