Skip to main content

Функции безопасности BGP еще работают?

Этот пост является текстовой версией выступления, которое я дал на конференции NLNOG 2018. Вы можете посмотреть выступление ниже, если вы предпочитаете эту среду:

У BGP была проблема в течение довольно долгого времени, большую часть времени, когда мы слышали об этом в новостях за пределами сетевого слова, которое он называет «BGP Hijack». Который может быть лучше сформулирован как «кто-то направил чужие адреса к ним».

Причина этого заключается в том, что BGP не был построен с идеей проверки владения блоками IP-адресов, поэтому программное обеспечение BGP фактически не знает, является ли маршрут к некоторым IP-адресам законным или нет.

В настоящее время есть два предложения, чтобы исправить это, BGPSec и RPKI, оба они так или иначе связаны с криптографией. Текущее состояние усыновления означает, что BGPSec, будучи определенным, является научной фантастикой в ​​реальном мире. Альтернативная спецификация RPKI, тем не менее, видит развертывание!

RPKI работает примерно так же, как и TLS. Существует ряд корневых центров сертификации, и нижестоящие пользователи начинают подписывать, о чем должны быть объявлены их диапазоны IP-адресов, и кем они должны быть объявлены.

Говоря в настоящее время, развертывание подписей RPKI на IP-адресах становится довольно хорошим:

Глобальное развертывание RPKI

Или если мы посмотрим на один регион RIPE:

RIPE Region RPKI развертывание

Мы видим значительно более высокое принятие.

Однако это не вся история. Хорошо, если вы подписываете свои диапазоны IP-адресов (также известные как префиксы), но процесс RPKI включает в себя сети, которые также проверяют маршруты, которые они импортируют от своих коллег и поставщиков.

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

Но давайте вспомним, что, как предполагается, препятствует РПКИ

простая настройка сети

Это «стандартная» настройка, здесь у нас есть интернет-провайдер с одним транзитным одноранговым транзитным узлом и интернет-обмен. Здесь есть один путь к префиксу (иллюстрируется книгой)

простой сетевой взлом

Проблема возникает, когда кто-то злой на IX объявляет префикс, потому что либо путь маршрутизации короче, либо что маршрутизатор настроен на смещение IX (потому что это дешевле). Это плохо, потому что маршрутизатор только что следовал за угнанным префиксом, потому что он не знал лучше, у него не было никакого способа узнать, что он был угнан!

простой захват сети с помощью RPKI

Именно здесь приходит RPKI, поскольку префикс теперь привязан к номеру сетевой маски + AS, перехват над IX не будет подтвержден, и маршрутизатор предпочтет правильный маршрут, а не плохой.

Наблюдательные читатели могут внезапно обнаружить дыру в этом проекте, так как обход этого потребует только написания пути на стороне злоумышленников, чтобы префикс hijack сохранил исходный номер AS и просто использовал ASN угонщиков в качестве восходящего потока.

Это работает, однако, если маршрутизатор все еще работает на «кратчайшем пути BGP = лучший путь», это уменьшает вероятность того, что путь будет принят как лучший.

Давайте посмотрим на другую ситуацию:

многосетевая сеть

Здесь у нас есть другая очень распространенная настройка, в этом случае у провайдера нет подключения к интернет-обмену, у него просто есть два восходящих провайдера.

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

многосетевая сеть с RPKI

С фильтрацией RPKI оба входящих BGP-фида следует считать недействительными для этого префикса, и маршрутизатору некуда направлять пакеты обратно. Несмотря на то, что пакеты все еще могут поступать из этого перехвата, почти всем системам для правильной работы требуется дуплексная связь (критический протокол TCP)

многосетевая сеть с RPKI с маршрутом по умолчанию

Однако на практике возникает следующая проблема: во многих случаях провайдеры отправляют маршрут по умолчанию своим клиентам, это обеспечивает трафик маршрутом, даже если провайдер не объявил, что может направить трафик туда. Иногда это может быть полезно и действительно в случаях.

Потому что он предоставляет метод «последней канавы» для получения пакетов к месту. Это означает, что эти угоны все еще работают, потому что, хотя маршрут угона отклонен, он все равно будет использовать маршрут по умолчанию, чтобы вернуться туда.

