Алгоритмы анализа удаленной системы

Вступление

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

Общая информация

Вообще, fingerprinting — это сбор информации об удаленной системе.
Используя ряд инструментов и алгоритмов, мы можем определить операционную
систему, серверные приложения (и их версии), тип аппаратного обеспечения и
другую, зачастую гораздо более важную, информацию. Традиционно системы сбора
информации делятся на активные (active fingerprinting) и пассивные (passive
fingerprinting). Первые используют различия откликов разных типов систем на
определенные ключевые воздействия. Располагая информацией об этих различиях,
исследователь может по типу отклика идентифицировать тип системы. Вторые
используют информацию, так сказать, «добровольно» рассылаемую исследоваемой
системой, хотя и, вполне возможно, предназначенную не исследующей системе.

Active fingerprinting

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

Одной из старейших техник этого рода является «коллекционирование
баннеров». Она заключается в анализе приветствий, выдаваемых стандартными
сервисами (ftp, pop3, finger, smtp, telnet). Сюда же относится информация из
строк параметров, возвращяемых в ответ на любой http запрос. Такие баннеры,
зачастую, содержат в себе информацию об используемом демоне, вплоть до номера
версии. Поскольку далеко не все демоны являются абсолютно портируемыми, то
это, вдобавок, дает нам возможность делать предположения об используемой
операционной системе. Есть две опасности, подстерегающие нас на этом пути. Во-
первых, многие демоны позволяют администратору произвольным образом
редактировать свои приветствия, то есть существует вероятность (хотя и
довольно малая), что демон совсем не тот, за которого он себя выдает.
Во-вторых, есть риск, что вообще вся операционная система работает под
какой-нибудь средой эмуляции (например VMWare). Это может спутать нам карты,
например, когда мы собираемся использовать особенности реализации TCP стека,
основываясь на сделанных предположениях.

Особенности функционирования указанных сервисов также позволяют получить
некоторую дополнительную информацию, используя возможности _протоколов_.
Типичным примером может служить команда SYST протокола ftp.

Рассмотрим поподробнее указанные сервисы.

FTP
—

Порт командного соединения — 21. Рассмотрим типичный баннер:

220
megillah.demos.su FTP server (Version wu-2.4(37) Mon Feb 15 16:48:38 MSK 1999)
ready.

Он предоставляет информацию о ПО FTP сервера вплоть до версии. Теперь, в
предположении, что сервис предоставляет услуги анонимному пользователю,
произведем авторизацию и воспользуемся командой SYST. (некоторые демоны
позволяют использовать команду SYST, не проходя авторизацию)

В зависимости от демона, нам будет предоставлена более или менее подробная
информация об операционной системе. Например:

user ftp

331 Guest login ok, send your complete e-mail address as password.

pass aaa@usa.net

230 Guest login ok, access restrictions apply.

syst

215 UNIX Type: L8 Version: BSD-199506

Дополнительный интерес может представлять, такая, скажем, специфическая
информация, как дата создания каталога bin или etc. Обычно она совпадает с
датой установки ftp сервиса. Получить ее можно, используя команду ls -la.

230 Guest login ok, access restrictions apply.

ftp> quote syst

215 UNIX Type: L8 Version: BSD-199506

ftp> dir .

200 PORT command successful.

150 Opening ASCII mode data connection for /bin/ls.

total 732

...

d--x--x--x  2 root  root    512 Jan 18 17:30 bin

d--x--x--x  2 root  root    512 Jan 18 17:31 etc

...

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

Telnet
------
Порт по умолчанию - 23. Несколько
типичных примеров:

>telnet *.*.*.33

FreeBSD/i386 (*.*.ru) (ttyp0)
login:
>telnet *.*.*.65

User Access Verification
Password:
>telnet *.*.*.28

Welcome to SuSE Linux 6.4 (i386) - Kernel 2.4.2 (0).
login:
>telnet *.*.*.178

Red Hat Linux release 6.0

Kernel 2.2.5-15 on an i686

login:
>telnet *.*.*.19

Welocome to NOOS IP Server
Processing mail only - disconnect please

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

SMTP/POP3
---------
Порты - 25/110. Примеры:

