Из грязи в RPKI-князи-1. Подключаем валидацию маршрутов в ВGP

Как клиенту подключить средство защиты глобальной маршрутизации в сети Интернет.

10 декабря 2020  • 

Привет! Я работаю старшим сетевым инженером в компании DataLine, занимаюсь сетями с 2009 года и успел со стороны понаблюдать, как компании подвергались атакам из-за уязвимости протокола маршрутизации BGP. Один BGP Hijacking чего стоит: пару лет назад хакеры с помощью перехвата BGP-маршрутов украли 137 тыс. долларов.

С переходом на удаленку компании организуют доступ из дома через защищенные соединения с помощью NGFW, IPS/IDS, WAF и прочих решений. Но про безопасность BGP порой забывают. Я расскажу в цикле статей, как каждый клиент сервис-провайдера может обезопасить себя с помощью RPKI – средства защиты глобальной маршрутизации в сети Интернет.

В первой статье на примере объясню, как это работает и как настроить защиту на стороне клиента в пару кликов. Во второй – поделюсь опытом внедрения RPKI в BGP на примере маршрутизаторов Cisco.

Что важно знать про RPKI, и при чем тут холодильник

RPKI (Resource Public Key Infrastructure) – это специализированная инфраструктура открытых ключей. Она помогает доказать подлинность ресурса в интернете, а также право ресурсодержателя использовать ресурсы и передавать информацию о ресурсах операторам связи.

Можно сравнить эту инфраструктуру с холодильником в общежитии или офисе. Вы получаете право пользоваться общим холодильником (интернетом), складываете еду на определенную полку (публикуете ресурсы), но обязаны определенным образом подписывать еду, чтобы ее не забрал кто-то еще.

Так и тут. RPKI использует для подписей профиль сертификата X.509 PKI, который описан в RFC3779. Операторы связи с его помощью принимают безопасные решения о маршрутизации ресурсов в сети Интернет. Чтобы увидеть, как они это делают, напомню про иерархию выделения ресурсов в интернете:

Ресурсы последовательно выделяют несколько организаций:

IANA (Internet Address Number Authority) – администрация адресного пространства интернета. Интернет-ресурсы изначально принадлежат IANA, она управляет пространствами IP-адресов для доменов верхнего уровня. Она же присваивает номера для автономных систем (AS) – систем IP-сетей и маршрутизаторов, которыми управляют операторы связи. Эти номера AS необходимы для маршрутизации.

RIR (Regional Internet Registry) – региональные интернет-регистраторы, IANA распространяет ресурсы через них. Всего их 5 для разных регионов – RIPE NCC, ARIN, APNIC, AfriNIC, LACNIC.

LIR (Local Internet Registry) – локальные интернет-регистраторы, как правило, крупные сервис-провайдеры. RIR распространяет ресурсы на LIR’ы, которые уже распределяют их между своими клиентами.

Такая же архитектура у RPKI. После каждого распределения ресурсов создается сертификат, подписанный ключом вышестоящей организации. IANA выпускает сертификаты для доверенных RIR, а они – для доверенных LIR.

Сертификаты хранятся в базе данных, по которой можно проверять достоверность информации. Базы данных расположены на публичных репозиториях RPKI у всех RIR – на так называемых “точках доверия”, или Trust Anchors.

Тут в игру вступают владельцы ресурсов в интернете. Чтобы подтвердить безопасность ресурсов, они создают с помощью сертификатов криптографически заверенные объекты, или ROA.

ROA (Route Origin Authorisation) – это объект c цифровой подписью, который подтверждает, что конкретная AS  имеет право быть источником какого-то маршрута и анонсировать его в интернете.

Запись ROA имеет 3 параметра:

  • номер AS, которая является источником маршрута;
  • префикс и его длина (это IP-адрес с маской: xxx.xxx.xxx.xxx/yy);
  • максимальная длина префикса.

С помощью максимальной длины префикса указывается, может ли данная AS анонсировать более специфичный маршрут. По умолчанию это запрещено, и длина префикса равна максимальной длине. Это значит, что анонс префикса с более длинной маской будет считаться неавторизованным.

Следовательно, при проверке подлинности любой префикс можно сравнить с ROA и задать ему три состояния:

  • VALID – для префикса есть ROA, и анонс маршрута совпадает по всем параметрам с референсными значениями в ROA.  AS в AS_PATH совпадает с AS в записи ROA, префикс тоже как в ROA, а его максимальная длина больше или равна длине маски в анонсе.
  • INVALID – для префикса есть ROA, но анонс маршрута не совпадает по одному из параметров в ROA.
  • UNKNOWN – значит, что запись ROA для префикса отсутствует в Trust Anchor вашего RIR. Это возможно, если префиксы еще не завалидированы. Пока все только переходят на RPKI, многие операторы связи применяют мягкие политики и доверяют таким префиксам. При жесткой политике безопасности префикс UNKNOWN будет отклонен маршрутизатором.

