Рейтинг
0.00

Qrator Labs

1 читатель, 27 топиков

Предотвращение и обнаружение утечек маршрутов BGP с помощью RFC9234

Что такое утечки маршрутов в контексте маршрутизации BGP
Согласно RFC7908: «Утечка маршрута — это распространение объявлений маршрутизации за пределы их предполагаемой области действия. То есть объявление от автономной системы (AS) об изученном маршруте BGP к другой AS нарушает предполагаемые политики получателя, отправителя и/или одной из AS на предыдущем пути AS. Предполагаемая область обычно определяется набором локальных политик перераспределения/фильтрации, распределенных между задействованными AS. Часто эти предполагаемые политики определяются в терминах парных одноранговых деловых отношений между AS (например, клиент, транзитный провайдер, одноранговый узел)».



Основываясь на этом определении, RFC9234 продвигает «утечку маршрута» на шаг вперед, чтобы объяснить, как именно утечки маршрутов BGP происходят в дикой природе: «Утечки маршрутов — это распространение префиксов BGP, которые нарушают предположения о топологических отношениях BGP, одного транзитного провайдера другому транзитному провайдеру или латеральному (т. е. нетранзитному) узлу или анонсированию маршрута, полученного от одного латерального узла, другому латеральному узлу или транзитному провайдеру».


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

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

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

Как часто они возникают и каковы риски
Согласно отчету Qrator Labs об инцидентах BGP за третий квартал 2022 года, в третьем квартале произошло 12 103 554 утечки маршрутов BGP, инициированных 3030 уникальными утечками маршрутов.

Конечно, не все из них имели достаточно распространения, чтобы быть видимыми глобально, хотя, по данным Qrator.Radar, в Q3 2022 г. было 6 глобальных утечек маршрутов, во II квартале 2022 г. — 5 глобальных утечек маршрутов, а в I квартале 2022 г. — 4. И утечки глобальных маршрутов происходят гораздо чаще, чем глобальные перехваты BGP, по крайней мере, с 2021 года.



Общие последствия утечки активного маршрута BGP могут варьироваться от повышенных сетевых задержек для жертвы (инициатора префикса) до DoS как для жертвы, так и для злоумышленника. Точный объем и масштаб последствий невозможно подтвердить, не будучи участником утечки BGP-сессии, но некоторые подсказки можно собрать с помощью мониторинга трафика для затронутых автономных систем и их ресурсов.

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



Если вы думаете, что терпят неудачу только мелкие интернет-провайдеры — это неправда. Это пример начала августа — классическая ситуация, когда трафик между двумя Tier-1 ISP перенаправлялся на несколько часов. И если бы провайдер-лидер был небольшой сетью, объем трафика был бы настолько огромным, что он мог бы вызвать DoS в глобальном масштабе. И мы уже видели подобные ситуации много раз. Но, к счастью, в этой конкретной ситуации, представленной на слайде, интернет-провайдер был достаточно большим, чтобы не отставать от всего перенаправляемого трафика.

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

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



Можем ли мы измерить влияние утечек маршрутов? Если у вас есть разные инструменты мониторинга данных, вы можете сопоставить влияние на данные и текущие инциденты BGP.

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



Что делать, если вы не хотите, чтобы на вас повлияли утечки маршрутов? Во-первых, установите, действительно ли ваши данные затронуты инцидентом BGP. Затем попытайтесь найти виновного. После этого с помощью Whois или аналогичного сервиса попробуйте найти контакты электронной почты такого актера. Тогда напишите им претензию и ждите ответа. Этот метод обычно работает, но вы также должны понимать, что для решения проблемы требуется много времени.

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


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


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



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

Существует также необязательный, транзитивный атрибут пути BGP, называемый «Только для клиента» или OTC, который предотвращает создание утечек AS и обнаруживает утечки, созданные AS в середине пути AS.


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

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


Теперь вернемся к утечкам маршрутов. Как уже упоминалось, утечки маршрутов очень просты. Они происходят, когда префикс, полученный от одного поставщика или однорангового узла, объявляется другому поставщику или одноранговому узлу. Другими словами, мы можем преобразовать его в следующее правило. Как только префикс объявляется клиенту, он должен передаваться только нижестоящему клиенту, косвенному клиенту и т. д. И чтобы гарантировать, что это правило не будет нарушено, мы добавили новый атрибут BGP под названием Only-To-Customer. Как это работает?



Когда провайдер отправляет префикс своему клиенту, он устанавливает атрибут OTC со значением своей собственной автономной системы. Если этот атрибут не установлен, клиент также добавляет к нему значение своей соседней автономной системы. Важный момент — не имеет значения, кто устанавливает атрибут; значение такое же.

