- Регистрация
- 7 Фев 2020
- Сообщения
- 525
- Реакции
- 98
- Репутация
- 147
Route leaking и hijacking вызывают неприятности: иногда это задержки, а порой и атаки DOS или MITM.
Чтобы разобраться, как возникает route leak, необходимо понять основные механизмы работы BGP, поскольку утечка вызывается без каких-либо дополнительных манипуляций.
BGP использует номера автономных систем, и по этому критерию выделяют iBGP и eBGP. Разница в том, что iBGP (internal) работает в пределах одной автономной системы, eBGP (external) — между разными. Сейчас нас интересует eBGP: route leak происходит из-за неверных настроек между пирами eBGP.
Предотвращение петель маршрутизации
Для предотвращения петель маршрутизации пиры BGP проверяют атрибут AS PATH. Если в AS PATH есть собственный номер AS — роутер его отбрасывает. Это и есть петля.
Для пиров eBGP действует правило: при получении сообщения UPDATE, в котором хранится информация о маршрутах, следует передать сообщение всем пирам BGP. Для пиров iBGP номер AS не меняется, сообщение UPDATE не передается другим пирам. Это стандартный механизм.
Выбор лучшего пути
BGP использует алгоритм из нескольких шагов (от десяти до тринадцати). В зависимости от вендора и информации о доступности сетей через несколько источников протокол выбирает только один путь, помещает его в локальную таблицу маршрутизации и передает своим пирам.
Есть много способов повлиять на этот выбор. Сейчас мы остановимся на атрибуте AS PATH. Он состоит из последовательности номеров, каждая автономная система добавляет в поле UPDATE сообщения номер своей AS в порядке очереди.
Отсюда вытекает процесс route leak — эффект бабочки: чистый BGP без фильтров может быть крайне опасен и нарушить оптимальные пути трафика.
Практика
R1 и R4 выступают в качестве пограничных провайдерских роутеров, оба маршрутизатора анонсируют сети 192.168.0.0/24 и 172.16.0.0/24 соответственно из своих AS 1 и 2. У каждого провайдера есть договоренность с магистральными провайдерами (R2 и R3) о том, что R1 и R4 будут перегонять трафик через них, а AS 2 и 3 обеспечат нужную пропускную способность, надежность и защиту.
Мы подключим в эту схему провайдера R5. Теперь мы можем, изменив длину AS path, стать транзитной AS для трафика между AS 1 и 2, пропустить через себя весь трафик и вызвать кучу неприятностей и головной боли для всех провайдеров в цепи.
Мы имеем доступ только до R5. R1 и R4 настроили пиринг до адресов 10.0.0.2 и 20.0.0.2 соответственно.
Классический случай для route leaking. Новая автономная система имеет как минимум два пира с разными AS: route leak подразумевает возможность транзита.
Настраиваем пиринг с провайдерами.
Конфигурация R1 и R4:
Маршрутизаторы R1 и R4, которые выступают в нашем примере в качестве провайдеров, тоже получили сообщения UPDATE от маршрутизатора R5. Запустили алгоритм выбора лучшего маршрута в BGP (BGP best path selection) и добавили маршрут R1 — R5 — R4 как лучший в свою локальную таблицу маршрутизации.
Так мы стали транзитным провайдером для трафика из сетей 192.168.0.0 и 172.16.0.0.
Мы видим следующее:
На первый взгляд, не произошло ничего необычного, стандартный алгоритм BGP. Но никто не хочет, чтобы его трафик шел через сторонние AS. Всплывает ряд проблем: uplink до провайдеров может не справиться с пропускной способностью, возникнут задержки, трафик может быть перехвачен и зазеркален.
Чтобы предотвратить такие ситуации, провайдеры должны настраивать community или фильтры ip prefix list для контроля за получением и отдачей трафика. Но потери или угон трафика все равно случаются.
BGP hijacking
В случае BGP hijacking нам не обязательно быть транзитной AS, от нас требуется просто анонсировать из своей AS чужие сети.
Сети провайдера защищены от хайджекинга, они просто не принимают маршруты, маска которых больше /25.
Как избежать route leak
Провайдеры стараются обезопасить себя от возможных утечек и хайджекинга с помощью атрибутов community и фильтров RegEx (регулярные выражения).
Другое применение RegEx — использовать его как очень мощный фильтр, который позволяет заглянуть в анонсы BGP и по присутствию или отсутствию определенных AS отбрасывать или, наоборот, принимать маршруты. Но нельзя предусмотреть все, поэтому лучшим и самым ответственным решением будет внимательно смотреть, что и куда ты анонсируешь из своей AS.
Отфильтровать все лишнее
Необходимо настроить фильтрацию, чтобы префиксы, полученные от одного провайдера, не анонсировались другому и наша AS не стала транзитной.
Взгляни на пример route policy для запрета анонса сетей первого провайдера через второго:
Наш пример в очередной раз доказывает, насколько опасны и непредсказуемы могут быть любые изменения в маршрутизации BGP.
Мы рассмотрели route leak и hijacking на очень скромном примере, однако и в глобальных сетях мировых магистральных провайдеров похожее происходит чуть ли не ежедневно. Если тебе интересно, почитай про , и .
Чтобы разобраться, как возникает route leak, необходимо понять основные механизмы работы BGP, поскольку утечка вызывается без каких-либо дополнительных манипуляций.
BGP использует номера автономных систем, и по этому критерию выделяют iBGP и eBGP. Разница в том, что iBGP (internal) работает в пределах одной автономной системы, eBGP (external) — между разными. Сейчас нас интересует eBGP: route leak происходит из-за неверных настроек между пирами eBGP.
Предотвращение петель маршрутизации
Для предотвращения петель маршрутизации пиры BGP проверяют атрибут AS PATH. Если в AS PATH есть собственный номер AS — роутер его отбрасывает. Это и есть петля.
Для пиров eBGP действует правило: при получении сообщения UPDATE, в котором хранится информация о маршрутах, следует передать сообщение всем пирам BGP. Для пиров iBGP номер AS не меняется, сообщение UPDATE не передается другим пирам. Это стандартный механизм.
Выбор лучшего пути
BGP использует алгоритм из нескольких шагов (от десяти до тринадцати). В зависимости от вендора и информации о доступности сетей через несколько источников протокол выбирает только один путь, помещает его в локальную таблицу маршрутизации и передает своим пирам.
Есть много способов повлиять на этот выбор. Сейчас мы остановимся на атрибуте AS PATH. Он состоит из последовательности номеров, каждая автономная система добавляет в поле UPDATE сообщения номер своей AS в порядке очереди.
В этом примере роутер выберет второй путь: при прочих равных путь через этот источник короче. Этот процесс можно сравнить с платной дорогой. Представь, что до твоего места назначения две дороги: на одной три пункта оплаты проезда, на второй два, цены на обоих одинаковы.
Отсюда вытекает процесс route leak — эффект бабочки: чистый BGP без фильтров может быть крайне опасен и нарушить оптимальные пути трафика.
Практика
R1 и R4 выступают в качестве пограничных провайдерских роутеров, оба маршрутизатора анонсируют сети 192.168.0.0/24 и 172.16.0.0/24 соответственно из своих AS 1 и 2. У каждого провайдера есть договоренность с магистральными провайдерами (R2 и R3) о том, что R1 и R4 будут перегонять трафик через них, а AS 2 и 3 обеспечат нужную пропускную способность, надежность и защиту.
Мы подключим в эту схему провайдера R5. Теперь мы можем, изменив длину AS path, стать транзитной AS для трафика между AS 1 и 2, пропустить через себя весь трафик и вызвать кучу неприятностей и головной боли для всех провайдеров в цепи.
Мы имеем доступ только до R5. R1 и R4 настроили пиринг до адресов 10.0.0.2 и 20.0.0.2 соответственно.
Классический случай для route leaking. Новая автономная система имеет как минимум два пира с разными AS: route leak подразумевает возможность транзита.
Настраиваем пиринг с провайдерами.
Конфигурация R1 и R4:
Проверяем таблицу маршрутизации от R1 до сетей R4:
Переходим к конфигурации с R5:
Получаем маршруты от провайдера R1 и переходим к конфигурации с провайдером R4.
Аналогичным образом, получив таблицу маршрутов от провайдера R4, R5 запустил свой расчет и посчитал, как быстрее всего добираться до каждой сети в нашем примере.
Маршрутизаторы R1 и R4, которые выступают в нашем примере в качестве провайдеров, тоже получили сообщения UPDATE от маршрутизатора R5. Запустили алгоритм выбора лучшего маршрута в BGP (BGP best path selection) и добавили маршрут R1 — R5 — R4 как лучший в свою локальную таблицу маршрутизации.
Так мы стали транзитным провайдером для трафика из сетей 192.168.0.0 и 172.16.0.0.
Мы видим следующее:
Теперь мы видим, что трафик идет через AS 5.
На первый взгляд, не произошло ничего необычного, стандартный алгоритм BGP. Но никто не хочет, чтобы его трафик шел через сторонние AS. Всплывает ряд проблем: uplink до провайдеров может не справиться с пропускной способностью, возникнут задержки, трафик может быть перехвачен и зазеркален.
Чтобы предотвратить такие ситуации, провайдеры должны настраивать community или фильтры ip prefix list для контроля за получением и отдачей трафика. Но потери или угон трафика все равно случаются.
BGP hijacking
В случае BGP hijacking нам не обязательно быть транзитной AS, от нас требуется просто анонсировать из своей AS чужие сети.
Теперь ближайшие AS примут наш UPDATE и станут пересылать трафик в нашу автономную систему. Мы получим доступ до всего трафика, адреса назначения которого находятся в сети 192.168.0.0/24.
Сети провайдера защищены от хайджекинга, они просто не принимают маршруты, маска которых больше /25.
Как избежать route leak
Провайдеры стараются обезопасить себя от возможных утечек и хайджекинга с помощью атрибутов community и фильтров RegEx (регулярные выражения).
Другое применение RegEx — использовать его как очень мощный фильтр, который позволяет заглянуть в анонсы BGP и по присутствию или отсутствию определенных AS отбрасывать или, наоборот, принимать маршруты. Но нельзя предусмотреть все, поэтому лучшим и самым ответственным решением будет внимательно смотреть, что и куда ты анонсируешь из своей AS.
Отфильтровать все лишнее
Необходимо настроить фильтрацию, чтобы префиксы, полученные от одного провайдера, не анонсировались другому и наша AS не стала транзитной.
Взгляни на пример route policy для запрета анонса сетей первого провайдера через второго:
До фильтра:
Так мы получаем полный доступ к таблице маршрутизации от двух провайдеров, не став транзитной AS.
Наш пример в очередной раз доказывает, насколько опасны и непредсказуемы могут быть любые изменения в маршрутизации BGP.
Мы рассмотрели route leak и hijacking на очень скромном примере, однако и в глобальных сетях мировых магистральных провайдеров похожее происходит чуть ли не ежедневно. Если тебе интересно, почитай про , и .