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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

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

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

Источник: https://habr.com/ru/company/dataline/blog/532292/


Интересные статьи

Интересные статьи

Всем привет. Когда я искал информацию о журналировании (аудите событий) в Bitrix, на Хабре не было ни чего, в остальном рунете кое что было, но кто же там найдёт? Для пополнения базы знаний...
В обновлении «Сидней» Битрикс выпустил новый продукт в составе Битрикс24: магазины. Теперь в любом портале можно создать не только лендинг или многостраничный сайт, но даже интернет-магазин. С корзино...
Каждый лишний элемент на сайте — это кнопка «Не купить», каждая непонятность или трудность, с которой сталкивается клиент — это крестик, закрывающий в браузере вкладку с вашим интернет-магазином.
Если у вас есть интернет-магазин и вы принимаете платежи через Интернет, то с 01 июля 2017 года у вас есть онлайн-касса.
Реализация ORM в ядре D7 — очередная интересная, перспективная, но как обычно плохо документированная разработка от 1с-Битрикс :) Призвана она абстрагировать разработчика от механики работы с табл...