Главная » Хабрахабр » [Перевод] Играем в морской бой по BGP

[Перевод] Играем в морской бой по BGP

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

Вот почему мы повсюду слышим о взломах BGP разной степени серьёзности: от смены маршрутизации всего YouTube до сервиса AWS Route 53. У BGP плохая репутация главным образом из-за доверительного характера связей между пирами по дефолту и трудной задачи проверки легитимности маршрутов.

Начнём с одинокого маршрутизатора: Но чтобы понять природу этих взломов, следует понять топологию интернета.

От одного маршрутизатора мало пользы, если он не может ничего маршрутизировать. Поэтому подключим к нему другой маршрутизатор на физическом уровне (это может быть что угодно: от медного Ethernet и подводного оптоволокна до линков 802.11 Wi-Fi).

В конце концов, смысл маршрутизаторов — это направление трафика из одного пункта назначения в другой. Затем два подключённых маршрутизатора (в нашем случае красный и синий) должны понять, что могут маршрутизировать трафик друг для друга.

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

Чем больше рутеров мы подключаем, тем более сложную топологию маршрутизации мы формируем. Но не очень полезно, если они разговаривают только друг с другом, вдруг красный и синий маршрутизаторы не связаны напрямую? Это возможно, потому что каждый узел BGP делится таблицами маршрутизации с другими узлами, к которым он подключён:

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

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

Он определён в RFC1997 (к сожалению, написанного в 1996 году, немного промахнулись). У BGP есть способ кодирования информации с помощью маршрута, называемого community. На практике это значение разбивается на два 16-битных числа (один для ASN и один для сигнала, связанного с/для этого ASN): Community можно присоединить к объявлению маршрута и оно состоит из 32-битного числа.

Они используются, чтобы передавать дополнительную информацию о маршруте, например, где провайдер взял этот маршрут:

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

О чём ещё можно сигнализировать через community? Это заставило меня задуматься. И как далеко можно зайти?

Это также означает, что один маршрутизатор может отправлять информацию другим, даже не имея прямой связи. После некоторого тестирования выяснилось, что каждая сеть Tier-1 стирает community, кроме бывшей Level 3, которая позволяет передачу community от маршрутизатора источника до клиента.

Зная о наличии непрямого канала связи по BGP, я хотел как-то использовать это для установления каких-нибудь нетрадиционных коммуникаций. Я выбрал в качестве среды «морской бой», поскольку для этой игры требуется передача минимального количества информации (координаты X и Y, а также информация о последнем выстреле: попал или промазал).

Два игры по BGP были созданы два community.

Вся игра вмещается в два 16-битных числа, позволяющих надёжно играть через два community.

Он подключен к BGP в Нью-Йорке, а моя установка работает в Лондоне. Поскольку морской бой — игра для двоих, я пригласил поиграть AS203729.

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

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

С такими настройками 16 мая 2018 года я AS206924 и AS203729 сыграли, вероятно, первую настольную игру в истории, которая проводилась чисто по BGP.

Это произошло на моей стороне и заставило Level 3 применять менее оптимальный маршрут для моего трафика в течение 45 минут. Игра прошла гладко, за исключением 45-минутной паузы из-за вышеупомянутого демпфирования. Чтобы не допустить повторения ситуации, мы решили перейти на 90-секундный период между ходами.

Что делает меня первым победителем настольной игры, проведённой по публичному протоколу интернет-маршрутизации. Несмотря на это, последний удар по флоту моего друга AS203729 был нанесен на 68-м ходу.

Наверное, нет. Было это логично? Черт возьми, да. Было ли это весело?

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

До следующего раза!


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Как Яндекс применил компьютерное зрение для повышения качества видеотрансляций. Технология DeepHD

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

Security Week 36: Telnet должен быть закрыт

Telnet — это очень старый протокол. Википедия сообщает, что он был разработан в 1969 году, много лет активно использовался для удаленного доступа к компьютерам и серверам, причем как под управлением Unix/Linux, так и для систем под Windows (telnet можно было ...