Играем в морской бой по BGP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Морской бой

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

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

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

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

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

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

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

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

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

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

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

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

Автор: m1rko

Источник ^[11]