Атрибут OTC не меняется в течение срока его действия. А с другой стороны, с правой стороны слайда, это перепроверено. Клиент сначала проверяет, что, если установлен OTC, он не должен отправлять свои префиксы другим провайдерам и партнерам. И такую ​​же проверку делает кусок провайдера с другой стороны.

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

Вот несколько формальных слайдов о том, как работает OTC. Вы можете проверить их позже в документе RFC. Это не сложно, но есть один важный момент. Вы можете пропустить их, потому что не хотите связываться с OTC. OTC устанавливается автоматически при настройке ролей. Вы устанавливаете роли — OTC работает в коде. Вы можете посмотреть, как это работает, но вам не нужно его настраивать. Это слайд, который описывает, как устанавливается OTC.

На этом слайде описывается, как проверяется OTC.

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

Здесь вы можете увидеть, насколько сложно настроить роли BGP в некоторых программах с открытым исходным кодом. Желтая часть — это то, что вам нужно для настройки ролей BGP, и OTC сделает всю работу за вас. Я надеюсь, что это не так сложно.

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


И это то, что происходит за кулисами. Атрибут OTC появляется в маршруте, но вы его не настраиваете — это сделано в коде за вас. Это просто.

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

Прямо сейчас и в будущем
MANRS приветствует объявление RFC9234, и мы твердо верим, что реализация роли BGP поможет сообществу еще больше защитить Интернет. Механизм роли BGP, предложенный в RFC9234, поможет предотвратить и обнаружить большинство непреднамеренных неправильных конфигураций BGP, которые создают утечки маршрутов. Хотя RPKI может защитить от перехвата источника маршрута, нам также нужен механизм для защиты пути и защиты от утечек маршрута. Будь то ASPA, AS-Cone, роль BGP или BGPSec, все они обеспечивают необходимые механизмы для защиты интернет-маршрутизации
МАНРС
Конечно, реальная реализация RFC9234 будет отличаться в зависимости от роли «локальной AS», принимающей роли BGP. Если вы интернет-обменник — вы можете использовать его прямо сейчас. Если вы являетесь интернет-провайдером, использующим какое-либо оборудование, предоставленное поставщиком/ами, спросите поставщика, каковы его планы по внедрению RFC9234. К сожалению, другого пути нет.

Мы считаем, что ролей BGP достаточно для покрытия (предотвращения и обнаружения) 80% утечек маршрутов BGP в случае, если основные интернет-биржи и крупнейшие мировые операторы (в первую очередь уровня 1) примут RFC9234. 20%, вероятно, останутся: сломанные случаи, оптимизаторы BGP, которые могут просто удалить атрибут, если захотят, что-то еще, о чем мы не подумали. Но большинство проблем с утечками маршрутов BGP должны и, вероятно, будут решены.

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

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


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


Если вы используете инструменты с открытым исходным кодом, вы уже можете попробовать настроить роли BGP. Ничто не мешает вам это сделать. Если вы используете программное обеспечение какого-либо поставщика — отлично! Отправьте запрос на поддержку ролей BGP выбранному поставщику. А если вы разработчик — тем более! Существует огромное пространство для улучшений, если вы можете внести свой вклад в другие реализации BGP. Вы можете внести свой вклад в синтаксические анализаторы BMP, реализацию дампов TCP, дампов BGP и т.д.

Будем надеяться, что с помощью RFC9234 мы сможем хотя бы приступить к устранению аномалий BGP для улучшения Интернета.

qrator.net/ru/

Национальное исследование надежности интернет-сегмента 2022



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

По мере увеличения количества альтернативных маршрутов между AS («Интернет» означает «взаимосвязанные сети» — и каждая сеть является AS), отказоустойчивость и стабильность Интернета во всем мире растут. Хотя некоторые пути с самого начала более важны, чем другие, создание как можно большего количества альтернативных маршрутов — единственный жизнеспособный способ обеспечить адекватную надежность сети.

Глобальная связь любой данной AS, будь то международный гигант или региональный игрок, зависит от количества и качества его пути к интернет-провайдерам уровня 1.

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

Методология измерения надежности Интернета
Рассматривая случай, когда AS испытывает деградацию сети, мы хотим ответить на следующий вопрос: «Сколько AS в том же регионе потеряет связь с операторами уровня 1, а вместе с этим и их глобальную доступность?»

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

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

Были ли у транзитных интернет-провайдеров когда-нибудь проблемы? Ответ положительный, и это происходит все чаще. Более уместен вопрос: при каких условиях конкретный интернет-провайдер может столкнуться с серьезной деградацией услуг, которую мы бы назвали простоем? Если такие проблемы кажутся маловероятными, возможно, стоит рассмотреть закон Мерфи: «Все, что может пойти не так, произойдет».

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



