Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP источника

Понимание проверки источника для BGP

Проверка источника помогает предотвратить непреднамеренное объявление маршрутов. Иногда сетевые администраторы по ошибке объявляют неуправленные сети маршруты. Эту проблему безопасности можно решить, настроив проверку источника (также известная как защищенная интердоменовая маршрутизация). Проверка источника – это механизм, с помощью которого объявления маршрутов могут аутентификации, исходя из ожидаемой автономной системы (AS). Проверка источника использует один или несколько серверов кэша открытых ресурсов (RPKI) для аутентификации определенных префиксов BGP ресурсов. Для аутентификации префикса маршрутизатор (адресант BGP) запрашивает базу данных проверенных сопоставлений префикса с AS, загружаемых с сервера кэша, и проверяет, что префикс исходит из ожидаемой AS.

Прим.:

При включив аутентификацию RPKI, Junos OS автоматически открывает TCP-порт 2222 без уведомления. Можно применить фильтр для блоки и защиты этого порта.

Junos OS поддерживает проверку источника для префиксов IPv4 и IPv6.

Рис. 1 показывает примерную топологию.

Рис. 1: Пример топологии для проверки источникаПример топологии для проверки источника

Поддерживаемые стандарты

В Junos OS проверки источника поддерживаются следующие документы РНК и проект:

  • RFC 6810, ресурсная инфраструктура открытых ключей (RPKI) протокола маршрутизатора

  • Проверка источника префикса в RFC 6811 BGP,

  • Интернет-проект проект-ietf-sidr-origin-validation-signaling-00, BGP Префикс Origin Validation State Extended (частичная поддержка)

    Расширенное сообщество (состояние проверки источника) поддерживается Junos OS маршрутизации. Указанное изменение в процедуре выбора маршрута не поддерживается.

Как работает проверка источника

RPKI и проверка источника используют сертификаты X.509 с расширениями, указанными в RFC 3779, X.509 Extensions дляIP-адресов и идентификаторов AS.

RPKI состоит из распределенного сбора информации. Каждый орган сертификации опубликовывал сертификаты о конечном объекте (EE), списки отзыва сертификатов (CRLs) и подписанные объекты в определенном местоположении. Все эти хранилища формируют полный набор сведений, доступный каждому серверу кэша RPKI.

Каждый сервер кэша RPKI поддерживает локальный кэш всего распределенного хранилища, регулярно синхронизая каждый элемент локального кэша с исходной точкой публикации репозитория.

На маршрутизаторе записи базы данных отформатированы как записи проверки маршрута (RV) Запись RV является (префикс, максимальная длина, источник AS) тройной. Он соответствует любому маршруту, префикс которого соответствует префиксу RV, длина префикса которого не превышает максимальную длину, заданную в записи RV, и чей источник AS равен as источнику, заданной в записи RV.

Запись RV – упрощенная версия авторизации источника маршрута (ROA). ROA — это объект, подписанный в цифровой формате, который представляет собой средство проверки того, что держатель БЛОКА IP-адресов получил разрешение AS на начало маршрутов к одному или более префиксам в адресном блоке. RoAs не используются напрямую при проверке маршрута. Сервер кэша экспортирует упрощенную версию ROA на маршрутизатор в качестве записи RV.

Максимальное значение длины должно быть больше или равна длине авторизованного префикса и меньше или равна длине (в битах) IP-адреса в семейке адресов (32 для IPv4 и 128 для IPv6). Максимальная длина определяет префикс IP-адреса, который AS имеет право объявлять.

Например, если префикс IP-адреса - 200.4.66/24, а максимальная длина – 26, AS имеет право объявлять 200.4.66.0/24, 200.4.66.0/25, 200.4.66.128/25, 200.4.66.0/26, 200.4.66.64/26, 200.4.66.128/26 и 200.4.66.192/26. При отображении максимальной длины AS имеет право только объявлять префикс, указанный в RV.

В качестве другого примера RV может содержать префикс 200.4.66/24 с максимальной длиной 26, а также префикс 200.4.66.0/28 с максимальной длиной 28. Этот RV разрешает AS объявлять любой префикс, начиная с 200.4.66 с длиной не менее 24 и не более 26, а также конкретный префикс 200.4.66.0/28.

Источник маршрута представлен самым правым номером AS в AS_PATH атрибуте. Проверка источника выполняется путем сравнения исходных AS в обновлении маршрутизации с авторизованным источником AS, опубликованным в записях RV.

Безопасность, предоставленная проверкой источника, как известно, слаба в отношении определенного злоумышленника, поскольку нет защиты против такого атакующего, подменившего исходный AS. Тем не менее, проверка источника обеспечивает полезную защиту от случайных объявлений.

