Исследование удаленных хостов с помощью hping
 

Целью этой статьи является обзор некоторых методов, которые могут быть эффективно использованы для исследования удаленных хостов. Кое-что на эту тему уже публиковалось в «Сетевых Решениях», однако, во-первых, это было давно, и, во-вторых, в тех публикациях упор делался на использование nmap и эвристические техники на основе изучения баннеров работающих сервисов.

Предполагается, что читатель понимает основные идеи host fingerprinting и знаком с принципами функционирования протоколов TCP/IP. Мы рассмотрим методы снятия отпечатков как сервисов, слушающих порт, так и операционных систем в различных защищенных МСЭ средах и попытаемся выяснить преимущества и недостатки различных способов. Знакомство с hping и nmap очень пригодится для понимания изложенного материала.

введение

Удаленное снятие отпечатков - это процесс идентификации операционной системы хоста и сетевых служб, прослушивающих определенные порты, по сети. Обычно это производится различными способами активного и пассивного сканирования, путем отправки некоторого количества пакетов и анализа ответов. Вообще, общедоступные утилиты, в том числе и nmap, довольно неплохо выполняют сканирование и определение версии удаленной ОС. Но в тех случаях, когда хост находится за межсетевым экраном, эти утилиты мало чем могут помочь, либо выдают неоднозначные или неверные результаты. Это особенно справедливо для машин, трафик которых серьезно фильтруется МСЭ и которым разрешено принимать и отправлять очень небольшое количество типов пакетов. В этих случаях нам нужно использовать другие методы для правильного определения состояния удаленной машины. Мы рассмотрим некоторые из них, включая RING- и ICMP-сканирование. В первом разделе рассматриваются различные методы сканирования портов, тогда как вторая часть пытается пролить свет на снятие отпечатка операционной системы.

сканирование портов

Начнем с основных методик сканирования портов, с использованием таких утилит, как nmap и hping. Вначале мы обсудим общеизвестное SYN- и SYNACK- сканирование и поведение различных хостов при приеме таких TCP-пакетов. Затем рассмотрим, как различаются результаты сканирования машин находящихся за МСЭ и тех, чей трафик не фильтруется. После этого мы обратим внимание на некоторые продвинутые техники, включая FIN-сканирование и UDP-сканирование хостов, находящихся за МСЭ.

hping

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

nmap

Network Mapper (nmap) это известная утилита для исследования сетей, которую можно использовать для сканирования портов и определения удаленной ОС. Широкий функционал утилиты включает в себя пассивное и idle-сканирование, хотя возможность отправки произвольных пакетов отсутствует.
cканирование с установлением наполовину открытого соединения (SYN)

Идея сканирования с установлением наполовину открытого соединения (также известного как SYN-сканирование) очень проста. Отсылается SYN-пакет и ожидается ответ. Если в ответ получено SYN ACK, это означает, что удаленный порт открыт, в противном случае, если получен пакет с флагом RST, порт закрыт. Как вы пониматете, техника предполагает, что трехэтапное установление TCP-соединения не производится.

фильтрованные и закрытые порты

Однако межсетевой экран может просто заблокировать доступ к каким-то открытым портам. В этих случаях говорят, что порт фильтрован. При таком раскладе мы никогда не получим ответ на наш SYN-пакет. Также многие МСЭ блокируют RST-пакеты, являющиеся «ответом от закрытого порта». В таких ситуациях сложно понять, какие порты закрыты, а какие фильтрованы. Ниже приводятся результаты сканирования с помощью nmap хоста без МСЭ.

Как можно заметить, данный хост не похож на находящийся за МСЭ. Мы просканировали порты 1, 2, 21, 80, и установили, что порты 1 и 2 закрыты, а оставшиеся два открыты. Рассмотрим другой пример.

Вы можете заметить, что первые два порта (1, 2) теперь помечены как filtered. По этим данным вы не можете определить, закрыты или открыты порты 1 и 2. Единственная доступная информация - это то, что порт фильтрован. Однако, как мы знаем, все закрытые порты, если они не фильтрованы, при нормальных обстоятельствах должны отсылать RST-пакет. Попробуем с помощью hping послать несколько произвольных пакетов на часто используемые порты и посмотреть на результат.

Я использовал команду hping -S -p 80 -c 2 209.41.165.180 для отправки двух пакетов с установленным SYN-флагом на 80 порт, в ответ на которые мы получили два пакета с флагом SA, означающим подтверждение нашей попытки создания соединения (SYN acknowledgement). DF указывает на то, что установлен бит «do not fragment». Теперь вернемся к нашей предыдущей проблеме и отправим два таких же пакета на порт 1.

В данном случае мы не получили ответа, что подтверждает то, что порт фильтруется МСЭ и любые типы ответов этого порта блокируются. Теперь отправим тот же пакет еще на несколько других портов.