Для оценки надежности AS были предприняты следующие шаги:
  • Для каждой AS в мире мы изучаем все альтернативные пути к операторам уровня 1 с помощью модели отношений AS, являющейся ядром Qrator.Radar;
  • Используя базу данных Maxmind GeoIP, мы сопоставили страны с каждым IP-адресом каждой AS;
  • Для каждой AS мы рассчитали долю ее адресного пространства, приходящуюся на соответствующий регион. Интернет-провайдеры, находящиеся в точке обмена интернет-трафиком в регионе, где они не имеют значительного присутствия, были отфильтрованы. Примером, который мы здесь используем, является Гонконг, где трафик обменивается между сотнями членов HKIX — крупнейшей азиатской интернет-биржи, большинство из которых не имеют никакого присутствия в локальном интернет-сегменте;
  • После изоляции региональных AS мы проанализировали потенциальное влияние сбоя одной из них на другие AS, а также на соответствующие страны;
В конце концов, для каждой страны мы определили АС с наибольшим/самым большим влиянием на другие АС в их регионе. Зарубежные AS не рассматривались.
Мы приняли значение воздействия AS как показатель надежности для страны. И использовал этот балл для оценки надежности стран. Чем меньше баллов — тем выше надежность.

Надежность IPv4


Особенности
По сравнению с 2021 годом в 2022 году:

  • Четыре сегмента покинули топ-20 рейтинга надежности IPv4: Таиланд, Тайвань, Испания и, что удивительно, Соединенные Штаты, которые сейчас находятся на 28-й позиции с показателем 7,45%, при том же AS, что они потеряли девять позиций в прошлом году — Level3. (Люмен) AS3356;
  • Швейцария потеряла 8 позиций в рейтинге надежности IPv4 со сменой критической AS с AS3303 в 2021 году на AS6830 в 2022 году;
  • Япония потеряла 7 позиций, критический AS не изменился;
  • Сингапур поднялся на 7 позиций, критический AS не изменился;
  • Люксембург поднялся на 5 позиций, критический AS не изменился;
  • Ирландия вернулась в топ-20 рейтинга надежности IPv4 после ухода из нее в 2019 году, критический AS не изменился.
Каждый год в рейтинге надежности происходят захватывающие движения, часто соответствующие тому, что происходит с телекоммуникационной отраслью внутри соответствующих регионов.

Перво-наперво — общая глобальная надежность, посчитанная как средняя и средняя. На этот раз мы смотрим на семь лет непрерывных исследований.


Как видите, 2022 год принес самые значительные изменения как Медианы, так и Средней надежности по сравнению со всеми предыдущими годами. Средняя надежность в мире сейчас составляет 26,7%, что почти на 9% больше, чем в 2021 году, а медианная надежность повысилась на 6,1%.

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

В 2022 году количество стран, которые успешно повысили показатель надежности до уровня менее 10%, что свидетельствует о высокой отказоустойчивости, на одну цифру больше, чем в прошлом году, — 42 национальных сегмента.

Надежность IPv6
Как обычно, мы должны начать с предоставленного Google графика внедрения IPv6, измеренного в % всех сеансов, использующих IPv6 для подключения к серверам Google:


По состоянию на сентябрь 2022 года примерно 37% пользователей Google используют собственное соединение IPv6, что фактически означает, что их интернет-провайдеры поддерживают версию IP-протокола v6.

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


Из этой таблицы сравнения надежности IPv6 Top-20 с частичным подключением видно, что есть несколько стран, в которых частичное подключение в IPv6 превышает 10%: Индонезия, Ирландия, Польша, Канада, Италия, Таиланд и Тайвань, а также Южная Африка. Кения и США. В Лихтенштейне ровно 10 % частичной связности и 10 % надежности IPv6.

Китай, вошедший в рейтинг надежности IPv6 только в 2021 году, хоть и сразу на седьмом месте, но с ошеломляющими 90% частичной связности, вышел из топ-20 IPv6 и сейчас находится на 111-й позиции с надежностью 44,03%, но только 18% частичной связи после замены критически важной автономной системы IPv6 с прошлогодней AS4538 на AS4134 этого года.

Глядя на частичную связность в сочетании с «классическим» процентом надежности, показывающим долю (по крайней мере, частично) недоступных ресурсов в случае сбоя, мы можем констатировать, что, за исключением африканских стран, худшие показатели среди топ-20 IPv6 принадлежат Индонезия (18,32%), Ирландия (18,92%), Польша (22,33%), Канада (20,67%), Италия (22,86%) и Тайвань (21,37%). В США совокупный процент также высок — 23,23%.

В Бразилии, первой стране по рейтингу IPv4 и второй по IPv6, совокупная недоступность составляет 7,26%, что является лучшим результатом среди топ-20 IPv6.

Согласно данным Google о внедрении IPv6 в каждой стране, в сентябре 2022 года лидерами являются Франция с уровнем внедрения 73,12%, Индия (сейчас самая густонаселенная страна в мире) с уровнем внедрения 69,16% и Германия с уровнем внедрения уровень принятия 64,29%. По данным Google, в любой другой стране уровень внедрения IPv6 ниже 60%.

И в то время как Франция и Германия видны в наших данных IPv6 наверху, Индия в этом году по-прежнему остается относительно низкой с точки зрения надежности — 83-е место с надежностью 23,80% для AS6453 и частичным подключением 7,38%, что является небольшим улучшением по сравнению с прошлым годом.

Средний показатель надежности IPv4 в 2022 году составляет 26,7%. Для IPv6 тот же показатель составляет 27,4%, и поскольку мы измеряем влияние сбоев, чем ниже показатель, тем лучше. А для IPv6 средний мировой показатель вырос почти на 2% по сравнению с прошлым годом, что свидетельствует о снижении надежности.

Широкополосный Интернет и записи PTR
«Всегда ли ведущий интернет-провайдер страны влияет на региональную надежность больше, чем кто-либо другой?» — вот вопрос, на который мы пытаемся ответить с помощью дополнительной информации и расследования. Мы предполагаем, что наиболее значительный (по пользовательской или клиентской базе) интернет-провайдер в регионе не обязательно является наиболее важным для подключения к сети в регионе.

Три года назад мы начали анализировать записи PTR. Как правило, записи PTR используются для обратного поиска DNS: использование IP-адреса для идентификации связанного имени хоста или доменного имени.

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

Итак, мы говорим строго об IP-адресах с присутствующими записями PTR. Практика их добавления не универсальна; некоторые провайдеры делают это, а другие нет.

В рейтинге на основе PTR мы смотрим на то, какая часть IP-адресов с поддержкой PTR перейдет в автономный режим из-за сбоя AS в каждой стране, а также на процент, соответствующий соответствующему региону.


Такой подход, учитывающий записи PTR, дает совсем другие результаты. В большинстве случаев меняется не только первичный региональный АС, но и процентное соотношение. Во всех в целом надежных (с точки зрения глобальной доступности) регионах количество IP-адресов с поддержкой PTR, отключающихся после выхода из строя одной автономной системы, в десятки раз больше. Это может означать, что ведущий национальный интернет-провайдер всегда обслуживает конечных пользователей в тот или иной момент.

Таким образом, мы должны предположить, что этот процент представляет собой часть пользовательской базы и клиентской базы провайдера, которая отключилась бы (если бы переключение на второго интернет-провайдера было невозможно) в случае сбоя. С этой точки зрения страны кажутся менее надежными, чем с точки зрения транзита. Мы оставляем возможные выводы из этого рейтинга на PTR читателю.

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

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


В этом году почти все критичные для IPv6 ASN для тупиковых сетей отличаются от классических, а в IPv4 контрастность тоже увеличивается. В прошлом году мы писали о трех «китах»: AS174 Cogent, AS6939 Hurricane Electric и AS3356 Level3 (Lumen).

Теперь вы можете видеть, что в 2022 году AS174 от Cogent по-прежнему остается критически важной AS во многих национальных сегментах (предыдущий график со сравнением IPv4 и PTR), но не столько для четких заглушек в IPv4. В IPv6 AS174 больше не является критической AS для чистых заглушек в Бельгии (где сейчас AS8368). Примечательно, что критическая AS для четких заглушек в США изменилась с прошлогоднего AS174 Cogent на AS6939 Hurricane Electric.

AS3356 Level3 (Lumen) в 2022 году практически не заметен в статистике четких заглушек. Тем не менее, она стала классической (транзитной) критической AS в IPv6, как и в прошлом году, для Великобритании, Польши и США, а недавно — для России, Кипра, Аргентины, Перу и Туниса.

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

Что касается выбытия национального сегмента США из топ-20 рейтинга IPv4, то это, вероятно, не вина Lumen, так как растущая зависимость от крупных телекоммуникационных компаний характерна практически для каждой страны мира. Мы считаем, что падение американского сегмента произошло из-за того, что другие страны из топ-20 и связанные с ними критически важные автономные системы улучшили свою связность быстрее и, возможно, эффективнее. Этот тезис дополнительно подтверждается динамикой средней и медианной надежности в 2022 году.

AS20473 Choopa (The Constant Company) — явная заглушка, критическая в IPv6 для четырех стран: Великобритании, Нидерландов, Швейцарии и Кипра — приятное дополнение по сравнению с прошлым годом, когда она была (полностью) критической только в Швейцарии. В 2022 году AS20473 также станет важной AS для транзита IPv6 в Великобритании.

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

Спасибо, что прочитали исследование надежности! Если у вас есть какие-либо вопросы, не стесняйтесь обращаться к нам по адресу Radar@qrator.net