Исправить это должно быть легко, верно? Просто удалите маршрут по умолчанию или трафик «черной дыры» в случае отсутствия действующего маршрута. Ну вот и наступает следующий контрольно-пропускной пункт для преодоления.

RIPE RPKI развертывание с подсвеченным инвалидом

Трудно поспорить с бизнес-обоснованием отказа от того, что может составлять 0,87% клиентского трафика. В идеальном мире эти 0,87% префиксов IP-адресов в любом случае должны быть обречены. Однако, учитывая, что развертывание RPKI только начинается, эти префиксы по большей части могут по-прежнему иметь доступ к большей части Интернета.

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

Для этого нам нужно отправить много пакетов ...

ICMP 9000

Вооруженные префиксами, которые специально подписаны как недействительные, и одним действительным префиксом. Я отправил много ICMP Ping на все IP-адреса, используя «зеленый» префикс управления.

Обжиг ICMP 9000

Если ответ возвращается, пинг отправляется на каждый из других недействительных «красных» префиксов, чтобы проверить, возвращается ли ответ

Ведра

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

Если они отображаются только в зеленом поле, значит, они правильно выполняют проверку RPKI! Если они отображаются в зеленой корзине и красной корзине ARIN, то они используют некоторый уровень проверки RPKI, однако пострадали от некоторых конфигураций по умолчанию в программном обеспечении (подробнее об этом чуть позже). Если они находятся во всех сегментах, то они вообще не выполняют никакой проверки RPKI.

Однако давайте посмотрим на окончательные результаты:

Результаты ковша

Чем меньше число, тем больше правоприменение. Как видите, разница между ARIN и RIPE составляет 0,1 миллиона. Это вероятно из-за настроек по умолчанию всего программного обеспечения проверки RPKI. Понимаете, ARIN TAL требует, чтобы вы загрузили его отдельно, и вместе с этим у него есть Соглашение о ретрансляционной стороне, которое составляет 3 страницы официального заявления, в котором содержатся некоторые тревожные заявления. Этот факт означает, что по умолчанию ARIN TAL (важная часть в проверке достоверности ARIN RPKI) по умолчанию не включена в программное обеспечение.

Имея это в виду, я могу представить вам ведущие номера AS в развертывании RPKI:

Зеленый лист

Или представлено красиво:

