As set bgp что это

Подключение по BGP и анонсирование PI префикса

Клиенты Selectel, которые хотят использовать свою провайдеро-независимую официально зарегистрированную публичную IP-адресацию, могут подключить анонсирование подсети PI в двух вариантах:

Глоссарий

Подключение по протоколу BGP

Чтобы воспользоваться услугой подключения по протоколу BGP, необходимо:

Схема присоединения роутера клиента по BGP

Обратите внимание! Должна использоваться подсеть из адресного подпространства Selectel.

Для настройки сессии с пограничными роутерами Selectel на роутере клиента должно быть настроено:

Как подключить услугу

Для подключения протокола по BGP в панели управления:

В тикете придет сообщение о готовности подключения.

Анонсирование PI префикса (IPv4 и IPv6)

Можно выбрать анонсирование PI префикса по схемам: direct и static.

В случае подключения услуги для IPv6 адресов анонсирование блоков IPv6 производится только с использованием static-route либо через подключение BGP. Для IPv4 подсетей по умолчанию используется вариант direct.

Чтобы заказать и воспользоваться услугой анонсирования PI префикса, необходимо:

Схема PI direct

Не требуется наличие шлюза на оборудовании клиента.

Схема PI static

Оборудование клиента выступает шлюзом для подсети. Должна быть подсеть из адресного подпространства Selectel.

Как подключить услугу

Для подключения анонсирования PI префикса в панели управления:

В тикете придет сообщение о готовности подключения.

Источник

BGP hijacking с помощью добавления AS жертвы в AS-SET атакующего

Статья поделена на три части части. В первой содержится общая информация о том что такое BGP hijacking и его традиционный вариант. Для тех кто знаком с этим явлением, рекомендуется перейти сразу ко второй части. Во второй части будет описан метод анонсирования чужих префиксов с помощью добавления чужой AS в свой AS-SET. В третьей части, будет сделана оценка сложности использования метода, описанного во второй части, для захвата IP-адреса ресурса torproject.org и выписки сертификата для него. Предполагается, что читатель знаком с принципами работы BGPv4.

Простой BGP hijacking

Если в двух словах, то BGP hijacking это захват чужих IP-адресов (случайный или преднамеренный).

Обычно, BGP hijacking выглядит таким образом: AS, которой не принадлежит какой-то префикс начинает его (чужой префикс) анонсировать, аплинки/пиры его принимают, и он начинает распространяться по Интернет. Принимают они его по той причине, что нет фильтрации префиксов на стыке (либо это ошибка конфигурации, либо так задумано (т.к. построить префикс-фильтр на стыке с очень крупными операторами очень сложно ввиду различных причин, для этой статьи это не важно)). Один из самых громких примеров недавнего времени, когда Ростелеком (AS12389) начал анонсировать префиксы Mastercard (AS26380), Visa и некоторых других финансовых организаций (по официальной версии, в результате сбоя ПО). Как выглядели эти анонсы, можно посмотреть в истории bgplay (просмотр через web, json (архив)), вот один из них на одном из коллекторов RIPE (префикс 216.119.216.0/24 принадлежит Mastercard (AS26380)):

А вот как выглядел настоящий анонс:

Т.е. в данном случае Ростелеком анонсировал префикс непосредственно от своей AS (последняя AS в AS-PATH — 12389). Проблемы можно было бы избежать, если бы аплинки и пиры Ростелекома фильтровали префиксы от Ростелеком путём построения префикс-листов по AS-SET и/или валидировали префиксы по ROA RPKI. Построение префикс-листов между крупными операторами зачастую не делается, а RPKI тоже внедрили далеко не все (но прогресс есть). Такой hijacking, теоретически, может совершить кто угодно, но только если анонсируемый префикс «просочится» через хотя бы один аплинк/пир. Обычно, крупные операторы России настраивают префикс-фильтры в сторону своих клиентов и поэтому, небольшие AS (маленькие/средние операторы, некоторые хостинги и некоторые предприятия), почти всегда, такую атаку совершить не могут (но опять же, это всё зависит от региона/страны/конкретного оператора).

Однако, злоумышленники всё-таки находят места (аплинков), где фильтрация не настроена (В 2017 году лидером по hijacking была Бразилия) и осуществляют атаку захват IP-адресов (зачастую, такие события попадают в новостные ленты), для большей эффективности атаки, могут анонсировать более специфичные префиксы (с более длинной маской), чем настоящий оригинатор. Теперь перейдём к варианту атаки, где не спасают ни валидация по ROA RPKI, ни префикс-листы, построенные по AS-SET.

BGP hijacking с добавлением AS жертвы в свой AS-SET

Рассмотрим следующий сценарий:

Сложно ли захватить torproject.org

