ИИтог

IPinfo: доля RPKI-валидных маршрутов выросла с 54% до 70%, во многом из-за Китая

безопасностьРедакция ИИтогHacker News🔥70Рейтинг ИИтог70Влияние55Новизна55Релевантность85Неожиданность55Участники20Достоверность85

Компания IPinfo опубликовала в своём блоге разбор года внедрения RPKI и ASPA, механизмов защиты глобальной маршрутизации (протокол BGP), которая исторически держалась на доверии. Классический пример сбоя: 24 февраля 2008 года Pakistan Telecom (AS17557) попыталась заблокировать YouTube внутри Пакистана, анонсировав более специфичный маршрут для адресов YouTube. Её вышестоящий провайдер PCCW Global (AS3491) принял анонс и передал дальше, из-за чего трафик YouTube по всему миру примерно на два часа ушёл в Пакистан. Именно такие ошибки и должна предотвращать RPKI: владелец блока IP-адресов публикует подписанную запись ROA (Route Origin Authorization) со списком сетей (автономных систем, AS), которым разрешено этот блок анонсировать, а операторы могут отбрасывать анонсы, не прошедшие проверку.

Главная цифра: доля маршрутизируемых префиксов, признанных RPKI-валидными, выросла с 54,0% в сентябре 2025 года до 70,3% в сентябре 2026-го, на 16,4 процентного пункта, или на 30% за год. В каждый из двух предыдущих лет рост составлял три-четыре пункта. Значительная часть скачка приходится на одну страну: доля IPv4-адресов Китая в валидных маршрутах выросла с 3,7% до 83,0%, это почти 60% глобального прироста по адресам. Если считать по IPv4-адресам на 28 сентября каждого года, доля в валидных маршрутах составляла 42,7% (2023), 47,9% (2024), 53,1% (2025) и 65,0% (2026); последний скачок, 11,9 пункта против примерно пяти в прежние годы. Без Китая доля выросла с 58,0% до 63,2% (на 5,2 пункта, чуть меньше, чем годом ранее). У самого Китая к концу декабря 2025 года валидными были лишь 2,9% маршрутизируемых префиксов, то есть основная часть перемен пришлась на 2026 год. В 2025-м Китай тянул мировой показатель вниз (53,1% против 58,0% без него), в 2026-м, вверх (65,0% против 63,2%). Среди других стран: Египет с 23% до 99%, Казахстан с 16% до 84%, Мексика с 37% до 78%, ЮАР с 38% до 60%. Из всего маршрутизируемого IPv4-пространства вне валидных маршрутов почти 60% находится в США, и примерно каждый четвёртый такой адрес принадлежит Министерству обороны США (в основном это пространство, которое ведомство начало анонсировать в 2021 году, чтобы отслеживать злоупотребления, а не для работы сервисов). Для IPv6 доля валидных префиксов за период выросла с 56% до 79%, для IPv4, с 54% до 68%: IPv6 обогнал IPv4 примерно на десять пунктов, хотя в обзоре RPKI за 2024 год для RIPE Labs Джоб Снийдерс (Job Snijders) отмечал, что рост IPv6 ROA «похоже, застопорился».

Авторы проверили, работает ли RPKI на практике. Типичный валидный префикс видят 596 маршрутизаторов из тех, что передают данные публичным коллекторам RIPE RIS и RouteViews; префикс без RPKI-записи, 595; невалидный, всего два. Почти половину невалидных маршрутов видит лишь одна точка наблюдения, а когда адреса анонсирует «не та» сеть (самый явный случай угона или ошибки), 71%. Отсюда вывод для чтения страновой статистики: простой подсчёт невалидных маршрутов сильно преувеличивает масштаб проблемы. У Испании самая высокая доля невалидных IPv4-префиксов, 28,2%, но если считать адреса в таких маршрутах с поправкой на число точек наблюдения, получается 0,057%. У Словакии доля падает с 17,4% почти до нуля. Среди стран хотя бы с миллионом IPv4-адресов самый высокий взвешенный показатель у Италии, 0,121% (годом ранее 0,075%), и 90% его даёт одна сеть. WIND TRE (AS1267) анонсирует 34 маршрута из собственного адресного пространства, которые не разрешены её же ROA: 19 более специфичны, чем допускают записи, и 15 исходят от AS1267, тогда как в ROA указана другая сеть оператора, AS24608. Ни один из них не виден более чем 77 точкам наблюдения против примерно 617 у окружающих подписанных блоков.

