Введение:
OS fingerprinting (OSF) — метод получения информации об ОС. OSF
актуален на начальном этапе реализации атаки на хост. Так, как имея
информацию о типе ОС атакующий может планировать на какие известные
уязвимости он будет воздействовать. При этом, чем точнее атакующий
определит тип и версию ОС удаленного хоста, тем эффективней будет
выполнен его «взлом». Администраторы идут на всяческие ухищрения чтобы
исключить точное определение своей ОС. И для того, чтобы точно
определить ОС приходится использовать комплексный подход — что
собственно и описывается в этом документе. Сам процесс определения ОС
нельзя представить не описав методы сканирования. После применения
которых составляется отпечаток системы (fingerprint) по которому уже
из базы заранее известных отпечатков выбирается соответствие. OS
fingerprinting бывает двух видов — активный и пассивный. Активный OSF
— это определение типа ОС путем отсылки пакетов на исследуемый хост.
Пассивный OSF — это определения типа ОС путем анализа пакетов идущих
от хоста. Недостатком активного является то — что атакующий может быть
легко замечен системой IDS, а преимуществом то — что не надо ждать
пока исследуемая система пошлет пакет к атакующему, а атакующий сам
посылает пакет на исследуюмую систему в любое удобное время.
Недостатком пассивного определения ОС является то — что обязательным
условием атаки является — нахождение хоста атакующего на маршруте
исследуемой системы либо обращение исследуемой системе к хосту
атакующего, а преимуществом то — что такую атаку очень сложно
заметить.
Классические методы OSF
Под классическими методами понимается сбор так называемых . Банером
называется стандартное приглашение сервиса например: FTPd, HTTPd,
SMTPd, telnetd, identd. И соответственно по ним определяется тип ОС.
Рассмотрим более подробно.
Исследование telnetd
Этот метод требует, чтобы на удаленном хосте был запущен демон telnetd
и у нас была возможность установить с ним соединение (во многих
случаях сейчас это проблема потому как все переходят на SSH, но на ОС
wiondows тем не менее он только начал активно использоваться). Раньше
системы сами сообщали о себе (этол считалось хорошим тоном) например:
Но сейчас разработчики поняли свою ошибку и убрали эту фичу. Но
остается селедующий метод — после установления соединения, мы
выполняем функцию sysread() и собираем информацию о сессии telnet.
Пример такой информации:
Чтобы правильным образом интерпретировать полученную информацию от
демона telnetd, нам необходимо порядок следования опций TELOPT (Telnet
Option), которые определены в telnet.h. В каждой ОС,за некоторым
исключением, определен свой собственный порядок следования этих опций.
После того как мы получили «отпечаток» в ascii, мы должны сначала
конвертировать эти данные в их числовые значения (1-255) и далее
отдельно сравнить по порядку каждое значение с соответствующей опцией
TELOPT.
или
Эти значения TELOPT можно посмотреть в /usr/include/arpa/telnet.h.
Исследование HTTPd
HTTP запрос:
Отсюда видно, что удаленная система Windows потому как в поле Server —
Web сервис возвращает не только тип и версию самого Web сервера, но и
тип ОС.
В случае если удаленный отвечает, что тип Web сервера Microsoft-IIS то
вероятнее всего, что там стоит ОС Windows NT/2000.
Исследование FTPd
Приглашение FTP сервиса Обычно имеет значение именно само приглашение
или же если открыт анонимный доступ то информация выдаваемая по
команде SYST.
Получив такой ответ можно предположить, что это FreeBSD. А если зайдя
на FTP вы получите сообщение:
То вероятнее всего это Linux потому как в большинстве Linux
систем wu-ftpd входит в стандартную поставку. Иногда система сама о
себе сообщает в заголовке:
Даже если всетаки администратор не забывает изменить заголовок то информацию по
прежнему можно получить по команде SYST:
Идентификация по identd
Для этого требуется чтобы был открыт 113 порт и установления
соединения с демоном identd. Форма ответа определена в RFC 1413:
The response is of the form
Пример ответа:
Отсюда сразу видно, что удаленная система Linux (в данном случае это
Debian 2.2) с ядром версии 2.2.12. Бывает так, что это не указывается
в явном виде — например:
OSF в таких случаях осуществляется по времени компиляции —
для этого предварительно составляется база с OSF. Соответственно
в данном случае это FreeBSD 4.2-STABLE.
Идентификация по lpd
«Все команды начинаются с единственным кодом октета, который является
двоичным числом, которое представляет запрошенную функцию. Код
неприменно сопровождается именем ASCII имени очереди принтера на
котором функция должна быть выполнена» [….] «Конец команды
обозначаеться ASCII line feed символом.»
«Каждая строка управляющего файла состоит из единственного, выводимого
символа ASCII, который представляет функцию, которая должна
выполняться, когда файл напечатан. Интерпретация этих командных
символов регистро-чувствительные. Остальная Часть линии после
командного символа — командный операнд.» [….] «Некоторые команды
должны включаться в каждый управляющий файл. Такие как — 'H
(ответственный хост) и 'P (ответственный пользователь). К тому же,
должна быть по крайней мере одна команда нижнего регистра, чтобы
произвести любой вывод.» Отрывки выше описывают правильный формат
сообщения/запроса в котором просьба должна быть структурной. Этот
теоретический анализ не беспокоится о первом отрывке RFC (Форматы
Сообщения), в действительности мы не хотим выйти и послать запрос
печати. И в основном мы не хотим печатать файлы на принтере на другом
конце. Как Вы догадывались бы, мы собираемся использовать управляющие
файловые команды, чтобы «определять» возможную Операционную Систему на
удаленном хосте. Нормальный запрос печати должен быть похожим на это:
[Придерживаясь синтаксиса определенного RFC 1179]
Это позволило бы напечатать файл «file.txt» после того как исходный
(порождающий запрос) хост и пользовательский идентификатор были
проверены. Так как мы производим fingerprinting удаленного хоста и не
можем знать «исходный хост» и «пользовательского идентификатора» чтобы
сформировать правильный(допустимый) запрос печати, мы должны
положиться на другие средства проверки lpd информации удаленного
хоста. Вместо посылки правильного запроса с правильно
отформатированной структурой синтаксиса, мы пошлем неправильный запрос
и увидим, как удаленный LPD нам ответит. В этом случае мы опустим
опознавательную информацию {H} и {P} и изменим {f} команду на другую,
чтобы гарантировать, что мы не получаем противоречивые ответы:
[Не придерживаясь синтаксиса определенного в RFC 1179]
В этом сценарии, мы послали искаженный запрос к удаленному LPD и ждем
его реакции. Формат и содержание этого подтверждения покажут
уведомительное сообщение ошибки, которое в многих случаях является
OS-зависимым. Мы можем тогда формировать базу данных возможных ответов
от lpd и сопоставленных с типом ОС.
Практический анализ:
Чтобы в действительности убедиться, что разные ОС имеют разный LPD
f0bic написал программу которая показывает различия и подобия между
различными fingerprint'ами LPD. Программа посылает искаженный запрос,
например:
Следующее — примеры, которые показывают информацию, собранной, посылая
искаженный запрос, изображенный выше.
Это на одних системах. А теперь на других:
Видно, что разные ОС возвращают разные ответы. Но некоторые ОС (Compaq
Tru64 Unix, HP-UX, и тому подобные) будут возвращать ответ нулевой
длины, что затруднит их аудит.
Методы реализованные в сканере Nmap.
В Nmap реализован метод получения информации об операционной системе
удаленного хоста, использующий механизм опроса стека TCP/IP
удаленного хоста. Nmap является ярким примером активного OSF.
Метод опроса стека TCP/IP удаленного хоста Как правило, реакцией
сервера на любое удаленное воздействие (входящий пакет данных,
запрос) является пакет данных, посылаемый источнику данного
воздействия (в дальнейшем под термином «сервер» понимается
атакуемый хост, а под термином «хост» — хост атакующего). Как
показывает практика, различные ОС при работе в сети по-разному
реагируют на один и тот же запрос. Исследовав особенности реакций
на запрос ОС, версии которых заранее известны, можно набрать
определенную статистику, сопоставив реакции на запрос с типом ОС.
При использовании комбинированного воздействия, статистическая
информация становится более конкретизированной.
В дальнейшем, исследуя реакцию сервера с неизвестной ОС, с
использованием накопленной статистики можно определить не только
тип, но и версию установленной на сервере ОС. Например, возможно
точно отличить Solaris 2.4 от Solaris 2.50 или Linux kernel
version 2.0.30 ( для всех Linux далее указывается версия ядра) от
Linux 2.0.35. Рассмотрим более подробно основные методы
исследования ОС сервера.
Формат заголовка IP
Формат TCP заголовка
Формат ICMP заголовка
FIN- исследование
Перед началом непосредственного исследования хост сканирует порты
сервера и определяет, какие порты являются открытыми. Затем на
любой открытый порт сервера хост посылает FIN-пакет (TCP-пакет на
завершение соединения) или любой другой пакет без флагов SYN и
ACK. В соответствии с RFC 793 сервер должен ответить на такой
пакет RST-пакетом, однако некоторые ОС типа Windows, BSDI, CISCO,
HP/UX, MVS и IRIX не посылают ничего в ответ.
Исследование BOGUS- флагом
Хост посылает на сервер SYN-пакет с установленным в TCP-заголовке
неиспользуемым «флагом» BOGUS . «Флаг» BOGUS не является настоящим
флагом. На самом деле этот термин подразумевает установку бит в
поле Reserved заголовка TCP- пакета как 1000000 (вместо всех нулей
согласно RFC 793). ОС Linux до 2.0.35 сохраняет в ответе этот
«флаг». Некоторые ОС обрывают соединение при получении такого
пакета.
Определение закона изменения ISN сервера
Хост посылает на сервер SYN-пакет с запросом на соединение,
записав в пакет свое (известное) значение ISN. Сервер, получив
запрос на соединение, прибавляет к полученному ISN единицу и
записывает полученное значение в поле ACK ответа (т.е.
SYN|ACK-пакета), а в поле ISS ответа — свой собственный ISN , и
передает пакет устанавливающему соединение хосту. На приемной
стороне (т.е. на стороне хоста) пакет анализируется. Операция
повторяется до тех пор, пока не будет выявлен закон изменения ISN
сервера. Возможны следующие закономерности:
+ закон «постоянного приращения» (традиционный закон «+64» —
старые версии UNIX): значение ISN сервера, записываемого в
поле ISS ответа на запрос «установление соединения»,
увеличивается на постоянную величину (либо на 64) с каждым
обрабатываемым запросом;
+ закон «случайных приращений» (новые версии Solaris, IRIX,
FreeBSD, DigitalUNIX, Cray): приращение ISN носит случайный
характер;
+ истинно случайные значения (Linux 2.0.x, OpenVMS, новые AIX):
значение ISN является случайной величиной;
+ закон «время-зависимых приращений» (Windows): значение ISN
периодически во времени увеличивается на некоторую небольшую
величину;
+ постоянный ( концентраторы 3Com [ISN=0x803], принтеры Apple
LaserWriter [0xC7001]): значение ISN остается постоянным.
Исследование поля Window TCP- пакета
Анализируя принятые от сервера TCP-пакеты целесообразно обратить
внимание на поле Window в их заголовках , поскольку значение этого
поля является своеобразной константой, характеризующей ОС. В
некоторых случаях для однозначного определения типа ОС достаточно
извлечь значение поля Window в TCP-заголовке принятого от сервера
пакета. Так, ОС AIX — единственная ОС, имеющая значение
Window=0x3F25. » Полностью переписанный» стек TCP/IP в ОС Windows
NT5 , равно, как и OpenBSD и FreeBSD , имеют Window=0x402E.
Исследование поля ACK в TCP- пакете
Рекомендацией RFC 793 определено стандартное изменение поля ACK в
TCP- пакетах при установлении соединения, передаче данных и
закрытии соединения. Однако в нестандартных ситуациях различные ОС
по-разному устанавливают значение этого поля. Исследование
проводится следующим образом. На закрытый TCP-порт хост отправляет
FIN|PSH|URG- пакет с известным значением ISN в поле ISS .
Большинство ОС скопируют значение ISN, прибывшее в ISS , в поле
ACK ответа. Однако ОС Windows и некоторые сетевые принтеры
отправят в поле ACK ответа ISN+1 . Если хост пошлет
SYN|FIN|PSH|URG-пакет, поведение Windows предсказать трудно.
Иногда эта ОС отправляет в поле ACK ответа прибывший ISN, иногда —
ISN+1, иногда — по всей видимости, случайное значение. Остается
только догадываться, какой код написала Microsoft для обработки
подобной ситуации.
Исследование скорости генерирования ICMP- сообщений
Согласно RFC 792 , протокол ICMP использует протокол IP в качестве
средства доставки. Очевидно, что ICMP-сообщения занимают
определенную часть полосы пропускания канала связи, что снижает
общую скорость передачи данных. По этой причине некоторые
продвинутые ОС, следуя рекомендации RFC 1812 , ограничивают
количество отправляемых в канал связи ICMP- сообщений об ошибках.
Так, Linux ограничивает количество ICMP- сообщений об ошибке типа
«получатель недоступен» (Destination Unreachable) до 80 сообщений
в 4 секунды, с простоем 0,25 секунды, если это ограничение было
превышено. Единственный способ проверить скорость генерирования
ICMP- сообщений сервером — послать на некоторый закрытый UDP-порт
с большим номером набор пакетов и подсчитать количество принятых
ICMP-сообщений. Этот тест является очень медленным, и, кроме того,
вызывает относительно большую нагрузку на сеть.
Исследование формата ICMP- сообщений
Для снижения общей нагрузки на сеть рекомендациями было
установлено, что дейтаграмма с ICMP- сообщением об ошибке должна
иметь меньший размер, чем дейтаграмма с ICMP -сообщением,
вызвавшая ошибку. Так, в качестве ICMP-сообщения «порт недостижим»
(Port Unreachable — PU) практически все ОС генерируют дейтаграмму,
представляющую собой необходимый IP- заголовок и 8 байт данных,
которые и являются непосредственно ICMP-сообщением. Однако ОС
Solaris формирует ICMP- сообщение немного большего размера, а
Linux — еще больше, чем Solaris. Таким образом, имеется
возможность распознавать ОС Linux и Solaris даже в том случае,
если сервер не осуществляет прослушивание портов.
Исследование эха в ICMP -сообщениях
Как известно, в ICMP- сообщении об ошибке должна присутствовать
часть дейтаграммы, вызвавшей эту ошибку. Эта часть состоит из
IP-заголовка дейтаграммы и первых 64-х бит данных дейтаграммы, и
называется «эхом» дейтаграммы.
Некоторые ОС используют IP-заголовок прибывшей дейтаграммы в
качестве «рабочего пространства» на начальном этапе ее обработки.
Это приводит к искажению IP-заголовка, и дейтаграмма с искаженным
заголовком отправляется как эхо ICMP-сообщения.
Различные ОС по-разному искажают заголовок дейтаграммы. Например,
ОС AIX и BSDI в IP-заголовке эха возвращают значение поля
TotalLength на 20 байт больше первоначального значения исходной
дейтаграммы. Некоторые версии ОС BSDI, FreeBSD, OpenBSD, ULTRIX и
VAXen стирают поле ID в эхо- IP заголовке.
Не смотря на то, что поле «контрольная сумма» IP-заголовка так или
иначе изменяется всвязи с изменением параметра TTL, некоторые ОС
типа AIX, FreeBSD отправляют в эхо-дейтаграмме несоответствующую
либо нулевую контрольную сумму. То же самое происходит и с
контрольной суммой в UDP- пакете.
Вцелом, возможно проведение девяти различных тестов для проверки
эха дейтаграммы в ICMP- сообщении и выявления различных
закономерностей для разных ОС.
Исследование поля Type Of Service в заголовке ICMP- сообщения
В ICMP- сообщении, наряду с уже упомянутыми признаками, можно
проанализировать поле Type Of Service (Тип сервиса, TOS).
Подавляющее большинство ОС устанавливают поле TOS=0. Однако старые
версии Linux ставят TOS=0xC0 (следует отметить, что это значение
не является указателем на какой-либо тип сервиса). Таким образом,
данный признак можно использовать совместно с другими тестами для
различения старых и новых версий Linux.
Исследование обработки фрагментов дейтаграммы
Как известно, протокол IP делит пакет на фрагменты для дальнейшей
передачи их в сеть. На практике различные ОС могут по-разному
осуществлять обработку перекрытия фрагментов. Так, некоторые ОС
заменяют старый фрагмент, прибывший без ошибок, повторно прибывшим
аналогичным. Другие ОС считают, что старый пакет имеет привилегию
над аналогичным новым и игнорируют его. Исследуя закон перекрытия
фрагментов можно сделать определенные выводы относительно типа ОС
исследуемого сервера.
Исследование поля Options заголовка TCP-пакета
Поле Options (опции) TCP-пакета является едва ли не самым важным
каналом утечки информации от хоста относительно ОС, установленной
на нем. Денное поле имеет некоторые особенности:
+ опции TCP- протокола не являются обязательными, и не все ОС
поддерживают их;
+ узнать, поддерживает ли ОС опции TCP можно, послав на сервер
запрос с указанием в соответствующем поле TCP- заголовка
некоторый набор опций (а лучше всего — полный набор). Сервер
укажет на поддержку определенных опций, установив соотв.
значение в поле Options TCP- заголовка ответа и сбросит все
остальные.
Таким образом, послав на сервер TCP- пакет с указанием следующего
набора опций:
BR> и получив от сервера ответ подобного рода
можно сделать вывод о том, что ОС сервера поддерживает опцию
MaxSegmentSize. Некоторые ОС, например, новые версии FreeBSD и
последние версии Linux 2.1.x , поддерживают все опции, другие
(например Linux 2.0.x) — лишь небольшой набор опций.
Рассматривая приведенный выше пример, можно обратить внимание на
то, что значение MaxSegmentSize (MSS) в запросе (256) отличается
от значения ответа (1024). Поэтому, если несколько ОС поддерживают
одинаковый набор опций, имеется возможность различения ОС по
значению опций.
Кроме того, из примера видно, что опция MSS в ответе стоит на
втором месте, а в запросе была указана на третьем месте. Эта
особенность используется в случае, когда разные ОС имеют
одинаковый набор опций с идентичными их значениями. При этом
возможно различение ОС по порядку следования указанных в ответе
опций.
Так, ОС Solaris возвращает:
или, кратко, NNTNWE . ОС Linux 2.1.122 возвращает MENNTNW .
Одинаковый набор опций, одни и те же значения но — разный порядок
их следования. Исследование флага DontFragment в IP-заголовке.
Многие ОС в определенных ситуациях не используют фрагментацию
пакетов, и поэтому устанавливают флаг DontFragment (DF) в
IP-заголовке отправляемой (нефрагментированной) дейтаграммы. Это
повышает производительность ОС при работе в сети всвязи с
уменьшением времени обработки передаваемых пакетов. Установив
зависимость наличия (или отсутствия) данного признака в конкретной
ситуации от типа ОС, можно в дальнейшем использовать его в одном
из тестов на определение ОС сервера.
Исследование возможности «борьбы с затоплением» SYN- пакетами
«Затопление» SYN-пакетами является достаточно известным способом
«завала» сервера, вызвав у него состояние «отказа в обслуживании».
Суть этой атаки заключается в том, что при отправлении на
некоторый открытый порт сервера определенного числа SYN-пакетов
(запрос на установление соединения) с указанием несуществующего
IP-адреса сервер перестает отвечать на все входящие на этот порт
запросы.
Большинство ОС могут успешно обработать не более 7 таких пакетов.
Однако некоторые новые версии ОС (например, новые Linux) способны
бороться с «затоплением» SYN-пакетами различными методами
(например, SYN-cookies) для предотвращения «отказа в
обслуживании».
Поэтому имеется возможность исследовать ОС сервера, послав на него
8 SYN -пакетов с указанием несуществующего IP-адреса в поле
«источник» IP- заголовка (указание ложного источника позволяет
избежать разрыва соединения между сервером и хостом) и затем
проверить возможность установления соединения с сервером по тому
порту, на который были отправлены SYN- пакеты.
Особенности ОС Windows
Несмотря на все выше перечисленные методы определения ОС сервера,
практически невозможно различить стек TCP/IP у ОС Windows 95,
Windows 98 и Windows NT всех версий, несмотря на то, что Windows
98 вышла позже Windows 95 на 4 года. Этот факт позволяет сделать
вывод о том, что стек TCP/IP, положенный в основу Windows 95, был
скопирован в Windows NT 4.0 и, может быть, слегка изменен в
Windows 98.
Поэтому атакующему, определив ОС сервера как Windows95/NT,
достаточно опробовать известные методы атаки на эти ОС (Ping of
Death, WinNuke, Teardrop, Land). Тем самым, работа сервера так или
иначе будет нарушена. Либо судить о версии системы по открытым
портам — например наврядли на 9x будет открыт 445 порт
(microsoft-ds), скроее всего это будет 2000.
Реализация метода комплексного опроса стека TCP/IP в NMAP
Рассмотрим реализацию метода исследования ОС удаленного хоста
путем комплексного опроса его TCP/IP стека, называемым иначе
методом снятия «отпечатков» стека TCP/IP и используемым в сканере
NMAP. Для определения ОС удаленного хоста, версия которой
неизвестна, необходимо иметь определенную информацию о том, как ОС
известных версий реагируют на определенные виды запросов,
описанных выше, иначе говоря — составить «отпечаток» стека TCP/IP
операционной системы. Для этого необходимо удаленный либо
локальный хост, тип и версия ОС которого заранее известны,
протестировать всеми описанными выше способами, проанализировать
результаты тестов и на основе полученных данных составить общую
характеристику (или т.н. «отпечаток») стека TCP/IP удаленного
хоста, привязав его к конкретному типу и версии ОС. Собрав
достаточно большое количество таких отпечатков (хотя можно
начинать и с одним), возможно теми же методами исследовать хост,
тип и версия ОС которого заранее неизвестна. Составив из
полученных результатов отпечаток и сопоставив его с уже
имеющимися, можно определить, какой ОС соответствует полученный
отпечаток и на основании этого сделать вывод об ОС исследуемого
хоста.
Алгоритм получения отпечатка стека TCP/IP следующий. Вначале
проводится сканирование портов удаленного хоста с целью
определения открытых портов и служб, функционирующих на
исследуемом хосте. Затем проводится несколько тестов, поэтапно
выполняющих опрос стека TCP/IP удаленного хоста с целью выявления
рассмотренных выше признаков.
На основе полученных от хоста ответов составляется отпечаток,
который затем сравнивается с уже имеющейся базой отпечатков, и
принимается решение о типе и версии ОС исследуемого хоста.
Заметим, что нет никакой разницы между алгоритмом получения
отпечатка для хоста с известной ОС и для хоста с ОС, версия
которой неизвестна. Вот пример одного из таких отпечатков,
полученного для ОС IRIX версии 6.2 — 6.4.
Для получения отпечатка было проведено 9 тестов. Далее подробно
рассмотрен каждый из них.
+ 1. Tseq ( Class = i800 ) — тест определения закона изменения
ISN хоста. Указатель Tseq определяет закон изменения ISN
сервера. Описание закона изменения ISN хранится в переменной
Class (здесь и далее значения параметров указаны для ОС IRIX;
для остальных ОС параметры те же, отличаются лишь значения).
Для ОС IRIX закон изменения ISN описан как i800 (Increment
800 ). Это означает, что каждое последующее значение ISN на
800 больше, чем предыдущее.
+ 2. T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT) — тест
определения TCP-опций. В данном тесте на открытый порт
сервера хост посылает SYN-пакет с набором TCP-опций. В
скобках записаны параметры, возвращаемые в ответе на
посланный SYN- пакет: DF = N — состояние флага DontFragment в
IP- заголовке ответа (N , т.е. 0) W = C000|EF2A — значение
поля Window в TCP- заголовке ответа (C000 либо EF2A) ACK =
S++ — значение поля ACK в TCP- заголовке ответа (S++ , т.е.
посланный хостом ISN+1) Flags = AS — состояние флагов в TCP-
заголовке ответа (должны быть установлены флаги ACK (A) и SYN
(S)) Ops = MNWNNT — набор TCP-опций (учитывается наличие
опций и порядок их следования), указанных в TCP- заголовке
ответа:
+ 3. T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) — тест обработки
NULL-пакета. На открытый порт сервера хост отправляет
«пустой» пакет с указанием TCP- опций, аналогичных
предыдущему тесту. Resp = Y — указатель, определяющий наличие
или отсутствие ответа от сервера на подобный запрос. Данный
указатель используется в том случае, когда конкретная ОС, для
которой составлен отпечаток, может не ответить на запрос,
используемый в тесте, тогда как другие ОС отвечают на
подобный запрос (это и устанавливается указателем Resp=Y/N).
В случае, если Resp не присутствует среди переменных,
подразумевается, что на подобный запрос любая ОС пошлет
ответ. Ops = — набор TCP- опций в ответе на запрос. «Пустое»
значение данной переменной означает отсутствие в ответе
каких-либо опций.
+ 4. T3(Resp=Y%DF=N%W=C000|EF2A%ACK=0%Flags=A%Ops=NNT) — тест
обработки SYN|FIN|PSH|URG- пакета. На открытый порт сервера
хост посылает пакет с указанием соотв. набора флагов и без
указания TCP- опций. Расшифровка ожидаемого ответа следующая:
ответ на запрос должен быть получен, флаг DontFragment
сброшен, поле Window=0 , значение поля ACK содержит посланный
хостом в запросе ISN, набор флагов — ACK и RST, TCP -опции в
ответе должны отсутствовать.
+ 5. T4(DF=N%W=0%ACK=0%Flags=R%Ops=) — тест обработки ACK-
пакета. На открытый порт сервера хост отправляет ACK-пакет
(здесь и далее расшифровка результатов по аналогии с
предыдущими тестами, за исключением переменных, смысл которых
объяснен по тексту).
+ 6. T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=) — тест обработки SYN-
пакета. На закрытый порт сервера хост отправляет SYN-пакет.
+ 7. T6(DF=N%W=0%ACK=0%Flags=R%Ops=) — тест обработки ACK-
пакета на закрытый порт. На закрытый порт сервера хост
отправляет ACK-пакет.
+ 8. T7(DF=N%W=0%ACK=S%Flags=AR%Ops=) — тест обработки
FIN|PSH|URG- пакета. На закрытый порт сервера хост отправляет
соответствующий пакет.
+ 9.PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%
ULEN=134%DAT=E) — тест формата ICMP- сообщения Port
Unreachable.
На закрытый порт сервера с большим номером хост отправляет запрос (TCP и
UDP- пакет), и анализируется прибывшее в ответ ICMP-сообщение Port
Unreachable (порт недоступен).
DF = N — состояние флага DontFragment в IP- заголовке ICMP- сообщения
TOS = 0 — значение поля TypeOfService в прибывшем ICMP- сообщении (равно0)
IPLEN = 38 — шестнадцатиричное значение поля TotalLength в IP- заголовке
прибывшего ICMP- сообщения (составляет 38h)
RIPTL = 148 — значение поля TotalLength в IP -заголовке эха ICMP- сообщения
(составляет 148h)
RID = E — проверка значения поля ID в IP- заголовке эха ICMP- сообщения (E-
совпадает с посланным значением, F-не совпадает)
RIPCK = E — проверка значения поля CheckSum в IP- заголовке эха ICMP-
сообщения (E- совпадает с посланным значением, F-не совпадает)
UCK = E — проверка значения поля CheckSum в UDP- заголовке (при
отправлении на сервер UDP- пакета) UDP- эха ICMP- сообщения (E- совпадает с
посланным значением, F-не совпадает)
ULEN = 134 — проверка значения поля CheckSum в UDP- заголовке UDP- эха
ICMP- сообщения ( составляет 134h)
DAT = E — проверка данных UDP- эха ICMP- сообщения (E- совпадает с
посланным значением, F-не совпадает). В общем случае, совокупность значений
переменных UCK=E, ULEN=0x134h (для IRIX) и DAT=E означает, что данные
эхо-UDP были приняты верно. Поскольку большинство ОС не отправляют
посланные в UDP-пакете данные в качестве эха, решение о его «верности»
принимается ни основании значений UCK и ULEN , а в поле DAT
устанавливается значение по умолчанию (т.е. DAT = E). ]
Passive OS fingerprinting
Пассивный OS fingerprinting базируеться на информации, присланой
удаленным хостом, когда тот пытаеться установить соединение с вашей
системой. Перехваченные параметры SYN пакета содержат достаточно
информации, чтобы идентифицировать систему удаленного хоста. Далее
идет речь не только о самой методике но и программе осуществляющей эту
методику (p0f). В отличие от активных сканеров типа nmap и queSO, p0f
делает это без того, чтобы послать что — нибудь удаленному хосту и
соответственно не может быть обнаружен IDS системой.
Примечание:
Некоторые части кода p0f в настоящее время используются IDS системами
и sniffer'ами.) Основные параметры по которым осуществляеться POF
(уникальные TCP параметры) — определенных для первого SYN пакета,
посланный удаленным хостом при установлении связи. Те параметры
включают: размер окна (wss), максимальный размер сегмента, флаг «не
фрагментировать» (DF), window scaling (wscale), sackOK флаг, nop флаг,
начальное время, время жизни (TTL), размер SYN пакета. При POF важно
правильно определять начальный TTL пакета. Обычно это равно значению в
раза 2 большее чем TTL, который вы видите, учитывая что ваш удаленный
хост не слишком далеко (если traceroute показывает больше чем 20-25
хопов, надо быть внимательным). Например, если вы видите TTL 55
возвращенном p0f, то вероятно TTL был 64. ОБРАТИТЕ ВНИМАНИЕ: лучше
оценить больше (это компенсирует маршрутизаторы которые не
отображаются в traceroute), чем недооценить (а то можно определить не
правильно или не определить вообще.
Reverse engeneering для стандартных утилит FTP сервиса
Иногда бывает так, что сложно определить какая система установлена на
удаленном хосте — в таком случае можно применить исследование самих
утилит системы. Различия есть не только в названиях функций, но и в
формате ELF файлов. Конечно же такие исследования требуют обширных
знаний об устройстве binary файлов под различные системы. Методика
вообщем выглядет таким образом — пеpекачиваться чеpез ftp файл
/bin/ls, после чего исследуется его устpойство. Если такого файла нет
или он недоступен, то либо администpатоp закpыл доступ к диpектоpии
bin, либо система не является unix-подобной и pеализует ls (список
файлов) как зауpядную комманду FTP. Что мы можем узнать из устpойства
/bin/ls? Если это ELF Binary, то очевидно мы сумеем воспользоваться
gdb (Gnu DeBug), чтобы опpеделить методы его pаботы. Одна из наиболее
хаpактеpных особенностей — системные вызовы. Для пpосмотpа диpектоpии
ls использует системный вызов getdents, однако под каждой системой он
имеет некотоpые отличия в названии (sys_getdents, o_getdents).
Например в linux используется getdents64(0x3, 0x8059ef8, 0x1000,
0x8059ef8) = 944 , а в BSD getdirentries(5, /* 0 entries */, 4096,
[2560]) = 0.это результаты исследования программой strace. Еще можно
пpовеpить платфоpменно-специфичные системные вызовы, котоpые не
употpебляются в дpугих системах. Для этого достаточно вооpужиться
таблицами системных вызовов с нескольких платфоpм и пpовести полное
сpавнение.
Как повысить вероятность определения OS
Конечно наиболее продвинутой программой для OS fingerprinting является
nmap (на момент написания этого документа вышел NMap 3.00). Но выходом
нового ядра той или иной системы или после применения некоторых
методов защиты — nmap уже не в состоянии определить тип системы,
поэтому предлагается методика которая позволяет с определенной
точностью определить систему. Для этого в программу производящую OS
fingerprinting требуется ввести классические методы, но определенной
долей доверия (так как их легче всего подделать), а также ипользовать
метод Reverse engeneering'а . Таким образом если программа не в
состоянии определить тип опрерационной системы по отпечатку TCP/IP
стека — то применяются классические и метод Reverse engeneering'а
после чего делаються соответствующие выводы о типе операционной
системы и пользователю сообщается вероятный тип исследуемой системы.
Защита от OS fingerprinting
Наиболее легко защищаться от класических методов — достаточно изменить
конфигурацию: Apache — в httpd.conf прописать Header set Server
«Apache/1.x.x PHP4 (нужная ОС)». В ProFTPd — достаточно добавить опцию
ServerIdent off. В общем случае *nix системы и ПО под них поставляется
с исходными кодами — наиболее эффективный вариант — это подправить
строки с ответами в демонах по которым производиться определение и
пересобрать их,а также подправить параметры TCP/IP стека в ядре и
пересобрать. В ОС Linux и BSD есть методы которыми можно сделать это
без исправления исходных текстов — через procfs. А вот в ОС Windows
чуть ли не единственный метод — это reverse engeneering для
winsock.dll и программ демонов.
Подробнее о procfs в Linux:
Все нужные нам настройки храняться в /proc/sys/net/ipv4. Чтобы
воспользоваться файловой системой /proc, при сборке ядра нужно
включить две опции. Опция CONFIG_PROC_FS позволяет вам получить доступ
к /proc и просматривать её, а CONFIG_SYSCTL — это та мелочь, что
позволяет вам изменять элементы /proc без необходимости перезагрузкки
системы или перекомпиляции ядра. Настройки доступны в процессе
загрузки только после того, как файловая система /proc будет
смонтирована.
Запрет ICMP echo (ping):
Отключить борьбу с SYN-flood:
Хороший прием против passive OS fingerprinting — это зпнести в /proc/sys/net/ipv4/ip_default_ttl
отличное от 64.
Скорость генерации ICMP пакетов
Вот еще несколько интересных ключиков:
Related links