Библиотека Интернет Индустрии I2R.ru

Снятие отпечатков пальцев

Традиционно, определение типа операционной системы производилось с помощью активных средств, таких как queso или nmap. Эти средства функционируют исходя из принципа, что IP-стек каждой системы имеет свои особенности. В частности, каждая операционная система по-своему реагирует на посылку неправильно сформированных пакетов. Оба средства имеют базы данных с информацией, как именно каждая ОС реагирует на эти пакеты. Таким образом, для определения типа операционной системы на удаленном хосте необходимо послать в его адрес специальным образом сформированные пакеты и сравнить полученный ответ с записями в базе данных. Широко распространенный сканер nmap (автор - Fyodor) использует именно такую методику. Fyodor также опубликовал подробную статью на эту тему.

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

Сигнатуры

Существует четыре области пакета, которые мы будем использовать для определения типа ОС (хотя есть и другие сигнатуры).

• TTL - значение Time To Live.
• Размер окна (Window Size).
• DF - бит Don't Fragment
• TOS - Type Of Service

Анализируя указанные характеристики пакета, Вы можете определить тип удаленной ОС. Это не 100% надежный способ, на одних ОС он работает лучше, на других хуже. Ни одна из этих характеристик в отдельности не определяет операционную систему. Однако, анализируя характеристики в комплексе, Вы повышаете точность определения. Лучше всего пояснить на примере. Ниже приведен листинг перехваченных пакетов. Эта система пыталась применить эксплоит против установленного у меня демона mountd, поэтому я захотел познакомиться с ней поближе. Я не стал использовать finger или nmap, которые сразу бы меня выдали. Напротив, я предпочел пассивно изучить входящую информацию. Приведенные ниже данные я получил при помощи snort - сниффера, которому я отдаю свое предпочтение.

04/20-21:41:48.129662 129.142.224.3:659 -> 172.16.1.107:604
TCP TTL:45 TOS:0x0 ID:56257
***F**A* Seq: 0x9DD90553   Ack: 0xE3C65D7   Win: 0x7D78

Анализируя наши 4 критерия, мы можем идентифицировать следующее:

• TTL: 45
• Window Size: 0x7D78 (или 32120 в десятичном виде)
• DF: бит Don't Fragment установлен
• TOS: 0x0

После этого сравниваем полученную информацию с базой данных сигнатур. Сначала ищем значение TTL, использованное удаленным хостом. Как мы видим в приведенных выше записях, это значение равно 45. Наиболее вероятно, что пакет прошел 19 переходов и начальное значение TTL было 64. Основываясь на этом, можно предположить, что пакет пришел от системы на базе Linux или FreeBSD, (однако, база нуждается в пополнении другими сигнатурами). Это значение TTL подтверждается проверкой маршрута до интересующего нас хоста при помощи traceroute. Если Вы беспокоитесь, что удаленный хост заметит Вашу попытку трассировки, Вы можете установить значение time-to-live (TTL, по умолчанию 30 переходов) на 1-2 перехода меньше расстояния до хоста (опция -m). Например, в данном случае мы можем осуществить трассировку хоста, установив максимальное число переходов равным 18 (traceroute -m 18). Вы получите полную информацию о маршруте до хоста, включая его вышестоящего провайдера, но, не "касаясь" при этом самого хоста. Для получения дополнительной информации о TTL ознакомьтесь с документом "Research Paper on Default TTL values".

Следующий шаг - сравнение значений Window Size. Я нахожу значение Window Size не менее эффективным средством идентификации системы. Как мы можем заметить в приведенном выше примере, значение этого параметра равно 0x7D78. Такое значение используется по умолчанию ОС Linux. Кроме Linux, такое же значение Window Size поддерживают в течение сессии FreeBSD и Solaris. Однако, маршрутизаторы Cisco (по крайней мере, используемая мной модель 2514) и Microsoft Windows/NT постоянно меняют значение Window Size. Я заметил, что наиболее точным является значение Window Size после начального трехшагового установления TCP-соединения. Для получения дополнительной информации о Window Size, см. Stevens, "TCP/IP Illustrated, Volume 1" Chapter 20.

Большинство систем устанавливает бит DF в пакете, поэтому применение этого значения для идентификации ограничено. Однако, это облегчает идентификацию небольшого числа систем, не устанавливающих этот бит, таких как SCO или OpenBSD. В процессе экспериментов я обнаружил, что поле TOS также мало пригодно для идентификации. Его значение больше зависит от типа сессии, чем от операционной системы. Иными словами значение TOS определяет не ОС, а используемый протокол. Применимость поля TOS для идентификации требует дополнительного изучения. Итак, основываясь на приведенной выше информации и сравнивая ее с базой данных сигнатур, с достаточной степенью уверенности можно определить ОС (в нашем случае это Linux с ядром 2.2.x).

Имейте в виду, что, так же как и активное, пассивное определение типа операционной системы имеет свои ограничения. Во-первых, приложения, формирующие пакеты на низком уровне (типа nmap, hunt, teardrop и т.п.), используют значения параметров, отличные от используемых операционной системой. Во-вторых, относительно несложно изменить значения TTL, Window Size, DF или TOS. Например, чтобы изменить значение TTL по умолчанию, необходимо произвести следующие действия:

в Solaris: ndd -set /dev/ip ip_def_ttl 'number'
в Linux: echo 'number' > /proc/sys/net/ipv4/ip_default_ttl
в NT: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Однако, комбинируя значения различных параметров, в данном примере - TTL и Window Size, Вы можете достаточно точно идентифицировать удаленную систему.

Другие сигнатуры и их применение

Мы не ограничены рамками четырех только что рассмотренных характеристик. Существуют и другие заслуживающие внимания показатели, такие как начальное значение sequence numbers, IP Identification numbers, опции TCP или IP. Например, маршрутизаторы Cisco устанавливают начальное значение IP Identification number в 0, вместо использования случайного числа. Можно также использовать заполнение пакетов ICMP. Использование этого параметра, а также опций TCP для идентификации удаленного хоста обсуждается Max Vision. Например, ICMP-запрос от систем Microsoft содержит в заполнении буквы, в то время как аналогичные пакеты от Solaris или Linux содержат цифры и символы. В опциях TCP значение Selective Acknowledgement SackOK обычно используется Windows и Linux, но как правило не используется FreeBSD или Solaris. Большинство операционных систем используют значение Maximum Segment Size (MSS) равное 1460, однако Novell обычно использует 1368, а некоторые варианты FreeBSD могут использовать MSS=512. Другие источники характерных признаков - тип и состояние используемого пакета. Как сказал Fyodor: "Например, запрос на установление соединения (SYN request) - просто золотое дно для меня (так как на него можно ответить). Пакеты RST также имеют много интересных возможностей, которые могут быть использованы для идентификации". Эти и другие характеристики могут быть объединены с характеристиками, перечисленными выше, чтобы помочь более точно идентифицировать удаленные операционные системы.

Пассивная идентификация может быть использована и для других целей. В частности, этой же методикой могут воспользоваться "плохие парни", чтобы идентифицировать жертву. Например, чтобы определить тип операционной системы "потенциальной жертвы", такой как web-сервер, необходимо всего лишь запросить с него страницу, а затем проанализировать полученные пакеты. Это избавляет от необходимости использовать активные средства, которые могут быть обнаружены системой обнаружения атак. Также, технология пассивной идентификации может быть использована для идентификации удаленных межсетевых экранов с proxy-сервером (proxy firewall). Так как эти устройства полностью перестраивают соединение для каждого клиента, вполне возможно их идентифицировать на базе характеристик, которые мы обсудили выше. Некоторые организации могут использовать пассивную идентификацию для определения "левых" (нестандартных) систем в своей сети. Это могут быть системы, появление которых в сети не разрешено. Например, сети на базе Microsoft или Sun могут легко вычислить затесавшиеся в них Linux или FreeBSD. Пассивная идентификация может быть применена для быстрой инвентаризации имеющихся в организации операционных систем без вмешательства в работу сети и нарушения ее производительности. При проведении оценки защищенности, данная технология позволит быстро идентифицировать критичные системы (типа Unisys Mainframe).

Формирование базы данных

База данных была сформирована опытным путем с использованием протоколов TELNET, FTP, HTTP и SSH. Необходимо произвести дополнительные опыты с использованием других протоколов, типов сессий и операционных систем. Если Вы располагаете характеристиками, которые можно включить в базу данных, пожалуйста, вышлите их по адресу project@honeynet.org. Особенно интересуют опции TCP или IP, а также системы, не отмеченные в базе.

Заключение

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

• Craig Smith
• Peter Grundl
• Subterrain Siphon Project