- Published on
- Updated on
Функции безопасности BGP еще работают?
- Authors
Эта публикация - перевод статьи. Ее автор - Ben Cox. Оригинал доступен по ссылке ниже:
Этот пост является текстовой версией доклада, который я сделал на NLNOG 2018, вы можете посмотреть его здесь, если вам так удобнее.
У BGP была проблема довольно долгое время, чаще всего, когда мы слышим об этом в новостях за пределами сетевого сообщества, это называется "BGP Hijack". Что можно лучше сформулировать как "кто-то направил чужие адреса к себе".
Это происходит потому, что BGP не был создан с идеей проверки прав собственности на блоки IP-адресов, поэтому программное обеспечение BGP не знает, является ли маршрут к некоторым IP-адресам легитимным или нет.
В настоящее время существует два предложения по устранению этой проблемы: BGPSec и RPKI, оба они так или иначе связаны с криптографией. Текущее состояние принятия означает, что BGPSec, хотя и определен, но в реальном мире является научной фантастикой. А вот альтернативная спецификация RPKI уже внедряется!
RPKI работает примерно так же, как и TLS. Существует набор корневых центров сертификации, а затем люди начинают подписывать, как должны объявляться их диапазоны IP-адресов и кем они должны быть объявлены.
В настоящее время развертывание подписей RPKI на IP-адресах идет довольно успешно:
Или если мы рассмотрим только регион RIPE:
Мы видим значительно более высокий уровень внедрения.
Однако это еще не вся история. Это здорово, если вы подписываете свои диапазоны IP-адресов (также известные как префиксы), но процесс RPKI предполагает, что сети также проверяют маршруты, которые они импортируют от своих коллег и поставщиков.
Проверка RPKI немного запутанна, для начала вам, скорее всего, потребуется запустить еще одно устройство в вашей сети, с которым общается ваш маршрутизатор, чтобы проверить, следует ли принимать префиксы или нет. Этому не способствует тот факт, что программное обеспечение для этого еще не полностью разработано и документировано, а маршрутизаторы, которые не обслуживались некоторое время, скорее всего, потребуют обновления (и для некоторых поставщиков такое обновление несет значительный риск хаоса).
Но давайте вспомним, что RPKI должен предотвращать
![простая сетевая настройка] (https://blog.benjojo.co.uk/asset/zcIaHgfFlc)
Это "стандартная" настройка, здесь у нас есть провайдер с одним транзитным аналогом в восходящем потоке и Internet eXchange. Здесь есть единственный путь к префиксу (проиллюстрировано книгой)
Проблема возникает, когда кто-то злой на IX объявляет префикс, потому что либо путь маршрутизации короче, либо маршрутизатор настроен так, чтобы быть предвзятым к IX (потому что это дешевле). Это плохо, потому что маршрутизатор только что последовал за угнанным префиксом, потому что он не знал ничего лучшего, у него не было способа узнать, что он был угнан!
![простой взлом сети с помощью RPKI] (https://blog.benjojo.co.uk/asset/mYqF3ik8di)
Именно здесь вступает в дело RPKI, поскольку префикс теперь заблокирован на нетмаску + номер AS, перехват через IX не будет подтвержден, и маршрутизатор предпочтет правильный маршрут плохому.
Наблюдательные читатели могут внезапно осознать дыру в этом дизайне, поскольку для обхода этой проблемы потребуется только написать путь на стороне атакующего, чтобы префикс угона сохранил оригинальный номер AS, и просто иметь ASN угонщика в качестве восходящего потока.
Это действительно работает, однако если маршрутизатор все еще работает по принципу "кратчайший путь BGP = лучший путь", это снижает вероятность того, что путь будет принят как лучший.
Давайте рассмотрим другую ситуацию:
Здесь мы имеем еще одну очень распространенную ситуацию, в этом случае у провайдера нет обменного соединения с интернетом, у него просто есть два провайдера в восходящем потоке.
Предположим, что атакующему удалось добиться того, чтобы его hijack достиг транзитных провайдеров, это довольно частое явление, так как все еще существует множество провайдеров, у которых либо плохие фильтры, либо вообще отсутствуют фильтры на то, какие префиксы их клиенты должны иметь возможность объявлять.
![мультихоумная сеть с RPKI] (https://blog.benjojo.co.uk/asset/DqXhuQx9J9)
При фильтрации RPKI, оба входящих BGP потока должны считаться недействительными для этого префикса, и маршрутизатору некуда направлять пакеты обратно. Хотя пакеты все еще могут поступать от этого перехватчика, почти все системы нуждаются в дуплексной связи для правильного функционирования (TCP является критическим)
Однако здесь возникает следующая проблема на практике, Во многих случаях провайдеры отправляют маршрут по умолчанию своим клиентам, это обеспечивает трафик маршрутом, даже если провайдер не объявил, что может направлять трафик туда. Иногда это может быть полезно и оправдано.
Потому что он обеспечивает "последний путь" для доставки пакетов в определенное место. Это означает, что такие перехваты все еще работают, потому что даже если маршрут перехвата отклонен, он все равно пойдет по маршруту по умолчанию, чтобы вернуться туда.
Исправить это должно быть просто, верно? Просто удалите маршрут по умолчанию или "черную дыру" трафика в случае, если нет действительного маршрута, чтобы добраться туда. А вот и следующее препятствие, которое нужно преодолеть.
![Развертывание RIPE RPKI с выделенным недействительным маршрутом] (https://blog.benjojo.co.uk/asset/d6hPh3H8oB)
С бизнес-причиной отказа от того, что может составлять 0,87% клиентского трафика, трудно поспорить. В идеальном мире эти 0,87% префиксов IP-адресов должны быть обречены в любом случае. Однако, учитывая, что развертывание RPKI только начинается, эти префиксы в большинстве своем все еще могут получить доступ к большей части Интернета.
Итак. Учитывая все это, как в настоящее время Интернет работает с развертыванием RPKI, кроме простого подтверждения подписи, учитывая, что для работы RPKI необходимо и подписать, и подтвердить.
Для этого нам потребуется разослать много пакетов...
Вооружившись префиксами, которые намеренно подписаны как недействительные, и одним действительным префиксом. Я разослал множество ICMP Pings на все IP-адреса, использующие "зеленый" контрольный префикс.
Если ответ приходит обратно, пинги посылаются на каждый из других недействительных "красных" префиксов, чтобы проверить, пришел ли ответ.
Таким образом, у нас остаются ведра хостов! Сопоставляя хосты внутри этих ведер, мы можем определить, выполняют ли их провайдеры проверку RPKI.
Если они появляются только в зеленом ведре, значит, они делают проверку RPKI правильно! Если они появляются в зеленой корзине и красной корзине ARIN, то они используют некоторый уровень проверки RPKI, однако пострадали от некоторых конфигураций по умолчанию в программном обеспечении (подробнее об этом чуть позже). Если они находятся во всех корзинах, то они вообще не проводят никакой проверки RPKI.
Однако давайте посмотрим на окончательные результаты:
Чем меньше число, тем больше правоприменительная практика. Как вы можете видеть, разница между ARIN и RIPE составляет 0,1 миллиона. Вероятно, это связано с настройками по умолчанию всех программ проверки RPKI. Так, ARIN TAL требует [вы должны загрузить его отдельно] (https://web.archive.org/web/20180909182108/https://www.arin.net/resources/rpki/tal.html) и вместе с ним [соглашение с ретранслирующей стороной] (https://web.archive.org/web/20180909182302/https://www.arin.net/resources/rpki/rpa.pdf), которое представляет собой 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 адресного пространства (128k IP-адресов).
Однако если отсортировать список по общему количеству активных хостов, а не по соответствию RPKI, картина выглядит гораздо более мрачной:
Первый 100% RPKI Invalid дроппер находится на 271 месте в этом списке.
Используя эти данные, мы также можем увидеть, что провайдеры, которые не загрузили ARIN TAL. Либо потому, что они не знали, что им это нужно, либо потому, что не могли согласиться с заключенным с ним соглашением.
![Смешанный лист] (https://blog.benjojo.co.uk/asset/4DZHUitP5j)
Это разочаровывает. Поскольку это означает, что ROA, подписывающие префиксы ARIN, будут менее безопасны, чем ROA, подписывающие другие, пока эти ограничения не будут отменены. Даже после этого это будет иметь долгосрочный эффект, поскольку обновления программного обеспечения требуют много времени для распространения в конечных сетях.
Одним из хороших мест для проверки RPKI могут стать DNS-резолверы. С этого года [кто-то взломал приличный кусок маршрута Amazons Route 53] (https://arstechnica.com/information-technology/2018/04/suspicious-event-hijacks-amazon-traffic-for-2-hours-steals-cryptocurrency/), чтобы украсть немного интернет (криптографических) денег. Это событие побудило Amazon начать подписывать некоторые из своих префиксов (однако они пока не блокируют недействительный трафик RPKI в своей сети, видите закономерность?).
Для проверки внедрения RPKI в DNS-резолверы я настроил DNS-серверы на IP-префиксы, которые использовались для сканирования на предмет проверки провайдера, и обнаружил, что ни один крупный сайт-резолвер не находится за сетью с проверкой 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% совместимая сеть.
Будущее мира префиксов с криптографической подписью еще далеко от реальности, но это, надеюсь, не должно останавливать нас от попыток.
Вы можете найти данные, полученные в результате этого поста+беседы, здесь:
Я хотел бы поблагодарить некоторые группы за помощь в этой работе,
- Job Snijders
- Nepal Research and Education Network (NREN)
- Японский центр сетевой информации / PPP-EXP
- NTT Communications
- LARUS Cloud Service Ltd.
Если вам понравилась эта статья, вы можете заглянуть в остальную часть блога, а чтобы быть в курсе моих новых публикаций, вы можете следить за мной в Twitter или использовать RSS