Ключевые слова:fingerprint, nmap, security, host, hping, tcp, iptables, (найти похожие документы)
From: Владимир Куксенок
Newsgroups:
Date: Sun, 16 Feb 2008 17:02:14 +0000 (UTC)
Subject: Host Fingerprinting с помощью hping
Оригинал перевода: http://www.securitylab.ru/analytics/243654.php
Оригинал на английском: Host Fingerprinting and Firewalking With hping
Naveed Afzal
National University Of Computer and Emerging Sciences, Lahore, Pakistan
перевод Владимир Куксенок
Целью этой статьи является обзор некоторых методов, которые могут быть
эффективно использованы для исследования удаленных хостов. В статье
намеренно рассматриваются сетевые хосты, находящиеся за межсетевым
экраном (МСЭ). Предполагается, что читатель понимает основные идеи
host fingerprinting и знаком с принципами функционирования протоколов
TCP/IP. Мы рассмотрим методы снятия отпечатков как сервисов, слушающих
порт, так и операционных систем в различных защищенных МСЭ средах и
попытаемся выяснить преимущества и недостатки различных способов.
Знакомство с hping и nmap очень пригодится для понимания изложенного
материала.
1. Введение
Удаленное снятие отпечатков это процесс идентификации операционной
системы хоста и сетевых служб, прослушивающих определенные порты, по
сети. Обычно это производится различными способами активного и
пассивного сканирования, путем отправки некоторого количества пакетов
и анализа ответов. Вообще, общедоступные утилиты, в том числе и nmap,
довольно неплохо выполняют сканирование и определение версии удаленной
ОС. Но в тех случаях, когда хост находится за межсетевым экраном, эти
утилиты мало чем могут помочь, либо выдают неоднозначные или неверные
результаты. Это особенно справедливо для машин, трафик которых
серьезно фильтруется МСЭ и которым разрешено принимать и отправлять
очень небольшое количество типов пакетов. В этих случаях нам нужно
использовать другие методы для правильного определения состояния
удаленной машины. Мы рассмотрим некоторые из них, включая RING
сканирование и ICMP сканирование. В первом разделе рассматриваются
различные методы сканирования портов, тогда как вторая часть пытается
пролить свет на снятие отпечатка операционной системы.
2. Сканирование портов
Начнем с основных методик сканирования портов, с использованием таких
утилит, как nmap и hping. Вначале мы обсудим общеизвестное SYN и
SYNACK сканирование и поведение различных хостов при приеме таких TCP
пакетов. Затем рассмотрим, как различаются результаты сканирования
машин находящихся за МСЭ и тех, чей трафик не фильтруется. После этого
мы обратим внимание на некоторые продвинутые техники, включая FIN
сканирование и UDP сканирование хостов, находящихся за МСЭ.
2.1 Hping
Hping описывается как утилита, которая может эффективно использоваться
для сканирования, снятия отпечатков и тестирования межсетевых экранов.
Среди большего количества возможностей утилиты присутствует
возможность отправки произвольных пакетов различных протоколов и
выполнение удаленного сканирования. Это очень удобно при изучении
ответов хоста на различные произвольные пакеты.
2.2 Nmap
Network Mapper (nmap) это известная утилита для исследования сетей,
которую можно использовать для сканирования портов и определения
удаленной ОС. Широкий функционал утилиты включает в себя пассивное
сканирование и idle сканирование, хотя возможность отправки
произвольных пакетов отсутствует.
2.3 Сканирование с установлением наполовину открытого соединения (SYN)
Идея сканирования с установлением наполовину открытого соединения
(также известного как SYN-сканирование) очень проста. Без завершения
трехэтапного установления TCP соединения, отсылается SYN пакет и
ожидается ответ. Если в ответ получено SYN ACK, это означает, что
удаленный порт открыт, в противном случае, если получен пакет с флагом
RST, порт закрыт.
2.3.1 Фильтрованные и закрытые порты
Однако, в некоторых случаях, межсетевой экран может просто
заблокировать доступ к некоторым открытым портам. В этих случаях
говорят, что порт фильтрован. В таких ситуациях мы не получим ответ на
наш 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 heade
rs + 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 heade
rs + 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
^C
root@life#
Я попросил 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 heade
rs + 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
^C
root@life#
2.4 Тестирование с помощью FIN пакетов
Метод основан на том, что если закрытый порт получает пакет с
установленным флагом FIN, при нормальных условиях он ответит RST
пакетом. Открытые порты не отвечают на FIN пакеты. Это может
пригодиться в тех случаях, когда SYN пакеты блокируются межсетевым
экраном. Однако это не применимо при сканировании Windows-компьютеров
вследствие того, что они никогда не отвечают на FIN пакеты. Давайте
создадим два хоста в VMWare. На один из хостов установим Linux, а с
другого будем отправлять FIN пакеты. Начнем с того, что заблокируем
весь нормальный SYN трафик на Linux-хосте. Чтобы заблокировать все
входящие пакеты с установленным флагом SYN, мы воспользуемся iptables.
2.4.1 Iptables
Iptables - это основная утилита ОС Linux, используемая для фильтрации
сетевых пакетов. В соответствии со своей внутренней архитектурой
iptables имеет три встроенных таблицы, каждая из которых содержит
некоторые заранее определенные цепочки (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
^C
E:\hping>
В результате отправки FIN пакетов на закрытый порт, ранее не
отвечавший, мы получили пакеты с флагом RA, что является индикатором
того, что порт закрыт. Читатель может проверить, те же самые пакеты на
порты 21, 22 и 80 не имеют ответов, что доказывает то, что они
открыты, тогда как все другие порты отвечают RA.
2.5 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
^C
root@life#
Как легко догадаться, для дальнейшего анализа мы будем использовать
вывод 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'. Такие исходящие пакеты обычно
блокируются межсетевым экраном, но в предыдущем примере мы показали
способ обхода правил МСЭ.
3. Снятие отпечатка ОС
Снятие отпечатков систем, находящихся за МСЭ, усложнено из-за того,
что межсетевой экран может изменять TCP/IP пакеты, вводя в заблуждения
исследователя системы. Методы снятия отпечатков ОС подразделяются на
пассивные и активные.
3.1 Пассивное снятие отпечатка ОС
В случае пассивного снятия отпечатка, на целевой хост не отправляется
никаких пакетов. Вместо этого используется некоторый промежуточный
хост (компьютер-зомби) и делается попытки определить ОС целевого
хоста, подсчитывая разницу между значениями IPID. Этот метод известен
как idle scan. Также попытаться определить целевую ОС можно получив
доступ к входящему и исходящему трафику целевого хоста каким-либо
другим способом. Не рассматривая эти способы, давайте сразу перейдем к
активному снятию отпечатков удаленной системы.
3.2 Активное снятие отпечатка ОС
При активном снятии отпечатка производится отправка произвольных
пакетов на целевой хост и делается попытка определения ОС на основании
таких значений полей заголовка ответных TCP/IP пакетов, как временные
характеристики или IPID, TOS, TCP ISN, флаг фрагментации и т.д. Другой
старый метод определения удаленной ОС состоит в анализе значения TTL
ICMP echo-пакета. Это простой способ, однако он не может выявить
различия разных вариантов одной и той же ОС, например win98, XP и
win2k. Обычно в каждой ОС установлено фиксированное, заранее
определенное, значение TTL. В операционных системах Microsoft это
значение по умолчанию равно 128, тогда как в Linux - 256. Ниже показан
пример определения удаленной ОС по значению TTL ответного ICMP
echo-пакета. Я просто пингую целевую машину и проверяю значение TTL
полученного в ответ пакета. В данном случае оно равно 113, что
позволяет предположить, что удаленная ОС принадлежит к семейству
Windows, так как стартовое значение TTL этих систем равно 128, а
маршрут от моей машины до целевой составляет примерно 15 промежуточных
хостов (113 + 15 = 128), что может быть проверено с помощью
traceroute.
E:\>ping 209.41.165.180
Pinging 209.41.165.180 with 32 bytes of data:
Reply from 209.41.165.180: bytes=32 time 38ms TTL=113
Reply from 209.41.165.180: bytes=32 time 51ms TTL=113
Ping statistics for 209.41.165.180:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milliseconds:
Minimum = 38ms, Maximum = 51ms, Average = 44ms
Нужно учитывать, что это не самый надежный метод. Если целевой хост
является маршрутизатором или находится за 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):
Interesting ports on ntc.net.pk (202.83.174.99):
(The 97 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
Device type: general purpose
Running: FreeBSD 4.X
OS details: FreeBSD 4.6.2-RELEASE - 4.8-RELEASE
Данные другого хоста (202.83.162.27):
Interesting ports on 202.83.162.27:
(The 99 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
80/tcp open http
Device type: general purpose
Running: FreeBSD 4.X|5.X
OS details: FreeBSD 4.3 - 4.4PRERELEASE, FreeBSD 4.9 - 5.1, FreeBSD 5.0-RELEASE,
Теперь попробуем применить описанную выше SYN ACK методику. Для начала
мы должны настроить локальный МСЭ на тихое блокирование всех SYN ACK
пакетов, приходящих с удаленного хоста.
life1# iptables -A INPUT -p tcp -j DROP -s 202.83.162.27
Теперь отправим SYN пакет на открытый 80 порт и начнем слежение за
выводом tcpdump.
root@life# hping -S -p 80 -c 1 202.83.162.27
17:22:51.079596 202.134.134.230.1816 > 202.83.162.27.http: S win 512
17:22:51.208938 202.83.162.27.http > 202.134.134.230.1816: S ack win 5840
17:22:53.218939 202.83.162.27.http > 202.134.134.230.1816: S ack win 5840
17:23:57.218939 202.83.162.27.http > 202.134.134.230.1816: S ack win 5840
17:23:03.218939 202.83.162.27.http > 202.134.134.230.1816: S ack win 5840
17:23:11.468939 202.83.162.27.http > 202.134.134.230.1816: S ack win 5840
17:24:21.618938 202.83.162.27.http > 202.134.134.230.1816: S ack win 5840
Разница во времени, между получением SYN ACK пакетов составляет
примерно 2, 4, 5, 7 и 10 секунд.
Теперь проделаем те же действия над первым хостом, для которого
достоверно известно, что на нем запущена ОС FreeBSD. Ниже приводится
вывод tcpdump.
root@life# hping -S -p 80 -c 1 202.83.174.99
17:45:50.019746 202.134.134.230.2644 > 202.83.174.99.http: S win 512
17:45:50.148940 202.83.174.99.http > 202.134.134.230.2644: S ack win 5840
17:45:54.108939 202.83.174.99.http > 202.134.134.230.2644: S ack win 5840
17:46:00.108939 202.83.174.99.http > 202.134.134.230.2644: S ack win 5840
17:46:12.308939 202.83.174.99.http > 202.134.134.230.2644: S ack win 5840
17:46:36.378938 202.83.174.99.http > 202.134.134.230.2644: S ack win 5840
В данном случае разница во времени составляет примерно 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 -> SYN -> Host 2
Host2 -> SYN ACK -> Host1
Host1 -> ACK -> Host2
Host1 -> FIN -> Host2
Host2 -> FIN ACK -> Host1
Host2 -> FIN ACK -> Host1
Host2 -> FIN ACK -> Host1
И так далее..
Первый хост (Host1) не отправляет ответов на FIN ACK пакеты второго
хоста (Host2). Кроме этого, можно еще использовать RST пакеты.
4. Заключение
Автоматизированные способы снятия отпечатков удаленной системы могут
давать неплохие результаты, однако в некоторых средах они не всегда
эффективны. В этих случаях для получения наиболее точных результатов
нужно комбинировать несколько различных методик. Приемы, описанные в
этой статье, применяются "вручную" и могут использоваться для
получения дополнительной информации об устройстве и функционировании
сети. Приведенные подходы не единственные, например, из-за широты
тематики не описывались методы пассивного снятия отпечатков.
Большинство межсетевых защит блокируют некоторые типы трафика и часто
затрудняют идентификацию находящихся за ними систем. Однако тщательное
изучение их поведения может помочь опознаванию закрытых, фильтрованных
и открытых TCP и UDP портов, а также определению операционной системы
удаленного хоста.
