Параметры виртуального сетевого адаптера Клиент-машины в Windows xp:

Подключение по локальной сети - Ethernet адаптер:

DNS-суффикс этого подключения . . :

Описание . . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter

Физический адрес. . . . . . . . . : 00-0C-29-ED-78-5F

Dhcp включен. . . . . . . . . . . : нет

IP-адрес . . . . . . . . . . . . : 192.168.20.128

Маска подсети . . . . . . . . . . : 255.255.255.0

Основной шлюз . . . . . . . . . . : 192.168.20.2

DNS-серверы . . . . . . . . . . . : 8.8.8.8

8.8.4.4

Как видно, нашей «локальной» сетью является виртуальная сеть 192.168.20.х, при этом машина-0 имеет адрес 192.168.20.1, а машина-1 — 192.168.20.128

Приступим к выполнению поставленных задач:

1. При помощи программы Microsoft Network Monitor 3.4 (или аналогичной) проанализировать трафик между двумя узлами локальной сети:

- выполнить ping второго узла (проанализировать ICMP-пакеты — запрос/ответ);

- выполнить обзор компьютеров рабочей группы (проанализировать пакеты NetBIOS —

запрос/ответ).

Для начала, просто выполним пинг, и проверим работает ли наша сеть.

Выполним пинг виртуальной машины с хоста:

cmd /k ping -t 192.168.20.128

Работает! Теперь в обратную сторону:

Отлично, теперь приступим к просмотру самих пакетов.

Запускаем программу Microsoft Network Monitor 3.4 на виртуальной машине.

Выключаем сетевые приложения для облегчения визуальной работы, Запускаем Capture, и делаем один эхо-запрос с виртуальной машины на хост:

cmd /k ping 192.168.20.1 -n 1

Жмём Stop, дабы ограничить попадание ненужного трафика в логи.

Итак, что мы видим:

Номера кадров захвата 1 и 2 – служебные сообщения программы-сниффера, пропускаем их.

3 – ICMP запрос эха от машины-1 к машине-0,

4 – хост машина спрашивает виртуальную о её физическом адресе

5 – последующий ответ, содержащий физ. адрес машины-1

6 – ICMP-ответ от хост машины

Нужно отметить, что процедура идентификации физ. адреса через ARP – не постоянная процедура перед каждым пакетом, а периодическая. Так как соотношение IP/MAC адреса не изменяется настолько быстро, на некоторое время оно сохраняется в ARP КЭШе.

Можно посмотреть текущие сохранённые записи об адресах путём ввода команды:

cmd /k arp –a

Также я добавлю, что по идее, сначала виртуальная машина (с которой отправлялся первый эхо-запрос) должна была опросить широковещательным пакетом хост-машину об адресе, но этого не произошло, так как я выполнял команду пинга до этого, и адрес остался в КЭШе. Поэтому первым мы видим ARP-запрос от «ответчика на пинг».

Перейдём к разбору самих пакетов ICMP

Для начала, запрос:

Для понимания того, что мы увидим, нужно разобраться со структурой захваченных кадров, и их отображением.

Все снифферы оперируют кадрами (фреймами, frames - иногда их называют также пакетами Ethernet). Кадр - это минимальная единица передаваемой информации в сети Ethernet. Вся информация передается только кадрами. Либо кадр прошел (информация дошла до получателя), либо по каким-то причинам получить его не удалось (коллизия, другое повреждение кадра, физические проблемы в сети и т.п.)

На самом верху в Network Monitor показан узел Frame. Собственно говоря, это информация не самого пакета, а Network Monitor об этом пакете: когда был пойман кадр, сколько времени прошло с момента поимки предыдущего пакета, размер пакета.

Ниже расположен узел Ethernet. Здесь - только два блока полезной информации: MAC-адрес получателя и MAC-адрес отправителя

Следующая "матрешка" в кадре Ethernet - это заголовок (служебные данные) протокола IP.

Дальше в кадрах Ethernet, пойманных в IP-сети, начинаются различия. Выше идут протоколы так называемого уровня 3+ по модели OSI. Наиболее часто используются следующие протоколы этого уровня: TCP, UDP, ICMP, IGMP

Наш текущий протокол – ICMP.

(для справки, нужно кликнуть на нужном поле, чтобы увидеть эти данные в самом HEX виде пакета)

Их можно видеть на скриншоте:

Здесь представлен полный кадр Ethernet, в нём мы видим:

Секция 1: блок с МАС-адресами, и ссылкой на вышестоящий протокол

сначала идёт МАС получателя: 00 50 56 C0 00 08 – можно сверить с данными о сетевых адаптерах выше и убедиться, что оно так и есть.

Далее МАС отправителя: 00 0C 29 ED 78 5F

Далее идёт ссылка на EtherType – 08 00. Два октета. Он указывает на протокол, инкапсулированный в кадре Ethernet. В большинстве случаев, это 0х8000 - Internet Protocol version 4 (IPv4). Для протокола ARP это будет 0х0806, к примеру.

Секция 2: это заголовок IPv4-пакета. Здесь мы можем видеть много различной служебной информации, но нас пока интересуют только

SourceAddress: 192.168.20.128

и DestinationAddress: 192.168.20.1,

Также нужно отметить октет NextProtocol, там будет значение 01, что указывает на тип инкапсулируемого протокола (ICMP).

