Из грязи в 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 на своей сети. Поздравляем!