Злоумышленнику нужно решить две задачи:

Как видно, CAA-запись есть, можно получить сертификат у letsencrypt, к аккаунту привязки нет в CAA-записи, значит задача теоретически решаема злоумышленником. IP-адреса домена torproject.org принадлежат довольном известному хостингу Hezner.

Допустим, ЦА злоумышленника это клиенты какого-нибудь российского оператора. Hezner не является клиентом российских операторов (но имеет пиринг с крупными — напрямую или через IX-ы). Чтобы злоумышленнику перенаправить трафик ЦА к себе, проще всего, стать клиентом этого оператора и просто выиграть за счёт более высокого local-pref. Здесь особо всё относительно просто и понятно.

Источник

Принципы работы протокола BGP

Сегодня мы рассмотрим протокол BGP. Не будем долго говорить зачем он и почему он используется как единственный протокол. Довольно много информации есть на этот счет, например тут.

Итак, что такое BGP? BGP — это протокол динамической маршрутизации, являющийся единственным EGP( External Gateway Protocol) протоколом. Данный протокол используется для построения маршрутизации в интернете. Рассмотрим как строится соседство между двумя маршрутизаторами BGP.

Рассмотрим соседство между Router1 и Router3. Настроим их при помощи следующих команд:

Соседство внутри одной автономной системы — AS 10. После ввода данных на маршрутизаторе, например на Router1, данный маршрутизатор пытается настроить отношения соседства с маршрутизатором Router3. Начальное состояние, когда ничего не происходит называется Idle. Как только будет настроен bgp на Router1, он начнет слушать TCP порт 179 — перейдет в состояние Connect, а когда пытается открыть сессию с Router3, то перейдет в состояние Active.

После того, как сессия установится между Router1 и Router3, то происходит обмен Open сообщениями. Когда данное сообщение отправит Router1, то данное состояние будет называться Open Sent. А когда получит Open сообщение от Router3, то перейдет в состояние Open Confirm. Рассмотрим более подробно сообщение Open:

В данном сообщение передается информация о самом протоколе BGP, который использует маршрутизатор. Обмениваясь Open сообщениями, Router1 и Router3 сообщают друг другу информацию о своих настройках. Передаются следующие параметры:

Для установления соседства необходимо выполнения следующих условий:

Здесь указывают сети, о которых сообщает Router1 и Path attributes, которые являются аналогом метрик. О Path attributes мы поговорим более подробно. Также внутри TCP сессии передаются Keepalive сообщения. Они передаются, по умолчанию, каждые 60 секунд. Это Keepalive Timer. Если в течении Hold Timer-а не будет получено Keepalive сообщение, то это будет означать потерю связи с соседом. По умолчанию, он равен — 180 секундам.

Вроде бы разобрались как маршрутизаторы передают друг другу информацию, теперь попытаемся разобраться с логикой работы протокола BGP.

Чтобы анонсировать какой-нибудь маршрут в таблицу BGP, как и в протоколах IGP, используется команда network, но логика работы отличается. Если в IGP, после указание маршрута в команде network, IGP смотрит — какие интерфейсы принадлежат данной подсети и включает их в свою таблицу, то команда network в BGP смотрит в таблицу маршрутизации и ищет точное совпадение с маршрутом в команде network. При нахождении таких, данные маршруты попадут в таблицу BGP.

Look for a route in the router’s current IP routing table that exactly matches the parameters of the network command; if the IP route exists, put the equivalent NLRI into the local BGP table.

Теперь поднимем BGP на всех оставшихся и посмотрим как происходит выбор маршрута внутри одной AS. После того, как BGP маршрутизатор получит маршруты от соседа, то начинается выбор оптимального маршрута. Здесь надо понять какого вида соседи могут быть — внутренние и внешние. Маршрутизатор по конфигурации понимает является ли сконфигурированный сосед внутренним или внешним. Если в команде:

в качестве параметра remote-as указан AS, который сконфигурирован на самом маршрутизаторе в команде router bgp 10. Маршруты, пришедшие из внутренней AS считаются внутренними, а маршруты из внешней соответственно внешними. И по отношению к каждому работает разная логика получения и отправки. Рассмотрим такую топологию:

На каждом маршрутизаторы настроен loopback интрефейс с ip: x.x.x.x 255.255.255.0 — где x номер маршрутизатора. На Router9 у нас есть loopback интерфейс с адресом — 9.9.9.9 255.255.255.0. Его мы будем анонсировать по BGP и посмотрим как он распространяется. Данный маршрут будет передан на Router8 и Router12. С Router8 данный маршрут попадет на Router6, но на Router5 в таблице маршрутизации его не будет. Также и на Router12 данный маршрут попадет в таблицу, но на Router11 его также не будет. Попытаемся разобраться с этим. Рассмотрим какие данные и параметры передается Router9 своим соседям, сообщая об этом маршруте. Пакет внизу будет отправлен с Router9 на Router8.

