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

    Привет! Я работаю старшим сетевым инженером в компании 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. 

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

    DataLine
    Экосистема ИТ-сервисов

    Комментарии 0

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

    Самое читаемое