Избыточный AS-SET как скрытая угроза безопасности маршрутизации

Проблема «раздутых» и некорректных AS-SET — объектов в базах данных IRR, которые могут подрывать безопасность глобальной маршрутизации реально существует

В мире BGP-маршрутизации доверие строится на основе данных из реестров (IRR). Одним из ключевых инструментов здесь является объект AS-SET — это групповой объект, который должен содержать список автономных систем (ASN), принадлежащих провайдеру и его клиентам. Однако на практике AS-SET часто становятся источником хаоса и уязвимостей.

Что такое AS-SET и зачем они нужны?

Когда оператор настраивает фильтры для приема маршрутов от своего клиента, он заглядывает в базу данных IRR. Если клиент — крупный провайдер, у него много своих клиентов. Чтобы не прописывать сотни ASN вручную, создается объект AS-SET. Оператор просто указывает: «Я принимаю всё, что входит в этот набор».

Суть проблемы: «Раздувание» и вложенность

Проблема «бича избыточных AS-SET» (scourge of excessive AS-SETs) заключается в том, что эти объекты могут содержать в себе другие AS-SET, создавая бесконечные цепочки вложенности.

1. Рекурсивный взрыв: Некоторые AS-SET при раскрытии превращаются в списки из десятков тысяч ASN. Это происходит из-за того, что администраторы включают в свои наборы AS-SETы крупных вышестоящих провайдеров или даже конкурентов.
2. Зацикливание: В базах данных встречаются ситуации, когда объект A включает объект B, который включает объект A.
3. Неактуальность: В списки часто попадают ASN, которые давно не существуют или сменили владельца, но остаются в «доверенном» наборе десятилетиями.

Почему это опасно?

• Слабые фильтры: Если ваш клиент добавил в свой AS-SET объект AS-ANY или набор огромного магистрального провайдера, ваши фильтры становятся бесполезными. Вы фактически разрешаете этому клиенту анонсировать почти любую сеть в интернете.
• Утечки маршрутов (Route Leaks): Из-за избыточных доверенных списков случайная ошибка в конфигурации одного клиента может привести к глобальной утечке трафика, так как фильтры на стороне провайдеров «пропустят» некорректные маршруты.
• Нагрузка на системы: Попытка роутера или скрипта автоматизации «развернуть» гигантский AS-SET может привести к сбоям или крайне долгой генерации конфигураций.

Известны случаи, когда один некорректный AS-SET приводил к тому, что небольшая сеть «авторизовывала» право анонсировать маршруты половины интернета. Это делает систему RPKI (которая более надежна) менее эффективной, так как многие операторы до сих пор полагаются на старые данные IRR при построении фильтров. В текущей ситуации всего лишь одна ошибка в одном текстовом объекте в базе данных может поставить под угрозу стабильность глобальной сети.

«Бесконечный» AS-SET компании Vocus

Vocus — крупный телекоммуникационный провайдер в Австралии и Новой Зеландии. Для автоматизации построения фильтров они использовали объект AS-SET с именем AS-VOCUS. Проблема заключалась в том, что внутри этого объекта было прописано другое имя — AS-VOCUS-NZ (подразделение в Новой Зеландии). В свою очередь, в AS-VOCUS-NZ по ошибке включили обратно AS-VOCUS.

В результате возникла рекурсивная петля (цикл). Когда какой-либо вышестоящий провайдер пытался «развернуть» (expand) этот список, чтобы построить фильтры для приема трафика от Vocus, его скрипты либо уходили в бесконечный цикл, либо генерировали гигантские конфигурации.

Масштаб «раздувания» (The Expansion)

Когда Дуг Мадори и Джоб Снайдерс проанализировали этот объект, они обнаружили катастрофическую избыточность:

• Что должно было быть: список из нескольких сотен автономных систем реальных клиентов Vocus.
• Что получилось: из-за некорректных вложений (включая объекты других крупных провайдеров, таких как AS-LEVEL3 или AS-COGENT), один объект AS-VOCUS стал «авторизовывать» (давать право на анонс) для десятков тысяч ASN.

По сути, любой, кто фильтровал трафик на основе этого AS-SET, автоматически доверял Vocus анонсировать маршруты почти половины интернета.

Почему это привело к инциденту?