Хотя проверка источника может быть реализована путем непосредственного участия каждого маршрутизатора в RPKI, это будет рассматриваться как слишком интенсивный ресурс (поскольку для проверки данных RPKI требуется множество открытых криптографических операций), а также с интенсивным рабочим процессом для настройки и поддержания конфигурации RPKI на каждом маршрутизаторе. Поэтому отдельный сервер кэша RPKI выполняет проверку открытых ключей и создает проверенную базу данных сопоставлений префикса к AS. Проверенная база данных загружается на клиентский маршрутизатор через защищенное TCP-соединение. Таким образом, маршрутизатору требуется небольшая информация об инфраструктуре RPKI и нет требований криптографии открытого ключа, кроме зашифрованного пароля для транспорта. Затем маршрутизатор использует загруженные данные для проверки полученных обновлений маршрутов.

При настройке серверных сеансов можно сгруппировать сессии вместе и настроить параметры сеанса для каждого сеанса в группе. Маршрутизатор периодически пытается настроить настраиваемое максимальное количество соединений с серверами кэша. В случае неудачной установки соединения периодически попытки подключения.

Тем временем, после того, как политика импорта проверки применяется к сеансу BGP, проверка маршрута выполняется независимо от состояния сеанса кэша (вверх или вниз) и базы данных RV (пустые или не пустые). Если база данных RV пуста или все сеансы сервера кэша не установлены, состояние проверки для каждого маршрута устанавливается неизвестно, поскольку для оценки полученного префикса BGP существует запись RV.

Можно настраивать период повторной попытки. После успешного подключения к кэш-серверу маршрутизатор запрашивает серийный номер последней базы данных и запрашивает, чтобы кэш RPKI транслировал все записи RV, принадлежащие этой версии базы данных.

Каждое входящий сообщение сбрасывает время жизни для сервера кэша RPKI. После того, как все обновления будут обучаемы, маршрутизатор будет выполнять периодические проверки качества работы на основе настраиваемого интервала. Это можно сделать, отправив блок данных протокола последовательного запроса (PDU) с тем же серийным номером, который сервер кэша отчитал в своем последнем уведомлении PDU. Сервер кэша отвечает нулями или более обновлениями и конечными (EOD) PDU данными, которые также обновляют текущее состояние сервера кэша и сбрасывают регистр-срок действия.

При получении префикса от внешнего BGP (EBGP) он рассматривается политикой импорта и маркируется как Valid, Invalid, Unknown или Unverified:

  • Valid (Действительно) — указывает на то, что префикс и пара AS находятся в базе данных.

  • Invalid (Недействительный) — указывает на то, что префикс найден, но соответствующая AS, полученная от равноправного узла EBGP, не является AS, отображенной в базе данных, или длина префикса в сообщении обновления BGP больше, чем максимальная длина, разрешенная в базе данных.

  • Unknown — указывает, что префикс не входит в число префиксов или диапазонов префиксов в базе данных.

  • Unverified — указывает, что источник префикса не проверен по базе данных. Это вызвано тем, что база данных заполнена и проверка не вызвана в политике BGP импорта, хотя проверка источника включена, или проверка источника не включена для BGP равноправных BGP равноправных пользователей.

Если в базе данных проверки есть потенциальные совпадения для маршрута, маршрут должен соответствовать одному из них, чтобы он был действительным. В противном случае он будет недействительным. Любое совпадение является достаточным для того, чтобы маршрут был действительным. Это не должно быть лучшим совпадением. Маршрут считается неизвестным только в отсутствие потенциальных совпадений. Дополнительные сведения о логике сопоставления префикса с AS базы данных см. в разделе 2 Интернет-проект проект-ietf-sidr-pfx-validate-01, BGPПодтверждение источника префикса.

Прим.:

Проверка RPKI доступна только в основном экземпляре. Если для экземпляра маршрутизации настроена проверка RPKI, то проверка RPKI не удаться со следующим сообщением об RV instance is not running ошибке.

BGP взаимодействия с базой данных проверки маршрута

База данных проверки маршрута (RV) содержит набор записей RV, загружаемых маршрутизатором с сервера кэша RPKI. После заполнения базы данных RV записями RV база данных RV сканирует таблицу маршрутов RIB-Local, чтобы определить, есть ли префиксы в RIB-Local, которые могут быть затронуты записями RV в базе данных. (RIB-Local содержит маршруты IPv4 и IPv6, показанные в выходных данных show route protocol bgp команды.)

Этот процесс запускает BGP политик импорта BGP (а не экспорта политик).