Уязвимость в самой схеме: RPKI проверяет, кому разрешено анонсировать префикс, но не проверяет путь. 28 августа 2026 года появился маршрут для 162.55.80.0/24 (256 адресов) с подделанным источником, AS24940 Hetzner. ROA Hetzner покрывала окружающий блок /16 и допускала анонсы вплоть до /24, поэтому подделка оказалась RPKI-валидной; легитимного /24 для конкуренции не существовало, а правило самого длинного совпадения префикса сделало этот маршрут предпочтительным. Этого хватило, чтобы получить настоящий TLS-сертификат и отдать гипервизорам вредоносное обновление Virtualizor (случай описала компания Kentik). По словам авторов, RPKI не подвела: ROA это разрешала. Они измерили, насколько распространена такая «широкая» настройка: из 855 217 IPv4-маршрутов с RPKI-покрытием у 138 698 (16,2%) ROA шире анонсируемого маршрута, и более специфичного маршрута, закрывающего зазор, нет; для IPv6 доля 20,9%. Это примерно 18 миллионов более специфичных префиксов, которые атакующий мог бы анонсировать, подделать источник и остаться RPKI-валидным и без конкурентов. Операторы ведут себя по-разному: у хостинг-провайдера Contabo «открытое окно» на 540 из 553 покрытых маршрутов, у DigitalOcean, на 780 из 863, у OVH, 11,5%; среди провайдеров доступа хуже всего Cablevision (98,1%), Shaw (96,5%) и Bharti Airtel (85,0%). RFC 9319 уже называет наилучшей практикой не задавать maxLength (параметр, позволяющий ROA покрывать и более мелкие блоки внутри себя). После инцидента Hetzner ужесточила три префикса, включая угнанный, но 49 из её 63 покрытых маршрутов остаются открытыми.

Кроме того, RPKI-покрытие может тихо исчезать. Доля IPv4-адресов Маврикия в валидных маршрутах упала с 94,0% до 69,0%: SEACOM (AS37100) 1 января потерял четыре из шести ROA, и одна из них покрывала 105.16.0.0/12 (около миллиона адресов, 46% из них на Маврикии); на 28 сентября записи для неё всё ещё не было. Saudi Telecom (AS25019) лишилась защиты на 19 маршрутах, включая шесть крупных блоков примерно на 1,6 миллиона адресов (ROA пропали между 30 марта и 13 апреля), а покрытие Саудовской Аравии восстановилось, когда записи вернулись 21 и 22 сентября. В Марокко Orange Maroc (AS36925), единственный крупный оператор, публикующий ROA, и большинство его записей дважды пропадали (с июля 2025 по июль 2026 и с 25 июля по 3 сентября): покрытие страны упало с 20% почти до нуля и вернулось. Отдельная ловушка измерений: некоторые методы проверки считают запись сбойной, хотя она продолжает защищать, например, когда после переноса репозитория ссылка на вышестоящий сертификат устарела, а реальная валидация, которой пользуются маршрутизаторы, идёт сверху вниз от якорей доверия и эту ссылку не использует. Авторы нашли тысячи записей, помеченных как сбойные, но присутствовавших во всех проверенных независимых наборах, а их маршруты оставались валидными; число сбойных записей, не мера потерянной защиты.

Наконец, ASPA (Autonomous System Provider Authorization), подписанная запись сети со списком её разрешённых вышестоящих провайдеров, позволяющая ловить утечки маршрутов, которые проверка источника пропускает. Внедрение раннее, но быстрое: 28 сентября 2025 года записи опубликовали 131 сеть, 28 сентября 2026-го, 3 272 (в 25 раз больше). Рост идёт ступенями вслед за тем, как реестры дают возможность подписывать ASPA (RIPE NCC около 85 сетей до конца ноября и 470 к концу декабря; ARIN, с 21 января; APNIC, с конца июня и снова в сентябре), так что главным драйвером авторы называют инструменты. На 28 сентября 2026 года ASPA-проверку проходили 9,7% наблюдаемой маршрутизации (6,2% годом ранее), но большую часть даёт автоматика: по черновым правилам путь через одну-две сети проходит всегда, а таких путей около 6%. Без них опубликованные записи подтверждают около 3,5% маршрутизации против примерно 0,1% год назад. Почти всё остальное не «проваливает» проверку, а остаётся неизвестным. Доля путей, нарушающих правила ASPA в середине пути, выросла с практически нуля до 0,048% наблюдений, по оценке авторов, это не обязательно ухудшение маршрутизации: по мере роста публикаций ранее не поддававшиеся оценке пути стали проверяемыми, и часть не прошла проверку. Текст источника в доступной части обрывается на разборе того, каких сетей это касается.

