Утечка маршрутов Safe Host: тест на трансграничную подотчётность

Основные положения

Границы события зафиксированы:В этой статье рассматривается утечка маршрутов от Safe Host (AS21217) в China Telecom (AS4134), наблюдавшаяся 6 июня 2019 года, и непосредственные свидетельства распространения и восстановления. Событие не объединяется с отдельной утечкой 24 июня 2019 года с участием Verizon, DQE и Cloudflare или с другими инцидентами маршрутизации China Telecom.
Подсчёты требуют указания источника:В публичных отчётах встречаются цифры более 70 000 маршрутов, в другой реконструкции — более 40 000 префиксов IPv4. Числа зависят от коллектора, временного интервала, семейства адресов, обработки дубликатов и того, что аналитик считает частью события. Никакое отдельное число не следует представлять как универсальную общепринятую оценку.
Путь в плоскости управления не является фактом слежки:Данные коллекторов и измерений могут показать, что AS4134 появилась в наблюдаемых путях и что часть трафика пошла по неожиданным маршрутам с определённых точек наблюдения. Сами по себе они не доказывают физическое местонахождение каждого пакета, инспекцию пакетов, доступ к данным или злой умысел.
Ответственность следует за операционным контролем:Safe Host контролировал, что экспортирует AS21217. China Telecom контролировала, что принимает и распространяет AS4134. Другие транзитные сети и сети доступа контролировали собственный импорт, предпочтения, дальнейший экспорт, мониторинг и эскалацию. Конечные пользователи не имели практических средств исправить состояние маршрутов.
Неопределённость отношений должна оставаться видимой:Публичное обсуждение операторов не привело к однозначной коммерческой классификации связи Safe Host–China Telecom. Наблюдаемый сбой подотчётности — это распространение за пределы предполагаемого охвата, а не ретроспективное утверждение, что все частные условия контракта известны.
Данные реестров необходимы, но не являются самодостаточным средством принуждения:Записи об ASN, адресах, IRR и RPKI идентифицируют ресурсы и ожидаемые источники. Они не могут закодировать каждое отношение или заставить маршрутизатор отвергнуть непредусмотренный путь. Действующая политика определяла, какие анонсы становились достижимыми путями.
RPKI решает лишь часть проблемы:Валидация источника маршрута может отклонить конфликтующий источник при наличии действительного ROA. Утечка маршрута может сохранить авторизованный источник, проходя через непредусмотренного провайдера, пира или клиента. Остаются необходимыми фильтры, учитывающие отношения, валидация «конуса клиентов», контроль максимального числа префиксов, явные умолчания, мониторинг и координация.
Восстановление требует независимых доказательств:Локальное исправление конфигурации не является полным протоколом восстановления. Подотчётное исправление показывает отзывы, новые пути, сходимость с разных точек наблюдения, остаточные исключения, обновлённые фильтры, проверенные оповещения и воспроизведение, демонстрирующее, что тот же класс анонсов теперь отклоняется или ограничивается.

Зафиксируйте границы события, прежде чем распределять ответственность

Инфраструктурная подотчётность начинается с фиксации границ события. 6 июня 2019 года публичные наблюдатели маршрутизации сообщили, что Safe Host, автономная система 21217, анонсировала очень большой набор маршрутов в China Telecom, автономную систему 4134, через стык во Франкфурте. China Telecom приняла эти анонсы и распространила их. Для некоторых наблюдаемых сетей и точек наблюдения AS4134, как следствие, появилась в путях, которые обычно не включали бы её. Современные и более поздние отчёты связывали событие с нарушением или ухудшением доступности, затронувшим части европейской мобильной и сервисной инфраструктуры. [1][2][3][4][5][6][7]

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

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

Дата важна, потому что июнь 2019 года содержал и другие инциденты маршрутизации. Более поздняя утечка с участием Verizon, DQE и Cloudflare затрагивала другие сети, механизмы и последствия для сервисов. Объединение этих событий создало бы драматичную историю, но слабый протокол подотчётности. Владелец исправления не может устранить инцидент, у которого набор маршрутов, временной интервал, границы отношений и ответственные средства контроля смешаны с другим событием.

Поэтому точный вопрос таков: каким образом экстраординарный набор маршрутов покинул AS21217, почему AS4134 приняла и распространила эти маршруты, как реагировали другие сети, какие свидетельства показывают произошедшие изменения путей и какие доказательства подтвердили бы, что состояние маршрутов было отозвано и ограничено от повторения?

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

Разногласия по числу маршрутов — это проблема доказательств, а не повод игнорировать событие

В публичных описаниях обычно говорится, что AS21217 допустила утечку более 70 000 маршрутов и что событие длилось более двух часов. Другая реконструкция инцидента описывает более 40 000 префиксов IPv4. [1][2][4][5] Эти цифры не обязательно исключают друг друга. Они могут отражать различия в коллекторах, адресных семействах, временных окнах, способах подсчёта обновлений и префиксов, дедупликации путей и определениях того, какие анонсы относятся к событию.

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

Поэтому подотчётное освещение требует протокола подсчёта. Защитимый отчёт об инциденте должен содержать:

какие коллекторы (RouteViews, RIPE RIS, операторские) или измерительные точки использовались;
точные временные метки начала и окончания и стандарт времени;
включались ли и IPv4, и IPv6;
считает ли метрика уникальные префиксы, обновления, варианты путей или источники;
как обрабатывались дублирующиеся анонсы и замены маршрутов;
какой шаблон AS-пути определял затронутый маршрут;
как отзывы и последующие нормальные пути сопоставлялись с аномальным набором; и
какие части сети остались вне наблюдения.

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

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

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

Утечка маршрутов — это исполнимый отказ политики отношений

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

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

Впоследствии RFC 7908 представил таксономию маршрутов, распространённых за пределы предполагаемого охвата. [14] Ценность этой таксономии в том, что она фокусируется на наблюдаемом распространении и политике отношений, не предполагая злого умысла. Обсуждение операторов вокруг события 2019 года не установило единого ярлыка отношений или одного бесспорного типа утечки. [8][9] Эта неопределённость должна остаться в протоколе.

Однако основное внешнее поведение всё же видимо. AS21217 распространила набор маршрутов, масштаб и размах которого не соответствовали узким ожиданиям от стыка. AS4134 приняла и экспортировала достаточную часть этого набора, чтобы пути распространились. Затем другие сети применили свою собственную политику: одни приняли путь, другие могли предпочесть его, третьи распространили, четвёртые отфильтровали, а пятые сохранили незатронутые альтернативы.

Называть это распределённым отказом не значит делать его бесхозным. Safe Host контролировал границу экспорта на AS21217. China Telecom контролировала первую видимую границу импорта и дальнейшего экспорта на AS4134. Каждая последующая автономная система контролировала, попадёт ли путь в её информационную базу маршрутизации, станет ли выбранным путём, войдёт ли в таблицу пересылки и будет ли объявлен дальше. Коллекторы маршрутов контролировали качество и сохранность независимых доказательств. Сервисные операторы и операторы доступа контролировали устойчивость и информирование пользователей.

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

Поэтому фраза «BGP принял маршруты» неполна. Программное обеспечение, выполняющее сконфигурированную политику, приняло маршруты. Протокол перенёс анонс; ограничения определили операторы.

Подотчётность экспорта начинается с авторизованного контракта маршрутов

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

Для AS21217 отчёт о подотчётности после события должен различать как минимум четыре набора:

маршруты, которые Safe Host был уполномочен порождать;
клиентские маршруты, которые Safe Host был уполномочен транзитить;
широкие маршруты, полученные от другого провайдера или пира;
маршруты, которые политика от AS21217 к AS4134 фактически экспортировала во время события.

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

Политика экспорта должна по умолчанию запрещать анонсирование до тех пор, пока не будет присоединена предполагаемая политика. RFC 8212 формализует операционную ценность явной политики импорта и экспорта eBGP. [15] Позиция «по умолчанию отклонять» не решает все ошибки генерации или присоединения, но устраняет опасное предположение, что новая или неправильно классифицированная сессия должна обмениваться всем, пока кто-то не добавит фильтры.

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

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

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

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

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

Подотчётность импорта — это первая возможность внешнего сдерживания

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

Поэтому AS4134 важна независимо от AS21217. Публичные доказательства подтверждают, что China Telecom приняла и распространила экстраординарный набор маршрутов. Протокол не раскрывает каждый фильтр или внутреннее решение, но наблюдаемый результат показывает, что средства контроля импорта и дальнейшего экспорта не сдержали событие на этой границе.

Импортёр, учитывающий отношения, может сочетать несколько средств контроля.

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

Во-вторых, ограничения AS-пути могут проверять, правдоподобен ли анонс для данных отношений. Клиент, как правило, не должен объявлять путь, подразумевающий транзит между несвязанными провайдерами. Данные о «конусе клиентов» несовершенны, поэтому исключения и неопределённость требуют операционной обработки, но несовершенные данные об отношениях всё же могут помочь в обнаружении и проверке.

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

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

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

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

Импортёр также контролирует дальнейший экспорт. Даже если маршрут сохранён для диагностики, его не обязательно распространять клиентам, пирам и провайдерам. Разделение контроля приёма, выбора, пересылки и объявления может не дать одному отказу превратиться в распределённое событие.

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

Доказательства AS-пути нельзя путать с доказательствами о каждом пакете

Трансграничный характер события вызвал понятную озабоченность. Публичный анализ показал, что AS4134 появлялась в путях к сетям, связанным с европейскими мобильными операторами и сервисами. Отчёты об измерениях также описывали трафик, следующий по неожиданным путям с определённых точек наблюдения. [1][2][3][4][5][7]

Необходимо чётко различать четыре уровня доказательств.

Первый —распространение в плоскости управления. Обновление BGP, наблюдаемое коллекторами RouteViews, RIPE RIS или другими, показывает, что путь был анонсирован пиру этого коллектора. Оно подтверждает утверждения о видимости маршрута в определённое время и с определённой точки.

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

Третий —поведение пересылки. Выбранный маршрут может войти в таблицу пересылки и нести трафик, но для проверки пути от конкретного источника необходимы traceroute или активные измерения. Даже тогда IP-геолокация, скрытые хопы, MPLS, асимметричная маршрутизация, балансировка нагрузки и различия в обратных путях ограничивают выводы.

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

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

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

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

Коллекторы маршрутов — это инфраструктура подотчётности с известными слепыми зонами

RouteViews и RIPE RIS предоставляют незаменимые независимые доказательства для междоменных инцидентов. Их архивы за июнь 2019 года и документация измерений делают возможной последующую реконструкцию. [12][13] RIPEstat также предоставляет поверхность доказательств для AS21217 и AS4134, хотя современные записи нельзя проецировать назад без оговорок. [10][11]

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

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

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

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

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

Записи реестров — это бухгалтерские книги, а не принуждение маршрутизаторов

Событие Safe Host непосредственно затрагивает поверхность контроля маршрутизации BGP, данные реестров ASN и IP, а также пиринговые или транзитные отношения.

Запись ASN может идентифицировать AS21217 и AS4134. Адресные реестры — распределения и назначения. Объекты Internet Routing Registry (IRR) могут публиковать предполагаемые источники и политику. RPKI может предоставить подписанную авторизацию источника. Эти записи улучшают уникальность, точность, историю передачи, метаданные безопасности и операционную координацию.

Они не определяют действующий путь.

Запись реестра не знает всех частных коммерческих отношений. Объект IRR не заставляет маршрутизатор загрузить сгенерированный фильтр. ROA говорит, какой источник авторизован для префикса и максимальной длины; он не говорит, какие провайдеры или пиры могут нести этот маршрут. Abuse- یا NOC-контакт не гарантирует, что оповещение достигнет лица с полномочиями отзывать маршруты.

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

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

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

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

Изъятие из этой статьи AS21217, AS4134, анонсов BGP, политики отношений, коллекторов маршрутов и доказательств отзыва разрушает тезис. Поверхность контроля сети — не метафора, добавленная к общему корпоративному инциденту. Она и есть инцидент.

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

RPKI и валидацию источника маршрута часто предлагают после инцидентов маршрутизации. Они заслуживают точного рассмотрения.

RFC 6811 описывает, как маршрутизатор может классифицировать маршрут относительно проверенных данных ROA. [16] Маршрут может быть валидным, невалидным или не найденным в зависимости от объявленного источника, префикса, максимальной длины и доступных проверенных записей. Отклонение или депреференция невалидных маршрутов может предотвратить некоторые неправильные указания источника и перехваты.

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

Это ограничение — не аргумент против RPKI. Это аргумент в пользу многоуровневых средств контроля.

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

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

Та же осторожность применима к более поздним стандартам и практикам. RFC 8212, действия MANRS и руководство NIST предоставляют полезные рамки контроля. [15][17][18] Их следует использовать для проектирования сегодняшнего исправления, а не для изобретения доказательств того, что каждый оператор развернул или был обязан по контракту во время события.

Лимиты максимального числа префиксов необходимы, но ими легко злоупотребить

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

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

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

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

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

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

Другие сети по-прежнему контролируют собственный приём и распространение

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

Далее расположенная транзитная сеть может не знать частных деталей исходных отношений Safe Host–China Telecom. Но она всё равно может спросить, правдоподобен ли путь, авторизован ли источник маршрута, аномален ли объём, конфликтует ли путь с данными «конуса клиентов» и сообщают ли независимые источники об утечке.

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

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

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

