Русский
Русский
English
Статистика
Реклама

Bgp hijacking

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

10.12.2020 12:12:32 | Автор: admin

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

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

Подробнее..

Активное внедрение стандарта Интернета RPKI полезно ли?

26.12.2020 10:13:54 | Автор: admin

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

Текущий год, помимо известных всем событий и увеличенной нагрузки на сеть, отметился ещё одним немаловажным движением. В течение этого года происходило ускоренное внедрение названного протокола у большинства крупнейших интернет-провайдеров. Даже хэштег на эту тему запустили в твиттере.

Да, внедрение RPKI безусловно можно назвать достижением, но только для определённого круга заинтересованных организаций. Для российского телекома это может стать началом конца.

Суть здесь вот в чём. Внедряемый стандарт подписей рассылок интернет-адресов основывается на иерархической системе сертификатов. То есть это почти та же система, только с дополнениями в виде номеров сетей и анонсов ip-адресов. Данный стандарт предполагает, что ведущие держатели мировых сетевых мощностей будут доверять только анонсам сетевых маршрутов от их непосредственных исполнителей, т.е. тех, кто эти маршруты будет собственно осуществлять, либо их непосредственных начальников. Неформально если - теперь сложно будет ходить "налево".

Проблема вот в чем. Мы, получается, переходим к иерархической схеме управления, к древовидной. И сам протокол, и принципы, на которых он основан, суть древовидные структуры. А это идёт в разрез с философией Интернета, который создавался и, тьфу-тьфу, функционирует в распределённом режиме. Интернет -это структура произвольного графа (за исключением некоторых сервисов типа DNS, уже названной системы сертификатов PKI и той же раздачи адресов), без ориентированности на строгую иерархию, без единственной головы.

Голов у Интернета в этом смысле много - если считать ими точки концентрации трафика. Теперь давайте разберёмся, что же это за "головы" мирового Интернета. Это в первую очередь телеком операторы т.н. бэкбона интернета - самых скоростных и широкополосных каналов связи. (Их принято называть операторами Tier 1, т.е. первого высшего уровня. Эти операторы никому не платят за интернет, поскольку они и являются его основой. К ним подключаются средние операторы Tier 2 и т.д.).

Связность в европе и окрестностяхСвязность в европе и окрестностях

Также в группу голов можно смело заносить крупных поставщиков контента, типа Netflix, Amazon, Vkontakte и Google. А также их крупнейших посредников - точки обмена трафиком, или пиринг-центры, представляющие из себя ассоциации разных интернет- и контент-провайдеров разного уровня. Именно во многом благодаря их существованию Интернет более-менее распределён, а значит устойчив к сбоям и, что немаловажно, к монополиям.

Во многом за счёт последних скорости интернета выше, а цены ниже. Именно они вносят значительный вклад в представление Сети как графовой распределённой структуры, у которой нет основных 3-4 владельцев, в основном американских (хотя надо отдать должное, скандинавская Telia Sonera на первом месте сейчас). Так вот, внедряемый стандарт основан на иерархии подписей маршрутов, аналогично иерархии подписей сертификатов сайтов.

Основа протоколаОснова протокола

И выдача маршрутов (как мне сейчас представляется) соотносится с современным положением вещей примерно так же как сама нынешняя система сертификатов PKI соотносится с распределёнными системами типа блокчейна. Ну или другая аналогия, политическая - как однополярный мир соотносится с многополярным. Программистская аналогия - как централизованный и распределённый контроли версий ПО. Финансовая: как Бреттон-Вудская, ныне Ямайская, система (золотодолларовый стандарт) соотносится с золотым стандартом начала 20-го века.

Вернёмся к Интернету.

Дерево связей протокола RPKIДерево связей протокола RPKI

По принятому протоколу доверие маршрутам обеспечивается только согласно иерархическим лицензиям, выданным от основных их владельцев - крупнейших телекомов бэкбона Интернета. То бишь из тех "голов", что я перечислял, влияние перетекает только к первой немногочисленной группе "владельцев" интернета. А различные региональные игроки остаются в стороне. Существующие ассоциации (пиринговые центры) наподобие российских MSK-IX или DATAIX, пока что довольно влиятельные, потеряют возможность обмениваться трафиком, так как их участники не смогут обмениваться маршрутами, нарушая границы своих иерархий, то есть обмен налево будет затруднён. А это и был основной смысл существования этих точек обмена. В результате контроль над трафиком уйдёт к крупнейшим телекомам. Российские телекомы не глобальны и впадут в зависимость от западных. Точки обмена трафиком просто распадутся. Установится монополия (или если хотите олигополия) в сфере коммуникаций, маршруты будут прокидываться через головы, они станут длиннее, а значит связь будет во многих случаях медленнее. Ну и конечно вырастут цены. За большую цену вы получите худшую связь.

И ещё один аспект - в целом под предлогом защиты Интернета зарубят связность и распределённость (свойства графа интернета), количество интерконнектов, что не только скажется на качестве и скорости, но и уменьшит надёжность связи.


Я надеюсь, что на Хабре найдутся специалисты, которые могут развеять мои сомнения и опасения. Или объяснят, что, например преимуществ у новой технологии больше чем недостатков (если они есть).

Удачного всем дня!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru