Рейтинг
0.00

Qrator Labs

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

Отчет о надежности интернет-сегмента за 2023 год



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

Глобальная связность любой автономной системы (АС), будь то международный гигант с миллионами потребителей услуг или небольшой региональный интернет-провайдер, зависит от количества и качества ее путей к провайдерам первого уровня. Уровень 1 относится к крупным транснациональным, часто трансконтинентальным операторам, которые обеспечивают глобальную связь между континентами и странами. Эти операторы находятся на вершине иерархии провайдеров и, следовательно, не платят друг другу за услуги IP-транзита. Однако внутри этого «элитного клуба» нет никаких обязательств поддерживать взаимные связи друг с другом. Только рынок может мотивировать такие компании к установлению взаимосвязей. Достаточно ли этого стимула? Мы рассмотрим этот вопрос ниже, в разделе, посвященном подключению IPv6.

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

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

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

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



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

Надежность IPv4
Общая тенденция стабильности IPv4

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

Для иллюстрации этого тезиса мы подсчитали средние и медианные значения стабильности IPv4 для всех стран за всю историю отчетности (последние 8 лет).

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

Можно заметить, что в мире продолжает демонстрироваться тенденция повышения отказоустойчивости: средний показатель надежности улучшился с 26,7% в 2022 году до 25,7% в 2023 году.


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

Таблица 1. Рейтинг надежности IPv4


Основные моменты:
  • Сингапур опустился на 11 позиций, опустившись с 4-го на 15-е место с заменой критической AS со StarHub (AS4657) на SingNet (AS3758).
  • Тайвань вернулся в Топ-20 Рейтинга надежности IPv4 на 17 месте (в 2021 году занимал 20 место).
  • После 7-летнего отсутствия Филиппины вновь вошли в Рейтинг на 20-й позиции, находясь на 24-м месте в 2022 году.
  • США вновь вошли в рейтинг, переместившись с 28-го на 18-е место.
  • Люксембург покинул рейтинг, опустившись с 16-го на 39-е место, а его критический AS изменился с AS174 на AS6661.
  • Индонезия потеряла четыре позиции с 17-го места и покинула рейтинг.
Рейтинг надежности Интернета последовательно демонстрирует устойчивую тенденцию систематического улучшения качества связи. Бразилия, Германия и Нидерланды прочно удерживают тройку лидеров два года подряд. Это свидетельствует о том, что количество соединений между их Автономными Системами настолько велико, что выход из строя критической AS не приведет к недоступности этих регионов.

Примечательным наблюдением 2023 года является резкое снижение рейтинга Люксембурга, который не только покинул топ-20, но и опустился на 39-е место. Критическая AS изменилась с международного оператора первого уровня Cogent (AS174) на местную Post Group Luxembourg (AS6661), которая, в свою очередь, имеет значительное количество местных клиентов. В 2023 году несколько клиентов Post Group Luxembourg отказались от всех других провайдеров, сделав эту AS единственным провайдером и, таким образом, став полностью зависимыми от ее политики маршрутизации. Следовательно, критичность отключения Post Group Luxembourg для страны существенно возросла, а из-за небольших размеров государства это событие привело к колоссальному снижению его отказоустойчивости в Интернете.

В Сингапуре, потерявшем в 2023 году 11 позиций, также произошла смена Автономной системы (АС) со StarHub (AS4657) на SingNet (AS3758), имеющую более высокий уровень критичности. Чем выше уровень критичности, тем больше автономных систем (и в целом конечных пользователей, имеющих доступ к Интернету) останутся без подключения в случае выхода из строя данного интернет-провайдера, и тем ниже будет позиция его страны в общем рейтинге.

Скорее всего, повышенная критичность SingNet связана с тем, что несколько Автономных Систем покинули StarHub и сделали SingNet единственным провайдером, а его выход из строя грозит им полной потерей связи.

С другой стороны, глядя на крупнейших провайдеров Сингапура, следует отметить общенациональный сбой в работе австралийской дочерней компании SingTel (AS7473) — Optus (AS7474) — в ноябре 2023 года. По нашим данным, Optus является четвертой AS в стране по количеству локальных клиентов, и пользователи AS этих клиентов испытывали проблемы с интернет-сервисами почти 14 часов. Кроме того, с точки зрения BGP, у Optus нет поставщиков резервного копирования, а есть только один вышестоящий интернет-провайдер — SingTel.

Среди новичков 2023 года выделяются Филиппины, стабильно улучшающие свои позиции на протяжении последних 4 лет и теперь, наконец, вошедшие в Топ-20 Рейтинга.


