Привет! Я работаю старшим сетевым инженером в компании 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.
Проверка подлинности маршрутов на маршрутизаторах происходит одним из способов:
Проверка самим маршрутизатором по прямой RPKI-сессии.
Загрузка на маршрутизатор готовой базы данных с локального кэш-сервера RPKI.
Первый способ требует выполнения на маршрутизаторе сложных криптографических вычислений. Он не рекомендован к использованию из-за своей ресурсоемкости для маршрутизатора.
Второй способ не требует таких больших затрат. Локальный кэш-сервер RPKI загружает в себя базу ROA со всех установленных Trust Anchors по протоколу RSYNC или RRDP и поддерживает ее в актуальном состоянии. Локальный RPKI-сервер на основе своей базы данных ROA генерирует базу данных для маршрутизатора. Каждая запись базы содержит упрощенный вариант ROA, и эта база передается на маршрутизатор по протоколу RPKI-RTR. По умолчанию это TCP-порт 8282. По этим данным на маршрутизаторе настраиваются политики для маршрутизации полученных префиксов.
Как завалидировать свои префиксы
Допустим, вы – клиент сервис-провайдера. У вас есть своя AS с парой /24 блоков IP-адресов, вы пиритесь по eBGP со своим провайдером, full view от него не получаете, других пирингов у вас нет. Вам приходит письмо, что провайдер внедряет на своей стороне систему валидации префиксов на основе RPKI и просит завалидировать свои анонсы.
В этом случае вам нужно подписать ROA свои префиксы, чтобы в дальнейшем ваши ресурсы были доступны из сети Интернет.
Для регионального регистратора RIPE NCC шаги такие:
Зайдем на портал 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.
В RPKI Dashboard перейдем во вкладку BGP Announncements. В нижней части экрана в меню Show выберем All.
Вернемся в начало страницы и выберем все префиксы по чек-боксу рядом с надписью Origin AS. Создадим ROA по кнопке Create ROAs for selected BGP announcements.
Подождем, пока сформируется стейджинг ROA. Внизу появится кнопка:
Нажмем ее и во всплывающем меню нажмем Publish!
Все, готово! Вы успешно завалидировали свои префиксы!
Для счастливых обладателей PI-адресов RIPE подготовил отдельную инструкцию для валидации префиксов. А еще удобнее использовать Wizard от RIPE NCC: https://portal.ripe.net/rpki-enduser.
Сейчас все крупные компании внедряют проверку маршрутов на базе RPKI. Рано или поздно валидацию BGP нужно подключить всем, кто хочет, чтобы приложения и сайты были доступны, а проверки маршрутов – успешны.
Если же вы сами являетесь сервис-провайдером, то лучше внедрить свою валидацию и фильтрацию маршрутов на основе RPKI.
Но об этом поговорим в следующий раз, всем пока и до встречи!