Рисунок 20 – Диалоговое окно CaptureInterface

В данном окне содержится информация об интерфейсе:

Device (устройство/интерфейс) Description (описание интерфейса); IP-адрес интерфейса (если адрес неизвестен, то пишется «unknown»); Packets (общее количество отслеженных пакетов с момента открытия окна); Packets/s (количество пакетов, отслеженных за последнюю секунду).

Затем настраивается режим мониторинга трафика путем открытия окна CaptureOptions, в соответствии с рисунком 21.

Рисунок 21 – Диалоговое окно CaptureOptions

В нем содержится информация для настройки режима мониторинга выбранного интерфейса:

Interface (определяет интерфейс, на котором будет осуществляться мониторинг пакетов); Link-layerheader (заголовок канального уровня оставляется по умолчанию); Prom. Mode (promiscuousmode) – значение «enable» указывает на то, что будет захватываться весь трафик; Snaplengthinbytes (указывает на максимальную величину отдельного пакета в байтах); Buffersize (определяет размер буфера в МБ).

В разделе CaptureFiles выставляются пользовательские значения. Если нужно завершить мониторинг по установленному критерию соответственных полей, сохраняя в отдельный файл и переключаясь на следующий с аналогичным режимом.

В разделе StopCapture реализуется завершение мониторинга до определенного лимита по критерию количества пакетов или байтов.

После начала мониторинга появляется главное окно, которое делится на 3 области: Рабочая область (выделена пунктирной линией с точкой  красным цветом); область фильтрации (выделена синим цветом пунктирной линией) и панель управления (выделена зеленым цветом сплошной линией), в соответствии с рисунком 22.

НЕ нашли? Не то? Что вы ищете?

Рисунок 22 – Главное окно сетевого анализатора Wireshark

Панель управления служит для управления основными возможностями приложения (например, начать перехват сетевых пакетов, открыть сохраненную ранее сессию перехвата пакетов и т. д). Область фильтрации дает возможность отфильтровать ненужные пакеты и оставить только необходимые. Фильтрацию можно осуществить, написав в соответствующем поле маску фильтрации (например, «SIP&&UDP» -  будут отображаться только пакеты, содержащие поля протоколов SIP и UDP).

В верхней части рабочей области отображаются перехваченные пакеты, а в нижней части расшифровка каждого поля сетевого пакета. Что позволяет разобрать захваченный пакет, предоставив значение каждого поля протокола любого уровня.

3.2 Установление сеанса связи с помощью протокола SIP


В соответствии с принципом работы протокола SIP, данным протоколом предусмотрено 3 основных сценария управления соединением:

С участием Прокси-сервера, который взаимодействует с сервером определения местоположения (в соответствии с рисунком 23); С участием сервера переадресации, который тоже в свою очередь взаимодействует с сервером определения местоположения (в соответствии с рисунком 24); Непосредственно между пользователями (в соответствии с рисунком 25).

Рисунок 23 – Организация связи двух пользователей с участием прокси-сервера

Рисунок 24 – Организация связи двух пользователей с участием сервера переадресации

Рисунок 25 – Организация непосредственной связи двух пользователей

В анализе аудио - и видео - информаций для управления SIP соединением в данной главе используется сценарий непосредственного общения двух пользователей, так как вызывающему известен адрес вызываемого. Соответственно, так как реализация логических объектов – клиент агента пользователя (UAC) и сервер агента пользователя  (UAS), является частью программного обеспечения агента пользователя (UA). То запросы UAC Терминала №1 будут обрабатываться UAS Терминала №2 напрямую. И с точностью до наоборот запросыUAC Терминала №2 будут обрабатываться UAS Терминала №1.

Характеристики сеанса связи, такие как тип медиаинформации, используемый кодек или частота дискретизации, не описываются средствамиSIP. Тело SIP-сообщения содержит описание сессии, выполненное в форматедругого протокола. Один из таких протоколов – SessionDescriptionProtocol(SDP). SDP-сообщение переносится SIP-сообщением так же, какдокумент, прикреплённый к сообщению электронной почты, или WEB-страница, переносимая в сообщении протокола HTTP.

Процедура управления соединением представляет собой равноправное взаимодействие двух агентов пользователя по протоколу SIP, которое длится определенное время. Диалог устанавливает последовательность сообщений между UA и обеспечивает верную маршрутизацию запросов.

UAC формирует запрос, который включает в себя:

стартовую строку, в которой указывается тип запроса; поле Request-URI и версию SIP; базовый набор полей заголовков (To, From, CSeq, Call-ID, Max-Forwards, Via).

