Утечка DDoS-защиты 2025 года превратила границы ролей BGP в проверку подотчётности

Резюме

• Kentik сообщила, что начиная с 07:35 UTC 1 апреля 2025 года автономная система AS3223 провайдера защиты от DDoS-атак Voxility передала транзитному провайдеру Lumen (AS3356) маршруты, полученные от пиров. По реконструкции Kentik, событие длилось около 20 минут и затронуло 31 258 маршрутов, из которых 7 381 видели как минимум 50 пиров, передающих данные в публичную систему коллекторов маршрутов RouteViews [1].

• Это была утечка путей или связностей, а не простой случай, когда чужая автономная система ошибочно объявила чужой префикс. Источники маршрутов могли оставаться легитимными, тогда как промежуточное звено пути нарушало задуманные отношения. Именно это различие объясняет, почему проверки источника маршрута (Route Origin Validation, ROV) оказалось недостаточно [1][15][16].

• Kentik использовала сообщения BGP из RouteViews и агрегированные данные о трафике, чтобы показать примеры с префиксами TPG Telecom и Yahoo, а также трафик, который был либо ошибочно направлен по утёкшему пути, либо потерян. Эти наблюдения убедительны, но ограничены: они не показывают все затронутые сети и точное перегруженное звено [1][8].

• Сети защиты от DDoS-атак — трудная, но не необязательная проблема фильтрации. Они могут легитимно передавать маршруты для большого и меняющегося набора клиентов. Поэтому подотчётность зависит от учёта отношений при выделении ресурсов, явных политик импорта и экспорта, контроля аномалий по числу маршрутов, использования ролей BGP и атрибута Only-to-Customer там, где они доступны, а также от доказательств, которые сохраняют и провайдер защиты, и его транзитные соседи [12][13][14][16][17].

• Статья не утверждает наличие злого умысла, нарушения закона, всеобщего сбоя или известной внутренней первопричины. В ней ставится вопрос: какие записи должны существовать у AS3223, AS3356, пиров, затронутых сетей и коллекторов маршрутов, чтобы доказать границы события, его влияние, отзыв маршрутов и долговременное исправление.

Что произошло

Видимое событие началось в 07:35 UTC 1 апреля 2025 года. Kentik сообщила, что Voxility, обозначенная номером автономной системы AS3223, начала анонсировать своему транзитному провайдеру Lumen (AS3356) маршруты, полученные от пиров. Пиром обычно называют сеть, с которой другая сеть обменивается трафиком для своих клиентов, не предоставляя полный транзит в интернет. Транзитный провайдер передаёт трафик в сторону более широкого интернета.

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

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

Kentik описала инцидент как ошибку пути, а не как ошибочное объявление источника маршрута. Компания насчитала 31 258 утёкших маршрутов, из которых 7 381 видели как минимум 50 пиров RouteViews, и заявила, что инцидент длился до 20 минут [1]. Эти цифры следует сохранять с указанием источника. Они не являются переписью всех маршрутизаторов интернета. RouteViews — это набор точек наблюдения BGP, предоставляемых участвующими сетями. Маршрут, видимый многим коллекторам, свидетельствует о широком распространении, но набор коллекторов всё равно остаётся выборкой [8].

Примеры путей делают сбой отношений конкретным. До утечки одна из лент RouteViews, предоставленная калифорнийской научно-образовательной сетью CENIC, показывала префикс TPG Telecom, следовавший по пути через Tata и Lumen. Во время инцидента тот же префикс появлялся за AS3223 и AS3356, причём значения сообществ Kentik интерпретировала как клиентский маршрут, полученный в Бухаресте. Другой пример касался префикса Yahoo, который обычно достигал GTT через PCCW, но во время утечки наблюдался через AS3356 и AS3223 [1][7]. Эти примеры показывают изменённый фактический путь.

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

Kentik также изучила агрегированные данные NetFlow. NetFlow — это сводка потоков трафика, записываемая сетевыми устройствами. Анализ показал, что трафик направлялся по путям, содержащим AS3356 и AS3223, в сторону пунктов назначения в нескольких странах. Кроме того, компания сравнила трафик с подмножеством наиболее заметных утёкших маршрутов и обнаружила как меньшую ошибочно направленную часть, так и более значительные нарушения или потери. Kentik прямо заявила, что точное узкое место на пути неизвестно [1]. Эта неопределённость важна.

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

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

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

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

Такая широта делает наивный список разрешённых маршрутов трудным. Kentik сослалась на развёрнутый bgp.tools набор AS-SET для AS3223, который включал десятки тысяч автономных систем и сотни тысяч IPv4- и IPv6-префиксов [1][3]. AS-SET — это объект реестра интернет-маршрутизации (Internet Routing Registry), объединяющий автономные системы для формирования политик. Такие объекты помогают автоматизировать фильтры, но крупные вложенные наборы могут стать слишком широкими, чтобы выражать осмысленную границу отношений.

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

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

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

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

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

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

Технический слой: действительность источника не равна действительности пути

BGP обменивается информацией о достижимости между автономными системами. Автономная система, или AS, — это сеть под единой административной политикой маршрутизации, идентифицируемая номером ASN. Объявление BGP включает IP-префикс, AS_PATH и другие атрибуты. AS_PATH перечисляет автономные системы, через которые прошло объявление маршрута. Маршрутизаторы используют локальную политику, длину пути и другие атрибуты для выбора маршрутов [10].

Безопасность источника проверяет, стоит ли правильный ASN у начала пути. Инфраструктура открытых ключей ресурсов (Resource Public Key Infrastructure, RPKI) позволяет держателю ресурса создать авторизацию источника маршрута (Route Origin Authorization, ROA), которая указывает, какой ASN может объявлять префикс. Проверка источника маршрута (Route Origin Validation) сравнивает полученный источник с этими авторизациями [15][16]. Это ценно, потому что позволяет отклонить или понизить приоритет маршрута с неавторизованным источником.

Событие апреля 2025 года не зависело от подмены легитимных источников. В примерах путей источники пунктов назначения сохранялись, а AS3223 вставлялась как непреднамеренный посредник. Kentik не обнаружила практически новых более специфичных маршрутов и пришла к выводу, что ROV не ограничила бы этот класс событий [1]. Поэтому контрольный вопрос смещается с авторизации источника на авторизацию распространения. Было ли AS3223 разрешено отправлять маршрут, полученный от пира, в AS3356? Было ли AS3356 разрешено принимать его как клиентский маршрут? Должны ли нижестоящие сети были распознать путь как несовместимый с ожидаемыми отношениями?

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

RFC 9234 определяет роли BGP (BGP Roles) и необязательный транзитивный атрибут Only-to-Customer, или OTC [14]. Соседние сети могут согласовывать роли — провайдер, клиент, пир, сервер маршрутов или клиент сервера маршрутов. Атрибут OTC затем несёт информацию о том, куда маршруту разрешено распространяться. В упрощённом контрфактическом сценарии, описанном Kentik, маршрут, полученный от пира и помеченный OTC, не должен приниматься AS3356 от AS3223 как клиентский маршрут [1]. Сам атрибут не доказывает, что какой-либо оператор внедрил механизм. Это основанное на стандартах описание свидетельства об отношениях, которого не хватало утёкшему пути.

Авторизация провайдера автономной системы (Autonomous System Provider Authorization, ASPA) решает другую часть проверки пути. Сеть может авторизовать своих провайдеров, давая валидаторам возможность оценивать, правдоподобны ли отношения с провайдером в пути [16]. Внедрение и проверка ASPA всё ещё остаются операционными вопросами, и статья не должна утверждать, что это детерминированно предотвратило бы именно это событие. Важно то, что безопасность маршрутизации выходит за пределы источника, потому что сбои путей и отношений требуют собственных свидетельств.

Явная политика импорта и экспорта остаётся основой. RFC 8212 меняет ожидание по умолчанию для внешних сессий BGP: маршруты не должны импортироваться или экспортироваться без настроенной политики [13]. RFC 7454 собирает практики операционной безопасности, включая фильтрацию и лимиты [12]. Эти стандарты не устраняют ошибки. Они задают отказоустойчивую по умолчанию позицию, при которой отсутствующая или неоднозначная политика не должна молча превращать сессию в обмен маршрутами для всего.

Обязанность AS3223 по доказательствам

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

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

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

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

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

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

Обязанность AS3356 по приёму

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

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

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

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

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

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

Кто пострадал и чего публичные данные не доказывают

Анализ трафика Kentik выявил доли стран назначения среди трафика, наблюдавшегося на AS-путях, содержащих утёкшую подпоследовательность, и рассмотрел подмножество наиболее заметных утёкших маршрутов [1]. Этот анализ сильнее, чем отчёт только по таблице маршрутизации, потому что связывает изменение плоскости управления с последствиями для передачи данных. Он всё же ограничен точками наблюдения клиентов Kentik, методом аннотации потоков и выбранным набором маршрутов.

Поэтому фразу «сети по всему миру» следует понимать как наблюдаемое широкое влияние, а не как утверждение, что пострадали все пользователи или все маршруты. Разные сети выбирают разные пути. Локальное предпочтение может отдавать приоритет клиентским маршрутам перед пиринговыми или провайдерскими. Добавление собственного AS к пути (AS-path prepending) может сделать один путь менее привлекательным, тогда как утёкший маршрут может выглядеть короче. География, пиринг и инжиниринг трафика влияют на то, увидит ли конкретная сеть утечку и выберет ли её.

Примеры с TPG Telecom и Yahoo показывают, что несвязанные сети назначения могли быть втянуты в путь [1][4][5][6]. Они не доказывают, что эти организации вызвали инцидент или что каждый их сервис был недоступен. Их префиксы служат объектами доказательства в анализе распространения маршрутов. Подотчётными поверхностями контроля остаются решения об экспорте, приёме и распространении вокруг утёкшего пути.

RouteViews и RIPE RIS помогают расширить представление [8][9]. RIPE RIS — ещё одна публичная платформа данных маршрутизации с коллекторами в нескольких точках. Сравнение двух систем может показать, когда и где появлялись пути, но ни одна платформа коллекторов не видит каждое решение маршрутизации. Маршрут может быть видим, но не выбран для передачи, а выбранный в одной сети путь не отражает опыт другой сети.

Точное узкое место также неизвестно. Kentik предположила, что неожиданный трафик, вероятно, перегрузил что-то на пути AS3356—AS3223, поскольку потерянный или нарушенный трафик превысил ошибочно направленный трафик, всё же достигший пункта назначения [1]. Это разумная операционная интерпретация, а не доказательство местоположения. Итоговый отчёт должен избегать указания порта, объекта или владельца ёмкости, если только записи пакетов, интерфейсов или потоков не подтверждают утверждение.

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

Записи реестров — якоря доказательств, а не вердикты

Публичные страницы ASN для AS3223 и AS3356 помогают привязать событие к стабильным идентификаторам номерных ресурсов [3][4]. Дополнительные страницы для AS7545 и AS10310 фиксируют источники примеров [5][6]. Эти записи полезны, потому что названия компаний, владение и описания услуг могут меняться, тогда как идентификаторы автономных систем остаются частью доказательств маршрутизации.

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

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

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

Средства контроля, которые должны были остановить или сократить утечку

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

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

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

Четвёртый контроль — согласованные роли BGP и OTC там, где реализация и поддержка пиров это позволяют [14]. Эти механизмы позволяют обеим соседним сетям подтвердить отношение и несут сигнал, помогающий обнаружить маршруты, движущиеся в запрещённых направлениях. Внедрение следует измерять по каждой сессии. Заявление в политике о поддержке ролей не доказывает, что граница AS3223—AS3356 использовала их 1 апреля 2025 года.

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

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

Седьмой контроль — мониторинг публичных коллекторов. RouteViews и RIPE RIS дают взгляд снаружи, который может поймать несоответствие между намеченными и фактическими объявлениями [8][9]. Операторам следует отслеживать неожиданное появление собственного ASN в путях, а не только неавторизованные источники. Предупреждение о пути может выявить утечку, которую мониторинг только источников пропустит.

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

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

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

Что должно взять на себя руководство

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

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

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

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

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

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

За чем следить дальше

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

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

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

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

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

Шестой сигнал — фильтрация клиентов транзитными провайдерами. Крупные операторы должны раскрывать достаточно сведений о своей позиции по безопасности маршрутизации, чтобы показать, что клиенты с большим объёмом защиты не получают неограниченные привилегии распространения. Рекомендации MANRS дают операционный базовый уровень для предотвращения неверных объявлений и поддержания контактной информации [2][17].

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

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

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

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

Изменения сценария

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

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

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

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

Источники

1. https://www.kentik.com/blog/beyond-their-intended-scope-ddos-mitigation-leak/
2. https://manrs.org/2025/03/beyond-their-intended-scope-ddos-mitigation-leak/
3. https://bgp.tools/as/3223
4. https://bgp.tools/as/3356
5. https://bgp.tools/as/7545
6. https://bgp.tools/as/10310
7. https://www.cenic.org/
8. https://www.routeviews.org/routeviews/
9. https://ris.ripe.net/docs/
10. https://www.rfc-editor.org/rfc/rfc4271
11. https://www.rfc-editor.org/rfc/rfc7908
12. https://www.rfc-editor.org/rfc/rfc7454
13. https://www.rfc-editor.org/rfc/rfc8212
14. https://www.rfc-editor.org/rfc/rfc9234
15. https://www.rfc-editor.org/rfc/rfc6811
16. https://www.rfc-editor.org/rfc/rfc8893
17. https://manrs.org/isps/guide/
18. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/