Информация о маршруте состоит из аттрибутов пути (Path attributes).

Атрибуты пути разделены на 4 категории:

Атрибут Origin — указывает на то, каким образом был получен маршрут в обновлении. Возможные значения атрибута:

Далее, Next-hop. Атрибут Next-hop

Теперь Router6 передал маршрут Router5 и первому правилу Next-hop не изменил. То есть, Router5 должен добавить 9.9.9.0 [20/0] via 192.168.68.8, но у него нет маршрута до 192.168.68.8 и поэтому данный маршрут добавлен не будет, хотя информация о данном маршруте будет храниться в таблице BGP:

Та же самая ситуация произойдет и между Router11-Router12. Чтоб избежать такой ситуации необходимо настроить, чтоб Router6 или Router12, передавая маршрут своим внутренним соседям, подставляли в качестве Next-hop свой ip адрес. Делается при помощи команды:

После данной команды, Router6 отправит Update сообщение, где для маршрутов в качества Next-hop будет указан ip интерфейса Gi0/0 Router6 — 192.168.56.6, после чего данный маршрут уже попадет в таблицу маршрутизации.

Пойдем дальше и посмотрим появиться ли этот маршрут на Router7 и Router10. В таблице маршрутизации его не окажется и мы могли бы подумать, что проблема как в первом с параметром Next-hop, но если мы посмотрим вывод команды show ip bgp, то увидим, что там маршрут не был получен даже с неправильным Next-hop, что означает, что маршрут даже не передавался. И это нас приведет к существованию еще одного правила:

Маршруты, полученные от внутренних соседей не передаются другим внутренним соседям.

Так как, Router5 получил маршрут от Router6, то другому своему внутреннему соседу он передаваться не будет. Для того, чтобы передача произошла необходимо настроить функцию Route Reflector, либо настроить полносвязные отношения соседства ( Full Mesh), то есть Router5-7 каждый будет соседом с каждым. Мы будем в данном случае использовать Route Reflector. На Router5 необходимо использовать данную команду:

Route-Reflector меняет поведение BGP при передаче маршрута внутреннему соседу. Если внутренний сосед указан как route-reflector-client, то данным клиентам будут анонсироваться внутренние маршруты.

Маршрут не появился на Router7? Не забываем также и про Next-hop. После данных манипуляций маршрут должен и на Router7, но этого не происходит. Это нас подводит к еще одному правилу:

Правило next-hop работает только для External маршрутов. Для внутренних маршрутов замена атрибута next-hop не происходит.

И мы получаем ситуацию, в которой необходимо создать среду при помощи статичной маршрутизации или протоколов IGP сообщить маршрутизаторам о всех маршрутах внутри AS. Пропишем статические маршруты на Router6 и Router7 и после этого получим нужный маршрут в таблице маршрутизаторе. В AS 678 же мы поступим немного иначе — пропишем статические маршруты для 192.168.112.0/24 на Router10 и 192.168.110.0/24 на Router12. Далее, установим отношения соседства между Router10 и Router12. Также настроим на Router12 отправку своего next-hop для Router10:

Итогом будет то, что Router10 будет получать маршрут 9.9.9.0/24, он будет получен и от Router7 и от Router12. Посмотрим какой выбор сделает Router10:

Как мы видим, два маршрута и стрелка ( > ) означает, что выбран маршрут через 192.168.112.12.
Посмотрим как происходит процесс выбора маршрута:

Теперь все маршруты от данного соседа будут иметь такой вес. Посмотрим как изменится выбор маршрута после данной манипуляции:

Но как видим один маршрут через Router6. А где же маршрут через Router7? Может и на Router7 его нет? Смотрим:

Странно, вроде все в порядке. Почему же он не передается на Router5? Все дело в том, что у BGP есть правило:

Маршрутизатор передает только те маршруты, которые использует сам.

Router7 используется маршрут через Router5, поэтому маршрут через Router10 передаваться не будет. Вернемся к Local Preference. Давайте зададим Local Preference на Router7 и посмотрим как отреагирует на это Router5:

Итак, мы создали route-map, в который попадаются все маршруты и сказали Router7, чтоб при получение он менял параметр Local Preference на 250, по умолчанию равен 100. Смотрим, что произошло на Router5:

