Как надо исправлять утечки маршрутов

Опубликовано 02 апреля 2020

Стоит оговориться, что нижеследующая история во многом уникальна.

И вот как она начиналась. В течение примерно одного часа, начиная с 19.28 UTC вчера, 1 апреля 2020 года, крупнейший российский интернет-провайдер — Ростелеком (AS12389) — начал анонсировать сетевые префиксы крупнейших игроков интернета: Akamai, Cloudflare, Hetzner, Digital Ocean, Amazon AWS и других известных имен. До того момента как проблема была решена пути между крупнейшими облачными провайдерами планеты были нарушены - Интернет "моргнул".

Данная утечка маршрута вполне успешно распространялась через провайдера Rascom (AS20764), откуда через Cogent (AS174) и, спустя еще несколько минут, через Level3 (AS3356) распространилась по всему миру. Утечка была настолько серьезной, что почти все Tier-1 операторы были задеты аномалией.

Выглядело это так:

Добавляя снизу вот это:

Эта утечка маршрутов задела 8870 сетевых префиксов, принадлежащих почти 200 автономным системам. С большим количеством некорректных анонсов — ни один из которых не был отброшен участниками, их принимающими. В конечном счете, наличие фильтров бы не изменило сам факт утечки маршрута, но сделало бы ее распространение несколько меньшим. Для того чтобы оценить динамику произошедшего, можно посмотреть на пример BGPlay для одного из префиксов Akamai: https://stat.ripe.net/widget/bgplay#w.resource=2.17.123.0/24

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

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

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

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

Ознакомьтесь со всеми функциями
в 7-дневной пробной версии

Наши специалисты готовы оказать вам поддержку

Будьте в курсе наших новостей и продуктов!

Подпишитесь на ежемесячный обзор самых популярных идей Интернета от CURATOR!

E-mail *

Предыдущие отчёты

Radar
Все очень плохо или новый вид перехвата трафика
13 марта в рабочую группу RIPE по борьбе со злоупотреблениями поступило предложение рассматривать BGP-перехват (hjjack) в качестве нарушения политики RIPE. В случае принятия предложения интернет-провайдер, атакованный с помощью перехвата трафика, получал бы возможность отправить специальный запрос для вывода злоумышленника на чистую воду. Если экспертная группа соберет достаточно подтверждающих доказательств, то такой LIR, являющийся источником BGP-перехвата, считался бы нарушителем и мог быть лишен статуса LIR. Были и некоторые аргументы против такого изменения. В данной публикации мы хотим показать пример атаки, когда не только настоящий злоумышленник был под вопросом, но и весь список пострадавших префиксов. Более того, такая атака вновь поднимает вопросы по поводу мотивов будущих перехватов трафика такого типа.
12 апреля 2019
Radar
«Два нефильтрованных» или легкий способ прострелить ногу
Уже несколько раз в отчетах об инцидентах маршрутизации мы рассказывали о возможных последствиях отсутствия фильтров BGP-анонсов на стыках с клиентами. Подобная, некорректная, конфигурация большую часть времени будет работать совершенно нормально — до тех пор, пока в один прекрасный день не станет виновной в сетевой аномалии регионального или глобального масштаба. И позавчера, 25.11.2018, это случилось снова — на этот раз в России. В 13.00 UTC (16:00 по московскому времени) небольшой российский оператор Krek Ltd ( AS57494 ) начал анонсировать префиксы между своими провайдерами, в результате перенаправив значительную часть трафика Ростелекома на свою сеть. Аномалия затронула более 40 тысяч префиксов — выдержать такую нагрузку сеть Krek, конечно, не могла. В результате от 10 до 20% пользователей на территории РФ потеряли доступ к тысячам сервисов, включая такие популярные как Amazon, Youtube, Вконтакте и онлайн-кинотеатру IVI.RU.
29 ноября 2018
CURATOR
Обновлено: Амплифицированные memcached DDoS-атаки на 500 Гбит/с прокатились по всей Европе
Давным-давно в далеком-далеком git-репозитории Брайаном Акером был сделан коммит , внедряющий замечательную фичу прослушивания UDP трафика в установке memcached по умолчанию. А между 23 и 27 февраля 2018 года по всей Европе прокатилась волна memcached-амплифицированных DDoS атак.
27 февраля 2018
Ваша подписка успешно активирована
На главную