Я иду искать: геопозиционирование хоста по IP-адресу в глобальной сети Интернет на примере криптобиржи Binance

В статье рассмотрены методы геопозиционирования сетевых интерфейсов по IP-адресу на примере API-сервиса криптобиржи Binance. Геопозиционирование основано на дистанционно-временных моделях пересчета времени кругового обхода (RTT) в дистанцию и определения примерного местоположения сетевого интерфейса.

Современным электронным сервисам очень важно знать о географическом местоположении клиентов для «тонких» настроек своих маркетинговых процессов. Повсеместно используются разные техники геопозиционирования пользователей, основанные на привязке к базовым станциям мобильной связи и точкам доступа Wi-Fi. Однако существует целый ряд других задач, для решения которых необходимо знать геопозицию не самого пользователя, а сервера и его сетевого интерфейса. Такие сервисы, как MaxMind (безусловный отраслевой лидер), широко известны публике (можно также почитать здесь), но в целом в сети мало материала в открытом доступе, посвященного технологическим вопросам глобального геопозиционирования хоста по его IP-адресу. В этой статье мы расскажем о некоторых решениях в этой предметной области и поделимся результатами наших исследований.

За подробностями следуйте под кат.

Зачем знать геопозицию сервера?

Рассмотрим реальный случай: арбитражные алгоритмы биржевой торговли анализируют ситуации, когда на одной бирже цена товара уже изменилась, а на другой еще нет. Если вы поймали этот момент различия цен, то на одной бирже вы можете этот товар купить, а на другой продать в том же количестве. Таким образом, в вашем кармане отложатся деньги от такой спекуляции. Например, между площадками Binance и Bitfinex разница в котировках Bitcoin (BTC) иногда позволяет получить прибыль на арбитражных сделках. Наблюдения показывают, что такие условия в котировках BTC на указанных площадках складываются несколько раз в день и длятся примерно от одной до двадцати секунд. Биржевому боту крайне важно жить на сервере, ближайшем и равноудаленном от биржевых дата-центров для получения конкурентного преимущества по времени доступа к ним обоим. Знание геопозиции интерфейсов биржевых сервисов поможет выбрать оптимальный хостинг для бижевого бота.

Пентестерам (как и злоумышленникам) тоже нужно знать о географическом расположении банковских (и не только) сервисов для оценки возможности получения физического доступа к вычислительной инфраструктуре целевой организации. Напомним, что проникновение квалифицированного злоумышленника в ЦОД, где развернуты критичные корпоративные сервисы, может привести к необратимым последствиям. Нам известны случаи размещения конфиденциальных данных, что называется, где попало.

Перечисленные случаи – это только вершина айсберга в вопросах поиска географического расположения хостов в сети Интернет.

Как это делается

Информация о геопозиции хоста собирается из различных открытых источников, например из ресурсных записей DNS и результатов прямых измерений. Начало работ в этом направлении описано в статье, опубликованной в 2001 году. Основой измерительных технологий стал метод Constraint-based geolocation (CBG), заключающийся в измерении времени кругового обхода (RTT) при выполнении запроса echo-request ICMP от нескольких хостов с известной геопозицией (или landmarks в оригинале) к хосту с измеряемой геопозицией. При различных допущениях, таких как равенство по времени пути пакета в обе стороны и скорость распространения сигнала в волоконном волноводе как 2/3 от скорости света в вакууме, можно пересчитать половину времени RTT в дистанцию и тем самым ограничить географическую область достижения ICMP-пакета некоторой окружностью с landmark-хостом в центре. Выполняя подобные измерения из нескольких распределенных по миру landmark-точек, получается столько же ограниченных областей. Их пересечение указывает на примерную геопозицию искомого хоста с точностью примерно до 100 км. Сущность метода CBG можно представить так:

Определение геопозиции хоста по методу CBG

Допущения в дистанционно-временной модели классического CBG достаточно грубы, что побудило исследователей к ее усовершенствованию. В результате «тонкого» тюнинга исследователями вносились изменения в эту модель. Например, некоторые исследователи предложили отбраковывать часть измерений RTT, а другие – рассматривать landmark-хосты как области, а не как географические точки. Эволюция CBG определила развитие и других методов геопозиционирования хостов по IP-адресу: Shortest ping, Topology-based geolocation (TBG), Octant, Street-level geolocation (SLG). В некоторых случаях удается достичь точности геопозиционирования хоста до здания, где он размещен (обычно ЦОД). Чтобы не перегружать текст, не станем упоминать про стохастические методы геопозиционирования, основанные на анализе распределения величины RTT. Только сама классификация известных методов может быть темой отдельного исследования. Как можно заметить, в настоящее время область геопозиционирования хостов по IP-адресу по-прежнему остается в поле актуальных научных исследований.