Qrator Labs запускает четвертый Центр очистки трафика в Москве



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

На сегодняшний день сеть Qrator Labs насчитывает уже 15 Центров очистки трафика: четыре точки фильтрации в России, две — в США, три — на территории ЕС, четыре — в Азии, одна — на Ближнем Востоке и одна — в Южной Америке. Общая пропускная способность распределенной инфраструктуры Qrator Labs – более 3 Тб.

«Российский бизнес все больше переходит в онлайн-формат, и доля компаний, предлагающих свои продукты и сервисы в интернете, стремительно растет. На фоне этого роста отчетливо прослеживается желание бизнеса защитить свои ресурсы от любых атак, которые могут вызвать даже малейшую недоступность сайта или приложения. Мы в Qrator Labs идем в ногу с потребностями клиентов, улучшая возможности нашей сети в России. Открытие четвертой точки фильтрации в Москве позволит нам предоставлять сервис по защите от DDoS-атак еще большему числу российских клиентов, обеспечивая высокую производительность фильтрации трафика», – комментирует Александр Лямин, основатель и генеральный директор Qrator Labs.

Партнерство с MANRS



Qrator Labs стала партнером MANRS, стремясь обеспечить более надежную и безопасную маршрутизацию в Интернете.

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

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

Но все же этого недостаточно.

В то же время инициатива MANRS получила много положительных результатов за последние несколько лет, собирая точки обмена Интернет-трафиком (IXP), сетевых операторов, поставщиков CDN и облачных услуг, а также производителей оборудования под одной целью — уменьшить поверхность угроз безопасности маршрутизации..

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

Вы можете ожидать получить известие от нас (Qrator Labs и MANRS) в ближайшее время.

www.manrs.org/about/partners/

Когда падают гиганты, всегда бывает афтершок



4 октября 2021 года имеет все шансы стать днем осведомленности о BGP.

Помимо мемов, вчера Facebook исчез из Интернета со всей его экосистемой, включая огромные ресурсы, такие как Instagram и WhatsApp.

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

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



Вот как обычно (5 октября, снимок 9:30) выглядит путь AS для префикса 129.134.30.0/24, охватывающий один из DNS-серверов Facebook.

Тем не менее, вчера, начиная с 15.40 UTC, они были исключены из объявления, что сделало их недоступными для службы DNS.



Вместе с двумя другими сетевыми префиксами: 129.134.30.0/23, 129.134.31.0/24, эти три вместе содержат все четыре сервера имен экосистемы социальных сетей и других сервисов Facebook.

Мы смотрели на серверы имен A и B во время инцидента, а не на C и D, хотя теперь все они указывают на IP-адреса, которые были включены в отозванные префиксы после инцидента.

Количество отозванных префиксов IPv4 было немного больше, чем два / 24 и один / 23:
129.134.25.0/24, 129.134.26.0/24, 129.134.27.0/24, 129.134.28.0/24, 129.134.29.0/24, 129.134.30.0/23, 129.134 .30.0 / 24 ',' 129.134.31.0/24 ',' 129.134.65.0/24 ',' 129.134.66.0/24 ',' 129.134.67.0/24 ',' 129.134.68.0/24 ',' 129.134.69.0 / 24 ',' 129.134.70.0/24 ',' 129.134.71.0/24 ',' 129.134.72.0/24 ',' 129.134.73.0/24 ',' 129.134.74.0/24 ',' 129.134.75.0/24 ',' 129.134.76.0/24 ',' 129.134.79.0/24 ',' 157.240.207.0/24 ',' 185.89.218.0/23 ',' 185.89.218.0/24 ',' 185.89.219.0/24 ', '69 .171.250.0 / 24 '

Эти IPv4-адреса объединяются в два / 16 сетевых префиксов, содержащих NS-серверы.

Также было отозвано несколько префиксов IPv6:
'2a03: 2880: f0fc :: / 47', '2a03: 2880: f0fc :: / 48', '2a03: 2880: f0fd :: / 48', '2a03: 2880: f0ff :: / 48', '2a03 : 2880: f1fc :: / 47 ',' 2a03: 2880: f1fc :: / 48 ',' 2a03: 2880: f1fd :: / 48 ',' 2a03: 2880: f1ff :: / 48 ',' 2a03: 2880 : f2ff :: / 48 ',' 2a03: 2880: ff08 :: / 48 ',' 2a03: 2880: ff09 :: / 48 ',' 2a03: 2880: ff0a :: / 48 ',' 2a03: 2880: ff0b :: / 48 ',' 2a03: 2880: ff0c :: / 48 ',' 2a03: 2881: 4000 :: / 48 ',' 2a03: 2881: 4001 :: / 48 ',' 2a03: 2881: 4002 :: / 48 ',' 2a03: 2881: 4004 :: / 48 ',' 2a03: 2881: 4006 :: / 48 ',' 2a03: 2881: 4007 :: / 48 ',' 2a03: 2881: 4009 :: / 48 '




