В предыдущей части я рассказывал, почему для ИБ важна валидация маршрутов в В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 на своей сети. Поздравляем!

Комментарии (1)


  1. alex_www
    04.02.2022 19:04

    Делая

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

    BGP будет делать новую версию роутинг таблицы на каждое обновление RPKI базы в роутинаторе. Лучше делать все политиками, скажем так

    route-policy rpki-route-validation
    if validation-state is invalid then
    drop
    else
    pass
    endif
    end-policy

    и добавлять ее на клиентские сессии. Скажем так

    route-policy customer1-import-pol
    apply as-path-filer1

    apply black-hole-policy

    apply prefif-filter1
    apply rpki-route-validation
    apply standard-cust-policies
    end-policy

    Так мы сможем решить ряд проблем. Например политикой мы можем разрешить ipv4 /32 с blackhole community или какие-нибудь сессии от кубера. В тоже время RPKI валидация включеная как у Вас сразу в address family лишает Вас такой гибкости.