Надежность IPv6
принятие IPv6

Общеизвестно, что, несмотря на схожие названия протоколов IPv4 и IPv6, их реализация существенно различается. Относительная новизна и существенные различия в работе этих двух протоколов, безусловно, замедляют темпы внедрения маршрутизации IPv6 в Интернете. Это подтверждает статистика использования IPv6 от Google, которая показывает, что распространение этого протокола во всем мире растёт, но не экспоненциально, как это характерно для многих интернет-технологий, а линейно (на графике показан процент всех сессий, использующих IPv6 для подключения к Google). серверы). Однако за 8 лет публикации нашего отчета этот показатель вырос с 10 до 44,87% в 2023 году.


Частичное подключение в IPv6
Одним из интересных явлений в IPv6 является частичное подключение к интернет-провайдеру. Попробуем объяснить, что представляет собой эта метрика. Для этого рассмотрим связи между основными операторами Tier-1, изобразив Ядро Интернета в виде графа:


Подключение IPv4 Tier-1 (слева) и подключение IPv6 Tier-1 (справа)

Пунктирная линия на графике IPv6 отражает отсутствие связей между основными провайдерами первого уровня.

В то время как в IPv4 все операторы уровня 1 имеют одноранговые отношения друг с другом, в IPv6 отсутствует связь между несколькими основными операторами, такими как:
  • между Hurricane Electric (AS 6939) и Cogent (AS 174),
  • между 2828 (XO Communications, объединенная Verizon) и 3320 (DTAG),
  • между 2828 (XO Communications) и 1239 (Спринт),
  • между 2828 (XO Communications) и 6762 (Sparkle, он же Telecom Italia).
В предыдущих отчетах мы уже писали о «классическом» отсутствии связи между 174 (Cogent) и 6939 (HE), которые из-за продолжающейся пиринговой войны отказались устанавливать пиринговое соединение.

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


Также появились некоторые колебания подключений Verizon в 2023 году:
  • 2828 США — 3320 Германия — связь наблюдалась в 2019 году, но в том же году исчезла,
  • 2828 США — 1239 США — ссылка мерцала и пропадала в мае 2022 года,
  • 2828 США — 6762 Италия — ссылка периодически появляется.
Что означает отсутствие ссылки? Если рассматривать только вертикальные отношения (провайдер-клиент), то это означает, что трафик не может течь между множествами клиентов («клиентскими конусами») двух операторов верхнего уровня, поскольку они не обмениваются трафиком друг с другом.
Невозможно пройти через цепочку более двух операторов первого уровня или транзитного оператора нижнего уровня, поскольку в этом случае будет нарушен принцип маршрутизации Valley-Free и возникнут утечки маршрутов.

Принцип Valley-Free — это широко распространенное правило маршрутизации, согласно которому префиксы, полученные рассматриваемой AS от провайдера или пира, могут передаваться только клиентам.

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


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

Таблица 2. Оценка стабильности IPv6


Основные моменты:
  • Топ-2 остается неизменным второй год подряд: Бразилия и Германия сохраняют лидирующие позиции.
  • Нидерланды поднялись на 5 позиций, обеспечив себе третье место и подтолкнув Англию на 4-е место.
  • Япония, отсутствующая в топ-20 с 2021 года, вошла в рейтинг на 5-й позиции.
  • Китай занял 12-е место после двухлетнего отсутствия в топ-20.
  • Индонезия потеряла 13 позиций, резко опустившись с 4-го на 17-е место.
Возвращение Японии в рейтинг после двухлетнего отсутствия можно объяснить снижением уровня критичности ее самого значимого телекоммуникационного оператора — Национального института информатики (AS2907) — с 20,27% до 4,33%. Количество клиентов этой АС не уменьшилось, что свидетельствует о том, что они начали подключать резервные каналы связи (другие провайдеры). В случае выхода из строя критических AS их доступность не будет потеряна, а значит больше стабильности и более высоких позиций в рейтинге.

Китай вновь появился в рейтинге после попадания в топ-20 в 2021 году. В стране наблюдается парадокс: с одной стороны, процент отказов при отключении China Telecom (AS4134) очень низкий (5,85%), но с другой С другой стороны, наблюдается поразительная частичная недоступность (почти 90%).

Высокая частичная недоступность в Китае обусловлена большим количеством автономных систем, анонсировавших префиксы, принадлежащие Китайской образовательной и исследовательской сети CERNET (AS4538). Эти объявления были сделаны из обычно неиспользуемых, но выделенных APNIC автономных систем, что привело к большому количеству перехватов BGP, как упоминалось в отчете за третий квартал 2023 года в разделе инцидентов BGP.
Что касается наших показателей глобального подключения, стоит отметить, что распространение этих объявлений в сторону операторов первого уровня заканчивается в двух ключевых AS: Hurricane Electric (AS6939) и Hong Kong Internet Exchange (AS4635).