Я попросил hping отослать по одному SYN-пакету на каждый порт, начиная с 20. Мы можем заметить, что некоторые ответные пакеты имеют флаг RA (Reset Acknowledged), что указывает на то, что эти порты закрыты, а не фильтрованы. Так как мы не получили ответов с портов 20, 24, 26-48, можно сделать вывод, что эти порты заблокированы межсетевым экраном. Таким образом, это может указывать на то, что данные порты также закрыты. МСЭ может быть настроен так, что все часто используемые порты не будут фильтроваться. Как мы видим, порт 443 (который используется для https и обычно открыт) отвечает RST-пакетом, что говорит нам о том, https-сервис не запущен и не блокируется.

тестирование с помощью FIN-пакетов

Метод основан на том, что если закрытый порт получает пакет с установленным флагом FIN, при нормальных условиях он ответит RST-пакетом. Открытые порты не отвечают на FIN-пакеты. Это может пригодиться в тех случаях, когда SYN-пакеты блокируются межсетевым экраном. Однако это не применимо при сканировании Windows-компьютеров вследствие того, что они никогда не отвечают на FIN-пакеты. Давайте создадим два хоста в VMWare. На один из хостов установим Linux, а с другого будем отправлять FIN-пакеты. Начнем с того, что заблокируем весь нормальный SYN-трафик на Linux-хосте. Чтобы заблокировать все входящие пакеты с установленным флагом SYN, мы воспользуемся iptables.
iptables

Iptables – это основная утилита ОС Linux, используемая для фильтрации сетевых пакетов. Iptables организует правила файрволла в виде так называемых таблиц (есть 3 встроенные таблицы, но можно добавить и свои), каждая из которых содержит некоторые заранее определенные цепочки (chains). Таблица filter отвечает за фильтрацию (блокирование или разрешение) и содержит три встроенные цепочки, названные INPUT, OUTPUT и FORWARD.
Таким образом, для блокирования всех TCP-пакетов с установленным флагом SYN, нам всего лишь нужно добавить соответствующее правило в цепочку INPUT.

Теперь начнем тестирование и отправим несколько FIN-пакетов с Windows-машины (в данном случае я использовал версию hping для Windows, запущенную на Windows 2000). По умолчанию наш Linux-хост прослушивает порты 21, 22 и 80.
Ниже приведены результаты отправки SYN-пакетов на порт 80.

Как мы видим, все 10 отправленных пакетов были потеряны. Если мы попробуем отправить SYN-пакеты на закрытый порт, получим тот же результат.

Теперь попробуем отправить пакеты с флагом FIN.

В результате отправки FIN-пакетов на закрытый порт, ранее не отвечавший, мы получили пакеты с флагом RA, что является индикатором того, что порт закрыт. Читатель может проверить, те же самые пакеты на порты 21, 22 и 80 не имеют ответов, что доказывает то, что они открыты, тогда как все другие порты отвечают RA.

UDP-порты

Сканирование UDP портов – непростое занятие из-за ненадежности получаемых результатов. Стандартный способ состоит в отправке пакетов на UDP- порты и идентификации открытых портов на основании того, что обычно от закрытых портов приходит ICMP-сообщение «Port Unreachable». Однако, не факт, что во всех случаях вы получите такой ответ.
Ниже показан результат сканирования UDP-портов с помощью nmap.

Полученные результаты не кажутся интересными, так как nmap не смог определить, какие порты открыты, а какие фильтрованы или закрыты. По результатам сканирования все три порта или открыты или фильтрованы, что является неверной информацией.
Так как сканируемый хост – DNS-сервер, высока вероятность того, что его 53 UDP-порт открыт для DNS-запросов. Попробуем просканировать его с помощью hping. Применив стандартный метод UDP-сканирования, мы также не получили ответа.

Изменим нашу стратегию. Для начала создадим простой текстовой файл произвольного содержания, размером примерно 120 байт, и снова просканируем хост, используя этот файл в качестве полезной нагрузки каждого пакета. Одновременно запустим tcpdump в promisc-режиме для просмотра всего сетевого трафика.

Как легко догадаться, для дальнейшего анализа мы будем использовать вывод tcpdump.

Обратите внимание на то, что, приняв наши данные, 53 UDP порт ответил сообщением об ошибке, что говорит нам о том, что этот порт открыт. Ответов на все остальные пакеты не было. Другой способ сканирования состоит в проверке ответных ICMP сообщений. Обычно, при отправке пакетов без полезной нагрузки на закрытый UDP-порт, система отвечает ICMP-сообщением Port Unreachable. Открытые порты на такие пакеты не отвечают. Это продемонстрировано в следующем примере.

