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

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

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

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

Выбираем и устанавливаем валидатор вместо 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 <as-number>
    	bgp router-id <router-id>
    	bgp cluster-id <cluster-id>
    	rpki server <server-ip-address>
     	 username <username>
     	 password <password>
     	 transport ssh port <ssh-port>
     	 refresh-time <value-in-seconds>
      	 response-time <value-in-seconds>
   	 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)
   <rpki-rtr-server-ip>   SSH:<ssh-port>  ESTAB      <uptime>   <ipv4-ROAs>/<ipv6-ROAs>

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

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

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