Умело применяя результаты научных исследований в этой предметной области и располагая собственным множеством landmark-хостов по всему миру, компания MaxMind прочно обосновалась в качестве лидера на рынке геопозиционирования. Серверы компании постоянно сканируют IP-адресное пространство с разрешением до префикса шириной /24 (IPv4) и формируют базу данных его географического распределения. Сотрудничество с RIPE NCC еще больше укрепило позицию компании на рынке. К собственным средствам измерения адресного пространства добавилась сеть зондов системы Atlas – масштабной измерительной сети RIPE NCC, состоящей из более чем 10 000 географически распределенных хостов (по состоянию на начало 2020 года) с точной привязкой к местности. Итогом деятельности компании на сегодняшний день является полноценное соответствие адресного пространства интернет-географии планеты с высокой точностью.

А что у нас?

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

Тем не менее мы разработали и исследовали ряд дистанционно-временных моделей для геопозиционирования сетевых интерфейсов Рунета. Для их исследования нами были использованы 42 VPS-хоста в определенных дата-центрах на территории РФ, множество веб-ресурсов с известным географическим размещением, позволяющих в режиме онлайн выполнять запросы ICMP echo request, возможности глобальной измерительной сети RIPE.Atlas, а также ресурсные записи DNS. Целью исследований являлось определение точности геопозиционирования, достижимой при использовании предложенных нами линейных и статистических моделей. Точность получилась несколько выше, чем при использовании классического метода constraint-based и соизмерима с его известными модификациями.

Для исследования стохастических моделей мы использовали в качестве объекта несколько клиентских интерфейсов московской точки обмена трафиком MSK-IX. Выбору способствовала превосходная информационная поддержка оператора на своих информационных ресурсах (сервис looking glass, система ресурсных записей DNS, записи в регистратурах маршрутизации, полный список адресов ЦОД и др.). Исследования подтвердили возможность определения геопозиции клиентского интерфейса с точностью до здания ЦОД.

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

Геопозиция серверов криптобиржи Binance

Упомянутая вначале статьи криптобиржа Binance основана в 2017 году, а в 2019 году закрепила за собой статус ведущей торговой криптобиржи мира с долей рынка более 53 %. Трейдеров и хакеров вполне обоснованно беспокоит вопрос о месте расположения серверов биржи. Некоторые предполагают, что они размещены в Корее, а кто-то настаивает, что в Токио (не будем перегружать текст ссылками на многочисленные обсуждения этого вопроса в сети). Биржа умалчивает о месте размещения своих серверов по соображениям безопасности. Мы попробовали внести ясность в этот вопрос с помощью использования дистанционно-временных моделей. Сразу заметим, что мы не будем приводить точные результаты нашего исследования.

Шаг 1. Для автоматической торговли Binance предлагает API-службу на домене api.binance.com. Возьмем его за отправную точку анализа. Разрешение этого домена в DNS хостами в разных странах дает следующий результат:

Страна (национальный домен)	DNS-разрешение для домена api.binance.com
ZA (ЮАР)	143.204.17.150, 99.86.226.172, 143.204.57.198
IN (Индия)	13.227.140.169, 13.35.134.176, 13.32.35.177, 54.182.7.113, 13.33.169.165, 99.86.31.175
GB (Великобритания)	13.35.244.184, 13.33.51.166, 13.224.242.171, 143.204.197.178, 52.84.143.112
CN (Китай)	69.63.178.13, 31.13.81.17, 69.171.235.64, 13.226.125.168, 13.224.196.172, 74.86.151.162, 13.224.153.172
KR (Южная Корея)	54.192.70.140, 52.85.195.217, 99.86.177.172, 13.226.125.168, 13.225.20.170
JP (Япония)	13.35.100.178, 13.225.179.170, 13.33.11.37
US (США)	99.84.240.113, 216.137.45.112, 99.84.125.184, 13.249.117.184, 99.84.169.185, 52.85.83.113, 13.226.15.171, 13.224.213.171, 13.225.57.171