Посмотрим, что произойдет, если допустим Router6 потеряет маршрут 9.9.9.0/24 через Router9. Отключим интерфейс Gi0/1 Router6, который сразу поймет, что BGP сессия с Router8 оборвана и сосед пропал, а значит и маршрут, полученные от него не действительны. Router6 сразу отправляет Update сообщения, где указывает сеть 9.9.9.0/24 в поле Withdrawn Routes. Как только Router5 получит подобное сообщение, отправит его к Router7. Но так как у Router7 есть маршрут через Router10, то в ответ сразу отправит Update c новым маршрутом. Если детектировать падения соседа по состоянию интерфейса не получается, то придеться ждать срабатывания Hold Timer-а.

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

Здесь ссылка на данную лабу, а тут конфигурация для GNS3.

Пришлось бы настраивать Route-Reflector или полносвязые отношения соседства. Разбивая одну AS 2345 на 4 sub-AS ( 2,3,4,5) для каждого маршрутизатора, мы в итоге получаем другую логику работы. Все отлично описано здесь.

Источник

BGP: Aggregate-address, as-set.

Продолжаем разбираться с агрегированием маршрутов в BGP.

Сейчас мы рассмотрим параметр as-set, что он нам дает и для чего использовать.

Например у нас есть роутер A, имеющий сети 10.0.0.0/24, 10.0.1.0/24, к нему подключен по ebgp роутер B с сеткой 10.0.2.0/24.

Мы принимаем решение сделать суммаризацию маршрутов в /16 сетку на роутере B. Как это сделать, мы уже знаем : aggregate-address 10.0.0.0 255.255.0.0 summary-only

Так же роутер А у нас подключен к другой AS, та в свою очередь еще к одной и так далее, и при просмотре маршрутов BGP на тех роутерах, мы будем видеть, что маршрут к нам пришел из AS роутера А (а на самом то деле из AS роутера B).

Смотрим на сеть 10.0.0.0/16 видим, что маршрут пришел из 10-ой системы (на самом деле здесь агригируется маршрут из другой, 40-ой системы), потом прошел через 100-ую.

Если мы укажем параметр as-aet в aggregate-address, то мы увидим и ту систему из которой пришла сеть, которая в дальнейшем была агрегирована.

aggregate-assress 10.0.0.0 255.255.0.0 as-set summary-only

и смотрим изменения:

Теперь видим, что добавилась AS, 40, в которой и был создан наш маршрут, который в дальнейшем был склеен.

Чем же нам грозит то, что не будет видно AS в которой был поражден маршрут? А тем, что может возникнуть петля.

В BGP реализован простейший метод проверки на петлю. При получении маршрута смотрится AS-PATH, и если себя там не обнаруживаем, то считается что петель нет, и наоборот, если мы находим там свою AS, то маршрут отбрасывается — loop detected. Так работает BGP по умолчанию, но это умолчание может изменяться.

Для того, что бы посмотреть, кем был агрегирован маршрут, можно использовать команду:

Видим, что aggregated by указывает на IP того роутера, который суммаризовал запрос. И рядом видим AS. Все честно 🙂

Источник

Протокол BGP. Маршрутизация по-взрослому.

Назначим и Loopback-интерфейсу какой-нибудь адрес, чтобы далее проверить связность:

Сначала поднимаем процесс BGP и назначаем AS Number, именно тот, что выдал нам LIR!
Далее настраиваем пиринг, задаем информацию о соседе:

В CLI появится сообщение:

Ура? Ура, но проверим состояние процесса.

Одно состояние сменяет другое и вот достигнут Established. Маршрутизатор за это время отправил одно OPEN-сообщение и аналогичное получил, а также получил и принял по два KEEPALIVE.
Проверим о каких сетях знает BGP.
sh ip bgp

Ни-че-го. Смотрим на R2.

И тут тоже самое.
А всё тут просто. До прописанной командой network сети должен быть точный маршрут, в противном случае она не окажется в таблице BGP. А муршрута нет:

А его и вписывать некуда, кроме разве что Loopback-интерфейса. Ну нет нигде этой сети. Исхитримся так:

Давайте резюмировать. Если у вас нет цели гонять через себя транзитный трафик (подключать через себя другие AS) и не требуется гибкое распределение исходящего трафика, то вам дорога к Default Route.
Но вот точно не имеет смысла принимать от одного провайдера анонсы Full View, а от другого Default Route, т.к. один линк всегда будет простаивать и не станет гонять через себя исходящий трафик, ведь выбираться будет более специфический маршрут, который точно найдется среди анонсированного вам Full View.
Но ничего не мешает брать от всех провов Default Route и в нагрузку определенные префиксы (конкретно этого провайдера, например). Тогда до нужных ресурсов у вас будут специфические маршруты, но при этом без Full View.
Взглянем на пример настройки Default Route для линка в нижестоящему маршрутизатору:

Тогда на нашем бордере таблица маршрутов будет такой:

Теперь кроме обычных входящих в Full View маршрутов будет присутствовать и маршрут по-умолчанию.

Источник