129.134.30.0/24 видимость, данные Qrator.Radar

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

Далее произошло сочетание DNS, BGP и рук.


«Шутка о сетевой маске», кредитор Марк Данн.

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

Более 5 часов.


Предоставлено: Дуг Мадори, Kentik.

Особенно интересно было, как глобальная интернет-инфраструктура отреагировала на такое исчезновение. Короче — плохо.

Именно здесь вступает в силу механика DNS в сочетании с человеческим фактором.

Cache Negative: это значение контролирует отрицательное время кэширования, то есть как долго распознаватель будет кэшировать ошибку имени NXDOMAIN. Максимальное значение, разрешенное RFC 2308 для этого параметра, составляет 24 часа (86400 секунд).

Обратите внимание, что в нем указано только максимально допустимое значение параметра, а не минимальное, которое может быть 0.

DNS-резолверы, кэширующие ответы SERVFAIL и NXDOMAIN, усилили шторм, поскольку им тоже нужно было проверять DNS-серверы верхнего уровня. Если кэш попаданий NXDOMAIN равен X циклам ЦП, то промах кэша NXDOMAIN составляет X x Y циклов ЦП, где Y может быть огромным числом из-за рекурсии и общих ресурсов.

Ошибка в браузере заставляет пользователя попробовать еще раз. Приложения также начинают повторять свои запросы. Люди, не имеющие доступа к своему WhatsApp, начинают искать другие способы общения. Наводнение распространяется на огромную территорию Интернета, затрагивая и другие ресурсы.

Большинство остальных — местные интернет-провайдеры. Вчера Vodafone сообщил о проблемах (на чешском языке) с обработкой трафика в Чешской Республике из-за исчезновения Facebook. Вероятно, не только из-за нагрузки на DNS, но и из-за изменения моделей потоков трафика, поскольку пользователи все еще пытались получить доступ к незатронутым мессенджерам и социальным сетям, особенно Telegram и Twitter.

Сотрудник словацкого интернет-провайдера (Blažej Krajňák) сообщил о значительном изменении трафика на рекурсивных преобразователях, заявив, что это похоже на DDoS-атаку на DNS-серверы:


Предоставлено: Блажей Крайняк.

На этом скриншоте графика из статистики глобального роумингового трафика AMS-IX вы можете увидеть, насколько значительна доля трафика Facebook / Instagram / WhatsApp от общего количества, от 10% до 20%:


Предоставлено: статистика трафика AMSIX GRX.

Брайан Кребс также сообщил, что несколько компаний по регистрации доменов выставили Facebook.com на продажу из-за автоматизированных систем, которые ищут просроченные / заброшенные / освобожденные домены — забавное последствие того, что серверы имен Facebook отсутствовали в Интернете в течение такого периода.

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

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

Вчера мы видели, что могло случиться иначе.

Предоставлено: Честный сетевик.

Да, и если вы все еще не подписались на нашу ленту Twitter — лучше сделайте это до следующего массового сбоя!

Устранение конкретного заблуждения относительно межсетевого взаимодействия



С 2014 года Qrator Labs разрабатывает сервис BGP-мониторинга и аналитики под названием Qrator.Radar. Одна из его основных функций — мониторинг определенных аномалий BGP, которые могут привести к инциденту, который мы в дальнейшем будем называть либо утечкой маршрута BGP, либо захватом BGP.

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

Наша компания начала собирать модель отношений BGP за пару лет до появления RFC 7908, пытаясь определить, что такое утечка маршрута BGP. Два основных различия между этими временами событий были описаны как:
  • Маршруты перенаправляются через неправильные ASN / ссылки (утечки маршрутов), описываются как типы 1-4 RFC 7908;
  • Маршруты перенаправляются на неправильные ASN (Hijack), описанные как типы 5 и 6 RFC 7908.
Во время утечки маршрута BGP трафик, предназначенный для вашей сети, скорее всего, будет проходить неэффективно, что может привести к увеличению задержки в сети и потере пакетов. Тем не менее, он почти наверняка достигнет вашей сети, если по какой-либо причине нет критической перегрузки сети (например, из-за плохого намерения сбоя).

Во время перехвата BGP трафик, предназначенный для вашей сети, перенаправляется третьей стороне и остается там.

Более того, механизмы создания аномалий такого типа также различны. Чтобы создать утечку маршрута, вам необходимо передать хороший маршрут неподходящему соседнему интернет-провайдеру. Чтобы создать захват, вам нужно либо объявить маршрут с субпрефиксом / более конкретным допустимым префиксом (чтобы привлечь весь трафик от интернет-провайдеров, которые получили такое объявление с любым AS_PATH, который вам нравится), либо создать объявление маршрута с сторонний префикс из вашей сети.

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