В случае с Hong Kong IX это подразумевает региональную связность ввиду особенностей распределения трафика через IX и не влияет на глобальную связность. В случае Hurricane Electric (AS6939) глобальное подключение не будет достигнуто, поскольку, как упоминалось выше, между AS6939 и AS174 нет пирингового канала. Это означает, что, согласно нашему показателю, большое количество AS, анонсировавших китайские префиксы CERNET, имели частичную доступность. Более того, при кратковременном соединении AS6939 и AS174 появилась глобальная связь, и многие частично доступные AS стали глобально доступными через AS6939, что сделало AS6939 критически важным для страны (с критичностью 88%).

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

Резкое падение рейтинга Индонезии можно объяснить тем, что ее автономная система Cyberindo Aditama (AS38158) в 2023 году начала активно отбивать клиентов, в том числе местных, что сделало ее более важной для региона автономной системой, сместив прошлогоднего лидера. PT Mora Telematika Индонезия (AS23947).

Практически ежегодная смена лидеров свидетельствует о динамичности развития IPv6. В отличие от IPv4, средняя стабильность и частичная связь для IPv6 не улучшаются. Однако рейтинг Топ-20 свидетельствует об улучшении среднего показателя простоев — с 7,06% в 2022 году до 5,34% в 2023 году.

Интернет-провайдеры только с одним восходящим потоком (штуковые сети) и их надежность
Уже несколько лет подряд мы наблюдаем тот факт, что значительная часть критичных AS из нашего рейтинга состоит из Автономных Систем с большим количеством Stub AS (Stub Autonomous Systems), которые по сути представляют собой сети только с одним вышестоящим провайдером и не являются транзитными. провайдеры для кого угодно.

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


Этими характеристиками обладают 75% нашего рейтинга адресного пространства IPv4, тогда как для IPv6 их меньше половины.

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


Ключевые результаты
  • Надежность IPv4 продолжает улучшаться из года в год, демонстрируя рост с 26,7% в 2022 году до 25,72% в 2023 году.
  • Глобальное внедрение IPv6 продолжает линейно расти; однако частичное подключение в IPv6 остается постоянным и не демонстрирует устойчивого роста.
  • Филиппины демонстрируют последовательное повышение общей стабильности IPv4.
  • Практически ежегодная смена лидеров IPv6 свидетельствует о динамичном развитии IPv6.
  • Высокий уровень частичного подключения IPv6 в Китае связан с локальным объявлением префиксов CERNET от имени недостаточно используемых азиатских AS.
Актуальная информация о национальной стабильности всегда доступна radar.qrator.net/as-rating/reliability/national-stability
Если у вас возникнут какие-либо вопросы, пишите нам на radar@qrator.net

Обновленный сайт работает!



Обновленный сайт Qrator.Radar работает!
Мы рады объявить о запуске нашего нового веб-сайта Qrator.Radar.

Мы полностью переработали наш бэкэнд, унифицировав его как для мониторинга BGP в реальном времени, так и для нового radar.qrator.net Это дает несколько преимуществ, в том числе улучшенную согласованность данных и производительность.
radar.qrator.net

Новая версия включает в себя следующие улучшения:
  • Во все разделы были включены новые поля, такие как «распространение», «серьезность» и «информация», чтобы дать представление о том, сколько наших докладчиков видят ваш префикс.
  • В графе маршрутизации трафика связи между автономными системами обозначены цветом .
  • Теперь вы можете видеть нисходящий и восходящий трафик!
  • Благодаря нашей новой системе хранения инцидентов мы значительно сократили время, необходимое для выбора инцидентов безопасности и доступа к ним.
  • Это улучшение особенно заметно для таких инцидентов, как утечка принятого маршрута.
  • Добавлена ​​интеграция с данными PeeringDB
  • Значительно расширен функционал рейтингов АС
  • Новый API предлагает более гибкое распределение прав доступа.
И это лишь малая часть изменений, с которыми вы можете ознакомиться на нашем обновленном сайте.

Подробное описание изменений и улучшений, которые мы внесли, вы можете найти в нашем блоге.
radar.qrator.net/blog/articles/179

Предотвращение и обнаружение утечек маршрутов 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 включает в себя три узла в России, два — в США, три — на территории ЕС, четыре — в Азии и один — на Ближнем Востоке.