Одной из основных функций служб мониторинга и аналитики глобальной маршрутизации BGP является отслеживание специфических аномалий, которые могут привести к сетевому инциденту, который мы бы далее будем называть утечкой маршрута BGP route leaking или захватом BGP route hijack.
Оба инструмента перенаправляют трафик третьей стороне по сравнению с состоянием маршрутизации без аномалий, но по-разному. За последние несколько лет было приложено много усилий для решения проблем утечек маршрутов, но до сих пор существуют недопонимание относительно того, что к чему и как всевозможные инструменты мониторинга помогают решать разные проблемы с безопасностью маршрутизации.
Мы начали собирать данные о модели сетевых взаимосвязей BGP за пару лет до появления RFC 7908, пытаясь определить, что является утечкой маршрутов, а что преднамеренным захватом адресного пространства с использованием BGP. Два основных различия между этими событиями были описаны следующим образом:
- Маршруты, перенаправленные через неправильные ASN/каналы (утечки маршрутов), описанные как типы 1-4 RFC 7908.
- Маршруты, перенаправленные на неправильные ASN (перехват трафика), описанные как типы 5 и 6 RFC 7908.
Трафик при утечке маршрута BGP, предназначенный для вашей сети, скорее всего, будет передаваться неэффективно, что может привести к увеличению задержки прохождения пакетов к вашей сети или их полной потере. Тем не менее, в этом случае трафик почти наверняка всегда достигнет вашей сети, если нет критической перегрузки сети по какой-либо причине (например, из-за злонамеренных действий нарушителя правил маршрутизации). При перехвате маршрута BGP трафик, предназначенный для вашей сети, перенаправляется третьей стороне и приземляется где-то там. Кроме того, механизмы создания таких аномалий также различаются. Для создания утечки маршрута необходимо передать корректный маршрут неподходящему соседнему интернет-провайдеру. Для создания перехвата маршрута необходимо либо объявить маршрут с более коротким или как его ещё называют специфичным для допустимого префикса, чтобы привлечь весь трафик от интернет-провайдеров, получивших такое объявление, с любым желаемым AS_PATH, либо начать анонсировать маршрут с префиксом третьей стороны из вашей сети. Поскольку механизмы создания маршрутных аномалий различаются, механизмы обнаружения инцидентов и предотвращения или смягчения последствий тоже будут различаться.
Для обнаружения причины утечки маршрута необходимо выяснить взаимосвязь между каждым из двух подключенных операторов и найти такие маршруты BGP (из коллектора BGP), которые нарушают формальную модель Gao-Rexford, для получения дополнительной информации смотрите раздел «Взаимосвязи AS» в документации CAIDA. Для обнаружения перехватов трафика необходимы достоверные данные о том, какие префиксы принадлежат каким интернет-провайдерам, и в большинстве случаев, когда появляется незарегистрированная пара префикс/ISP, — необходимо создать оповещение или принять меры.
Для предотвращения или смягчения последствий перехвата трафика в рамках единой системы проверки происхождения префиксов используются два стандартных подхода. Можно зарегистрировать объект Route в вашем IRR или создать объект ROA. Наша команда описала различия между этими подходами на конференции RIPE79. Однако общим является то, что оба подхода определяют, какие префиксы принадлежат каким операторам, и пытаются блокировать маршруты от интернет-провайдера в случае анонсирования им незарегистрированных за ним префиксов (внезапно ставшим транзитным интернет-провайдером). Для предотвращения или смягчения последствий чистых утечек маршрута мы участвуем в создании открытой политики BGP. Другой подход — блокировка маршрутов с неожиданными соседями или провайдерами интернет-услуг в AS_PATH. Проект ASPA IETF несколько отличается от чистого предотвращения перехвата трафика или утечек маршрутов, поскольку он больше направлен на блокировку некорректных AS_PATH в случае утечки маршрутов и перехвата без или с некорректной обработкой AS_PATH.
ROA против утечек маршрутов
Итак, безопасна ли ваша сеть, если вы используете подписи и фильтрацию ROA? Нет, потому что без ASPA или любого аналогичного протокола сам по себе ROA не предотвратит утечки маршрутов другими пользователями. Мы надеемся, что теперь вы понимаете, насколько сложна эта проблема, где для обеспечения безопасности основ современной междоменной маршрутизации — протокола Border Gateway Protocol — необходим отдельный подход.
Подписи ROA против фильтрации ROA
Ещё одно распространённое заблуждение связано с алгоритмом ROA. В алгоритмах ROA участвуют две стороны: подписывающая сторона — оператор связи, предоставляющий достоверную информацию о принадлежащих ему префиксах, и фильтрующая сторона — магистральный или транзитный оператор, отфильтровывающий некорректные маршруты на основе информации, предоставленной подписывающей стороной.
Как оператор-заглушка (то есть автономная система с одним вышестоящим провайдером), вы ограничены в количестве способов влияния на число фильтрующих сторон. Чем больше их, тем безопаснее будут ваши префиксы (тем меньше регионов пострадает, если нарушитель маршрутизации решит захватить ваши префиксы). Если вы решите подписать свои префиксы, вы можете использовать существующую инфраструктуру фильтрации, которая будет только расти в ближайшем будущем. Более того, мы рекомендуем вам сделать именно это в любом случае, независимо от размера сети вашей автономной системы.
В конце статьи все же следует предупредить – существующая инфраструктура фильтрации может быть несовершенной, и в некоторых случаях вы не сможете вернуть себе свой трафик из затронутого региона из-за выбранного параметра максимальной длины и фильтрации ROA со стороны вашего интернет-провайдера.
Более подробно обсудить со мной вопрос практического применения этого материала можно в личных сообщениях. Контактные данные указаны в соответствующем разделе этого сайта.