Чтобы обнаружить причину утечки маршрута, вам необходимо выяснить взаимосвязь между каждым из двух подключенных операторов и выяснить такие маршруты BGP (от сборщика BGP), которые нарушают формальную модель Гао-Рексфорда, для получения дополнительной информации см. с «отношениями AS» CAIDA.
Чтобы обнаружить угоны, вам необходимо знать, какие префиксы принадлежат каким интернет-провайдерам, и в большинстве случаев, когда появляется незарегистрированная пара префиксов интернет-провайдера — создайте сигнал тревоги или примите меры.
www.caida.org/data/as-relationships/

Чтобы предотвратить / смягчить захват, существует два стандартных подхода в рамках единой структуры проверки происхождения префикса. Вы можете зарегистрировать объект Route в IRR или создать объект ROA. Наша команда описала различия между этими подходами во время RIPE79. Однако общее — они оба указывают, какие префиксы принадлежат каким операторам (самими операторами), и пытаются заблокировать маршруты от интернет-провайдера с незарегистрированными префиксами (транзитными интернет-провайдерами).

Чтобы предотвратить / смягчить чистые утечки маршрутов, мы принимаем участие в создании открытой политики BGP. Другой подход — одноранговая блокировка — блокировка маршрутов с неожиданными соседями / интернет-провайдерами в AS_PATH.
datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/
archive.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf
datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/

Проект ASPA IETF стоит немного в стороне от чистого предотвращения перехвата / утечки маршрутов, потому что он больше касается блокирования плохих AS_PATH (случаев утечки маршрутов и перехватов без / с плохой манипуляцией AS_PATH).

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

Подписание ROA против фильтрации ROA
Еще одно распространенное заблуждение связано с РОА. В алгоритмах ROA есть две стороны: подписывающая сторона — оператор, который предоставляет достоверную информацию о принадлежащих ему префиксах; и есть фильтрующая сторона — транзитный оператор, который отфильтровывает плохие маршруты в соответствии с информацией, предоставленной подписавшей стороной.

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

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

Qrator Labs и Oxygen обеспечат защиту от DDoS-атак для клиентов дата-центра





Qrator Labs и оператор сети дата-центров и провайдер облачных сервисов Oxygen объявили о начале стратегического партнерства в области защиты от DDoS-атак.

Oxygen – это современный ЦОД уровня Tier-3 с показателем надёжности 99,982 % и суммарной мощностью 12,8 МВА. С момента запуска в 2001 году у дата-центра не было ни единого сбоя в работе, он обеспечивает максимально высокий SLA для своих клиентов, в том числе по температуре. Кроме наращивания физических мощностей, ЦОД Oxygen развивает и виртуальный дата-центр на базе Oxygen Cloud Platform – одну из самых прогрессивных облачных платформ на сегодняшний день.

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

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

В рамках стратегии создания SOC (Security Operation Center) Oxygen развивает стек облачных продуктов в области информационной безопасности. Решение Qrator Labs по защите от DDoS-атак и взломов успешно дополнит перечень сервисов ЦОДа. Клиентам дата-центра будет доступно специализированное решение по защите от DDoS-атак и взломов на базе сети фильтрации Qrator Labs. За счет интеграции с другими облачными услугами Oxygen и подключению к SOC заказчики защитят свою инфраструктуру на всех уровнях.

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

Павел Кулаков, основатель и генеральный директор Oxygen:
Ландшафт современной цифровой экономики меняется стремительными темпами, и Oxygen – один из хедлайнеров модернизации, создающий не просто ЦОДы, а полноценный ИТ-кластер, включающий в себя разработку облачных платформ, внедрение новых технологических решений, R&D-центр. Для нас крайне важно предлагать своим клиентам не только площадку для размещения их ИТ-инфраструктуры, но и самые современные и востребованные сервисы, обеспечивающие безопасность данных клиентов.

Александр Лямин, основатель и генеральный директор Qrator Labs:
Для нас как для вендора, разрабатывающего инновационный сервис фильтрации трафика, партнерство с дата-центром Oxygen открывает широкие возможности для масштабирования нашего решения и работы с клиентами не только в России, но и на мировых рынках. В частности – в Юго-Восточной Азии, где Oxygen первым из российских операторов дата-центров развернул облачный кластер, разместив его в Сингапуре

Qrator Labs расширяет присутствие на Ближнем Востоке и открывает Центр очистки трафика в Дубае



Qrator Labs открыла новый Центр очистки трафика на рынке Ближнего Востока для предоставления услуг по противодействию DDoS-атакам. Новая точка присутствия компании запущена в Дубае.