Рис. 2 отображает процесс.

Рис. 2: BGP маршрут и проверка маршрута

Политики импорта применяются к RIB-in. Другой способ понять, что политики импорта применяются к маршрутам, показанным в выходных данных команды, в то время как политики экспорта применяются к маршрутам, показанным show route receive-protocol bgpshow route advertising-protocol bgp командой.

Как показано в таблице, для контроля того, какие маршруты BGP в таблице маршрутов, и экспорт политик маршрутов используется для управления маршрутами, которые BGP из таблицы маршрутов соседним Рис. 3 маршрутизаторам.

Рис. 3: Импорт и экспорт политик маршрутовИмпорт и экспорт политик маршрутов

При настройке политики импорта для проверки маршрута конфигурация политики использует validation-database условие совпадения. Это условие совпадения инициирует запрос в базе данных RV о состоянии проверки префикса в данном экземпляре маршрутизации. По умолчанию запрашивается база данных проверки, совпадающая с экземпляром маршрутизации. Если экземпляр проверки маршрута не найден, запрашивается основной экземпляр.

В следующей BGP импорта условие вызывает просмотр в базе данных from validation-database RV маршрутизатора. Если состояние проверки действительно, то происходит действие. Действие – принять маршрут и установить в таблице validation-state маршрутов действительное.

Атрибут сообщества для того, чтобы объявить состояние проверки RPKI соседям IBGP

Проверка префикса проводится только для внешних BGP обновлений (EBGP). В as вам, вероятно, не нужно иметь сеанс RPKI, работающий на каждом внутреннем BGP (IBGP) маршрутизаторе. Вместо этого необходим способ переноса состояния проверки по всей сетке IBGP, чтобы все динамики IBGP могли иметь согласованную информацию. Это осуществляется с помощью данной проверки в не транзитивном расширенном сообществе. Атрибут сообщества объявляет и получает состояние проверки префикса между соседями IBGP.

Junos OS для проверки маршрутов поддерживает следующие хорошо известные расширенные сообщества:

  • источник-проверка-state-valid

  • origin-validation-state-invalid

  • origin-validation-state-unknown

Следующий пример BGP политики импорта настраивается на маршрутизаторе, сеансе с сервером RPKI.

Маршрутизатор с сеансом RPKI

Следующий пример BGP политики импорта настраивается на одноранговом маршрутизаторе IBGP, который не имеет сеанса с сервером RPKI.

Одноранговой маршрутизатор IBGP без сеанса RPKI

Проверка безостановочной активной маршрутизации и источника

При настройке проверки источника на маршрутизаторе с двумя маршрутизаторами маршрутизации и безостановочной маршрутизации активирована, и первичный, и standby Routing Engine имеют копию базы данных RV. Эти две базы данных RV остаются синхронизированными друг с другом.

Маршрутизатор не поддерживает два одинаковых сеанса с сервером RPKI. Протокол RPKI-RTR запускается только на модуль маршрутизации. В режиме ожидания модуль маршрутизации сеанс сервера кэша RPKI всегда не может быть.

База данных RV активно поддерживается основным сервером модуль маршрутизации через сеанс с сервером RPKI. Эта база данных реплицируется на модуль маршрутизации. Хотя сеанс не работает на модуль маршрутизации, реплицированная база данных RV содержит записи RV. Когда standby модуль маршрутизации снова и становится основным модуль маршрутизации, он уже имеет полностью заполненную базу данных RV.

Чтобы просмотреть содержимое двух баз данных, используйте show validation database команды show validation replication database и команды.

Маркировка диапазона префиксов как никогда разрешенного

Модель проверки маршрута имеет один существенный недостаток: Она содержит только положительные обновления. Он может объявить, какая AS является легитимным владельцем префикса. Однако он не может явно передать отрицательное обновление, как в: Этот префикс никогда не исходит от данной AS. Эта функциональность может быть в некоторой степени обеспечена с помощью обходного решения AS 0.

Реализация Junos OS не пытается ограничить входные данные из кэша. Например, установлена и согласована запись RV с AS 0 источника. Это позволяет обходной путь для маркировки диапазона префиксов, который никогда не может быть объявлен, так как AS 0 не является допустимой AS. As в записи RV никогда не соответствует AS, полученной от одноранговых узла EBGP. Таким образом, любой совпадающий префикс помечен как недопустимый.

Пример использования и преимущества проверки источника для BGP

Если администратор автономной системы (AS) начинает объявления всей или части назначенной сети другой компании, то BGP не имеет встроенного метода распознавания ошибки и реагирования таким образом, чтобы избежать перебоев в обслуживании.

