новый метод удаленной идентификации физических устройств (продолжение)

продолжение. начало в «Сетевых Решениях» №5 за 2005 г.

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

В 1998 году Паксон провел ряд исследований, направленных на исключение влияния расфазировки на результаты сетевых измерений. Один из использованных нами алгоритмов основан на результатах тех исследований. Чуть позже, Пазстор и Вейтч создали программные часы для PC с очень большой точностью и очень маленьким значением расфазировки. Фундаментальное различие между нашей работой и предыдущими исследованиями заключается в том, что предыдущие исследования задавались целью снизить эффекты от влияния расфазировки импульсов, в то время как мы используем их с пользой.
Анагостакис и другие использовали запросы ICMP timestamp для изучения задержек, вносимых очередями в маршрутизаторах. Как известно, MAC-адрес сетевой платы уникален и может в какой-то степени служить «отпечатком пальцев» устройства, если предположить, что атакующий может его увидеть и что владелец устройства не сменил MAC-адрес. Главным преимуществом нашего метода над использованием MAC-адресов является то, что его можно применить, находясь от обследуемого устройства за тысячи миль и сотни хопов. Для снятия «отпечатков» также подошли бы cookies, но, опять же, эта технология не столь надежна.

часы и расфазировка импульсов

При обсуждении часов и расфазировки импульсов мы будем пользоваться терминологией из спецификации NTP. Clock C предназначен для отображения времени, прошедшего с некоторого начального момента i [C]. Разрешение Clock C, r[C] — наименьшее значение, на которое может быть инкрементировано значение часов. Разрешение в 10 мс означает, что часы имеют величину кванта времени 10 мс, но из этого не следует, что они увеличивают свои показания каждые 10 мс. Частота Hz [C] Clock [C] — это величина обратная их разрешению, т.е., например, часы со значением кванта времени 10 мс рассчитаны на частоту 100 Гц. Для любого t>= i[C] R[C](t) определяет показания времени часов С в момент времени t, где t обозначает реальное время, как определено в международных стандартах. Смещение часов C, off[C] — это разница между показаниями С и реальным временем, например, off[C](t) = R[C](t) – t для всех t<= i[C].

Расфазировка импульсов часов s[C] — это первая производная от смещения относительно времени. Для простоты будем считать, что R[C] — функция, дифференцируемая по времени. Будем измерять расфазировку часов в микросекундах в сеунду (мс/с) или же, что тоже самое, в частях на миллион (parts per million – ppm). Позже будет показано, что значение расфазировки следует принять постоянным.
Физическое устройство может на практике иметь несколько, возможно независимых, часов. Для удаленной идентификации устройств используются несколько различных часов — часы, отвечающие за системное время устройства, и внутренние часы стека TCP/IP, которые обозначаются как TCP timestamps option clock или TSopt. Здесь мы не будем вдаваться в дебри железа и рассматривать, почему эти часы имеют расфазировку, так как наша цель – измерение ее значений.

cистемные часы

Для большинства пользователей компьютеров наиболее очевидными являются системные часы Csys, которые отсчитывают время, прошедшее с 00:00:00 UTC, 1 января 1970. Часы на профессионально администрируемых машинах синхронизируются с реальным временем по протоколу NTP или SNTP, на домашних же компьютерах зачастую не производится какой-либо синхронизации.

Такая ситуация возникла потому, что установки по умолчанию большинства операционных систем не предусматривают какой-либо синхронизации системных часов с точным временем, а если и предусматривают, то делают это не часто. Например, по умолчанию, Windows XP Professional синхронизирует системные часы с NTP-сервером Microsoft при загрузке и дополнительно раз в неделю. Red Hat Linux 9.0 по умолчанию не использует NTP, хотя и поддерживает такую возможность. Другие системы, как то Debian 3.0, Free BSD 5.2.1 и Open BSD 3.5, по крайней мере под выбранной конфигурацией «типичный пользователь» даже не предложили установить ntpd. Для таких, профессионально не обслуживаемых машин при наличии возможности узнать показания их системных часов в разные моменты времени, можно с легкостью получить информацию о расфазировке Csys.

часы TCP timestamps

RFC 1323 описывает опцию TCP timestamps в протоколе TCP. Поток TCP будет использовать опцию timestamps в случае, если на обоих стеках она поддерживается и инициатор потока включит опцию в инициализационный SYN-пакет. Все современные операционные системы, с которыми мы работали, поддерживают данную опцию. Правда, Windows XP и Windows 2000 являются исключениями в этом плане. Далее будет показано, как можно с помощью небольшой уловки заставить эти операционные системы включить данную опцию.

Наиболее важной частью опции TCP timestamps для физической идентификации устройств является то, что часть заголовка каждого TCP-пакета в потоке будет содержать 32-битное значение времени, сгенерированное создателем пакета. RFC четко не определяет значения, которые должно принимать время, но при этом оговаривает, что значение должно считываться с «виртуальных часов», которые «примерно пропорциональны реальному времени». Алгоритм PAWS из RFC 1323 оговаривает, что разрешение виртуальных часов может быть между 1 мс и 1с. Далее будем называть данные «виртуальные часы» часами опции TCP timestamps или Ctcp. Нет никакого требования к тому, чтобы часы TCP timestamps коррелировали с системными часами устройства. Более того, в большинстве операционных систем, таких как Windows XP, Linux и FreeBSD, данные часы могут быть независимы от NTP-коррекции системных часов. Часы TCP timestamps в системах RedHat 9.0, Debian 3.0, FreeBSD 5.2.1 имеют разрешение 10 мс; в OS X Panther и Open BSD 3.5 — 500 мс; в Windows 2000, XP и Pocket PC 2002 - 100 мс. Большинство систем сбрасывают эти часы на 0 во время перезагрузки. Для них i[Ctcp] — это время запуска. Если сторона, производящая идентификацию, сможет изучить значения часов TCP timestamps в различные моменты времени, ей не составит труда вычислить из этого значение расфазировки часов TCP timestamps устройства s[Ctcp].

использование опции TCP timestamps для идентификации

Пока предположим, что между физическими устройствами и IP-адресами существует однозначная взаимосвязь. Рассмотрим вопросы множества хостов за NAT несколько позже. В данном разделе же будем считать, что за NAT может располагаться только одно активное устройство.
Измеряющая сторона должна иметь возможность просматривать TCP-пакеты с включенной опцией timestamps от идентифицируемого устройства. Измеряющей стороной может быть, например, Интернет-провайдер или какой-либо перехватчик пакетов, вклиненный в сеть, по которой передаются пакеты. Мы применили наши методики к данным, полученным с бэкбона провайдера на линках OC-48. Измерителем также может являться любая система, с которой часто общается идентифицируемое устройство. В качестве примера, можно привести поисковые системы вроде Google, новостные веб-сайты и т.д. Если измеряющая сторона активна, то она может инициировать TCP-поток к устройству, если, конечно, оно доступно и имеет открытый порт. Если измеритель полупассивный или активный, то он может сделать просматриваемые им потоки неестественно большими по продолжительности, что даст ему возможность получить значения часов устройства на длительном отрезке времени.

уловка для измерения машин с Windows 2000

С помощью нижеописанного метода можно измерить расфазировку часов на машинах под управлением Windws 2000 и XP даже если они находятся за NAT или файрволлом. Но в случае с NAT из-за его природы, мы будем ограничены потоками, инициированными Windows-машинами. К несчастью, Windows 2000 и XP не включают в их инициализирующих SYN-пакетах опцию TCP timestamps, а RFC предписывает, что пакеты в середине последовательности не могут включать данную опцию. Учитывая это и предполагая, что обе стороны соответствуют требованиям RFC, пассивный измеряющий не сможет использовать данную опцию в потоках, инициированных Windows 2000 и XP.

Если сторона, производящая измерения полупассивна, то напрашивается следующая уловка. Для простоты представим, что идентифицируемое устройство само подключается к машине измерителю. После получения инициализирующего SYN-пакета от Windows-машины, измеритель ответит SYN/ACK, но при этом нарушит требования RFC 1323 и включит в ответе опцию TCP timestamps. После получения такого ответа, наши машины с Windows 2000 и Windows XP игнорировали тот факт, что они не включили опцию в инициализационном SYN-пакете и включали эту опцию во всех остальных пакетах последовательности. Следует отметить, что измеряющий не обязательно должен быть стороной, к которой подключается идентифицируемое устройство. Ему достаточно реализовать атаку «устройство в центре» и модифицировать пакеты таким образом, чтобы Windows-машина получала их с включенной опцией TCP timestamps. Если измеритель — это провайдер идентифицируемого устройства, то он может модифицировать исходящий от Windows-устройства инициализирующий пакет и включить в нем данную опцию. Тогда пакеты, которые пойдут от того, с кем соединялась Windows-машина, также будут с этой опцией, и она будет включать TCP timestamps в дальнейшую последовательность пакетов в потоках.

Эта методика была проверена на машинах с Windows XP, подключенных к локальной сети и точке доступа/NAT производства LinkSys, на Windows XP SP2 со встроенным файрволлом и Windows XP SP1 с файрволлом ZoneAlarm.

расчет расфазировки часов TCP timestamps

Предположим, что проводящему идентификацию стала доступна последовательность TCP-пакетов T от идентифицируемого устройства, и что все пакеты содержат включенную опцию TCP timestamps. Перед вычислением расфазировки часов сделаем также небольшое замечание. Пусть ti — время в секундах, при котором измеряющий наблюдал i-й пакет в последовательности T и, пусть Ti — временная метка, содержащаяся в i-м пакете. Определим xi = ti-t1; vi=Ti-T1; wi=vi/Hz; yi=wi-xi; Ot={(xi, yi): iО {1,…, |T|}}. Единица измерения wi — секунда; yi — наблюдаемое смещение i-го пакета, Ot — множество значений смещений для T. Ниже будет рассмотрено, как рассчитать Hz, если оно не известно. На рисунке 1 показаны множества значений смещения для двухчасового трафика двух устройств из бэкбона Интернет на линках ОС-48 2004-04-28 (по соображениям конфиденциальности IP-адреса опущены). Сдвиг часов на t1 и T1 для xi и vi не обязателен, но делает графики как более понятными.

Если предположить, что часы у производящего идентификацию точны, и что значения t отражают реальное время, и что между тем как идентифицируемый генерирует i-й пакет и тем как измеритель записывает его, то yi=off(xi+t1). Учитывая это, и также предположив, что R дифференцируема, тогда первая производная y, которая является склоном между точками Qt — расфазировка Ctcp.

Рассмотрим график, предстваленный на рисунке, более внимательно. Видно, что широкая полоса соответствует устройству, у которого часы TSopt имеют низкое разрешение (100 мс); узкая полоса соответствует устройству с большим разрешением (10 мс). Ширина этих полос означает, что если длина последовательности, которой мы располагаем, невелика, то мы не сможем аппроксимировать склон между точками Qt путем вычисления переходов между любыми двумя точками множества. Более того, как отмечают Паксон и другие, переменные сетевые задержки делают простую линейную регрессию недостаточной. Для того чтобы подсчитать расфазировку s из Qt, мы применили метод линейного программирования Муна, Скелли и Тоусли, который реализует алгоритм выпуклой оболочки для отсортированной информации.

Метод линейного программирования выводит выражение линии ax+b, которая граничит с множеством точек Qt. Мы используем верхнюю границу по той причине, что задержки в сети и на хостах имеют положительные значения. Склон линии a — это вычисленная расфазировка Ctcp. Для данной линии для всех iО {1,…, |T|}, a*xi +b≥ yi., что означает что решение должно граничить сверху со всеми точками Qt. Затем с помощью линейного программирования минимизируем среднее расстояние по вертикали от всех точек Qt до линии, т.е. минимизируем целевую функцию.

(1/|T|)*е(a*xi+b-yi) (i=1…|T|).

Следует отдельно рассмотреть случай, когда неизвестно Hz. Одно из решений подразумевает подсчет наклона между точками I={(xi,vi): iО {1,…,|T|} и округление до ближайшего целого.
Еще один вариант: если А — склон между точками в множестве I, можно вычислить расфазировку Ctcp как A/Hz-1.

использование запросов ICMP timestamp

Для того, чтобы узнать расфазирвку часов устройства, измеритель может быть, например, веб-сайтом, с которым общается устройство или еще чем-либо, что имеет возможность отослать идентифицируемому устройству запрос ICMP timestamp (сообщение ICMP тип 13). Измеряющий также должен иметь возможность записывать ответы на данные запросы от исследуемого устройства (сообщения ICMP тип 14). Самое главное условие для реализации данного метода — идентифицируемое устройство не должно находиться за NAT или файрволлом, блокирующим ICMP.

Предположим, что измеряющей стороне стала доступна последовательность пакетов T с ответами ICMP timestamp от идентифицируемого устройства. Сообщения с ответами ICMP будут содержать два 32-битных значения, сгенерированных устройством. Первое значение — это время, при котором соответствующий пакет был получен; второе значение — время, при котором ответ ICMP timestamp был сгенерирован. В данном случае время соответствует системным часам идентифицируемого устройства Csys и содержит количество миллисекунд, прошедших с полночи UTC.

Windows-машины выдают слепок времени в формате прямой последовательности байт, в то время как остальные протестированные нами машины — в обратном. Теперь можно воспользоваться методом, который мы использовали чуть выше, и рассчитать значение расфазировки. Стоит также отметить, что в данном случае нам не придется высчитывать Hz, так как согласно RFC 792 Hz должно быть равно 1000 (или же, если нет, должен быть установлен специальный бит, указывающий на несовместимость). Также не следует забывать о том, что значения времени будут отсчитываться от полночи, так что они будут сбрасываться раз в сутки, поэтому следует делать поправку на это.

краткое сравнение с TCP timestamps

В дальнейшей части работы упор делается на использование TCP timestamps. Это не связано с тем, что подход ICMP ущербный. Выбор был сделан в пользу TCP по той причине, что в большинстве систем часы TCP timestamps работают на более низкой частоте, чем 1000 Гц в ICMP.

Несмотря на все плюсы использовния ICMP, TCP-методика позволяет осуществлять идентификацию машин за NAT или файрволлами. Также следует отметить, что если машина не слишком часто синхронизирует свои системные часы по NTP, то показания часов TCP timestamps сильно коррелируют с ними, что означает, что распределение расфазировки для них будут одинаковыми.

распределение и стабильность измерений расфазировки часов TCP timestamps

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

распределение значений расфазировки — анализ пассивных последовательностей

Ниже будет описан опыт, целью которого было понять и проанализировать распределение расфазировки часов на множестве различных устройств, применяя пассивную методику. В ходе эксперимента мы проанализировали последовательность пакетов трафика на линке ОС-48, собранную за час вечернего (с 19:30 до 20:30) времени.

Результаты показали, что в обычной ситуации из значения расфазировки часов можно узнать как минимум 6 бит информации об устройстве. Если же заставить его посылать пакеты более часто, и проследить за ним в течение большего периода времени, можно получить еще больше бит.

распределение значений расфазировки часов

Нас заинтересовал вопрос: от чего зависит расфазировка часов — от операционных систем или от аппаратуры? Если использовать аналогичные машины, то логично было бы предположить, что значения расфазировки часов будут примерно одинаковыми. Для проверки этой гипотезы на практике мы провели эксперимент с 69 идентичными машинами. Все они были следующей конфигурации: Pentium2 448, Windows XP pro SP1. Измерения проводились с машины на Pentium 2 под управлением Debian 3.0. Результаты показали, что все машины имели разные, индивидуальные значения расфазировки часов.

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

влияние операционных систем, NTP и т.д.

Нами были проведены измерения для компьютеров под управлением Windows XP и Red Hat Linux 9.0 с и без NTP. Результаты показали, что под обеими ОС без NTP значения расфазировки системных часов и часов TCP timestamps не зависят от ОС. В то же время в зависимости от ОС значения расфазировки часов TCP timestamps могли как совпадать с системными, так и отличаться. Если используется синхронизация NTP, то расфазировка часов TCP timestamps все равно не поменяется.

влияние типа питания ноутбуков

На лэптопе под управлением Red Hat 9.0 при переключении с питания от сети на батарею было замечено небольшое скачкообразное смещение показаний часов TCP timestamps, после чего значение расфазировки осталось тем же. На лэптопе под управлением Windows XP sp2, если он свободен от пользовательского ввода, но продолжает обслуживать поток TCP, расфазировка изменилась при переключении на питание от батареи. После того как мы повторили тот эксперимент несколько раз, загружаясь при питании от батарей, стало ясно, что значения расфазировки идентичны для всех случаев. После подключения питания от сети, расфазировка часов на лэптопе с Windows XP сначала имеет большой «всплеск», после чего приходит в норму.

возможные применения

1. Виртуальные сети-ловушки honey-nets.
Для проведения эксперимента, нами была создана виртуальная сеть honeynet, состоящая из 100 виртуальных хостов Linux 2.4.18 и 100 хостов Windows XP SP1.Сервере имел 1 гигабайт памяти и обслуживал часы по NTP.

На данной конфигурации были опробованы методики TCP timestamps и ICMP применительно ко всем 200 хостам.
В ходе эксперимента мы выработали несколько приемов, позволяющих отличать реальные машины от виртуальных хостов. Первое что бросается в глаза, это то, что в отличие от реальных хостов, виртуальные всегда возвращали нулевые значения времени в ICMP. Также было отмечено, что виртуальные машины Windows XP имели Hz[Ctcp]=2, в то время как все реальные машины Windows XP имели Hz[Ctcp]=10.
На этом примере видно, что honeyd не полностью имитирует все аспекты стеков TCP/IP операционных систем.

Даже если бы он имитировал особенности ОС более тщательно, все равно, с помощью методики удаленной идентификации физических устройств можно легко отличить реальные машины от виртуальных. После применения методики были получены следующие данные: расфазировка часов TCP timestamps для всех 200 виртуальных хостов была примерно равна 0; расфазировка системных часов для всех хостов имела примерно одно и тоже положительное значение.

Для того, чтобы поэкспериментировать с реальными технологиями виртуализации, мы использовали Vmware Workstation 4.5.2, с установленными в ней 5-ю копиями Red Hat 9.0. Реальная машина также работала под управлением Red Hat 9.0. Результаты подсчета расфазировки часов показали, что пять виртуальных машин не имели постоянных (или примерно постоянных) расфазировок. Кроме того, значение расфазировки для этих машин было большим, чем мы ожидали.

2. Подсчет количества устройств за NAT.
Еще одно возможное применение нашей методики — подсчет количества устройств, находящихся за NAT. Следует отметить, что и раньше в данной области проводились исследования. Например, Белловин показал, что атакующий может использовать поле IP ID для подсчета устройств за NAT, но его подход имеет три ограничения:
1) поле IP ID имеет длину всего 16 бит;
2) современные операционные системы использую постоянное или переменное значение IP ID;
3) данный метод не позволяет узнать точное количество устройств за NAT, если они не активны одновременно.

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

3. Отслеживание устройств.
Так как физические устройства имеют постоянные во времени значения расфазировки часов и тип доступа, сетевая топология и т.д. никак не влияют на получаемые значения расфазировки, можно использовать нашу методику для отслеживания физических устройств. Например, одно из возможных применений — определение, было ли какое-либо физическое устройство использовано при каком-либо событии. Конечно, она не предоставляет серийных номеров устройств, но в совокупности с другими признаками позволяет достаточно точно отслеживать устройства в Интернете.



Тадаеши Кохно, Анре Броидо, Кэй Си Клаффи, перевод Дмитрия Герусса.