Разберем проверку префикса на примере. Допустим, у меня есть префикс х.х.х.х/22, который маршрутизируется в сети Интернет и анонсируется из моей AS N. Изначально я  не создал для него записи ROA. Раз запись о префиксе отсутствует в Trust Anchor, анонс префикса будет иметь статус UNKNOWN.

Далее я создал для него запись ROA c параметрами: AS N, префикс х.х.х.х/22, максимальная длина префикса – /23. Теперь от имени своей AS N я могу проанонсировать апстрим-провайдерам этот префикс /22 или же две /23 подсети, которые входят в /22 подсеть. Такой анонс будет иметь статус VALID.

Если же я проанонсирую /24 от имени AS N или префикс /22 (/23+/23) от имени AS P, то такой анонс будет иметь статус INVALID. Допустим, нам необходимо проанонсировать подсеть /24 из более крупного блока адресов, который уже анонсируется в глобальную сеть. Значит, в записи ROA для более крупной подсети нужно изменить параметр максимальной длины префикса или создать для нее свой ROA.

Проверка подлинности маршрутов на маршрутизаторах происходит одним из способов:

  1. Проверка самим маршрутизатором по прямой RPKI-сессии.
  2. Загрузка на маршрутизатор готовой базы данных с локального кэш-сервера RPKI.

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

Второй способ не требует таких больших затрат. Локальный кэш-сервер RPKI загружает в себя базу ROA со всех установленных Trust Anchors по протоколу RSYNC или RRDP и поддерживает ее в актуальном состоянии. Локальный RPKI-сервер на основе своей базы данных ROA генерирует базу данных для маршрутизатора. Каждая запись базы содержит упрощенный вариант ROA, и эта база передается на маршрутизатор по протоколу RPKI-RTR. По умолчанию это TCP-порт 8282. По этим данным на маршрутизаторе настраиваются политики для маршрутизации полученных префиксов.

Как завалидировать свои префиксы

Допустим, вы – клиент сервис-провайдера.  У вас есть своя AS с парой /24 блоков IP-адресов, вы пиритесь по eBGP со своим провайдером, full view от него не получаете, других пирингов у вас нет. Вам приходит письмо, что провайдер внедряет на своей стороне систему валидации префиксов на основе RPKI и просит завалидировать свои анонсы.

В этом случае вам нужно подписать ROA свои префиксы, чтобы в дальнейшем ваши ресурсы были доступны из сети Интернет.

Для регионального регистратора RIPE NCC шаги такие:

  1. Зайдем на портал RIPE в личный кабинет по адресу https://my.ripe.net. В правой части страницы перейдем в Resourses, далее – в RPKI Dashboard.

    Если вы раньше никогда не заходили на эту страницу, RIPE попросит вас подписать соглашение EULA. Затем выбираем тип центра сертификации (Certificate Authority, CA):

    • Hosted – хранить сертификат на стороне RIPE;
    • Non-Hosted – хранить сертификат на своей стороне.

    Быстрее и удобнее выбрать вариант Hosted. В варианте Non-Hosted вам нужно предоставить XML-файл, сгенерированный вашим ПО центра сертификации. Система RIPE NCC сгенерирует ответный XML-файл, который нужно загрузить и использовать в своем программном обеспечении RPKI CA.

  2. В RPKI Dashboard перейдем во вкладку BGP Announncements. В нижней части экрана в меню Show выберем All.

  3. Вернемся в начало страницы и выберем все префиксы по чек-боксу рядом с надписью Origin AS. Создадим ROA по кнопке Create ROAs for selected BGP announcements.

  4. Подождем, пока сформируется стейджинг ROA. Внизу появится кнопка:

    Нажмем ее и во всплывающем меню нажмем Publish!

Все, готово! Вы успешно завалидировали свои префиксы!

Для счастливых обладателей PI-адресов RIPE подготовил отдельную инструкцию для валидации префиксов.  А еще удобнее использовать Wizard от RIPE NCC: https://portal.ripe.net/rpki-enduser.

Сейчас все крупные компании внедряют проверку маршрутов на базе RPKI. Рано или поздно валидацию BGP нужно подключить всем, кто хочет, чтобы приложения и сайты были доступны, а проверки маршрутов – успешны.

Если же вы сами являетесь сервис-провайдером, то лучше  внедрить свою валидацию и фильтрацию маршрутов на основе RPKI.

Но об этом поговорим в следующий раз, всем пока и до встречи!

Расскажите друзьям и коллегам о статье
  • Поделиться
  • Поделиться
  • Поделиться

Последние статьи

15 апреля
Сергей Жильцов

Главные вопросы при планировании инфраструктуры виртуальных рабочих столов.

08 апреля
Николай Продайвода

Как организовать гарантированный канал доставки трафика, даже если нет возможности подвести оптику и закупить дорогостоящее оборудование.

25 марта
Вячеслав Нечаев

Комментарии

Подпишитесь на нашу рассылку

Получайте свежие и полезные материалы и приглашения на наши мероприятия