Qrator Labs

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-атак.

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 открыла новый Центр очистки трафика на рынке Ближнего Востока для предоставления услуг по противодействию 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 перед инцидентом. Если в этих сетях существовала какая-либо служба — до утечки они были доступны по менее конкретным и регулярным маршрутам. После (и во время) инцидента возникли более конкретные префиксы с огромными префиксами, которые начали распространяться, поэтому весь трафик проходил через просочившуюся ссылку.


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

19 января 2021 года компания Qrator Labs официально отмечает десятилетний юбилей!

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

Каждое выступление рассчитано на 15-20 минут, поэтому каждый зритель может рассчитывать на два с половиной часа презентаций от ключевых сотрудников Qrator Labs.

Отмечайте 19 января 2021 года в своих календарях, потому что вот что будет происходить начиная с 14:00 Московского времени.

I/III — Первый Час
10 лет развития бизнеса: с нуля к росту, путь от первых клиентов и спасенных карьер к захвату рынков новейшими технологиями.
Максим Белоенко, вице-президент глобальных продаж.
Создание технологии опережающей конкурентов, нескончаемое научное исследование на стыке информатики и практики реального мира.
Артем Гавриченков, со-основатель и технический директор Qrator Labs.
5-минутный перерыв

II/III — Второй Час
Интеграции с облаком Qrator Labs — как мы работаем над улучшением сервисов, которые предоставляем под одной крышей — партнерскими решениями CDN и WAF.
Андрей Лескин, менеджер по продукту.
Qrator Radar — пятилетнее путешествие от внутренней разработки к одному из крупнейших в мире специализированных сервисов.
Евгений Богомазов, сетевой инженер.
5-минутный перерыв

III/III — Третий Час
Пресейл и интеграция:

• Технический пресейл — как мы принимаем на борт наиболее крупных клиентов;
• Партнерская интеграция — сделай единожды и наслаждайся результатом;
• Продуктовое видение — сделай дважды и у тебя на руках почти готовый продукт.

Георгий Тарасов, инженер.
Жизнь NOC (Центра управления сетью) в компании занимающейся кибербезопасностью.
Дмитрий Шемонаев, глава Центра Управления Сетью.
Заключительное слово и итоги десятилетия компании. Работа с заказчиками в 20-х годах, грядущие инновации. Дальнейший рост компании первого эшелона на базе исследовательской деятельности и взаимоотношений с потребителем, как с инвестором.
Сергей Пасечник, директор отдела продаж.
До встречи 19 января!

youtu.be/L-yKHlcbJ2w
С наилучшими пожеланиями, Qrator.net team

Можно было бы ожидать, что 2021 год начнется несколько иначе, чем хаос прошлого года. В Qrator.Radar мы тоже надеялись на лучшее. К сожалению, уже 6 января — сегодня мы ошиблись.


Начиная с 4:21 UTC, из AS9304 — провайдера HGC Global Communications Limited из Гонконга — произошло огромное количество префиксов по сравнению со средней утечкой — 8764. Они содержали IP-адреса 907 ASN из 66 стран, что привело к 9140 конфликтам. в целом.

Активная фаза инцидента длилась около 2,5 часов, после чего сократилась.


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


Среди наиболее пострадавших от этой утечки маршрута оказались известные участники Интернет-транзита из ЕС и США, такие как Akamai и Cloudflare. Однако объем утечки префиксов был настолько широк, что для компании с обширной компьютерной сетью почти невозможно не пострадать от такого инцидента.

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

Базирующаяся в Великобритании AS15412, принадлежащая Flag Telecom Global Internet, сегодня извлекла ценный урок. Теперь у сетевых инженеров этой компании больше не должно возникать вопросов о необходимости как входящей, так и исходящей фильтрации по префиксу.

AS203, принадлежащий к тому, что ранее называлось «Level3», приобретенным «CenturyLink» в 2016 году, а затем переименованным в «Lumen» в 2020 году, часто появляется в отчетах об инцидентах команды Qrator.Radar. Мы не должны никого винить, но такое возникновение инцидентов маршрутизации для отдельной организации вызывает беспокойство — мы надеемся, что эта статья поможет вам понять, как даже небольшое событие может иметь огромное влияние при соблюдении определенных предварительных условий.



21 октября 2020 года примерно в 14:11 по всемирному координированному времени AS203 начал анонсировать 158 префиксов, которые почти сразу же создали более 1100 конфликтов для более чем 1000 объявленных префиксов. Этот инцидент, который еще не прекратился, пока мы пишем этот конкретный отчет, затронул 31 интернет-провайдера в 19 странах, включая таких игроков, как AS9198 — KAZTELECOM-AS, AS35415 — WEBZILLA, AS7979 — SERVERS-COM и многие другие.



Вот график путей для одного из префиксов, которые были взломаны Webzilla:


Почему анонс такого умеренного набора префиксов привел к значительной аномалии, которая, по нашим оценкам, стоила законным владельцам потери значительной части их доступности — от 30% до 100% в зависимости от удаленности от магистрали Интернета?


Проще говоря — потому что «Люмен» — провайдер уровня 1. Объявления из такой автономной системы с обширным охватом на всех континентах легко побеждают в испытании пути BGP над исходными объявлениями. Что в дальнейшем позволяет им распространяться на другие автономные системы, достигая глобального покрытия. Объявления AS203 достигают мира в два прыжка, что имеет решающее значение для распространения префиксов.

Взгляните на следующую картину, которая прекрасно иллюстрирует, что даже меньшее или равное количество конкретных префиксов успешно распространяется по Интернету, захватывая трафик своих первоначальных владельцев в случае, если взлом происходит с Уровня-1:


Можно сказать, что в среднем этот инцидент унес 50% обычного трафика из легитимных автономных систем. Мы могли только предполагать, что причина воздействия этого инцидента заключается в том, что только 10% недействительных префиксов ROA сопровождали это событие.

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