новости
статьи
.save ass…

Определение операционной системы удаленного хоста

В данной статье рассмотрен метод получения информации об операционной системе удаленного хоста, использующий механизм опроса стека TCP/IP удаленного хоста. Вначале представлены некоторые классические методы определения ОС удаленного хоста. Затем рассматриваются конкретные методы воздействия на удаленный хост, по результатам которых можно сделать определенные выводы об установленной на нем ОС. Наконец, рассмотрен механизм комплексного воздействия на удаленный хост, использующий комбинацию некоторых из рассмотренных методов и реализованный в программе NMAP. И в заключении даны некоторые советы по тому, как, собственно, save свою ass от этой напасти.

введение (зачем это нужно)

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

Допустим, осуществляется попытка проникновения в удаленный хост. В результате сканирования портов было обнаружено, что 53-й порт хоста открыт. На основании данного признака можно предположить, что на хосте установлена одна из версий ОС UNIX, и выполняется одна из уязвимых версий демона bind. Если это весьма условное предположение является верным, атакующий имеет только одну попытку использовать обнаруженную "дыру", поскольку неудавшаяся попытка атаки "подвесит" демона и порт окажется закрытым, после чего атакующему придется искать новые "дыры" в безопасности удаленного хоста. В другом варианте развития событий, неудачная попытка атаки будет запротоколирована службой безопасности, таким образом дальнейшия поползновения в этом направлении могут быть сильно затруднены.

Если атакующий точно определит тип и версию ОС удаленного хоста (например, Linux kernel 2.0.35 или Solaris 2.51), он может соответствующим образом скоординировать свои действия, проанализировав информацию, касающуюся известных проблем в безопасности определенной ОС.

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

Информацию о типе и версии ОС удаленного хоста можно использовать в качестве спекулятивного средства социальной инженерии. Например, атакующий получает от удаленного хоста следующую информацию:

DataVoice TxPort PRISMA 3000 T1 CSU/DSU 6.22

Следующим его шагом может быть звонок администратору данного хоста от имени службы поддержки DataVoice и подробный рассказ о мифической "дыре" в Prisma 3000 с рекомендацией обязательной установки программы — "заплаты", "только что отправленной" по электронной почте администратору. "Заплата" на самом деле является закладкой, пересылающей атакующему все пароли системы. Как видно, информация об ОС хоста является основным оружием в руках опытного взломщика.

Впрочем, как любая медаль имеет по меньшей мере две стороны;), удаленное определение ОС может служить и вполне мирным целям. В частности, для проверки, на чем все-таки работает удаленный хостинг или шелл, который вы собираетесь приобрести. Очень многие хостинг-провайдеры ограничиваются в описании продукта общими фразами, типа “unix-hosting”. Вы купили такой хостинг, предполагая что там Linux будет, а вам AIX подсунули;) Аналогично, иногда бывает полезно проверить, на чем работает ваш провайдер доступа (ISP), поскольку сами провайдеры такой информации выдавать, как правило, не желают.

классические методы определения операционной системы удаленного хоста

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

Playground~> telnet hpux.u-aizu.ac.jp

Tryin 163.143.102.12...

Connected to hpux.uaizu.ac.jp.

Escape character is '^]'.

HP-UX hpux B.10.01.A 9000/715 (ttyp2)

login:

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

Payfones> telnet ftp.netscape.com 21

Trying 207.200.74.26...

Connected to ftp.netscape.com.

Escape character is '^]'.

220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready.

Далее, применив команду SYST, можно получить более подробную информацию:

SYST

215 UNIX Type: L8 Version SUNOS

Кроме того, если имеется доступ к FTP, атакующий может просмотреть bin-файлы в каталоге /bin/ls и определить, в какой ОС они используются.

Впрочем, тут нужно сделать оговорку, что подавляющее большинство FTP-демонов под Windows предусматривают подмену ответа на SYST на заранее предлагаемый разработчиками вариант, и обычно этот вариант — UNIX Type: L8;)

Аналогичную информацию можно получить и от веб-сервера:

Playground> echo 'GET / HTTP/1.0\n' | nc hotboot.com 80 | egrep '^Server:'

Server: Microsoft-IIS/4.0

Playground>

...и от SMTP-демонов:

220 stone.domainx.domainy.tld ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2650.21) ready

...и от POP3-демонов:

+OK WinRoute Pro 4.0 POP3 server ready 115.971953707@unspecified.host

+OK Lotus Notes POP3 server version X1.0 ready on postserver/sovrep.gov.by

... и даже вот так бывает:

+OK Сервер Microsoft Exchange POP3 версии 5.5.2650.23 готов

В вышеописанных примерах с веб- и SMTP/POP3-серверами вывод о типе ОС напрашивается изходя из предпосылки, что ни IIS, ни Exchange, ни WinRoute на UN*X-системах обычно не живут;)

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

метод опроса стека TCP/IP удаленного хоста

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

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

В дальнейшем, исследуя реакцию сервера с неизвестной ОС, с использованием накопленной статистики можно определить не только тип, но и версию установленной на сервере ОС. Например, возможно точно отличить Solaris 2.4 от Solaris 2.50 или Linux kernel version 2.0.30 (для всех Linux далее указывается версия ядра) от Linux 2.0.35.

Рассмотрим более подробно основные методы исследования ОС сервера.

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-сообщения "порт недостижим" (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-пакет с указанием следующего набора опций:

<WindowScale=10><NOOP><MaxSegmentSize=256><TimeStamp><EndOfOptions>

и получив от сервера ответ подобного рода

<NOOP><MaxSegmentSize=1024><NOOP><NOOP><EndOfOps>

можно сделать вывод о том, что ОС сервера поддерживает опцию MaxSegmentSize.

Некоторые ОС, например, новые версии FreeBSD и последние версии Linux (начиная с ядер 2.1.x), поддерживают все опции, другие (например Linux 2.0.x) — лишь небольшой набор опций.

Рассматривая приведенный выше пример, можно обратить внимание на то, что значение MaxSegmentSize (MSS) в запросе (256) отличается от значения ответа (1024). Поэтому, если несколько ОС поддерживают одинаковый набор опций, имеется возможность различения ОС по значению опций.

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

Так, ОС Solaris возвращает:

<NOOP><NOOP><TimeStamp><NOOP><WindowScale><EchoedMSS>

или, кратко, NNTNWE. Все попадавшиеся ОС Linux от 2.1.122 до 2.2.15 возвращают MENNTNW. Одинаковый набор опций, одни и те же значения, но — разный порядок их следования.

Исследование флага DontFragment в IP-заголовке

Многие ОС в определенных ситуациях не используют фрагментацию пакетов и поэтому устанавливают флаг DontFragment (DF) в IP-заголовке отправляемой (нефрагментированной) дейтаграммы. Это повышает производительность ОС при работе в сети в связи с уменьшением времени обработки передаваемых пакетов. Установив зависимость наличия (или отсутствия) данного признака в конкретной ситуации от типа ОС, можно в дальнейшем использовать его в одном из тестов на определение ОС сервера.

Исследование возможности борьбы с затоплением SYN-пакетами

Затопление SYN-пакетами (SYN-flood) является достаточно известным способом "завала" сервера, вызвав у него состояние "отказа в обслуживании". Суть этой атаки заключается в том, что при отправлении на некоторый открытый порт сервера определенного числа 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). Тем самым, при отсутствии нужных заплат и сервиспаков, работа сервера так или иначе будет нарушена. Windows 2000, имеющая значительно усовершенствованный стек TCP/IP, распознается легко.

как это делает NMAP

Рассмотрим реализацию метода исследования ОС удаленного хоста путем комплексного опроса его TCP/IP стека, называемого иначе методом снятия "отпечатков" (fingerprinting) стека TCP/IP и используемого в сканере NMAP (www.insecure.org/NMAP).

Для определения ОС удаленного хоста, версия которой неизвестна, необходимо иметь определенную информацию о том, как ОС известных версий реагируют на определенные виды запросов, описанных выше, иначе говоря — составить "отпечатки" стека TCP/IP различных операционных систем.

Для этого необходимо удаленный либо локальный хост, тип и версия ОС которого заранее известны, протестировать всеми описанными выше способами, проанализировать результаты тестов и на основе полученных данных составить общую характеристику (или т.н. "отпечаток") стека TCP/IP удаленного хоста, привязав его к конкретному типу и версии ОС.

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