Эти заголовки обязательны для всех SIP-запросов. Они являются основными частями SIP-сообщения, поскольку обеспечивают большинство требуемых услуг маршрутизации (адресацию сообщений, маршрутизацию ответов, ограничение распространения сообщения, сохранение последовательности сообщений и уникальную идентификацию транзакций).

После того как новый запрос создан, и базовые заголовки составлены должным образом, в сообщение добавляются необязательные заголовки и запрос отправляется.

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

В результате UAS получает запрос и выполняет набор процедур обработки.

При принятии запроса, должны быть произведены любые связанные с ним изменения состояния соединения, а если он отклоняется, ни одно из изменений производиться не должно.

UAS обрабатывает запрос пошагово:

Аутентификация пользователя; Определение типа запроса (в случае, если UASопределил тип запроса, но не поддерживает его, он должен передать ответ с кодом 405); Обработка поля «To». В данном поле вызывающий пользователь указывает адрес получателя запроса (если UAS решает отклонить запрос, он должен сформировать ответ с кодом 403 и отправить его); Обработка поля Request-URI. Поле Request-URI идентифицирует UAS, который должен обрабатывать запрос (при использовании в Request-URIадресации, не поддерживаемой сервером, запрос отклоняется и посылается ответ с кодом 416). Обработка заголовка Require. Поле этого заголовка используется UAC, чтобы сообщить UAS о расширениях, которые тот должен поддерживать для правильной обработки запроса (если UAS не понимает какого-либо из расширений, он отправляет ответ с кодом 420 и список непонятных ему опций, указанных в заголовке Require); Обработка содержимого тела сообщения. Сервер изучает тело сообщения и поля заголовков, которые описывают его (если в сообщении содержится тело с непонятным типом, языком или кодеком, и это тело является обязательным, UAS должен отбросить запрос и отправить ответ с кодом 415); Основное правило состоит в том, что UAS должен передавать предварительные ответы только на запрос INVITE и создавать как можно быстрее окончательные ответы на все запросы, кроме INVITE.

Оперируя этими знаниями, можно приступить к захвату трафика SIP-телефонии с помощью анализатора Wireshark

3.3 Анализ аудиоинформации в SIP-телефонии


В соответствии с рисунком 25, в роли вызывающегоявляется пользовательский терминал №1 (URI которого [email protected]), с приписаннымему IP-адресом 172.16.0.108. Он пытается установить сеанс связи с терминалом №2 (URI – [email protected]), который в свою очередь является вызываемым с IP-адресом 172.16.0.50.

Организация взаимодействия терминалов происходит с помощью SIP-протокола, в состав которого входит протокол SDP, содержащий в себе описание сессии сеанса связи.

Сетевой анализатор предоставляет возможность наглядно увидеть процесс инициализации сеанса связи с помощью сообщений команд запроса и ответа, начиная с 15-го кадра (в соответствии с рисунком 26).

СформированныйINVATE-запрос от UAC вызывающего терминала отправляется на UAS вызываемому (команда запроса характеризуется наличием строки Request-Line).

Время (Time)за которое пакет с определенной длиной/весом (Length)доходит до адреса назначения (Destination) от адреса источника (Source), можно увидеть в соответствующих полях, информирующих об этом.

Рисунок 26 – Установление сессии сеанса связи

Запрос INVATE приглашает Пользователя №2 принять участие в сеансе связи. Тот в свою очередь отправляет SIP-ответ ошибки в запросе (характеризующая Status-Line), в котором сообщается о том, что запрос требует проведения процедуры аутентификации пользоваUnauthorized).

Далее от вызывающего исходит запрос ACK, информирующий о получении ответа на запрос INVATE.

После чего по новому отправляется запрос на приглашение, только уже с данными для аутентификации. Информацию о которых можно увидеть в поле расшифровки пакета с иерархически сформированной структуризацией пакета, в соответствии с рисунком 27.

Рисунок 27 –Поле расшифровки кадра, содержащий значения отдельных полей протоколов, формирующий данный пакет

В данной расшифровке снизу вверх можно увидеть, как формировался пакет со стороны терминала с sophtfones-приложением. Соответственно «развернуть» инкапсулированные данные и узнать о всех значениях применяемых протоколов.

Где зеленой линией подчеркнуто название VoIP-приложения, реализующее функции UA, а также добавленное в заголовок SIP-сообщения информация, содержащая метод аутентификации и его значения, в соответствии с рисунком 28.

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7