Очевидно, что для обеспечения доступа и защиты сервисов Binance используется CDN-облако (content distribution network). Это Amazon, как вы увидите далее. Разрешение домена в различные адреса CDN-шлюзов выполняется непосредственно Name-сервером Amazon посредством использования ресурсной записи типа CNAME d3h36i1mno13q3.cloudfront.net в публичной DNS. В таблице представлена только часть информации, DNS-разрешение выполнялось из 25 стран на всех континентах. Как можно видеть из результатов, все IP-адреса принадлежат адресному пространству AS16509 AMAZON 02. Все полученные IP-адреса имеют PTR-записи, в которых содержатся географические аббревиатуры точек доступа Amazon:

server-143-204-17-150.jnb50.r.cloudfront.net	Йоханнесбург, ЮАР
server-13-227-140-169.bom50.r.cloudfront.net	Бомбей, Индия
server-13-35-100-178.lax3.r.cloudfront.net	Где-то в Японии
server-99-84-240-113.ord50.r.cloudfront.net	Где-то в США

Полученное множество облачных IP-адресов соответствует зонам доступа службы Amazon AWS.

Серверы Binance логически могут быть размещены относительно CDN-облака двумя возможными вариантами: или они развернуты непосредственно на облачных вычислительных ресурсах (что маловероятно, принимая во внимание историю развития биржи), или в некотором собственном/арендованном дата-центре, доступ к вычислительным ресурсам которого проксирует Amazon. В последнем случае можно ожидать возможность доступа к API-сервису Binance посредством обращения к IP-адресу его настоящего сетевого интерфейса, который не засвечен в публичном DNS. Запрос к базам данных RIPE NCC в надежде найти собственное адресное пространство биржи не вернул объектов с вхождением строки «Binance» в описателях объектов маршрутизации – не повезло.

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

Выводы по шагу 1:

1. Доступ к серверу api.binance.com проксируется CDN Amazon.
2. Сетевой интерфейс API-сервиса является единственным, размещен вне адресного пространства CND, адрес этого интерфейса неизвестен.
3. Binance, вероятно, не владеет собственным адресным пространством, а заимствует его у хостинг-оператора.

Шаг 2. Попытаемся определить приблизительное географическое размещение интерфейса API-сервиса Binance. К сожалению, его реальный IP-адрес неизвестен. Это делает невозможным применение основанных на прямом измерении RTT методов геопозиционирования. Для этого случая используем метод облачного зондирования, разработанный нами. В чем его суть поясним далее.

Особенностью работы CDN является возможность обращения внешнего пользователя с HTTP(S)-запросом к любому облачному шлюзу в мире. Если измерить время выполнения API-запроса при обращении на конкретный CDN-шлюз и вычесть из него RTT выполнения запроса echo-request ICMP к адресу этого шлюза, то получим оценку времени RTT на участке от CDN-шлюза до сетевого интерфейса API-сервиса Binance:

Принцип облачного зондирования

Полученные таким образом значения времени требуют некоторой статистической обработки. Выполняя измерения для каждого CND-шлюза, выявим тот CND-шлюз, который ближе всего находится к истинному сетевому интерфейсу API-сервиса Binance. Метод облачного зондирования, по сути, близок к Shortest ping и имеет аналогичные ему погрешности при местоопределении.

Применение метода облачного зондирования позволило определить локацию искомого API-интерфейса с точностью до 400 км. Страна размещения дата-центра Binance и города-кандидаты определились. Криптобиржа Binance не зря скрывает геопозицию своего API-сервиса. Мы тоже считаем корректным умолчать об этом.

Шаг 3. Поиск адреса истинного интерфейса API-сервиса Binance

На этом этапе нам известно немного больше. Главная информация – географическая область, определенная на предыдущем шаге. Теперь нужно выделить область адресного пространства IP, обслуживающую известную территорию, в надежде, что ее анализ позволит определить истинный адрес интерфейса API-сервиса Binance. Диапазоны адресов IP для некоторой территории выделить довольно просто. Мы воспользовались базой геоданных MaxMind в формате CSV и выбрали из нее все подсети, позиционирование которых в полях Latitude, Longitude и Accuracy_radius пересекается с искомой геозоной. Кроме этого, полученное множество IP-адресов мы расширили до границ префиксов, реально анонсируемых в BGP. Данные BGP-анонсов мы получили с использованием RIPEstat Data API.