Алгоритм получения отпечатка стека TCP/IP следующий. Вначале проводится сканирование портов удаленного хоста с целью определения открытых портов и служб, функционирующих на исследуемом хосте. Затем проводится несколько тестов, поэтапно выполняющих опрос стека TCP/IP удаленного хоста с целью выявления рассмотренных выше признаков.

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

Заметим, что нет никакой разницы между алгоритмом получения отпечатка для хоста с известной ОС и для хоста с ОС, версия которой неизвестна. Вот пример одного из таких отпечатков, полученного для ОС IRIX версии 6.2 — 6.4.

FingerPrint IRIX 6.2 — 6.4

Tseq(Class=i800)

T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)

T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

T3(Resp=Y%DF=N%W=C000|EF2A%ACK=0%Flags=A%Ops=NNT)

T4(DF=N%W=0%ACK=0%Flags=R%Ops=)

T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(DF=N%W=0%ACK=0%Flags=R%Ops=)

T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)

PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Для получения отпечатка было проведено 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-заголовке ответа:

<MSS><NOOP><WindowScale><NOOP><NOOP><TimeStamp>

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).

а как с этим бороться?

Итак, мы разобрались, какую опасность таит в себе удаленное определение ОС (и версий “демонических” софтов), были описаны и все наиболее популярные техники добычи такого рода информации. Ну а теперь резонный вопрос: а что делать администратору, чтобы выкрутиться из ситуации?

Вообще-то, в деле обеспечения безопасности “заметание следов” есть вторая по действенности техника после защиты по периметру (что есть тот самый лом, против которого практически нет приемов;) А действенна она потому, что большинство современных “хак0ров” ограничивается в своих поползновениях что-то поломать следующей простой тактикой: выяснить что у врага за ОС и найти эксплойты под нее и использующиеся на ней демоны. Причем практика показывает, что мыслит народ строго прямолинейно: если серверная платформа — WinNT, то и IIS в полном объеме там найдется, и Exchange;). Аналогично, предполагается сцепка UN*X — Apache — Sendmail — wu-FTPd.

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

С первым дело обстоит относительно просто. Некоторые пакеты предполагают замену соответсвующих строк в конфигурационных файлах. Например, системное приглашение при входе в Linux-систему хранится в файлах /etc/issue и /etc/issue.net, приветствие Sendmail можно поменять в следующем разделе /etc/sendmail.conf

# SMTP initial login message (old $e macro)

O SmtpGreetingMessage=$j Sendmail $v/$Z; $b

Однако большинство производителей ПО все-таки не предусматривают “легких путей” по переиначиванию системных приглашений и других строк, содержащих такого рода информацию. И тут остается 2 метода. Для пакетов, распространяемых с исходным кодом, самое простое — залезть в исходник и поправить то, что вам нужно. В остальных случаях, как бы и стремно и спорно не звучала моя рекомендация — советую попробовать пропатчить исполняемые файлы: если подходить к делу с умом, в подавляющем случае срабатывает;)

Кстати, отвлекаясь от основной темы повествования, приведу вам еще один пример одурачивания ближнего своего. Допустим, вы решили заняться shell-провайдингом и не очень хотели бы, чтобы ваши клиенты экспериментировали на системе со всякими там эксплойтами и тому подобным. В качестве примера предположим, что вы выбрали в качестве платформы Linux. Информация о типе и версии ОС содержится в системных переменных ядра ostype, osversion, osrelease (ищите в /proc/sys/kernel/). По умолчанию изменять эти значения нельзя (на них вы увидите права доступа 444, что означает, что даже руту писать туда ничего нельзя). Но если очень хочется...;) Лезьте в исходники ядра, в файлик sysctl.c — и вы найдете то, что нужно. Правьте, пересобирайте ядро и можно начинать пугать юзеров странными ответами на команду uname —a;)

Главное после этого не пускать пользователей дальше их домашнеего каталога, потому как опытный UN*Xоид всегда распознает тип ОС при “поверхностном осмотре”.

