Из грязи в RPKI-князи-2. Имплементация RPKI на сетевом оборудовании03.02.2022 11:16

В предыдущей части я рассказывал, почему для ИБ важна валидация маршрутов в ВGP и как каждый клиент сервис-провайдера может обезопасить протоколы маршрутизации с помощью RPKI. 

Но если у вас своя АС с несколькими пирингами, как это бывает у многих банков или ИТ-компаний, то лучшим решением будет внедрить свою валидацию и фильтрацию маршрутов на основе RPKI. И в этом случае прошлой весной вас (и нас) ждал неприятный сюрприз. Широко используемый RPKI-RTR-сервер от RIPE успел получить статус deprecated ☹. Прекратилась разработка и дальнейшая поддержка продукта, с последующим удалением из официального репозитория.

Так что во второй короткой части расскажу, как мы решали проблему с заменой решения и внедряли RPKI на нашем сетевом оборудовании. Покажу на примере Cisco, для которого инструкции от RIPE почему-то нет.

03a20dde9e6e48a9f986f5672265d6c5.jpg

Выбираем и устанавливаем валидатор вместо RIPE«овского

Итак, в прошлом году мы искали замену валидатору от RIPE. Альтернатив достаточно много — мы искали легкое и быстродействующее решение. Поэтому, например, нам не подошел OctoRPKI от Cloudflare: половина написана на Go, поэтому получается чуть менее предсказуемо по перформансу, чем стильный-модный-молодежный Rust. Плюс процесс установки чуть более сложный, но каждый волен выбирать решение по своему вкусу.    

Наш выбор пал на Routinator от NLnet Labs. Простой в установке валидатор, к тому же для нас оказался удобен его интерфейс. 

У нас уже была старая ВМ с установленным валидатором от RIPE, ее пришлось удалить. Локальный кэш-сервер с Routinator задеплоили с нуля. Но при этом сам процесс установки не сильно отличался от установки валидатора от RIPE. Подробная инструкция по установке для разных ОС есть на GitHub, а по сути этапа всего четыре:

  1. Разворачиваем ВМ или baremetal (sic!) с любым дистрибутивом Linux. От выбранного дистрибутива зависит дальнейший процесс установки.

  2. Устанавливаем Routinator через cargo или пакетом.

  3. Активируем Routinator через systemd.

  4. Убеждаемся, что он работает, — заходим на веб-интерфейс.

Все, вы великолепны! Хотя, нет… не все. Нужно же еще настроить на сетевом оборудовании сессии по протоколу RTR, о котором мы уже говорили в прошлый раз.

Настраиваем RTR-сессии

Инструкции по настройке сессий есть на официальном сайте RIPE. Но в нашем случае настраивать будем на маршрутизаторах Cisco c IOS XR на борту. А инструкции для Cisco на сайте RIPE нет!

Так что нужно выполнить следующие шаги:

  1. Заходим в CLI маршрутизатора.

  2. Настраиваем RTR-сессию с валидатором: 

    conf t
router bgp 
 	bgp router-id 
 	bgp cluster-id 
 	rpki server 
  	 username 
  	 password 
  	 transport ssh port 
  	 refresh-time 
   	 response-time 
	 exit
	exit

  3. Активируем RPKI-валидацию на маршрутизаторе и разрешаем прием префиксов типа INVALID. Это временная мера: пока у нас мягкие политики, мы просто занижаем приоритет таким префиксам.

    address-family ipv4 unicast
  bgp origin-as validation enable
  bgp bestpath origin-as allow invalid

  4. Далее проверяем, что сессия установилась: 

    show bgp rpki server summary

    State должен быть ESTAB, выглядит примерно так: 

    Hostname/Address       Transport       State      Time       ROAs (IPv4/IPv6)
   SSH:  ESTAB         /

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

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

Все, минимально рабочая конфигурация готова. Вы успешно имплементировали RPKI на своей сети. Поздравляем!

© Habrahabr.ru