Для полноты картины, приведу данные остальных полей по порядку, начиная с начала:

Versions: IPv4, Internet Protocol; Header Length = 20 --- 45

DifferentiatedServicesField: DSCP: 0, ECN: 0 --- 00

TotalLength: 60 (0x3C) --- 00 3С

Identification: 2171 (0x87B) --- 08 7B

FragmentFlags: 0 (0x0) --- 00 00

TimeToLive: 128 (0x80) --- 80

NextProtocol: ICMP, 1(0x1) --- 01

Checksum: 34932 (0x8874) --- 88 74

SourceAddress: 192.168.20.128 --- C0 A8 14 80

DestinationAddress: 192.168.20.1 --- C0 A8 14 01

Секция 3: сам ICMP пакет.

Первым октетом идёт тип пакета Type – 08 – в данном случае, это эхо-запрос.

Далее идут параметры Code, Checksum, Identifier, Sequence number.

Code: 0 (0x0) --- 00

Checksum: 15964 (0x3E5C) --- 3E 5C

ID: 512 (0x200) --- 02 00

Sequence number = 3328 --- 0D 00 – это «достаточно уникальный» идентификатор пакета, который позволяет отличать друг от друга одинаковые, по сути, пакеты запросов и ответов, но которые обслуживаются в разное время.

В последнюю очередь в пакет включена «полезная нагрузка» в виде данных, передающихся вместе с пакетом. Примечание – данные из эхо-запроса должны быть полностью включены в эхо-ответ. Для ICMP ping’a эти данные составляет латинский алфавит различной длины, в зависимости от размера пакета.

Теперь, ответ:

Чтобы не расписывать каждую строку заново, я скопирую всё дерево, и обращу внимание на важные моменты:

Frame: Number = 6, Captured Frame Length = 74, MediaType = ETHERNET

- Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-0C-29-ED-78-5F],SourceAddress:[00-50-56-C0-00-08]

+ DestinationAddress: VMware, Inc. ED785F [00-0C-29-ED-78-5F]

+ SourceAddress: VMWare, Inc. C00008 [00-50-56-C0-00-08]

EthernetType: Internet IP (IPv4), 2048(0x800)

- Ipv4: Src = 192.168.20.1, Dest = 192.168.20.128, Next Protocol = ICMP, Packet ID = 10085, Total IP Length = 60

+ Versions: IPv4, Internet Protocol; Header Length = 20 --- 45

+ DifferentiatedServicesField: DSCP: 0, ECN: 0 --- 00

TotalLength: 60 (0x3C)

Identification: 10085 (0x2765)

+ FragmentFlags: 0 (0x0)

TimeToLive: 128 (0x80)

NextProtocol: ICMP, 1(0x1)

Checksum: 27018 (0x698A)

SourceAddress: 192.168.20.1

DestinationAddress: 192.168.20.128

- Icmp: Echo Reply Message, From 192.168.20.1 To 192.168.20.128

Type: Echo Reply Message, 0(0)

Code: 0 (0x0)

Checksum: 18012 (0x465C)

ID: 512 (0x200)

SequenceNumber: 3328 (0xD00)

ImplementationSpecificData: Binary Large Object (32 Bytes)

Во-первых, сразу заметно, что поменялись адреса отправителя и приёмщика,

Далее мы видим, что сменился Type, теперь он 0, а не 8 (как у запроса)

SequenceNumber остался прежним, что логично.

Поле данных (алфавит) также осталось сохранным, как и требуется от протокола.

Ради интереса, я отправил эхо-запрос длиной 2000 байт:

cmd /k ping 192.168.20.1 -n 1 -l 2000

Как и ожидалось, из-за MTU (maximum transmission unit), ограниченного 1480 байтами в Windows, наш запрос-пакет разбился на 2 фрагмента, первый из которых содержал данные ICMP и часть данных эха, а вторая часть передалась простой фрагмент IPv4 пакета.

Теперь, перейдём к поверхностному обзору пакетов NetBIOS.

Перезапустим службу обозревателя ПК в ЛВС, чтобы увидеть новый поток данных:

Итак, что мы видим на первый взгляд:

Время попробовать другую программу для анализа пакетов, Wireshark – он уже установлен на хосте, так что посмотрим оттуда.

Как видно, всё начинается с широковещательного объявления себя в сети.

1, 3, 4, 5 – регистрация рабочей группы в сети по протоколу NBNS

2, 6,7 – объявление данного ПК в сети.

8 – приходит ответ от машины-1, которая также объявляет о своём присутствии все машины подсети, они определяют кто будет главным обозревателем сети.

12,13 – далее идёт разрешение айпи машины-1 в MAC, и машины начинают общаться при помощи протокола TCP.

17 – по протоколу NBSS (netbios session service) начинается сессия, в которой машины обмениваются информацией о некоторых своих особенностях.

Для примера заглянем внутрь пакета 17 и 18 – это запрос и ответ на установку сессии:

17

18

Из описаний полей всё достаточно очевидно, ПК обмениваются сообщениями NetBIOS по протоколу TCP, инкапсулированному в IP пакеты, которые в свою очередь являются частью кадров Ethernet.

Мы видим, что запрос идёт на порт 139, видим тела служебных сообщений NetBIOS, содержащих тип сообщения (запрос\ответ), флаги, имена вызываемой и вызывающей машин, и либо подтверждение запроса в ответном пакете.