С подделкой отпечатков дело обстоит куда сложнее, поскольку потребуется “оперативное вмешательство” в реализацию стека TCP/IP. Однако кое-что сделать все-таки можно. Рассмотрим для примера все тот же Linux. Часть параметров TCP/IP можно настраивать с помощью Sysctl, меняя значение переменных ядра, связанных с сетевыми делами. Подробно эти переменные были рассмотрены в “СР” № 7(8) в статье “Ядерные тайны IP”. Так вот, бегло просмотрев список выполняемых NMAP тестов (предположим для начала, что ваш враг будет пользоваться именно им), замечаем, что изменение значений переменных tcp_window_scaling и tcp_timestamps могут теоретически привести к обдуриванию NMAP* в тесте номер 2 (опции TCP). Вот вам пример для ядра 2.2.15:

было:

Remote operating system guess: Linux 2.1.122 — 2.2.16

OS Fingerprint:

T1(Resp=Y%DF=Y%W=7F53%ACK=S++%Flags=AS%Ops=MENNTNW)

T2(Resp=N)

T3(Resp=Y%DF=Y%W=7F53%ACK=S++%Flags=AS%Ops=MENNTNW)

T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

при tcp_window_scaling —> 0

No exact OS matches for host (If you know what OS is running on it, see http://w

ww.insecure.org/cgi-bin/NMAP-submit.cgi).

TCP/IP fingerprint:

T1(Resp=Y%DF=Y%W=7F53%ACK=S++%Flags=AS%Ops=MENNT)

T2(Resp=N)

T3(Resp=Y%DF=Y%W=7F53%ACK=S++%Flags=AS%Ops=MENNT)

T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

при tcp_timestamps —> 0

Remote operating system guess: Linux 2.2.12

OS Fingerprint:

T1(Resp=Y%DF=Y%W=7F53%ACK=S++%Flags=AS%Ops=MENW)

T2(Resp=N)

T3(Resp=Y%DF=Y%W=7F53%ACK=S++%Flags=AS%Ops=MENW)

T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T7(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Сразу оговорюсь, этот пример не есть руководство к действию, поскольку вы должны сами для себя осознавать, для чего именно нужны эти опции, и есть ли смысл прятаться от врагов такой ценой. Сразу скажу, что больше переменных Sysctl, изменение значений которых приведет к одурачиванию именно NMAP в ядре нет;) Однако на то оно и open source, чтобы более извращенные параноики, обезображенные интеллектом и знанием языка СИ, смогли внести в ядро и более радикальные изменения;)

Совершенно банально обдуривается NMAP при изменении дефолтового значения TCP-окна. Особенно это касается распознавания ОС Windows;) Добавляете в HKLM/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters DWORD value под названием TcpWindowSize и пихаете туда то, что считаете нужным. NMAP в печали;)

Например, было:

Remote operating system guess: Windows NT4 / Win95 / Win98

OS Fingerprint:

T1(Resp=Y%DF=Y%W=2017%ACK=S++%Flags=AS%Ops=M)

T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

T3(Resp=Y%DF=Y%W=2017%ACK=S++%Flags=AS%Ops=M)

T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)

PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

а стало:

No OS matches for host (see http://www.insecure.org/cgi-bin/NMAP-submit.cgi).

TCP/IP fingerprint:

T1(Resp=Y%DF=Y%W=FFFF%ACK=S++%Flags=AS%Ops=M)

T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

T3(Resp=Y%DF=Y%W=FFFF%ACK=S++%Flags=AS%Ops=M)

T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)

T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)

PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Все, в общем-то, почти одно и то же, а результат — налицо. Что еще можно нахомутать в OC Windows, затрудняюсь сказать.

Одним словом, пробуйте, сражайтесь, прячьтесь и выкручивайтесь насколько изобретательности хватит. Как говаривали знакомые админы, if we are paranoid, are we paranoid ENOUGH? Однако, повторюсь: главное при этом четко осознавать — что именно вы делаете и что вам за это будет;) А то от паранойи, знаете ли, и до маразма недалеко;)

Alice D. Saemon, alice@nestor.minsk.by 

За основу положена одноименная статья автора NMAP — Fyodor’а, fyodor@insecure.org в переводе Алексея Волкова, topcat@nm.ru
Выражаю благодарность Ghost//Necrosoft за помощь в тестировании и издевательствах над ядром Linux.

* Все тесты проводились на NMAP V. 2.54BETA7
обсудить статью

© сетевые решения
.
.