Напомним, что европейский регистратор верхнего уровня RIPE NCC организовал глобальный сбор данных протокола BGP в крупнейших мировых точках обмена трафиком (IX-Internet Exchange), которыми могут воспользоваться все желающие. Файлы с пакетами BGP появляются в свободном доступе с интервалом 5 минут. Благодаря этому у исследователей по всему миру есть возможность анализа инцидентов, связанных с нарушениями глобальной связности сети Интернет не только почти в реальном времени, но и в ретроспективе.

Полученная область адресного пространства IP, соответствующая искомой геозоне, получилась не очень большой: всего 1 130 496 адресов IPv4. Теперь необходимо выполнить следующие действия:

1. Запросить в DNS ресурсные записи типа PTR для каждого из адресов множества в надежде, что среди полученных доменных имен нам встретится что-нибудь с подстрокой «Binance». Такие домены нашлись, но среди них не было целевого сетевого интерфейса API-сервиса.
2. Выполнить Binance API-вызов Test connectivity GET /api/v3/ping (документация API Binance) для всех адресов из исследуемого множества. Разумеется, этот вызов теперь будет маршрутизироваться мимо CDN Amazon. Здесь нас ждал успех: искомый интерфейс вернул корректный ответ. IP-адрес интерфейса получен.

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

Шаг 4. Точное геопозиционирование API-сервиса Binance

Теперь осталось совсем немного: применить разработанные нами техники геопозиционирования, которые упоминаются в начале статьи. Для этого необходимо измерить RTT к искомому сетевому интерфейсу при разных условиях из разных точно известных локаций. Здесь нам немного не повезло. Исследуемый сетевой интерфейс, как оказалось, не отвечает на запрос ICMP echo-request. Стучаться можно только в HTTPS. Это сильно ограничило (до нуля) число хостов с точной локацией, которые могут что-то измерить таким способом. Поэтому пришлось исследовать другой ближайший интерфейс, замеченный в трассировках к искомому интерфейсу. Измерения показали географическую локацию с точностью около 50 км. Принимая во внимание дополнительные задержки от найденного интерфейса к API-сервису, следует считать, что интерфейс API-сервиса размещен в той же точке с точностью до 80 км.

Заключение

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

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

Список источников

1. Определение местоположения без GPS
2. Web-геосервисы
3. Связность Рунета
4. Дата-центры MSK-IX в Москве
5. Constraint-Based Geolocation of Internet Hosts, Bamba Gueye, Artur Ziviani, Mark Crovella, Serge Fdida
6. Revisiting Constraint Based Geo Location: Improving Accuracy through Removal of Outliers, Sameer Qazi and Muhammad Kadri
7. A landmark calibration-based IP geolocation approach, Jingning Chen, Fenlin Liu1, Xiangyang Luo, Fan Zhao and Guang Zhu1
8. Towards IP Geolocation Using Delay and Topology Measurements, Ethan Katz-Bassett, John P. John, Arvind Krishnamurthy, David Wetherall, Thomas Anderson, Yatin Chawathe
9. An investigation of geographic mapping techniques for internet hosts, V. Padmanabhan and L. Subramanian, in ACM SIGCOMM Computer Communication Review, vol. 31. ACM, 2001, pp. 173–185
10. RIPE NCC Atlas network
11. Review of Different IP Geolocation Methods and Concepts Jayaprabha Bendale, Prof. J. Ratanaraj Kumar G.S.Moze College of Engineering, Balewadi, Pune-45. University Of Pune, Pune, India
12. B. Wong, I. Stoyanov, E.G. Sirer, Octant: a comprehensive framework for the geolocation of Internet hosts, proceedings of USENIX NSDI conference, 2007, pp. 23–36
13. Y. Wang, D. Burgener, M. Flores, A. Kuzmanovic, C. Huang, Towards street-level client-independent IP geolocation, proceedings of the 8th USENIX conference on networked systems design and implementation, 2011, pp. 27–36
14. Detect Online Fraud and Locate Online Visitors
15. AWS docs
16. GeoIP2 City and Country CSV Databases
17. RIPEstat Data API
18. RIS Raw Data
19. binance-official-api-docs

Raccoon Security – специальная команда экспертов НТЦ «Вулкан» в области практической информационной безопасности, криптографии, схемотехники, обратной разработки и создания низкоуровневого программного обеспечения.