В какой-то момент один из клиентов Vocus случайно (из-за ошибки конфигурации BGP) начал анонсировать чужие маршруты (произошла утечка — Route Leak).

• В нормальной ситуации вышестоящий провайдер должен был заблокировать эти анонсы, так как они не принадлежат клиенту.
• Но так как фильтры были построены на основе «раздутого» AS-VOCUS, система безопасности посчитала эти анонсы легитимными.

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

Как обнаружили проблему?

Один из инструментов мониторинга (Kentik) зафиксировал аномальный рост количества префиксов, принимаемых от конкретного BGP-стыка. При попытке проверить, почему фильтр это пропустил, инженеры электросвязи обнаружили, что текстовый файл конфигурации роутера, сгенерированный на основе этого AS-SET, весил несколько мегабайт и содержал тысячи ненужных строк.

Проверка AS-SET в реальном времени

Для того чтобы проверить AS-SET для конкретной автономной системы, например, такой как AS12389 (PJSC Rostelecom), необходимо обратиться к публичным базам данных IRR (Internet Routing Registry), таким как RIPE, RADB или NTT. Разберём, что собой представляет его AS-SET и как провести аудит на предмет «избыточности», о которой предупреждал Дуг Мадори.

Поиск объекта AS-SET

Для AS12389 основным объектом в базе данных RIPE обычно является AS-ROSTELECOM.

Чтобы проверить его содержимое вручную, можно использовать команду whois в терминале:

whois -h whois.ripe.net AS-ROSTELECOM

Анализ структуры (Рекурсия)

Главная проблема, упомянутая в материалах, — это вложенность. AS-SET может содержать другие AS-SET. Если мы развернем AS-ROSTELECOM, мы увидим:

• Direct members: Список ASN, которые напрямую принадлежат клиентам компании.
• Included sets: Другие объекты (например, AS-RT-CUSTOMERS), которые в свою очередь содержат сотни других имен.

Проверка на «избыточность» (The Scourge of Excessive AS-SETs)

Чтобы понять, насколько «раздут» этот объект, профессиональные сетевые инженеры используют инструменты вроде bgpq3 или bgpq4. Они позволяют увидеть, во что превратится этот объект при генерации реального фильтра на роутере:

bgpq4 -l AS12389_FILTER -6 AS-ROSTELECOM

На что обратить внимание при проверке AS12389:

1. Количество записей: Если команда выдает тысячи префиксов, это может быть признаком того, что в AS-SET включены объекты крупных транзитных операторов или даже «мусорные» записи.
2. Наличие RPKI: В современном интернете проверка только по AS-SET (IRR) считается недостаточной. Если для префиксов, входящих в этот набор, созданы ROA (Route Origin Authorization), то данные из IRR становятся вторичными.
3. Глубина вложенности: Проверьте, нет ли в списке объектов вроде AS-ANY или имен других Tier-1 операторов. Если они там есть, это создает огромную «дыру» в безопасности, позволяя анонсировать лишние маршруты.

Практический инструмент: BGP.Tools

Как упоминалось в видео про Orange Spain, сервис bgp.tools — отличный способ визуально проверить AS-SET.

1. Введите AS12389 в поиске на сайте.
2. Перейдите во вкладку IRR.
3. Система покажет все зарегистрированные объекты и то, насколько они соответствуют реальной картине анонсов в BGP.

Если вы являетесь администратором или партнером этой сети, ваша задача — убедиться, что в AS-ROSTELECOM (или аналогичных объектах) присутствуют только активные клиенты. Если там присутствуют ASN организаций, которые уже не имеют прямого соединения с AS12389, этот объект становится «избыточным» и потенциально опасным для глобальной стабильности маршрутизации.

Рекомендации на будущее

Дуг Мадори и его коллега Джоб Снайдерс предлагают несколько шагов для оздоровления экосистемы:

• Гигиена данных: Операторы должны регулярно проводить аудит своих AS-SET и удалять лишние вложения.
• Ограничение глубины: Инструменты фильтрации должны иметь лимиты на глубину рекурсии и общее количество ASN, извлекаемых из одного объекта.
• Переход на RPKI: Максимальное использование RPKI вместо IRR позволяет строить более строгую и криптографически подтвержденную систему проверки маршрутов.

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