Предположим, например, что администратор в сети клиента по ошибке объявляет маршрут (скажем, 10.65.153.0/24), перенаправив трафик поставщику услуг клиента AS 1. Этот маршрут /24 является более конкретным маршрутом, чем маршрут, используемый фактическим поставщиком контента (10.65.152.0/22), который направляет трафик в AS 2. Благодаря тому, как работают маршрутизаторы, большинство маршрутизаторов выбирают более конкретный маршрут и отправляют трафик в AS 1 вместо AS 2.

Захваченный префикс широко распространен в Интернете, поскольку транзитные маршрутизаторы распространяют обновленные данные о пути. Недопустимые маршруты могут быть широко распределены через Интернет, так как маршрутизаторы в свободной зоне (DFZ) по умолчанию имеют захваченный маршрут. Через определенное время правильный путь AS восстанавливается BGP равноправных узлах, но тем временем следует ожидать прерывания обслуживания.

Поскольку BGP зависит от транзитной модели доверия, важное значение имеет проверка между клиентом и поставщиком. В примере выше поставщик услуг AS 1 не проверил неисправное объявление для 10.65.153.0/24. Принимая это объявление и перенаправив его равноправным узлам и поставщикам, AS 1 распространяла неверный маршрут. Маршрутизаторы, которые получили этот маршрут от AS 1, выбрали его, так как это был более конкретный маршрут. Фактический поставщик контента перед ошибкой рекламил 10.65.152.0/22. /24 было меньшее (и более конкретное) объявление. В соответствии с обычным BGP выбора маршрута, затем был выбран /24, фактически завершив перехват.

Даже при быстром обнаружении и выявлении поставщиков контента и сотрудничества с другими поставщиками обслуживание их префиксов может прерываться на многие минуты, до нескольких часов. Точная продолжительность простоя зависит от конкретной точки доступа в Интернет. В таких событиях вновь проявляется интерес к решениям для этой уязвимости. BGP имеет важное значение для отношений с провайдерами и не будет уходить в ближайшее время. В этом примере демонстрируется решение, использующее проверку источника. Данное решение основывается на криптографических расширениях BGP модели распределенного клиент-сервера, которая позволяет избежать чрезмерного перенастройки ЦП маршрутизатора.

Проверка источника помогает преодолеть уязвимость транзитного доверия, позволяя поставщику ограничивать объявления, которые он принимает от клиента. Эти механизмы включают передачу политик маршрутов на основе расширенного BGP сообщества.

Примере: Настройка проверки источника для BGP

