ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.04.2024
Просмотров: 8
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Лабораторная работа №2
Анализ сетевого трафика
Цель работы: изучение сетевого трафика, генерируемого сетевым устройством в сетях передачи данных при работе с различными сетевыми сервисами; анализ служебных заголовок часто используемых сетевых протоколов.
2.4 Порядок выполнения работы
Анализ работ протокола ARP
Запущена программа Wireshark 3.6.5 и включен захват трафика на беспроводном интерфейсе
Результаты выполнения команд ipconfig /all в таблице 1.
| Параметр | Значение |
| Физический адрес | 94-DB-C9-44-C3-B3 |
| DHCP включен | Да |
| IPv4-адрес | 192.168.166.242 |
| Маска подсети | 255.255.255.0 |
| Основной шлюз | 192.168.166.120 |
| DHCP-сервер | 192.168.166.120 |
| DNS-серверы | 192.168.166.120 |
| Физический адрес основного шлюза | 1a:83:71:61:11:60 |
| Производитель устройства, выступающего основным шлюзом | Не зарегистрирован |
Таблица 1. Параметры сети
В командной строке была выполнена команда очистки таблицы arp –d.
Выполнение команды ping на основной шлюз показано на рисунке 1.
Рисунок 1. Выполнение ping на основной шлюз (192.168.166.120)
Результат выполнения фильтров ARP в программе wireshark на рисунке 2
Рисунок 2. Результат анализа работы arp-протокола
Захват трафика в Wireshark выключен.
В браузере google-chrome выполнен поисковый запрос «MAC-address vendor» и с помощью онлайн сервиса установлен производитель устройства, выступающего основным шлюзом и внесен в таблицу 1. Т.к. основной шлюз был на сотовом телефоне POСO X3 PRO, MAC которого не был зарегистрирован. (Рисунок 3)
Рисунок 3. Vendor MAC 1a:83:71:61:11:60 не зарегистрирован.
Анализ работы протокола ICMP
Включен захват трафика в Wireshark
Результат пинга гугла, яндекса и основного шлюза показан на рисунке 4.
Рисунок 4. Вывод пинга
На основе выполненных команд заполнена таблица 2
| Сетевой ресурс | Время отклика | Значение поля TTL |
| , Google.ru | Средне = 93мсек | 110 |
| Yandex.ru | Средне = 79 мсек | 50 |
| 192.168.166.200 | Средне = 30 мсек | 64 |
| 8.8.8.8 | Средне = 103 мсек | 52 |
Таблица 2. Данные пингов
В программе wireshark фильтруем icmp-request и icmp-reply, результат на рисунке 5.
Рисунок 5. Результат анализа работы icmp-протокола.
Включено захват трафика в программе wireshark.
В командной строке поочередно вели команду «tracert 8.8.8.8»
Рисунок 6. Результат выполнение команды «tracert 8.8.8.8»
В программе Wireshark выставить значение быстрого фильтра icmp.
Рисунок 7. Результат выполнение команды «tracert 8.8.8.8»
Анализ протокола разрешения имен DNS и транспортный протокол UDP.
Включено захват трафика в программе wireshark.
В командной строке поочередно вели команду «ipconfig/flushdns» после очистки вели команду «nslookup tps.uz»
Выключен захват
На основе рисунка заполняем таблицу
Таблица 3.
| Инфо сегмента | Src port | Dst port | Src IP | Dst IP |
| Standart query A TPS.uz | 58663- произвольный порт | 53- порт, идентификацирующий протокол DNS | 192.168.166.242 | 192.168.166.120 DNS – сервер провайдера |
| Standart query response A | 53- порт, идентификацирующий протокол DNS | 58663 | 192.168.166.120 DNS – сервер провайдера | 192.168.166.242 |
Анализ работ протокола HTTP и транспортного протокола TCP.
Включено захват трафика в программе wireshark.
На основе рисунка заполняем таблицу
Таблица 4.
| Инфо сегмента | Src port | Dst port | Src IP | Dst IP |
| GET | 50429- произвольный порт | 80- порт, идентификацирующий протокол DNS | 192.168.166.242 | 80.80.200.58 |
| HTTP | 80- порт, идентификацирующий протокол DNS | 50429 | 80.80.200.58 | 192.168.166.242 |
Ответы на контрольные вопросы.
1. Протокол ARP относится к 2 – канальному уровню модели OSI т.к. этот уровень отвечает за физическую адресацию, а ARP – это протокол предназначенный для определения MAC адреса по известному IP
2. Протокол ICMP относится к 3 – сетевому уровню модели OSI т.к. этот уровень отвечает за определение маршрута и логическую адресацию. ICMP – это сетевой протокол, входящий в стек протоколов TCP/IP. В основном ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных, например, запрашиваемая услуга недоступна или хост, или маршрутизатор не отвечают.
3. TTL (Time To Live) — поле в заголовке IPv4 пакета. Оно задает «время жизни» пакета. Каждый маршрутизатор должен уменьшать значение поля TTL при прохождении пакета на единицу. Это приведет к изменению заголовка пакета, следовательно, маршрутизатор должен пересчитать контрольную сумму IP-заголовка.
Изначально поле TTL должно было дополнительно уменьшаться на единицу каждую секунду, пока пакет обрабатывается маршрутизатором. Но в последствии от ежесекундного уменьшения отказались и не всегда упоминают этот факт (факт присутствия в протоколе данного правила). Причина отказа проста — большинство маршрутизаторов, как правило, обрабатывают поток пакетов настолько быстро, что они не задерживаются на секунду.
Когда значение поля TTL достигает 0, маршрутизатор должен отбросить такой пакет. Следовательно имеет место правило: маршрутизатор не пропускает пакеты с нулевым значением поля TTL. В этом действии кроется основное предназначение этого поля — избежание петель маршрутизации. В случае ошибочной маршрутизации,
пакет не будет ходить бесконечно по сети, а отбросится через некоторое время. TTL до основного шлюза и до 8.8.8.8 (64 и 52)
4. Сокет (англ. socket — разъём) — название программного интерфейса для обеспечения обмена данными между процессами. Процессы при таком обмене могут исполняться как на одной ЭВМ, так и на различных ЭВМ, связанных между собой сетью. Сокет — абстрактный объект, представляющий конечную точку соединения.
Следует различать клиентские и серверные сокеты. Клиентские сокеты грубо можно сравнить с конечными аппаратами телефонной сети, а серверные — с коммутаторами. Клиентское приложение (например, браузер) использует только клиентские сокеты, а серверное (например, веб-сервер, которому браузер посылает запросы) — как клиентские, так и серверные сокеты.
Интерфейс сокетов впервые появился в BSD Unix. Программный интерфейс сокетов описан в стандарте POSIX.1 и в той или иной мере поддерживается всеми современными операционными системами.
Принципы сокетов
Для взаимодействия между машинами с помощью стека протоколов TCP/IP используются адреса и порты. Адрес представляет собой 32-битную структуру для протокола IPv4, 128-битную для IPv6. Номер порта — целое число в диапазоне от 0 до 65535 (для протокола TCP).
Эта пара определяет сокет («гнездо», соответствующее адресу и порту).
В процессе обмена, как правило, используется два сокета — сокет отправителя и сокет получателя. Например, при обращении к серверу на HTTP-порт сокет будет выглядеть так: 194.106.118.30:80, а ответ будет поступать на mmm.nnn.ppp.qqq:xxxxx.
Каждый процесс может создать «слушающий» сокет (серверный сокет) и привязать его к какому-нибудь порту операционной системы (в UNIX непривилегированные процессы не могут использовать порты меньше 1024).
Слушающий процесс обычно находится в цикле ожидания, то есть просыпается при появлении нового соединения. При этом сохраняется возможность проверить наличие соединений на данный момент, установить тайм-аут для операции и т. д.
Каждый сокет имеет свой адрес. ОС семейства UNIX могут поддерживать много типов адресов, но обязательными являются INET-адрес и UNIX-адрес. Если привязать сокет к UNIX-адресу, то будет создан специальный файл (файл сокета) по заданному пути, через который смогут сообщаться любые локальные процессы путём чтения/записи из него (см. сокет домена Unix). Сокеты типа INET доступны из сети и требуют выделения номера порта.
Обычно клиент явно «подсоединяется» к слушателю, после чего любое чтение или запись через его файловый дескриптор будут передавать данные между ним и сервером.
5. 53 - порт, идентифицирующий протокол DNS
6. 80 – порт, идентифицирующий протокол HTTP