Регуляторам и заказчикам следует избегать считать все эти стороны взаимозаменяемыми. Самые эффективные вопросы следуют за маршрутом:

Что эта сеть получила?
Что она приняла?
Что она выбрала?
Что она переслала?
Что она объявила дальше?
Какая политика и доказательства управляли каждым решением?
Какое оповещение сработало, кто им владел и какое действие последовало?
Как сеть доказала, что аномальное состояние было отозвано?

Такой маршрутно-ориентированный метод делает распределённую ответственность конкретной, не делая вид, что каждый оператор имел одинаковую видимость или полномочия.

Трансграничную устойчивость следует проектировать, а не выводить из названий провайдеров

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

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

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

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

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

Надёжный протокол восстановления доказывает отзыв и нормализацию

Публичные отчёты указывают, что аномальная маршрутизация сохранялась более двух часов по некоторым наблюдениям до нормализации путей. [1][2][4][5][7] Как и с подсчётами маршрутов, точная продолжительность зависит от точки наблюдения и определения. Последний аномальный маршрут у одного наблюдателя может не отражать глобальную сходимость.

Подотчётный протокол восстановления должен различать:

когда начался запускающий экспорт;
когда первый внешний наблюдатель обнаружил его;
когда оповещение достигло ответственной команды;
когда Safe Host изменил или отключил экспорт;
когда AS4134 прекратила принимать или распространять маршруты;
когда прямые соседи зафиксировали отзывы;
когда крупные коллекторы вернулись к ожидаемым путям;
когда пересылка и работоспособность сервисов нормализовались; и
когда остаточные устаревшие или исключительные маршруты были удалены.

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

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

Ни одно из этих наблюдений в отдельности не доказывает универсальную сходимость. Вместе они образуют ограниченный, проверяемый протокол.

Отчёт также должен указать, что изменилось на постоянной основе. Примеры:

исправленная роль сессии или привязка route-map;
сгенерированный фильтр авторизованных префиксов;
ограничение по «конусу клиентов» или пути;
сниженные предупредительный и жёсткий пороги максимального числа префиксов;
явная политика «по умолчанию отклонять»;
валидация RPKI и поддержка ROA;
ответственное оповещение об аномалиях;
улучшенные контактные данные и данные для эскалации;
канареечный или поэтапный процесс развёртывания; и
тест воспроизведения с использованием исторического шаблона маршрута.

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

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

Тест на повторяемость важнее заявления о политике

Самое сильное доказательство того, что исправление работает, — это контролируемое воспроизведение класса отказа.

Тестовая среда должна воспроизводить сессию с соответствующей ролью отношений и замороженным ожидаемым набором маршрутов. Затем следует внедрить:

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

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

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

Тест также должен включать отказ самого средства контроля. Что произойдёт, если лента IRR устарела, валидатор RPKI недоступен, компилятор политик выдал ошибку или коллектор мониторинга потерял сессию? Решения «отказ-закрыто» и «отказ-открыто» должны быть осознанными и привязанными к критичности сервиса.

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

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

Вопросы управления должны следовать за контролем, а не за заголовками

Советы директоров, регуляторы, заказчики и аудиторы могут задавать действенные вопросы, не притворяясь, что управляют сессиями BGP.

Советы директоров должны спросить:

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

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

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

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

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

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

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

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

Тест на подотчётность — это ограниченное распространение и проверяемое восстановление

Событие Safe Host 6 июня 2019 года остаётся поучительным, поскольку соединяет техническую политику маршрутизации с трансграничными последствиями.

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

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

Ответственность остаётся конкретной. Экспортёр контролировал набор маршрутов. Прямой импортёр контролировал первую границу сдерживания. Другие сети контролировали дальнейшее распространение и устойчивость. Операторы мониторинга контролировали доказательства. Сервис-операторы контролировали реагирование на воздействие на пользователей. Конечные пользователи несли последствия без полномочий над состоянием BGP.

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

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

Поэтому заслуживающий доверия оператор должен быть способен доказать четыре вещи:

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

Это тест на фильтрацию пиров и трансграничную подотчётность, который выявила утечка Safe Host. Стандарт — не идеальное предотвращение. Это ограниченное распространение, назначенный контроль, воспроизводимые доказательства и восстановление, которое можно проверить за пределами сети, делающей заявление.

Утечка маршрутов Safe Host в 2019 году: почему фильтрация пиров стала тестом на трансграничную подотчётность

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