>telnet *.*.*.2 25
220 *.*.*.ru ESMTP Sendmail 8.11.2/8.11.2; Thu, 21 Jun 2001 18:34:19 +0400
...

>telnet *.*.*.178 25
220 *.*.*.ru ESMTP Sendmail 8.9.3/8.8.7; Thu, 21 Jun 2001 18:44:38 +0400
...

Помимо обычной процедуры анализа баннеров, протокол SMTP содержит команды,
позволяющие определить наличие на машине учетной записи пользователя с
заданным позывным. Это команды VRFY, EXPN. Заметим, что при настройке
безопасности почтового сервера их часто отключают. По спецификации команда
VRFY предназначена для проверки существования пользователя. Команда EXPN
предназначена для получения расширенной информации о пользователе (в том
числе, его реальной фамилии и имени) и почтовых группах. Наконец, команда MAIL
TO: служит для указания адресата при отправлении почты и, довольно часто, сама
осуществляет проверку существования пользователя (в случае локального
адресата). Рассмотрим типичный сценарий:

vrfy alex

550 alex... User unknown

vrfy root

250 root 

expn alex

550 alex... User unknown

expn root

250 root 

rcpt to:alex

503 5.0.0 Need MAIL before RCPT

mail from:dull@turn.ru

250 2.1.0 dull@turn.ru... Sender ok

rcpt to:alex

550 5.1.1 alex... User unknown

rcpt to:root

250 2.1.5 root... Recipient ok

В более безопасных системах подобные проверки существования заменяются на
проверки синтаксической корректности или вообще отключаются. Еще более
интересной является техника mail-bouncing-а. Она слабо распространена из-за
достаточно большой сложности и малой скорости работы. Смысл техники
заключается в анализе заголовков электроных писем, специально составленных и
посланных в исследуемую сеть. Так, интерес представляют письма для
несуществующих пользователей, поскольку они возвращают уведомления о
невозможности доставки (не всегда). В этих уведомлениях содержится некоторая
информация о почтовых серверах, участвующих в процессе доставки письма. На
основе нескольких таких "бумерангов" можно узнать некоторое число хостов
внутренней сети (не имея к ней непосредственного доступа) и топологию почтовых
пересылок. Кроме того, почтовый протокол позволяет отправлять письма с явным
указанием нескольких промежуточных пунктов пересылки. Это дает возможность
создать письмо, которое, проделав заданный маршрут внутри исследуемой сети,
вернется к отправителю (все это, конечно, существенно зависит от настроек
почтовых серверов).

РОР3 позвоволяет определить тип демона (по баннеру), и, следовательно,
зачастую и операционную систему. Он также может использоваться для подбора
паролей пользователей. Кроме того, некоторые реализации страдают тем, что, в
случае неверного имени пользователя они выдают сообщение об ошибке сразу после
ввода пароля, тогда как в случае, если пользователь существует, но пароль
неверен, система делает ощутимую паузу перед выдачей сообщения об ошибке (это
сделано для замедления подбора паролей). В этом случае также появляется
возможность определения существующих в системе пользователей.

FINGER
------
Порт по умолчанию - 79.

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

>telnet *.*.*.253 79
18:58
Line User Host(s) Idle Location
2 tty 2 SHAYAKH Async interface 00:00:00 ROTARY
3 tty 3 Ruslan_GalAsync interface 00:00:00 ROTARY
4 tty 4 zgk Async interface 00:00:58 ROTARY
5 tty 5 dinnre Async interface 00:07:01 ROTARY
6 tty 6 UPAP_4 Async interface 00:01:00 ROTARY
7 tty 7 murguverciAsync interface 00:01:34 ROTARY
9 tty 9 shinov99 Async interface 00:00:30 ROTARY
10 tty 10 novose19 Async interface 00:00:00 ROTARY
12 tty 12 test_k Async interface 00:00:02 ROTARY instead int 8
13 tty 13 Async interface 00:00:02 TO MOTOROLA 6520 instead int 11
* 18 vty 0 idle 00:00:00 *.*.*.*

Connection to host lost.

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

>telnet *.*.*.1 79
root
Login: root Name: Petr D. Belkin
Directory: /root Shell: /bin/bash
Last login Sat Nov 25 22:42 2000 (SAMT) on tty1
New mail received Sun Jun 10 16:20 2001 (SAMST)
Unread since Wed Feb 7 12:28 2001 (SAMT)
No Plan.

Connection to host lost.

Как видно из рассмотренного примера, предоставляется информация о реальном
имени, фамилии, дате последнего подключения, дате последнего чтения почты и
так далее. Кроме того, различные реализации поддерживают разные типы
wildcard-ов. Т.е. иногда возможно получить информацию на пользователя, не зная
точно его идентификатора, и/или получить список пользователей системы.

HTTP
----
Стандартный порт - 80.

Данный сервис обеспечивает функционирование World Wide Web, отвечая за
пересылку документов по запросу. Около двух третей всех веб-серверов сегодня
функционируют на програмном обеспечении от Apache (причем Unix-версия
распространена значительно сильнее). Практически все остальные веб-сервера
работают на IIS 4 или IIS 5 (под WinNT и Win2K). Протокол HTTP версии 1.1,
описанный в RFC 2068, предусматривает метод OPTIONS, по которому веб-сервер
возвращает развернутую информацию о себе. Например:

OPTIONS * HTTP1.1

HTTP/1.1 200 OK
Date Wed 20 Jun 2001 17:41:42 GMT
Server: Apache/1.3.19 (Unix) PHP/4.0.5 mod_jk rus/PL30.4
Content-Length: 0
Allow: GET, HEAD, OPTIONS, TRACE
Conection: close

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

SMB
(NetBIOS)
-------------

Само по себе, наличие данного сервиса говорит о многом, так как в
подавляющем большинстве случаев оно свидетельствует о том, что операционная
система принадлежит семейству Windows (исключение составляют Unix системы с
установленным сервисом SAMBA). Используя уязвимость настроек по умолчанию,
исследователь удаленной системы может получить список разделяемых ресурсов, а
в случае WinNT/2K и список пользователей с подробной информацией о каждом, и,
зачастую, удаленный доступ к реестру. В описание пользователя в том числе
входят его login name, полное имя, принадлежность к группам, дата последней
смены пароля. Также, может быть получена другая информация, касающаяся
настроек домена. Сегодня существует уже много утилит, позволяющих получить
такую информацию. Наиболее древняя из них - ntis by David Litchfield нашла
свое развитие в программе cis, а самой, на мой взгляд, популярной на
сегодняшний день является система winfingerprint
(http://www.technotronic.com/winfingerprint/).

Рассмотрим однако, что можно сделать, обходясь лишь стандартным
инструментарием WinNT/2K.

E:>net time *.*.*.197
System error 5 has occurred.
Access is denied.

E:>net use *.*.*.197IPC$ "" /U:""
The command completed successfully.

E:>net time *.*.*.197
Current time at *.*.*.197 is 6/21/2001 7:00 PM
The command completed successfully.

E:>at *.*.*.197
Access is denied.

E:>net view *.*.*.197
Shared resources at *.*.*.197

Share name Type Used as Comment
-------------------------------------------------------------------------------
Drive C Disk Windows
Drive D Disk FreeBSD
Drive E Disk i2000
The command completed successfully.

E:>net use *.*.*.197IPC$ /del
*.*.*.197IPC$ was deleted successfully.

Аналогичные операции можно осуществить и из системы Unix, используя утилиту
smbclient.

Кроме того утилита nbtstat (или nmblookup под Unix) позволяет получить
список зарегистрированных на машине NetBIOS имен (с типами). Среди них
содержатся - имя домена, имя машины в домене, имя текущего активного
пользователя. Более того, анализ этих имен позволяет определить роль машины в
домене (PDC, BDC, Master Browser). Ниже приведена небольшая выдержка из
таблицы типов NetBIOS имен.

	0x00	base computernames and workgroups, also in "*" queries

	0x01	master browser, in magic __MSBROWSE__ cookie

	0x03	messaging/alerter service; name of logged-in user

	0x20	resource-sharing "server service" name

	0x1B	domain master-browser name

	0x1C	domain controller name

	0x1E	domain/workgroup master browser election announcement [?]

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

Рассмотрим типичные паттерны:

открытые порты 23, 79, возможно 80, при остальных закрытых, достаточно
точно характеризуют машину как роутер.
открытый порт 111 дает практически стопроцентную гарантию, что
исследуемая система является UN*X-ом. Также это весьма вероятно в случае
наличия открытых портов в промежутке 150-520.
набор портов 21, 25, 110, и, может быть, 23, 80 - это типичный Linux или
BSD. (хотя, конечно, и не только он).
открытый порт Postgree-са (5432) позволяет предположить UN*X подобную
операционную систему. Тогда как в случае MS SQL (1322) - однозначно Windows
(причем NT/2K).
наличие открытого порта 139 предпологает альтернативу: либо это UN*X с
установленной SAMBA, тогда его обычно можно определить по открытому порту
SWAT (используемому для удаленной настройки SAMBA), либо это Windows. В этом
случае, если больше открытых портов нет - то это, скорее всего, W9x. Если же
есть открытые порты из 21,25,110 - то это, видимо, NT/2K.

Более точное определение операционной системы можно провести с
использованием параметров TCP/IP пакетов. Самой лучшей на сегодняшний день
утилитой подобного плана является nmap by Feodor (www.insecure.org). Там же
можно подробнее почитать об используемых алгоритмах. Мы же остановимся на
параметре TTL, поскольку он доступен без дополнительных инструментов (через
утилиту ping). TTL (TimeToLive) - это время жизни пакета. При отправке оно
устанавливается в некоторое стандартное значение (разное для различных
операционных систем), а затем, при прохождении каждого промежуточного пункта
уменьшается на 1. Если оно достигает нуля, пакет отбрасывается, как слишком
старый. Пакеты, дошедшие до нас, содержат TTL равный начальному минус
расстояние до исследоваемого хоста в hop-ах (промежуточных хостах). При
необходимости, это расстояние можно узнать, используя стандартную утилиту
traceroute (tracert под Windows). Однако оно обычно не превышает 10-20 hop-ов,
что позволяет однозначно распознать исходное значение.

если исходный TTL=128, то это, скорее всего, Windows.
если TTL=256, то это или UN*X, или WinNT.
если 64 или 32, то это или какой-нибудь роутер, бридж, хаб, или редкий
UN*X.

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

TCP-timestamping
----------------

Используя опцию TCP протокола tcp-timestamping и знание операционной
системы, часто можно определить uptime системы (время последнего включения).
При использовании этой опции мы принуждаем систему оставить свой временной
штамп. Штамп, по спецификации, должен со временем увеличиваться, однако не
оговаривается как именно. Практически во всех системах (кроме Windows систем)
отсчет штампа начинается с нуля в момент загрузки операционной системы. Но
скорость наращивания зависит от платформы (от 1 в сек до 1000 в сек). Для
решения этой проблемы мы можем воспользоваться знанием об используемой
операционной системе или сделать несколько проб через, скажем, 1 секунду, и на
основе полученной информации вычислить скорость приращения.

ICMP
Time/Mask
--------------

Internet Control Message Protocol описывает ряд контрольных сообщений и
способы реагирования на них, оставляя, однако, некотрую свободу в реализации
ICMP на различных ОС. В числе прочих существуют сообщения ICMP Time Request
(хост может ответить на него сообщением своего локального времени) и ICMP Mask
Request (по спецификации ответить на него может только маршрутизатор).

Рассмотрим следующую таблицу:

ОС Отвечает на ICMP Time Отввечает на ICMP Mask

Windows нет да
FreeBSD да нет
Linux 1.x да да
Linux 2.x да нет
SunOS да да
Solaris да да
HPUX да да
IRIX да ?

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

DNS
---

Стандартный порт - UDP 59. Изначально служба использовалась для
установления соответствия меджу сетевым именем и ip-адресом хоста. Часто
таблицы соответствий содержат также дополнительную информацию о хосте. В
состав операционных систем UN*X, WinNT, Win2K входит стандартная утилита
nslookup, являющаяся клиентом этой службы. Подсоединившись к удаленному
ns-серверу, мы можем затребовать у него информацию по хосту, принадлежащему
его зоне:

E:FP-art>nslookup
Default Server: *.ru
Address: *.*.*.226

> www.iso.ru
Server: *.ru
Address: *.*.*.226

Name: www.iso.ru
Address: 195.146.82.43

> set querytype=ALL
> www.iso.ru
Server: *.ru
Address: *.*.*.226

Non-authoritative answer:
www.iso.ru internet address = 195.146.82.43

iso.ru nameserver = exchange.iso.ru
iso.ru nameserver = home.relline.ru
iso.ru nameserver = ns.relline.ru
exchange.iso.ru internet address = 195.146.66.195
home.relline.ru internet address = 195.146.64.42
ns.relline.ru internet address = 195.146.81.130

Более того, если ns-сервер настроен не совсем корректно (на сегодняшний
день около 50% серверов являются таковыми), мы можем затребовать у него полный
список всех хостов зоны вместе со всей связанной с ними информацией.

> server ns.relline.ru
Default Server: ns.relline.ru
Address: 195.146.81.130

> ls -d iso.ru
[ns.relline.ru]
iso.ru. SOA exchange.iso.ru admins.iso.ru.
(1999121558 28800 7200 604800 86400)
iso.ru. NS exchange.iso.ru
iso.ru. NS home.relline.ru
iso.ru. NS ns.relline.ru
iso.ru. MX 40 relay1.macomnet.ru
iso.ru. MX 50 relay2.macomnet.ru
iso.ru. MX 10 exchange.iso.ru
demoserver A 195.146.66.200
admin A 195.146.66.198
www A 195.146.82.43
exchange A 195.146.66.195
ebs A 195.146.66.197
iso.ru. SOA exchange.iso.ru admins.iso.ru.
(1999121558 28800 7200 604800 86400)

Если это удалось, то, во-первых, мы получили список хостов сети, во-вторых,
на основе MX-записей (почтовых) мы можем определить основной и вторичный
почтовые сервера и маршруты хождения почты (частично).

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

Traceroute
-----------

Утилита (ее версия под Win называется tracert) предназначена для
определения маршрута пакета, посланного к заданному хосту. Ее работа
основывается все на том же параметре TTL. В начале TTL выставляется в 1. Тогда
первый же маршрутизатор, получивший его, обязан по спецификации его
уничтожить. При этом он обычно (однако это не является требованием
спецификации) посылает обратно уведомление - "у меня умер пакет, идущий от А к
Б". Так мы получаем первый пункт маршрута. Затем устанавливаем TTL в 2. И так
далее. Если мы теперь построим маршруты к каждому известному нам хосту
подсети, а затем объединим их в граф (обычно дерево), то мы будем иметь
некоторое представление о топологии подсети. Если, к тому же, подсеть имеет
несколько шлюзов со внешней сетью, то построение такого же дерева из другой
начальной точки (точнее такой, чтобы вход в подсеть происходил через другой
шлюз) может дать нам дополнительную информацию о ее топологии. Помощь в такого
рода исследованиях может оказать служба
(http://www.tracert.com/cgi-bin/trace.pl)

Louse route

------------

Эта опция IP протокола позволяет при отсылке пакета указать основные вехи
его маршрута, никак не оговаривая то, как он будет передаваться между ними. В
сочетании с опцией Timestamping, она дает возможность запустить пакет в
исследуемую подсеть, заставить его там "поболтаться", а затем вернуться,
собирая по пути информацию о всех пройденных пунктах маршрута. (Все это,
конечно, может быть блокированно корректно настроенным firewall-ом.) На основе
нескольких таких "трасс" возможно опять-таки построить некоторый граф подсети,
не говоря уже об обнаружении новых, ранее не замеченых хостов.

SNMP
----

Simple Network Managment Protocol был разработан для предоставления
возможности удаленного управления сетевыми устройствами, в том числе
маршрутизаторами. SNMP-агенты (то есть серверные приложения) входят сегодня в
состав многих маршрутизаторов, свитчей и тому подобных устройств, кроме того,
в ОС WinNT и Win2K имеется встроеный SNMP-Agent, реализованный в виде сервиса
(по умолчанию он выключен). Вторая версия данного протокола предусматривает
достаточно надежную аутентификацию, однако она пока почти нигде не
используется. В первой же версии происходит только проверка так называемой
community-string (посылаемой в plain-text виде по UDP). Стандартными
значениями community-string являются "public" и "private", и они, в
большинстве случаев, не меняются администраторами. Наиболее простым клиентом к
SNMP службе является пакет утилит snmputils под Unix, в состав которого входит
snmpwalk, позволяющий получить большое количество интересной информации. Так,
в случае WinNT/Win2K, мы можем получить список запущенных процессов (с
приоритетами и информацией о занимаемой памяти и процессорном времени), список
установленного софта с указанием версий (тот, что появляется в меню
Start->Control Panel->Add/Remove Programs), список установленного
оборудования и всю текущую информацию о маршрутизации. Более того, есть
возможность таким образом изменить настройки маршрутизации, чтобы пустить весь
траффик по маршруту, где исследователь сможет подвергнуть его анализу.

Passive fingerprinting

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

Метод анализа
проходящих пакетов
--------------------------------

В сигнатуру пакета, на основе которой предпологается производить
определение ОС входят следующие поля:

TTL - здесь ситуация совпадает с описанной несколько выше (в разделе об
анализе TTL с помощью утилиты ping).
Window Size - размер TCP-окна это количество пакетов, которое может
послать отправитель без прихода подтверждения от получателя. Оно может
меняеться в зависимости от качества связи. Различные ОС используют различные
начальные значения этого параметра и различные алгоритмы его модификации.
Так, например, Linux, Solaris, FreeBSD поддерживают более-менее постоянное
значение, а Cisco и Windows непрерывно его модифицируют.
DF - этот флаг TCP-пакета используется для запрета его фрагментации.
Практически все ОС устанавливают его, однако некоторые (такие как OpenBSD
или SCO-Unix) не делают этого.
TOS - это поле определяет желаемые характеристики соединения (скорость,
качество, дешевизну), и его анализ так же может помочь в определении ОС.
ID - первоначальное (при установке соединения) значения этого поля также
различно для разных операционных систем.

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

Анализ проходящего трафика на менее глубоком уровне также может дать
некоторую информацию - например какими сервисами каких удаленных систем
пользуется система, относительно которой производится сбор информации. Удобным
в установке и настройке сниффером (инструментом для анализа проходящих
пакетов) является snort (www.snort.org).

Application level passive
fingerprinting
----------------------------------------

Другим подходом к пассивному анализу удаленной системы является анализ
информации уровня приложений. Он может осуществляться как на основе анализа
проходящего траффика (как в предыдущем методе), так и на основе анализа
информации, получаемой серверными приложениями исследующей системы от
различных удаленных клиентов. Примером последнего метода могут послужить decoy
server-ы - способ определения атак на систему путем подмены обычных серверных
приложений (таких, как ftp, http, smtp, pop3 сервера) на приложения,
выполняющие их функции и попутно регистрирующие нетипичную деятельность
клиента.

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

Ping-payload
------------

Принцип работы утилиты ping основан на посылке ICMP пакета ICMP-Echo,
содержащего произвольные данные, на который хост-адресат отвечает пакетом
ICMP-Echo-Reply, содержащим те же самые данные. Время между отправкой
ping-пакета и получением ответа на него и является временем отклика удаленной
системы. С точки зрения пассивного анализа, интерес представляет способ
генерации, данных заполняющих пакет. Различные операционные системы используют
различное наполнение. Так, в случае Win2K, содержимое пакета будут составлять
строчные символы латинского алфавита ("abcde...xyzabcd..."), а в случае RedHat
6.1 в содержимом будут и цифры, и специальные символы. Эти отличия позволяют
попытаться распознать операционную систему ping-ующего хоста.

HTTP
----

Данный протокол позволяет серверу получить некоторую информацию о
клиентской машине, основываясь, главным образом, на составе и порядке
header-ов в запросе (несущих вспомогательную информацию). Так, например,
заголовок User-Agent: содержит информацию об используемом браузере, а
зачастую, и о клиентской операционной системе.

Более подробную информацию о клиенте (которым, собственно, является
браузер) сервер может получить, отослав клиенту html-документ, содержащий
специальный javascript-код, определяющий необходимые серверу параметры и
возвращающий их серверу, используя, например, механизм CGI. На этом
основывается работа многочисленных баннерных сетей и счетчиков. Хорошим
примером подобного javascript-кода может служить счетчик spylog-а. Однако
подобная техника не может считаться полностью пассивной, так как может быть
опознана на клиентской стороне.

FTP
---

Несмотря на кажущуюся простоту, и этот протокол позволяет серверу
достаточно точно определить клиентское программное обеспечение. При успешном
соединении клиент в начале ftp-сессии подает некоторые из следующих команд:
AUTH, USER, PASS, PWD, PORT, SYST, EPSV, PASV, LIST, CWD. То, какие именно
команды и в каком порядке он подает, позволяет уверено различать многих
клиентов:

линукс-клиент (AUTH, USER, PASS, SYST, PORT)
стандартный Windows-клиент (USER, PASS, PORT)
клиент, встроенный в Far (USER, PASS, PWD)
FreeBSD-клиент (USER, PASS, SYST, EPSV)
MSIE (USER anonymous, PASS IEUser@, TYPE I, PASV, CWD)
Go!Zilla (USER anonymous, PASS gozilla@anon.com, PASV, LIST)
ReGet (USER anonymous, PASS User@x-x-x-xxx.ReGet.Com, SYST)

Telnet
------

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

SMTP/POP3/NNTP
--------------

Служебные заголовки сообщений электронной почты дают обильную информацию об
источнике и процессе пересылки письма. Анализируя их, исследователь может
получить список хостов внутри сети исследуемой системы, участвующих в процессе
пересылки почты, и сделать некоторые предположения относительно правил
маршрутизации почты в исследуемой подсети. В заголовках всегда фигурирует ip
или hostname источника письма. Рассмотрение таких полей, как Message-ID,
X-Mailer, User-Agent дает возможность определить клиентское программное
обеспечение, использованное при написании и отсылке письма (вплоть до номера
версии) и, часто, операционную систему клиента. Например:

 Message-ID:  		(это Linux, Pine v4.10)
 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
 X-Mailer: Microsoft Outlook Express 5.00.3018.1300

Аналогичную информацию можно получить, анализируя заголовки новостных
сообщений (NNTP). Здесь наиболее выразительными являются User-Agent,
X-Http-User-Agent, X-Mailer, Message-ID, X-Newsreader, X-Operating-System.

Заключение

==========

Кому же и зачем нужны подобные алгоритмы? Сегодня спектр их применения
весьма широк:

HoneyPot и IDS системы оборудуются софтом, работа которого основана на
FP-алгоритмах, производящим отслеживание и идентификацию злоумышлеников.
Используя специальное программное обеспечение, администраторы сетей
могут быстро обнаруживать аномальные явления (такие, например, как появление
Linux машины в сети Windows машин).
Опытные злоумышленики могут, используя подобные методы, определить
версии ОС и ПО удаленной машины с тем, чтобы затем, найдя наиболее уязвимое
место, произвести целенаправленную атаку.
Script-kiddies, наоборот, ищут системы, уязвимые для имеющихся у них
инструментов.

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

Начиная написание данной статьи, я и не подозревал, что объем разнородной
информации на эту тему столь велик (хватило бы на небольшую книгу 8-).
Поэтому, к сожалению, многие вещи пришлось выкинуть (было убрано большое число
примеров и ссылок, в конце концов, это же не учебник 8-Р ). За бортом остались
такие темы, как анализ и спуффинг протоколов маршрутизации (RIP, OSPF), анализ
таких Windows-специфичных сервисов, как WINS, и многое другое. Однако, я
постарался, чтобы текст был понятен и не-специалисту (кратко объясняя многие
базовые понятия). Насколько это удалось - судить Вам.

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

2004

Безопасность

Последние статьи

Категории

Разное

Алгоритмы анализа удаленной системы

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