Новые интернет-провайдеры появляются буквально каждый день, и 12 декабря 2017 года не было исключением. Новичок в экосистеме междоменной маршрутизации, AS39523 (DV-LINK-AS), начала анонсировать собственное адресное пространство (один префикс), добавив к нему в то же время еще 80 чужих префиксов, принадлежащих как российским, так и международным контент-провайдерам, таким как Google, Facebook, Mail.ru, Vkontakte и многих других.
Инцидент длился более 2-х часов, начавшись в 4:44 по UTC с пиком в 80 префиксов, закончившись в 7:19 с еще одним пиком в районе 7:04 UTC.
Из-за специфического набора сервисов, испытавших влияние инцидента, мы можем предположить, что статические маршруты протекли в BGP. Тем не менее, основной вопрос заключается в том, почему эти некорректные анонсы вообще распространились? Тот факт, что перехваченные префиксы распространились во все уголки интернета, демонстрирует как отсутствие каких-либо фильтров между AS39523 и ее прямым поставщиком AS31133 (Мегафон), так и между AS31133 (Megafon) и крупнейшими мировыми операторами связи, такими как Level3 (AS3356), Cogent (AS174), Zayo (AS6461), Hurricane Electric (AS6939) и другими.
Существуют три наиболее распространенных причины отсутствия входящих фильтров на стыках операторов вида клиент-поставщик:
Это несложно доказать, все что нужно — это найти глобально видимый префикс без route объекта. Например, у сети 91.243.129.0/24 нет никаких соответствующих route-объектов ни в одной базе данных, но при этом она спокойно анонсируется Мегафоном и его Tier1-апстримами.
Пример из IPv6 также легко найти. Не существует route6 объекта для сети 2a03:34e0::/32, что видно из NLNOG’s IRRExplorer, но опять же префикс 2a03:34e0::/32 распространяется без затруднений. Отсюда можно сделать вывод, что не существует фильтров между AS12695 и AS31133 (Мегафон), либо фильтры не работают, а также что нет фильтров и между Мегафоном и Hurricane Electric (AS6939).
Данный перехват еще раз поднял проблему фильтрации префиксов на стыках клиентов и поставщиков. Конечно, можно свалить всю вину на AS39523, но без настроенных фильтров на стыках между транзитными операторами связи, мы обречены видеть подобные инциденты снова и снова. Мы настоятельно рекомендуем всем транзитным операторам перепроверить свои политики фильтрации, по меньшей мере внедрив prefix-based BGP фильтры на всех соединениях с клиентами.
Всего неделю назад на московском пиринговом форуме Александр Азимов, глава проекта Radar.Qrator, представил доклад, посвященный данной теме — вы можете перейти по ссылке для того, чтобы прослушать доклад и получить больше информации о том, как отсутствие фильтров становится дырой в безопасности, позволяющей проводить успешные атаки MiTM даже на зашифрованный трафик.
Особая благодарность Job Snijders из NTT Communications за помощь в подготовке данной публикации.
Инцидент длился более 2-х часов, начавшись в 4:44 по UTC с пиком в 80 префиксов, закончившись в 7:19 с еще одним пиком в районе 7:04 UTC.
Из-за специфического набора сервисов, испытавших влияние инцидента, мы можем предположить, что статические маршруты протекли в BGP. Тем не менее, основной вопрос заключается в том, почему эти некорректные анонсы вообще распространились? Тот факт, что перехваченные префиксы распространились во все уголки интернета, демонстрирует как отсутствие каких-либо фильтров между AS39523 и ее прямым поставщиком AS31133 (Мегафон), так и между AS31133 (Megafon) и крупнейшими мировыми операторами связи, такими как Level3 (AS3356), Cogent (AS174), Zayo (AS6461), Hurricane Electric (AS6939) и другими.
Существуют три наиболее распространенных причины отсутствия входящих фильтров на стыках операторов вида клиент-поставщик:
- Некоторые транзитные операторы не могут убедить своих клиентов создать корректные route объекты. Так как клиент платит деньги за услугу, некоторые интернет-провайдеры не считают обязательным накладывать строгие фильтры, и в результате мы имеем исключения.
- Другая проблема заключается в том, что нет никакой авторизации для объектов AS-SET. В результате в AS-SET можно добавить любой ASN или AS-SET! Существуют интернет-провайдеры, у которых в их объекте AS-SET будут тысячи префиксов, при всего паре десятках реально относящихся к их клиентскому конусу. Данная ситуация только ухудшается ближе к ядру Интернета, где крупные Tier2-сети могут иметь AS-SET, раздутый до сотен тысяч записей. Вместо того чтобы работать со своими клиентами над решением этой проблемы, часть Tier1-операторов предпочитает просто убрать любые фильтры для провайдеров со слишком большими AS-SET.
- Наконец, некоторые интернет-провайдеры считают, что фильтры, основанные на AS_PATH, неадекватны и, соответственно, не применяют вообще никакой фильтрации префиксов.
Это несложно доказать, все что нужно — это найти глобально видимый префикс без route объекта. Например, у сети 91.243.129.0/24 нет никаких соответствующих route-объектов ни в одной базе данных, но при этом она спокойно анонсируется Мегафоном и его Tier1-апстримами.
Пример из IPv6 также легко найти. Не существует route6 объекта для сети 2a03:34e0::/32, что видно из NLNOG’s IRRExplorer, но опять же префикс 2a03:34e0::/32 распространяется без затруднений. Отсюда можно сделать вывод, что не существует фильтров между AS12695 и AS31133 (Мегафон), либо фильтры не работают, а также что нет фильтров и между Мегафоном и Hurricane Electric (AS6939).
Данный перехват еще раз поднял проблему фильтрации префиксов на стыках клиентов и поставщиков. Конечно, можно свалить всю вину на AS39523, но без настроенных фильтров на стыках между транзитными операторами связи, мы обречены видеть подобные инциденты снова и снова. Мы настоятельно рекомендуем всем транзитным операторам перепроверить свои политики фильтрации, по меньшей мере внедрив prefix-based BGP фильтры на всех соединениях с клиентами.
Всего неделю назад на московском пиринговом форуме Александр Азимов, глава проекта Radar.Qrator, представил доклад, посвященный данной теме — вы можете перейти по ссылке для того, чтобы прослушать доклад и получить больше информации о том, как отсутствие фильтров становится дырой в безопасности, позволяющей проводить успешные атаки MiTM даже на зашифрованный трафик.
Особая благодарность Job Snijders из NTT Communications за помощь в подготовке данной публикации.
