Материалы представленные на сайте исключительно с целью ознакомления пользователям Интернета и не преследуют коммерческих целей или нарушение авторских прав.
© 2018 - 2024
Основные принципы пассивного исследования стека аналогичны концепциям, лежащим в основе его активного исследования. Однако в данном случае вместо передачи пакетов для определения используемой операционной системы взломщик осуществляет мониторинг сетевого трафика. Таким образом, наблюдая за сетевым трафиком между различными компьютерами, можно определить тип и версию удаленной операционной системы. Большие исследования в этой области были проведены Ланцом Спитзнером (Lance Spitzner). На их основе была написана книга, которую можно найти по адресу http://www.enteract.com/~lspitz/finger.html. Кроме ТОГО, по адресу http://www.subterrain.net/projects/siphon можно также найти утилиту siphon, предназначенную для пассивного исследования портов и идентификации операционной системы. Теперь познакомимся с тем, как же выполняется пассивное исследование стека.
Параметры, используемые для пассивного исследования стека
Для определения типа и версии операционной системы можно использовать самые разнообразные признаки. Однако сейчас мы ограничимся рассмотрением лишь нескольких атрибутов, связанных с сеансом сетевого взаимодействия с помощью протокола TCP/IP.
· атрибутов TTL (Time-to-Live — время жизни). Устанавливает ли операционная система значение TTL для исходящих пакетов?
· Windows Size (размер окна). Какой размер окна используется?
· DF (Don't Fragment — бит фрагментации). Устанавливается ли операционной системой признак DF?
· TOS (Type-of-Service — тип службы). Устанавливается ли операционной системой значение TOS. Если да, то какое?
Проанализировав каждый из атрибутов и сравнив полученные результаты со значениями из имеющейся базы данных, можно определить удаленную операционную систему. Поскольку этот метод не гарантирует получения правильного ответа на основе каждого из атрибутов в отдельности, для получения более надежных результатов атрибуты можно комбинировать. Именно такой подход и используется утилитой siphon.
Вот как работает описанный метод. Если с помощью утилиты telnet установить удаленное соединение между узлами 192 .168 .1.10 и 192 .168 .1.11 , то с использованием утилиты siphon можно определить тип удаленной операционной системы.
[shadow]# telnet 192.168.1.11
С помощью нашей любимой утилиты snort можно частично просмотреть пакеты, передаваемые в процессе сетевого взаимодействия.
06/04-11:23:48.297976 192.168.1.11:23 -> 192.168.1.10:2295
TCP TTL:255 TOS:OxO 10:58934 DF
**S***A* Seq: OxD3B709A4 Ack: OxBE09B2B7 Win: 0x2798
TCP Options => NOP NOP TS: 9688775 9682347 NOP WS: 0 MSS: 1460
При этом видно, что упоминавшиеся выше атрибуты принимают следующие значения:
· TTL= 255
· Размер окна = 2798
· Бит DF = Yes A TOS = 0
Теперь обратимся к базе данных утилиты siphon — файлу osprints.conf:
[shadow]f grep -i Solaris osprints.conf
# Window:TTL:DF:Operating System DF = 1 for ON, 0 for OFF.
2328:255:l:Solaris 2.6 - 2.7
2238:255:l:Solaris 2.6 - 2.7
2400:255:l:Solaris 2.6 - 2.7
2798:255:l:Solaris 2.6 - 2.7
FE88:255:l:Solaris 2.6 - 2.7
87CO:255:l:Solaris 2.6 - 2.7
FAFO:255:0:Solaris 2.6 - 2.7
FFFF:255:1:Solaris 2.6-2.7
Из приведенного фрагмента видно, что в четвертой записи содержатся те же значения, которые были получены с использованием утилиты snort. Таким образом, с помощью утилиты siphon можно точно определить исследуемую операционную систему.
[crush]# siphon -v -i xl0 -о fingerprint.out
Running on: 'crush' running FreeBSD 4.0-RELEASE on a(n) i386
Using Device: xlO
Host Port . TTL DF Operating System 192.168.1.11 23 255 ON Solaris 2.6 - 2.7
Итак, в качестве удаленной была определена система Solaris 2.6. И это .не вызвало особых проблем. Пассивное исследование стека взломщик может использовать для выбора потенциальных жертв. Для этого достаточно понаблюдать за соответствующим Web-узлом и проанализировать сетевой трафик либо воспользоваться утилитой siphon. Несмотря на то что описанный метод является достаточно эффективным, он все же имеет некоторые ограничения. Во-первых, в приложениях, генерирующих свои собственные пакеты (например, шпар), не применяются те же признаки, что и самой операционной системой. Поэтому полученные результаты могут оказаться неточными. Во-вторых, на удаленном узле можно без проблем изменить атрибуты соединения.
Solaris: ndd -set /dev/ip ip_def_ttl 'число'
Linux: echo 'число' > /proc/sys/net/ipv4/ip_default_ttl
NT:
HKEY_LOCAL_MACHINESystemCurrentControlSet
ServicesTcpipParameters
Активное исследование стека
Прежде чем перейти к рассмотрению возможностей утилит nmap и queso, необходимо вкратце пояснить, в чем же состоит суть исследования стека TCP/IP. Исследование стека (stack fingerprinting) — это очень мощная технология, позволяющая быстро определить тип и версию операционной системы узла с высокой степенью вероятности.
Очевидно, что разные разработчики по-разному подходят к реализации стека TCP/IP. В частности, многие разработчики по-своему трактуют рекомендации документов RFC, что впоследствии проявляется в логике работы тех или иных сетевых служб. Таким образом, зная о существующих различиях и проверив реакцию служб изучаемой системы на различные ситуации, можно практически однозначно определить тип и версию соответствующей операционной системы. Для достижения максимальной достоверности при исследовании стека требуется по крайней мере один порт, находящийся в режиме ожидания запросов. С помощью утилиты nmap можно выдвинуть предположение об используемой операционной системе даже при отсутствии таких портов, однако степень его достоверности в этом случае будет невысокой. Полное описание процесса исследования стека можно найти в статье Федора (Fyodor), впервые публикованной в журнале Phrack Magazine.
Ниже приведен перечень тестов, которые можно использовать в процессе исследования стека для определения типа и версии операционной системы.
· Передача пакетов FIN (FIN probe). Пакет FIN отсылается в открытый порт. Как уже упоминалось, согласно документу RFC 793 исследуемая система не должна отвечать на такое сообщение. Однако многие реализации стека (например, Windows NT) отвечают на них, отправляя пакет FIN/ACK.
· Попытка установки флагов (bogus flag probe). Отсылается пакет SYN с установленным флагом в заголовке TCP, значение которого не определено спецификацией протокола. Некоторые операционные системы, например Linux, в ответном пакете устанавливают этот же флаг.
· Изучение начальной последовательности (Initial Sequence Number (ISN) sampling). Основная задача этого теста — попытаться определить характерные признаки начальной последовательности, генерируемой узлом при получении запроса на установку соединения, которые характерны для той или иной реализации TCP.
· Мониторинг бита фрагментации ("don't fragment bit" monitoring). Этот бит устанавливается некоторыми операционными системами для повышения производительности. Проверка данного бита может помочь в определении типа операционной системы, для которой характерно такое поведение.
· Исходный размер окна TCP (TCP initial window size). Для некоторых реализаций стека протоколов TCP/IP данный параметр уникален, что способствует точности определения типа операционной системы.
· Значение АСК (дек value). В различных реализациях стека IP по-разному задается значение поля АСК. В одних случаях возвращается полученный от вас номер последовательности, а в других — значение номера последовательности, увеличенное на 1.
· Обработка сообщений об ошибках ICMP (ICMP error message quenching). Некоторые операционные системы следуют рекомендациям документа RFC 1812 (www. ietf.org/rfc/rfcl812.txt) и ограничивают скорость передачи сообщений об ошибках. Поэтому, отправляя UDP-пакеты на какой-либо порт (обычно с большим номером), вполне реально измерить количество сообщений об ошибках, поступившее за определенный период, и определить таким образом тип операционной системы.
· Измерение длины сообщений ICMP (ICMP message quoting). При возникновении ошибок ICMP разными операционными системами передаются сообщения различной длины. Проанализировав полученное сообщение, можно сделать некоторые предположения об исследуемой операционной системе.
· Проверка целостности ответных сообщений об ошибках ICMP (ICMP error message-echoing integrity). В некоторых реализациях стека используется изменение заголовка IP при возврате сообщений об ошибках ICMP. Проверив тип изменений, внесенных в заголовок, можно сделать некоторые предположения об операционной системе исследуемого узла.
· Тип службы (TOS — type of service). Можно проверять поле TOS для сообщений "ICMP port unreachable" (порт недоступен). В большинстве реализаций это поле имеет значение 0, однако иногда используются и другие значения.
· Обработка фрагментации (fragmentation handling). Как отмечают Томас Пташек (Thomas Ptacek) и Тим Ньюсхам (Tim Newsham) в своей известной статье Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection (http://www. clark.net/~roesch/idspaper.html), различные стеки обрабатывают перекрывающиеся сообщения по-разному. При сборке фрагментированньк пакетов некоторые стеки записывают новые данные поверх старых и наоборот. Проверив, каким образом были собраны тестовые пакеты, можно сделать предположение об исследуемой операционной системе.
· Параметры TCP (TCP options). Параметры TCP определены в документе RFC 793 и недавно изданном RFC 1323 (www.ietf.org/rfc/rfcl323.txt). Нововведения, описанные в RFC 1323, нашли отражение только в самых последних реализациях стеков. Отправляя пакет с набором различных параметров, таких как по operation, maximum segment size, window scale factor, timestamp и так далее, можно сделать вывод о типе и версии операционной системы.
Для того чтобы воспользоваться утилитой nmap и выполнить все перечисленные тесты (за исключением обработки фрагментации и обработки сообщений об ошибках ICMP), достаточно указать в командной строке параметр -о. Давайте посмотрим, как будет выглядеть полученный результат.
[tsunami] nmap -0192.168.1.10
Starting nmap V. 2.53 by fyodor@insecure.org
Interesting ports on shadow (192.168.1.10) :
Port State Protocol Service
7 open tcp echo
9 open tcp discard
13 open tcp daytime
19 open tcp chargen
21 open tcp ftp
22 open tcp ssh
23 open tcp telnet
25 open tcp smtp
37 open tcp time
111 open tcp sunrpc
512 open tcp exec
513 open tcp login
514 open tcp shell
2049 open tcp nfs
4045 open tcp lockd
TCP Sequence Prediction: Class=randorn positive increments
Difficulty=26590 (Worthy challenge)
Remote operating system guess: Solaris 2.5, 2.51
Как видно, при включении режима исследования стека утилиты nmap можно легко получить достаточно точное определение типа и версии операционной системы. Даже если на изучаемом узле не открыто ни одного порта, утилита nmap поможет сделать довольно точное предположение об используемой операционной системе.
[ tsunami]# nmap -p80 -0 10.10.10.10
Starting nmap V. 2.53 by fyodor@insecure.org
Warning: No ports found open on this machine,
OS detection will be
MUCH less reliable
No ports open for host (10.10.10.10)
Remote OS guesses: Linux 2.0.27 - 2.0.30, Linux 2.0.32-34,
Linux 2.0.35-36, Linux 2.1.24 PowerPC,
Linux 2.1.76, Linux 2.1.91 - 2.1.103, Linux 2.1.122 - 2.1.132; 2.2.0-prel - 2.2.2, Linux 2.2.0-pre6 - 2.2.2-ac5
Nmap run completed -- 1 IP
address (1 host up) scanned in 1 second
Как видно из приведенного листинга, утилита nmap даже без открытых портов, правильно определила операционную систему Linux.
Одной из примечательных особенностей утилиты nmap является то, что листинг сигнатур хранится в отдельном файле с именем nmap-os-fingerprints. При появлении каждой новой версии утилиты этот файл также обновляется, и на момент написания данной книги в нем содержались сотни сигнатур. Если вы хотите добавить новые сигнатуры и повысить таким образом эффективность утилиты nmap, обратитесь ПО адресу http://www.insecure.org:80/cgi-bin/nmap-submit.cgi.
Хотя на момент написания данной книги утилита nmap, по-видимому, позволяет наиболее точно выполнить исследование стека TCP/IP, она, тем не менее, является далеко не первой программой, в которой реализована соответствующая технология. До того как Федор встроил в утилиту nmap средства определения операционной системы, для этих же целей уже была создана утилита queso (http://www.apostols.org/projectz/). Необходимо отметить, что утилита queso не позволяет выполнять сканирование портов и может определять тип операционной системы только при наличии в исследуемой системе открытого порта (по умолчанию используется порт 80). Если порт 80 закрыт, необходимо задать другой открытый порт, как показано в следующем примере, в котором с помощью утилиты queso осуществляется попытка определить тип операционной системы через порт 25.
[tsunami] queso 10.10.10.20:25
10.10.10.20:25 * Windoze 95/98/NT
Контрмеры: защита от определения операционной системы
Обнаружение попыток определения операционной системы
Многие из упоминавшихся выше средств выявления сканирования с успехом могут служить и для обнаружения попыток определения типа операционной системы, Хотя они не проинформируют вас о том, что выполнялось специальное сканирование с помощью утилиты nmap или queso, с их помощью все же удастся распознать сам факт такого особого сканирования, например с установкой флага SYN.
Предупреждение попыток определения операционной системы
Хотелось бы посоветовать какое-нибудь средство, позволяющее противодействовать попыткам определения операционной системы, однако, к сожалению, вынуждены констатировать, что решить эту проблему весьма непросто. Конечно, можно изменить исходный код операционной системы (естественно, если он имеется в вашем распоряжении) или поменять ее параметры, влияющие на характеристики стека, однако такое вмешательство может значительно изменить функциональность ОС. Например, в системе FreeBSD 4.x имеется параметр ядра TCP_DROP_SYNFIN, который можно применить для игнорирования пакетов SYN+FIN, используемых утилитой nmap в целях исследования стека. Установка этого параметра поможет пресечь попытки определения типа операционной системы, однако в то же время нарушит поддержку RFC 1644 (TCP Extensions for Transactions).
Вместо этого мы предлагаем создавать такие сети, в которых сканированию могли бы подвергнуться лишь надежные и хорошо защищенные proxy-серверы и брандмауэры, а не компьютеры внутренней сети. В этом случае, даже если взломщику и удастся разведать тип операционной системы того или иного узла, проникновение через устройства защиты будет значительно затруднено.
Дата: 2019-05-28, просмотров: 267.