FraiDex
09.01.2008, 18:05
Целью этой статьи является обзор некоторых методов, которые могут быть эффективно использованы для исследования удаленных хостов. Кое-что на эту тему уже публиковалось в «Сетевых Решениях», однако, во-первых, это было давно, и, во-вторых, в тех публикациях упор делался на использование 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 хоста без МСЭ.
root@life# nmap –P0 –p 1,2,21,80 202.83.174.99
Interesting ports on (202.83.174.99):
PORT STATE SERVICE
1/tcp closed tcpmux
2/tcp closed compressnet
21/tcp open ftp
80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 1.140 seconds
Как можно заметить, данный хост не похож на находящийся за МСЭ. Мы просканировали порты 1, 2, 21, 80, и установили, что порты 1 и 2 закрыты, а оставшиеся два открыты. Рассмотрим другой пример.
root@life# nmap –P0 –p 1,2,21,80 209.41.165.180
Interesting ports on (209.41.165.180):
PORT STATE SERVICE
1/tcp filtered tcpmux
2/tcp filtered compressnet
21/tcp open ftp
80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 4.047 seconds
Вы можете заметить, что первые два порта (1, 2) теперь помечены как filtered. По этим данным вы не можете определить, закрыты или открыты порты 1 и 2. Единственная доступная информация - это то, что порт фильтрован. Однако, как мы знаем, все закрытые порты, если они не фильтрованы, при нормальных обстоятельствах должны отсылать RST-пакет. Попробуем с помощью hping послать несколько произвольных пакетов на часто используемые порты и посмотреть на результат.
root@life# hping -S -p 80 -c 2 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=44 ip=209.41.165.180 ttl=63 DF
id=62648 sport=80 flags=SA seq=0
win=65535 rtt=2359.0 ms
len=44 ip=209.41.165.180 ttl=63 DF
id=63296 sport=80 flags=SA seq=1
win=65535 rtt=1359.0 ms
--- 209.41.165.180 hping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1359.0/1859.0/2359.0 ms
Я использовал команду hping -S -p 80 -c 2 209.41.165.180 для отправки двух пакетов с установленным SYN-флагом на 80 порт, в ответ на которые мы получили два пакета с флагом SA, означающим подтверждение нашей попытки создания соединения (SYN acknowledgement). DF указывает на то, что установлен бит «do not fragment». Теперь вернемся к нашей предыдущей проблеме и отправим два таких же пакета на порт 1.
root@life# hping -S -p 1 -c 2 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
--- 209.41.165.180 hping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
В данном случае мы не получили ответа, что подтверждает то, что порт фильтруется МСЭ и любые типы ответов этого порта блокируются. Теперь отправим тот же пакет еще на несколько других портов.
root@life# hping -S -p ++20 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=44 ip=209.41.165.180 ttl=108 DF
id=9352 sport=21 flags=SA seq=1
win=16616 rtt=1062.0 ms
len=40 ip=209.41.165.180 ttl=108
id=10442 sport=22 flags=RA seq=2
win=0 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=11643 sport=23 flags=RA seq=3
win=0 rtt=562.0 ms
len=44 ip=209.41.165.180 ttl=108 DF
id=13778 sport=25 flags=SA seq=5
win=16616 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=40085 sport=49 flags=RA seq=29
win=0 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=40941 sport=50 flags=RA seq=30
win=0 rtt=562.0 ms
Я попросил hping отослать по одному SYN-пакету на каждый порт, начиная с 20. Мы можем заметить, что некоторые ответные пакеты имеют флаг RA (Reset Acknowledged), что указывает на то, что эти порты закрыты, а не фильтрованы. Так как мы не получили ответов с портов 20, 24, 26-48, можно сделать вывод, что эти порты заблокированы межсетевым экраном. Таким образом, это может указывать на то, что данные порты также закрыты. МСЭ может быть настроен так, что все часто используемые порты не будут фильтроваться. Как мы видим, порт 443 (который используется для https и обычно открыт) отвечает RST-пакетом, что говорит нам о том, https-сервис не запущен и не блокируется.
root@life#hping -S -p 443 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=40 ip=209.41.165.180 ttl=108
id=40924 sport=443 flags=RA seq=0
win=0 rtt=238.0 ms
тестирование с помощью 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.
life1# iptables –A INPUT –p tcp –tcpflags SYN –j DROP
Теперь начнем тестирование и отправим несколько FIN-пакетов с Windows-машины (в данном случае я использовал версию hping для Windows, запущенную на Windows 2000). По умолчанию наш Linux-хост прослушивает порты 21, 22 и 80.
Ниже приведены результаты отправки SYN-пакетов на порт 80.
E:\hping>hping –S –p 80 –c 10 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): S set, 40 headers + 0
data bytes
--- LIFE1 hping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Как мы видим, все 10 отправленных пакетов были потеряны. Если мы попробуем отправить SYN-пакеты на закрытый порт, получим тот же результат.
E:\hping>hping –S –p 50 –c 10 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): S set, 40 headers + 0
data bytes
--- LIFE1 hping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Теперь попробуем отправить пакеты с флагом FIN.
E:\hping>hping –F –p 50 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): F set, 40 headers + 0
data bytes
len=40 ip=202.83.174.99 ttl=56
id=30859 sport=50 flags=RA seq=0
win=0 rtt=24.0 ms
len=40 ip=202.83.174.99 ttl=56
id=30863 sport=50 flags=RA seq=1
win=0 rtt=14.0 ms
В результате отправки FIN-пакетов на закрытый порт, ранее не отвечавший, мы получили пакеты с флагом RA, что является индикатором того, что порт закрыт. Читатель может проверить, те же самые пакеты на порты 21, 22 и 80 не имеют ответов, что доказывает то, что они открыты, тогда как все другие порты отвечают RA.
UDP-порты
Сканирование UDP портов – непростое занятие из-за ненадежности получаемых результатов. Стандартный способ состоит в отправке пакетов на UDP- порты и идентификации открытых портов на основании того, что обычно от закрытых портов приходит ICMP-сообщение «Port Unreachable». Однако, не факт, что во всех случаях вы получите такой ответ.
Ниже показан результат сканирования UDP-портов с помощью nmap.
root@life#nmap -sU -p 21,53,80 yns1.yahoo.com
Interesting ports on 66.218.71.205:
PORT STATE SERVICE
21/udp open|filtered ftp
53/udp open|filtered domain
80/udp open|filtered http
Nmap finished: 1 IP address (1 host up) scanned in 3.141 seconds
Полученные результаты не кажутся интересными, так как nmap не смог определить, какие порты открыты, а какие фильтрованы или закрыты. По результатам сканирования все три порта или открыты или фильтрованы, что является неверной информацией.
Так как сканируемый хост – DNS-сервер, высока вероятность того, что его 53 UDP-порт открыт для DNS-запросов. Попробуем просканировать его с помощью hping. Применив стандартный метод UDP-сканирования, мы также не получили ответа.
root@life#hping -2 -p 50++ yns1.yahoo.com
HPING yns1.yahoo.com (WAN (PPP/SLIP) Interface 66.218.71.205): udp mode
set, 28 headers + 0 data bytes
6 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Изменим нашу стратегию. Для начала создадим простой текстовой файл произвольного содержания, размером примерно 120 байт, и снова просканируем хост, используя этот файл в качестве полезной нагрузки каждого пакета. Одновременно запустим tcpdump в promisc-режиме для просмотра всего сетевого трафика.
root@life/tmp#tcpdump
root@life#hping -2 -p ++50 -d 120 –E file.txt yns1.yahoo.com
HPING yns1.yahoo.com (WAN (PPP/SLIP) Interface 66.218.71.205): udp mode
set, 28 headers + 120 data bytes
len=46 ip=66.218.71.205 ttl=49
id=37187 seq=3 rtt=531.0 ms
Как легко догадаться, для дальнейшего анализа мы будем использовать вывод tcpdump.
root@life#tcpdump
tcpdump: listening on \Device\NPF_GenericDialupAdapter
00:42:50.484375 IP life.2950 > yns1.yahoo.com.50: UDP, length 120
00:42:51.484375 IP life.2951 > yns1.yahoo.com.51: UDP, length 120
00:42:52.484375 IP life.2952 > yns1.yahoo.com.52: UDP, length 120
00:42:53.484375 IP life.2953 > yns1.yahoo.com.53: 24930 updateM+
[b2&3=0x6364][24930a] [25958q] [25444n] [25958au][|domain]
00:42:53.953125 IP yns1.yahoo.com.53 > life.2953: 24930 updateM FormErr- [0q] 0 /0/0 (12)
00:42:53.953125 IP life > yns1.yahoo.com: ICMP life udp port 2953 unreachable, length 36
00:42:54.484375 IP life.2954 > yns1.yahoo.com.54: UDP, length 120
Обратите внимание на то, что, приняв наши данные, 53 UDP порт ответил сообщением об ошибке, что говорит нам о том, что этот порт открыт. Ответов на все остальные пакеты не было. Другой способ сканирования состоит в проверке ответных ICMP сообщений. Обычно, при отправке пакетов без полезной нагрузки на закрытый UDP-порт, система отвечает ICMP-сообщением Port Unreachable. Открытые порты на такие пакеты не отвечают. Это продемонстрировано в следующем примере.
root@life#hping -2 -p 11 –c 3 202.179.137.59
HPING 202.179.137.59 (WAN (PPP/SLIP) Interface 202.179.137.59): udp mode
set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=202.179.137.59
ICMP Port Unreachable from ip=202.179.137.59
ICMP Port Unreachable from ip=202.179.137.59
--- 202.179.137.59 hping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Как вы могли заметить, я отправил три пакета на 11 UDP-порт и получил три ICMP-сообщения Port Unreachable. Такие исходящие пакеты обычно блокируются межсетевым экраном, но в предыдущем примере мы показали способ обхода правил МСЭ.
снятие «отпечатка пальцев» ОС
Идентификация систем, находящихся за МСЭ, усложнено из-за того, что межсетевой экран может изменять TCP/IP-пакеты, вводя в заблуждения исследователя системы. Методы снятия отпечатков пальцев ОС (fingerprinting) подразделяются на пассивные и активные.
пассивное снятие отпечатков
В случае пассивного снятия отпечатков на целевой хост не отправляется никаких пакетов. Вместо этого используется некоторый промежуточный хост (компьютер-зомби) и делается попытки определить ОС целевого хоста, подсчитывая разницу между значениями IPID. Этот метод известен как idle scan. Также попытаться определить целевую ОС можно, получив доступ к входящему и исходящему трафику целевого хоста каким-либо другим способом. Не рассматривая эти способы, давайте сразу перейдем к активному методу.
Предполагается, что читатель понимает основные идеи 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 хоста без МСЭ.
root@life# nmap –P0 –p 1,2,21,80 202.83.174.99
Interesting ports on (202.83.174.99):
PORT STATE SERVICE
1/tcp closed tcpmux
2/tcp closed compressnet
21/tcp open ftp
80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 1.140 seconds
Как можно заметить, данный хост не похож на находящийся за МСЭ. Мы просканировали порты 1, 2, 21, 80, и установили, что порты 1 и 2 закрыты, а оставшиеся два открыты. Рассмотрим другой пример.
root@life# nmap –P0 –p 1,2,21,80 209.41.165.180
Interesting ports on (209.41.165.180):
PORT STATE SERVICE
1/tcp filtered tcpmux
2/tcp filtered compressnet
21/tcp open ftp
80/tcp open http
Nmap finished: 1 IP address (1 host up) scanned in 4.047 seconds
Вы можете заметить, что первые два порта (1, 2) теперь помечены как filtered. По этим данным вы не можете определить, закрыты или открыты порты 1 и 2. Единственная доступная информация - это то, что порт фильтрован. Однако, как мы знаем, все закрытые порты, если они не фильтрованы, при нормальных обстоятельствах должны отсылать RST-пакет. Попробуем с помощью hping послать несколько произвольных пакетов на часто используемые порты и посмотреть на результат.
root@life# hping -S -p 80 -c 2 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=44 ip=209.41.165.180 ttl=63 DF
id=62648 sport=80 flags=SA seq=0
win=65535 rtt=2359.0 ms
len=44 ip=209.41.165.180 ttl=63 DF
id=63296 sport=80 flags=SA seq=1
win=65535 rtt=1359.0 ms
--- 209.41.165.180 hping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1359.0/1859.0/2359.0 ms
Я использовал команду hping -S -p 80 -c 2 209.41.165.180 для отправки двух пакетов с установленным SYN-флагом на 80 порт, в ответ на которые мы получили два пакета с флагом SA, означающим подтверждение нашей попытки создания соединения (SYN acknowledgement). DF указывает на то, что установлен бит «do not fragment». Теперь вернемся к нашей предыдущей проблеме и отправим два таких же пакета на порт 1.
root@life# hping -S -p 1 -c 2 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
--- 209.41.165.180 hping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
В данном случае мы не получили ответа, что подтверждает то, что порт фильтруется МСЭ и любые типы ответов этого порта блокируются. Теперь отправим тот же пакет еще на несколько других портов.
root@life# hping -S -p ++20 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=44 ip=209.41.165.180 ttl=108 DF
id=9352 sport=21 flags=SA seq=1
win=16616 rtt=1062.0 ms
len=40 ip=209.41.165.180 ttl=108
id=10442 sport=22 flags=RA seq=2
win=0 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=11643 sport=23 flags=RA seq=3
win=0 rtt=562.0 ms
len=44 ip=209.41.165.180 ttl=108 DF
id=13778 sport=25 flags=SA seq=5
win=16616 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=40085 sport=49 flags=RA seq=29
win=0 rtt=562.0 ms
len=40 ip=209.41.165.180 ttl=108
id=40941 sport=50 flags=RA seq=30
win=0 rtt=562.0 ms
Я попросил hping отослать по одному SYN-пакету на каждый порт, начиная с 20. Мы можем заметить, что некоторые ответные пакеты имеют флаг RA (Reset Acknowledged), что указывает на то, что эти порты закрыты, а не фильтрованы. Так как мы не получили ответов с портов 20, 24, 26-48, можно сделать вывод, что эти порты заблокированы межсетевым экраном. Таким образом, это может указывать на то, что данные порты также закрыты. МСЭ может быть настроен так, что все часто используемые порты не будут фильтроваться. Как мы видим, порт 443 (который используется для https и обычно открыт) отвечает RST-пакетом, что говорит нам о том, https-сервис не запущен и не блокируется.
root@life#hping -S -p 443 209.41.165.180
HPING 209.41.165.180 (WAN (PPP/SLIP) Interface 209.41.165.180): S set, 40 headers + 0 data bytes
len=40 ip=209.41.165.180 ttl=108
id=40924 sport=443 flags=RA seq=0
win=0 rtt=238.0 ms
тестирование с помощью 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.
life1# iptables –A INPUT –p tcp –tcpflags SYN –j DROP
Теперь начнем тестирование и отправим несколько FIN-пакетов с Windows-машины (в данном случае я использовал версию hping для Windows, запущенную на Windows 2000). По умолчанию наш Linux-хост прослушивает порты 21, 22 и 80.
Ниже приведены результаты отправки SYN-пакетов на порт 80.
E:\hping>hping –S –p 80 –c 10 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): S set, 40 headers + 0
data bytes
--- LIFE1 hping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Как мы видим, все 10 отправленных пакетов были потеряны. Если мы попробуем отправить SYN-пакеты на закрытый порт, получим тот же результат.
E:\hping>hping –S –p 50 –c 10 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): S set, 40 headers + 0
data bytes
--- LIFE1 hping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Теперь попробуем отправить пакеты с флагом FIN.
E:\hping>hping –F –p 50 LIFE1
HPING LIFE1 (LAN eth1) Interface 192.168.10.2): F set, 40 headers + 0
data bytes
len=40 ip=202.83.174.99 ttl=56
id=30859 sport=50 flags=RA seq=0
win=0 rtt=24.0 ms
len=40 ip=202.83.174.99 ttl=56
id=30863 sport=50 flags=RA seq=1
win=0 rtt=14.0 ms
В результате отправки FIN-пакетов на закрытый порт, ранее не отвечавший, мы получили пакеты с флагом RA, что является индикатором того, что порт закрыт. Читатель может проверить, те же самые пакеты на порты 21, 22 и 80 не имеют ответов, что доказывает то, что они открыты, тогда как все другие порты отвечают RA.
UDP-порты
Сканирование UDP портов – непростое занятие из-за ненадежности получаемых результатов. Стандартный способ состоит в отправке пакетов на UDP- порты и идентификации открытых портов на основании того, что обычно от закрытых портов приходит ICMP-сообщение «Port Unreachable». Однако, не факт, что во всех случаях вы получите такой ответ.
Ниже показан результат сканирования UDP-портов с помощью nmap.
root@life#nmap -sU -p 21,53,80 yns1.yahoo.com
Interesting ports on 66.218.71.205:
PORT STATE SERVICE
21/udp open|filtered ftp
53/udp open|filtered domain
80/udp open|filtered http
Nmap finished: 1 IP address (1 host up) scanned in 3.141 seconds
Полученные результаты не кажутся интересными, так как nmap не смог определить, какие порты открыты, а какие фильтрованы или закрыты. По результатам сканирования все три порта или открыты или фильтрованы, что является неверной информацией.
Так как сканируемый хост – DNS-сервер, высока вероятность того, что его 53 UDP-порт открыт для DNS-запросов. Попробуем просканировать его с помощью hping. Применив стандартный метод UDP-сканирования, мы также не получили ответа.
root@life#hping -2 -p 50++ yns1.yahoo.com
HPING yns1.yahoo.com (WAN (PPP/SLIP) Interface 66.218.71.205): udp mode
set, 28 headers + 0 data bytes
6 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Изменим нашу стратегию. Для начала создадим простой текстовой файл произвольного содержания, размером примерно 120 байт, и снова просканируем хост, используя этот файл в качестве полезной нагрузки каждого пакета. Одновременно запустим tcpdump в promisc-режиме для просмотра всего сетевого трафика.
root@life/tmp#tcpdump
root@life#hping -2 -p ++50 -d 120 –E file.txt yns1.yahoo.com
HPING yns1.yahoo.com (WAN (PPP/SLIP) Interface 66.218.71.205): udp mode
set, 28 headers + 120 data bytes
len=46 ip=66.218.71.205 ttl=49
id=37187 seq=3 rtt=531.0 ms
Как легко догадаться, для дальнейшего анализа мы будем использовать вывод tcpdump.
root@life#tcpdump
tcpdump: listening on \Device\NPF_GenericDialupAdapter
00:42:50.484375 IP life.2950 > yns1.yahoo.com.50: UDP, length 120
00:42:51.484375 IP life.2951 > yns1.yahoo.com.51: UDP, length 120
00:42:52.484375 IP life.2952 > yns1.yahoo.com.52: UDP, length 120
00:42:53.484375 IP life.2953 > yns1.yahoo.com.53: 24930 updateM+
[b2&3=0x6364][24930a] [25958q] [25444n] [25958au][|domain]
00:42:53.953125 IP yns1.yahoo.com.53 > life.2953: 24930 updateM FormErr- [0q] 0 /0/0 (12)
00:42:53.953125 IP life > yns1.yahoo.com: ICMP life udp port 2953 unreachable, length 36
00:42:54.484375 IP life.2954 > yns1.yahoo.com.54: UDP, length 120
Обратите внимание на то, что, приняв наши данные, 53 UDP порт ответил сообщением об ошибке, что говорит нам о том, что этот порт открыт. Ответов на все остальные пакеты не было. Другой способ сканирования состоит в проверке ответных ICMP сообщений. Обычно, при отправке пакетов без полезной нагрузки на закрытый UDP-порт, система отвечает ICMP-сообщением Port Unreachable. Открытые порты на такие пакеты не отвечают. Это продемонстрировано в следующем примере.
root@life#hping -2 -p 11 –c 3 202.179.137.59
HPING 202.179.137.59 (WAN (PPP/SLIP) Interface 202.179.137.59): udp mode
set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=202.179.137.59
ICMP Port Unreachable from ip=202.179.137.59
ICMP Port Unreachable from ip=202.179.137.59
--- 202.179.137.59 hping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Как вы могли заметить, я отправил три пакета на 11 UDP-порт и получил три ICMP-сообщения Port Unreachable. Такие исходящие пакеты обычно блокируются межсетевым экраном, но в предыдущем примере мы показали способ обхода правил МСЭ.
снятие «отпечатка пальцев» ОС
Идентификация систем, находящихся за МСЭ, усложнено из-за того, что межсетевой экран может изменять TCP/IP-пакеты, вводя в заблуждения исследователя системы. Методы снятия отпечатков пальцев ОС (fingerprinting) подразделяются на пассивные и активные.
пассивное снятие отпечатков
В случае пассивного снятия отпечатков на целевой хост не отправляется никаких пакетов. Вместо этого используется некоторый промежуточный хост (компьютер-зомби) и делается попытки определить ОС целевого хоста, подсчитывая разницу между значениями IPID. Этот метод известен как idle scan. Также попытаться определить целевую ОС можно, получив доступ к входящему и исходящему трафику целевого хоста каким-либо другим способом. Не рассматривая эти способы, давайте сразу перейдем к активному методу.