Ключевые факты

  • Доля маршрутизируемых префиксов, валидных по RPKI, выросла с 54,0% (сентябрь 2025) до 70,3% (сентябрь 2026): +16,4 п.п., или 30% за год; в каждый из двух предыдущих лет рост был три-четыре пункта.
  • Китай: доля IPv4-адресов в валидных маршрутах выросла с 3,7% до 83,0%, почти 60% глобального прироста по адресам; без Китая доля по адресам выросла с 58,0% до 63,2%.
  • Невалидный маршрут в среднем видят всего два маршрутизатора против 596 у валидного и 595 у маршрута без RPKI-записи, проверка работает; поэтому страновые рейтинги по числу невалидных маршрутов вводят в заблуждение (Испания: 28,2% по маршрутам против 0,057% по взвешенным адресам).
  • У 16,2% покрытых IPv4-маршрутов (138 698 из 855 217) ROA шире анонса, а у IPv6 доля 20,9%; на этом строится подделка источника, как в случае Hetzner 28 августа 2026 года (RPKI-валидный поддельный /24).
  • ASPA: записи опубликовали 3 272 сети против 131 год назад (в 25 раз больше), но реально подтверждено около 3,5% маршрутизации, а нарушающие правила пути составляют 0,048% наблюдений.

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

Маршрутизация BGP исторически держится на доверии, и одна ошибочная или злонамеренная запись способна перенаправить трафик целых сервисов: в 2008 году YouTube примерно на два часа оказался недоступен из-за анонса Pakistan Telecom. Рост доли RPKI-валидных префиксов с 54,0% до 70,3% за год (против трёх-четырёх пунктов в год прежде) показывает резкое ускорение, а данные о видимости маршрутов (невалидные видят два маршрутизатора против 596) говорят, что защита уже срабатывает на практике. При этом заметная часть скачка, это одна страна: Китай даёт почти 60% глобального прироста по адресам.

Кому это важно

Сетевым инженерам и операторам, которые публикуют ROA или проверяют анонсы; хостинг-провайдерам и провайдерам доступа, чьи записи оказались наиболее «широкими» (Contabo, DigitalOcean, Cablevision, Shaw, Bharti Airtel в приведённых авторами примерах); специалистам по безопасности инфраструктуры; тем, кто составляет рейтинги и отчёты о внедрении RPKI по странам. Для остальных читателей это сигнал о состоянии базовой защиты интернета.

Как это применить

Из материала следуют практические выводы. Операторам: по RFC 9319 лучшей практикой считается не задавать maxLength, чтобы ROA совпадала только с реально анонсируемым блоком; стоит проверять, нет ли у вас ROA, шире анонсов и без закрывающих зазор более специфичных маршрутов. Пропажу ROA заметить трудно, поскольку она не вызывает сбоя, поэтому покрытие нужно отслеживать специально (примеры: SEACOM на Маврикии, Saudi Telecom, Orange Maroc). Аналитикам: страновую статистику лучше читать по адресам с поправкой на число точек наблюдения, а не по числу невалидных маршрутов, и уточнять, как посчитаны сбойные записи.

Можно ли доверять

Это собственные измерения IPinfo, а не данные регистратора или официальный реестр; текст написан от лица авторов («мы») без указанного имени. Авторы сами оговаривают методологические ловушки: некоторые способы проверки считают защищающую запись сбойной, и просят учитывать, какой способ подсчёта использован, включая их собственные цифры. Объяснение, почему покрытие Китая выросло так резко именно в 2026 году, в доступной части материала не приводится. Источник в нашей копии обрывается в разделе об ASPA, так что заключение статьи не пересказано.

Риски и подводные камни

RPKI проверяет, кто вправе анонсировать префикс, но не путь, и не ловит атакующего, остающегося в рамках опубликованного разрешения: поддельный /24 с источником Hetzner был валиден, потому что ROA допускала такие анонсы. По оценке авторов, в таком положении около 18 миллионов более специфичных префиксов. ASPA пока может проверить лишь небольшую часть маршрутизации: после исключения автоматически проходящих коротких путей подтверждено около 3,5%, остальное в основном неизвестно, а не сбойно. Рост доли ASPA-невалидных путей (до 0,048%) авторы не считают обязательным ухудшением маршрутизации, а атрибуция сбоев по происхождению маршрута может обвинять не ту сторону: одна сеть с устаревшей записью делает невалидными маршруты всех своих клиентов.

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

— авторы статьи, блог IPinfo