57598   | MD | ripencc  | SHA-AS, MD
15426   | NL | ripencc  | XENOSITE Amsterdam, NL
34968   | NL | ripencc  | IUNXI, NL
35470   | NL | ripencc  | XL-AS, NL
34762   | BE | ripencc  | COMBELL-AS, BE
28878   | NL | ripencc  | SIGNET-AS, NL
39647   | NL | ripencc  | REDHOSTING-AS, NL
8455    | NL | ripencc  | ATOM86-AS ATOM86, NL
21155   | NL | ripencc  | ASN-PROSERVE Amsterdam, NL
197902  | NL | ripencc  | HOSTNET, NL
24679   | DE | ripencc  | SSERV-AS, DE
20559   | NL | ripencc  | FUNDAMENTS-AS, NL
8608    | NL | ripencc  | QINIP Esprit Telecom B.V., NL
200831  | NL | ripencc  | MIHOSNET, NL
30870   | NL | ripencc  | TRANS-IX-AS Trans-iX, NL
29028   | NL | ripencc  | COMPUKOS-AS, NL
24586   | NL | ripencc  | NL-INTERMAX B.V., NL
34756   | NL | ripencc  | ASN-GVRH, NL
8312    | NL | ripencc  | ZYLON-AS, NL
202955  | NL | ripencc  | IAHOSTER, NL
201975  | NL | ripencc  | UNISCAPEB IT-Services & Hosting, NL
41480   | NL | ripencc  | SYSTEMEC-AS, NL
201290  | NL | ripencc  | BLACKGATE, NL
39637   | NL | ripencc  | NETLOGICS-AS, NL
8587    | NL | ripencc  | INFRACOM-AS, NL
50554   | NL | ripencc  | NCBV-BACKBONE, NL
61349   | NL | ripencc  | MAXITEL, NL
58075   | NL | ripencc  | X2COM, NL
59980   | NL | ripencc  | MIJNDOMEIN, NL
24730   | NL | ripencc  | ASN-NETHOLDING, NL
60820   | NL | ripencc  | WIFI4ALL-AS, NL
202916  | NL | ripencc  | IPS, NL
28747   | BE | ripencc  | EASYHOST-COLO-AS, BE
34215   | NL | ripencc  | ATINET, NL
42812   | NL | ripencc  | DT-IT, NL
48729   | NL | ripencc  | O4S-AS, NL
199456  | GB | ripencc  | VLDTECH-ASN, GB
60950   | NL | ripencc  | CLOUDNL-AS, NL
202016  | NL | ripencc  | DOMINOICT, NL
61429   | NL | ripencc  | AS-CASTOR, NL
35027   | NL | ripencc  | ASN-SEVENP, NL
21073   | NL | ripencc  | ZORANET-AS Amsterdam, NL
41153   | NL | ripencc  | GNTEL-AS, NL
49627   | NL | ripencc  | SPEAKUP, NL
61147   | NL | ripencc  | CALLHOSTED-AS Callhosted NL
42585   | NL | ripencc  | NETWORKING4ALL, NL
15703   | NL | ripencc  | TRUESERVER-AS TrueServer BV, NL
15879   | NL | ripencc  | KPN-INTERNEDSERVICES, NL
35260   | NL | ripencc  | IU-NET, NL
62353   | NL | ripencc  | ASN-DATAPLACE, NL
202947  | NL | ripencc  | Multi ICT B.V., Almere, NL
34141   | NL | ripencc  | IN2IP-AS, NL
41960   | NL | ripencc  | NEXTPERTISE Nextpertise, NL
20495   | NL | ripencc  | WEDARE wd6.NET B.V, NL
52144   | NL | ripencc  | NOTUBIZ, NL
42755   | NL | ripencc  | DATAFIBER, NL

Зоркий глаз заметит, что этот список на 91% голландский! С некоторыми лидерами Бельгии интернет-провайдер следующий на 3%

Все живые и защищенные хосты могут вмещаться примерно в / 15 адресного пространства (128 тыс. IP-адресов).

Однако, если вы отсортируете это по общему количеству активных хостов, а не по RPKI, изображение будет выглядеть более мрачным:

Красный лист

Первый 100% RPKI Invalid droppper появляется только в ранге # 271 в этом списке.

Используя данные, мы также видим, что провайдеры не загрузили ARIN TAL. Либо потому, что они не знали, что им нужно, либо не могли согласиться с соглашением, которое они имеют с ним.

Смешанный лист

Это неприятно смотреть. Поскольку это означает, что префиксы ARIN для подписи ROA будут менее безопасными, чем для других ROA, пока эти ограничения не будут отменены. Даже после этого он будет иметь длительный эффект, поскольку обновления программного обеспечения занимают много времени для распространения в конечных сетях.

Хорошее место для начала проверки RPKI - это DNS-распознаватели, так как в этом году кто-то похитил приличный кусок Amazons Route 53, чтобы украсть некоторые интернет-(криптографические) деньги. Это событие подтолкнуло Amazon начать подписывать некоторые из своих префиксов (однако они еще не блокируют недопустимый трафик RPKI в своей сети, видите шаблон?)

Чтобы протестировать использование RPKI в DNS-преобразователях, я настроил DNS-серверы на префиксы IP, которые использовались для сканирования на проверку ISP, и обнаружил, что за сетью, проверенной RPKI, нет основных узлов-преобразователей, которые включают: 1.1.1.1, 4.2.2.1, 8.8 .8.8, 9.9.9.9 и 80.80.80.80.

Я даже протестировал с использованием RIPE Atlas и обнаружил, что только у одного зонда был DNS-распознаватель, который блокировал недопустимые префиксы RPKI, и этот зонд находился в сети, указанной выше, как сеть, соответствующая 100%.

Будущее мира криптографических подписанных префиксов далеко от реальности, но мы надеемся, что это не остановит нас от попыток.


Вы можете найти данные, сгенерированные этим сообщением + поговорить здесь:

Я хотел бы поблагодарить некоторые группы за помощь в этом: