div.main {margin-left: 20pt; margin-right: 20pt}
алгоритмы анализа удаленной
системы
Вступление
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
Сразу сделаем оговорку, что большинство ftp-демонов под win32 устроены таким образом, что администратор может
назначать произвольный отклик на команду SYST. Вот, например, знаменитый War FTP Daemon
предлагает администратору выбрать между
“чэсным” ответом и “закосом” под UNIX.
Дополнительный интерес может представлять, такая, скажем,
специфическая информация, как дата создания каталога 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
...
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
Используя знания о стандартных конфигурациях различных
веб-серверов под различные платформы, исследователь может попытаться
использовать стандартные веб-скрипты для получения дополнительной
информации.
На самом деле можно обойтись и без метода OPTIONS дабы получить сведения о типе демона, содержащиеся
в поле Server. Достаточно и
нормального, скажем, GET-запроса.
Можно поэкспериментировать с “кривыми” или заведомо невыполнимыми
(ведущими к 404 Not Found) запросами.
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, а также 7, 9.
открытый порт Postgres’а (5432)
позволяет предположить UN*X подобную операционную систему. Тогда как в
случае MS SQL (1322) - однозначно Windows (причем NT/2K).
наличие открытого порта 139 предпологает альтернативу: либо это UN*X с
установленной SAMBA, тогда его обычно можно определить по открытому порту
SWAT (используемому для удаленной настройки SAMBA), либо это Windows. В
этом случае, если больше открытых портов нет - то это, скорее всего, W9x.
Если же есть открытые порты из 21,25,110 - то это, видимо, NT/2K, или
какой-нибудь ну очень забавный SOHO-сервер под Win9x/ME.
Более точное определение операционной системы можно провести с
использованием параметров TCP/IP пакетов (TCP-fingerprinting, о нем уже достаточно подробно писалось в одном из
предыдущих выпусков “СР” -- прим. ред.). Самой лучшей на сегодняшний день
утилитой подобного плана является nmap by Fyodor (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
Стандартныe портs –
UDP и TCP
53. Изначально служба использовалась для установления соответствия меджу
сетевым именем и 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 - первоначальное (при установке соединения) значения этого поля
также различно для разных операционных систем.
При применении данного метода следует использовать
статистический подход - накапливать информацию, относящуюся к одному
соединению, а затем определять по заранее составленным таблицам наиболее
вероятную ОС.
Анализ проходящего трафика на менее глубоком уровне также может
дать некоторую информацию - например какими сервисами каких удаленных систем
пользуется система, относительно которой производится сбор информации.
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
Данный протокол позволяет серверу получить некоторую информацию
о клиентской машине, основываясь, главным образом, на составе и порядке
заголовков в запросе (несущих вспомогательную информацию). Так, например,
заголовок 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)
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, и многое
другое. Однако, я постарался, чтобы текст был понятен и не-специалисту
(кратко объясняя многие базовые понятия). Насколько это удалось - судить
Вам.
altsoph@zmail.ru,
впервые опубликовано на www.hackzone.ru
|
