Главная страница
Навигация по странице:

  • 2.4 Порядок выполнения работы

  • Инфо сегмента Src port Dst port Src IP

  • Ответы на контрольные вопросы.

  • Лабораторная работа №2. Лабораторная работа 2 Анализ сетевого трафика


    Скачать 0.74 Mb.
    НазваниеЛабораторная работа 2 Анализ сетевого трафика
    Дата03.02.2023
    Размер0.74 Mb.
    Формат файлаdocx
    Имя файлаЛабораторная работа №2.docx
    ТипЛабораторная работа
    #918678

    Лабораторная работа №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


    написать администратору сайта