В этом примере показано, как настроить проверку источника между BGP равноправными узлами, обеспечивая передачу полученных объявлений маршрутов (исходя из ожидаемой автономной системы (AS). Если проверена as источника, политика может указать, что префиксы, в свою очередь, объявлены.

Требования

В данном примере требования к оборудованию и программному обеспечению следующие:

  • Ресурсная инфраструктура открытых ключей (RPKI) кэш-сервера с использованием сторонного программного обеспечения для аутентификации BGP префиксов.

  • Junos OS версии 12.2 или более поздней версии, которая работает на устройстве маршрутки, которое взаимодействует с сервером кэша по TCP-соединению.

Обзор

Иногда маршруты объявляются непреднамеренно из-за ошибки оператора. Чтобы избежать этой проблемы с безопасностью, можно настроить BGP на проверку и настроив на нее исходную AS и отклонить эти недопустимые объявления. Эта функция использует сервер кэша для аутентификации префиксов или диапазонов префиксов.

Следующие утверждения конфигурации обеспечивают проверку источника AS:

В данном примере для параметров проверки используются настройки по умолчанию.

Большинство доступных троек являются необязательными. Необходимые настройки:

Уровень иерархии позволяет настраивать статические записи на устройстве маршрутов, переописывая записи, полученные с сервера кэша [edit routing-options validation static] RPKI.

Например:

Можно настроить политику маршрутизации, действуя на основе состояния проверки префикса маршрута. Атрибут сообщества можно использовать для того, чтобы объявить и получить состояние проверки префикса между внешними BGP (EBGP) и внутренними равноправными узлами BGP (IBGP). Использование политики маршрутов на некоторых маршрутизаторах может быть удобнее, чем настройка сеанса с сервером RPKI. В этом примере демонстрируется использование атрибута "validation-state community" между равноправными узлами IBGP.

Рис. 4 показывает примерную топологию.

Рис. 4: Топология для проверки источникаТопология для проверки источника

В данном примере устройство R0 имеет IBGP-соединение с устройством R1 и EBGP соединение с устройством R2. Устройство R0 получает записи проверки маршрута (RV) с сервера кэша с помощью протокола, определенного в проекте проекта Интернет-проекта-ietf-sidr-rpki-rtr-19, протокол RPKI/маршрутизатора для отправки записей RV. Протокол RPKI-маршрутизатора работает через TCP. Записи RV используются устройством R0 для создания локальной базы данных RV. На устройстве R1 состояние проверки устанавливается на основании BGP "проверка-state", полученного вместе с маршрутом.

Конфигурации

интерфейс командной строки быстрой конфигурации

Чтобы быстро настроить этот пример, скопировать следующие команды, ввести их в текстовый файл, удалить все разрывы строки, изменить все данные, необходимые для настройки сети, а затем скопировать и вкопировать команды в интерфейс командной строки на [edit] иерархии.

Устройство R0

Устройство R1

Устройство R2

Настройка устройства R0

Пошаговая процедура

В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.

Для настройки устройства R0:

  1. Настройте интерфейсы.

  2. Настройте BGP.

    Примените экспортную политику таким образом, чтобы прямые маршруты экспортировали из send-direct таблицы маршрутов в BGP.

    Примените политику импорта для того, чтобы установить атрибуты validation-state и BGP сообщества для всех маршрутов, импортируемых (или полученных) с одноранговых устройств validation EBGP устройства R0.

    Настройте сеанс IBGP с устройством R1. Настройте сеанс EBGP с устройством R2.

  3. Настройте OSPF (или другой протокол внутреннего шлюза [IGP]) на интерфейсе, который сталкивается с одноранговой IBGP и на интерфейсе обратной связи.

    Прим.:

    Если в сообщении IBGP используется адрес интерфейса обратной связи, необходимо включить интерфейс IGP neighbor интерфейса обратной связи. В противном случае сеанс IBGP не будет установлен.

  4. Настройте политику маршрутов, которая экспортирует прямые маршруты из таблицы маршрутов в BGP.

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

  6. Настройте сеанс с сервером кэша RPKI.

  7. Настройте номер автономной системы (AS).

Результаты

В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show protocols и show policy-optionsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.

После настройки устройства войдите в commit режим конфигурации.

Настройка устройства R1

Пошаговая процедура

В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.

Настройка устройства R1:

  1. Настройте интерфейсы.

  2. Настройте BGP.

    Примените политику импорта для того, чтобы установить параметр validation-state и BGP сообщества для всех маршрутов, полученных от одноранговых устройств validation-ibgp IBGP устройства R1.

    Настройте сеанс IBGP с устройством R0.

  3. Настройте OSPF.

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

  5. Настройте номер автономной системы (AS).

Результаты

В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show protocols и show policy-optionsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.

После настройки устройства войдите в commit режим конфигурации.

Настройка устройства R2

Пошаговая процедура

В следующем примере необходимо провести различные уровни в иерархии конфигурации. Для получения информации о навигации по интерфейс командной строки см. использование редактора интерфейс командной строки в режиме конфигурации в руководстве Junos OS интерфейс командной строки пользователя.

Настройка устройства R2:

  1. Настройте интерфейсы.

    Для демонстрационных целей на интерфейсе обратной связи настроено несколько адресов.

  2. Настройте BGP.

  3. Настройте политику маршрутов.

  4. Настройте номер автономной системы (AS).

Результаты

В режиме конфигурации подтвердите конфигурацию путем ввода show interfaces команд show protocols и show policy-optionsshow routing-options команд. Если в выходных данных не отображается указанная конфигурация, повторите инструкции, показанные в данном примере, чтобы исправить конфигурацию.

После настройки устройства войдите в commit режим конфигурации.

Проверки

Подтвердим, что конфигурация работает правильно.

Проверка отображения измененных атрибутов в таблицах маршрутов

Цель

Убедитесь BGP на маршрутизаторах Device R0 и Device R1 имеются ожидаемые состояния проверки и ожидаемые локальные предпочтения.

Действий

В рабочем режиме введите show route команду.

Смысл

Маршруты имеют ожидаемые состояния проверки и значения локального предпочтения на основе информации, полученной от сервера кэша RPKI.

Использование операций трассировки

Цель

Настройте операции трассировки для проверки источника и отслеживайте результаты вновь объявленного маршрута.

Действий
  • На устройстве R0 настройте трассировку.

  • На устройстве R2 добавьте маршрут, добавив еще один адрес на интерфейсе обратной связи.

  • На устройстве R0 проверьте файл трассировки.

Смысл

Проверка маршрута работает, как ожидалось.

Отображение сведений о проверке

Цель

Запустите различные команды проверки.

Действий