Рейтинг
0.00

Qrator Labs

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

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



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

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

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

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



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

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

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

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

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

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

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

www.manrs.org/about/partners/

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



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

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

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

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



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

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



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

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

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

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

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




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

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

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


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

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

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


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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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





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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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


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

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

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

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


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


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

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

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


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

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

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

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

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



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



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



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


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

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

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


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

Приглашение на десятилетний юбилей Qrator Labs



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

AS9304 утечка префиксов 8764 через AS15412

Можно было бы ожидать, что 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, сегодня извлекла ценный урок. Теперь у сетевых инженеров этой компании больше не должно возникать вопросов о необходимости как входящей, так и исходящей фильтрации по префиксу.