Как вы могли заметить, я отправил три пакета на 11 UDP-порт и получил три ICMP-сообщения Port Unreachable. Такие исходящие пакеты обычно блокируются межсетевым экраном, но в предыдущем примере мы показали способ обхода правил МСЭ.

снятие «отпечатка пальцев» ОС

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

пассивное снятие отпечатков

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

активное снятие отпечатков

При активном снятии отпечатков на целевой хост отправляются произвольные пакеты и делается попытка определения ОС на основании таких значений полей заголовка ответных TCP/IP-пакетов, как временные характеристики или IPID, TOS, TCP ISN, флаг фрагментации и т. д. Другой старый метод определения удаленной ОС состоит в анализе значения TTL ICMP echo-пакета. Это простой способ, однако он не может выявить различия разных вариантов одной и той же ОС, например Windows 98, XP и 2000.

Обычно в каждой ОС установлено фиксированное, заранее определенное, значение TTL. В операционных системах Microsoft это значение по умолчанию равно 128, тогда как в Linux - 256. Ниже показан пример определения удаленной ОС по значению TTL ответного ICMP echo пакета. Я просто пингую целевую машину и проверяю значение TTL полученного в ответ пакета. В данном случае оно равно 113, что позволяет предположить, что удаленная ОС принадлежит к семейству Windows, так как стартовое значение TTL этих систем равно 128, а маршрут от моей машины до целевой составляет примерно 15 промежуточных хостов (113 + 15 = 128), что может быть проверено с помощью traceroute.

Нужно учитывать, что это не самый надежный метод. Если целевой хост является маршрутизатором или находится за NAT (Network Address Translation), описанный способ потерпит неудачу. Не вдаваясь в подробности известных методик снятия отпечатка удаленной ОС, используемых в утилитах типа nmap, я опишу способ, сложный в реализации, но дающий хорошие результаты по опознаванию удаленной ОС. Этот способ известен как RING scan и имеет программную реализацию. Суть методики в отправке произвольных SYN-пакетов на открытый порт и ожидании SYN ACK пакетов. После получения SYN ACK пакета, он молча блокируется, что заставляет удаленный хост заново переслать его по истечению таймаута. Вычисляя задержку между такими SYN ACK пакетами для различных хостов, вы можете собрать статистику задержек для различных операционных систем. Эти данные можно эффективно использовать для опознавания ОС, имеющих сходный тип TCP стека и находящихся за МСЭ, например FreeBSD и Windows 2000, в которых используется одинаковый тип TCP стека. Я привожу пример, в котором nmap не смог верно определить ОС на двух хостах, ошибочно приняв обе за FreeBSD по той причине, что один из хостов находился за межсетевым экраном.

Сканируем первый хост (202.83.174.99):

Данные другого хоста (202.83.162.27):

Теперь попробуем применить описанную выше SYN ACK методику. Для начала мы должны настроить локальный МСЭ на тихое блокирование всех SYN ACK пакетов, приходящих с удаленного хоста.

Теперь отправим SYN пакет на открытый 80 порт и начнем слежение за выводом tcpdump.

Разница во времени, между получением SYN ACK пакетов составляет примерно 2, 4, 5, 7 и 10 секунд.
Теперь проделаем те же действия над первым хостом, для которого достоверно известно, что на нем запущена ОС FreeBSD. Ниже приводится вывод tcpdump.

В данном случае разница во времени составляет примерно 4, 5, 12 и 24 секунды, причем после четвертого полученного SYN ACK пакета их отправка закончилась. Эксперименты с другими хостами показали, что задержки повторной передачи SYN ACK пакетов системы FreeBSD составляют примерно 3, 6, 12, 24 секунды, а Windows-хостов соответственно 2, 4, 6, 8, 10 секунд. Это информация может быть полезной для правильного опознавания операционной системы в тех случаях, когда другие методы терпят неудачу и дают неверные результаты. Обратите внимание на то, что представленные выше значения не очень точны и были получены в результате опытов с двумя хостами, на одном из которых установлена Windows 2000, а на другом FreeBSD 4.6. Исследовав несколько десятков хостов можно получить более точные данные. Описанная методика имеет несколько производных от нее, например, вместо проверки времени задержки ответных SYN ACK пакетов, можно продолжить стандартное трехфазовое TCP соединение, а затем закрыть его, отослав FIN пакет, но при этом не отправлять никаких подтверждений на ответные FIN ACK пакеты:
И так далее..
Первый хост (Host1) не отправляет ответов на FIN ACK пакеты второго хоста (Host2). Кроме этого, можно еще использовать RST-пакеты.

заключение

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

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

Из журнала "Сетевые решения"

FraiDex, спасиб за хорошую статью, наконец-то разобрался, в этих syn, fin-сканированиях.)