Регион Ближнего Востока сегодня проходит серьезный процесс трансформации, интегральной частью которого является формирование экосистемы технологических инноваций. Расходы на информационные технологии в регионе MENA, включающем Ближний Восток, Турцию и Африку, по прогнозам IDC, должны увеличиться на 2,8% и достичь 77,5 млрд долларов в 2021 году.

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

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

Рынок Ближнего Востока сильно монополизирован, поэтому обеспечить приемлемую связность в регионе достаточно непросто. Однако нам удалось построить свою сеть таким образом, чтобы повысить отказоустойчивость и усилить географическую распределенность сети Qrator Labs и обеспечить прямой доступ к клиентам и партнерам региона. Развитие инфраструктуры нашего облачного решения позволяет нам предоставлять клиентам сервис по противодействию DDoS-атакам с минимальными сетевыми задержками по приемлемой стоимости.
комментирует директор Qrator Labs в ближневосточном регионе Максим Белоенко

ЦОТ в Дубае стал 13-м в глобальной инфраструктуре Qrator Labs. На сегодняшний день сеть фильтрации Qrator включает в себя три узла в России, два — в США, три — на территории ЕС, четыре — в Азии и один — на Ближнем Востоке.

В тот день, когда весь мир не ушел

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

Начиная с 09:48 UTC мы увидели около 200 тысяч маршрутов с ранее не существующими префиксами с неработающим AS_PATH. Но обо всем по порядку.


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

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

Практически все маршруты содержали похожие детали — «44393 14570 40676». AS44393 — Securebit Route Collector, AS14570 — I Am A Bad Actor, LLC (мы оценили воображение) и AS40676 — Psychz Networks (нам понравился саундтрек).

Пример (Примечание: отсутствует в RIPEDB stat.ripe.net/widget/routing-status#w.resource=189.203.175.128%2F25&w.min_peers_seeing=0):


Почти для всех префиксов имелся соответствующий объект правильного маршрута (всего 12000 различных ISP в качестве исходных ASN). Тем не менее, количество префиксов с недопустимым ROA было больше, чем количество действительных. Кто-то (или несколько) сбросил кучу под-префиксов для допустимых префиксов и вставил для них точный ASN в AS_PATH.


Большинство злоумышленников (90%) были / 25 действительных / 24 — знакомый признак «оптимизации» маршрутизации в действии.

Хотя некоторые неординарные особенности нас насторожили. В отличие от обычных маршрутов оптимизатора, почти все новые маршруты приводили только к неверным префиксам. Но это можно объяснить тем, что AS44393 сам по себе является сборщиком маршрутов и уже имеет лучшие маршруты к хорошим префиксам.

Что еще более странно — от AS_PATH к bad_prefixes содержится более 4000 новых ссылок, которые мы никогда раньше не видели. Таким образом, в отличие от типичных оптимизаторов, as_path для новых префиксов не были взяты из действительных префиксов, а были созданы на месте с действительным ASN, вставленным в конце AS_PATH (для прохождения проверки ROA в случае отсутствия порога максимальной длины).


Мы писали письма людям, ответственным за AS44393 и AS14570. Они сказали нам, что находятся на принимающей стороне, а не на исходящей, в результате чего нам остается только AS40676. Мы были удивлены, увидев AS40676 на интересной веб-странице: www.noction.com/clients. Это имя AS (Psychz Networks) указано как клиент компании-разработчика оптимизатора BGP. Итак, в конце концов, корень проблемы снова оказался в нем.

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

Что тут сказать? Оптимизация маршрута — это всегда способ прострелить себе ногу в самый неподходящий момент. И если вы не используете ROA с max_length, вы не заметите, что кто-то поранил вас этим оружием без стороннего мониторинга. Но последняя радостная мысль: вы знаете список всех владельцев оружия.

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

Подготовка к проблеме



27 января 2021 года произошла весьма своеобразная утечка на маршруте. AS61666 — GLOBO начала объявлять префиксы своего восходящего провайдера MHNET — AS28146 другому своему провайдеру ALGAR — AS16735. За три минуты GLOBO утекло 1330 префиксов, и весь инцидент с маршрутизацией длился 8 минут — времени, которого хватило, чтобы создать 1435 конфликтов в 21 стране с 265 ASN, в основном в Бразилии (194 ASN), США (22 ASN) и Венесуэле. (7 ASN).



Этот инцидент распространился среди 86% спикеров BGP на пике, что составляет значительный процент. Почти 10% префиксов в утечке имели Invalid ROA (154 префикса) и не помогли предотвратить распространение.



Но что еще более впечатляет в этой утечке маршрутов, так это то, что эти пути имели ОГРОМНЫЙ добавление в их атрибут AS_PATH — 16 (!).


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

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

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


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