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

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

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

1) стартовую строку, в которой указывается тип запроса;

2) поле Request-URI и версию SIP;

3) базовый набор полей заголовков (To, From, CSeq, Call-ID, Max-Forwards, Via).

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

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

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

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

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

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

1. Аутентификация пользователя;

2. Определение типа запроса (в случае, если UASопределил тип запроса, но не поддерживает его, он должен передать ответ с кодом 405);

3. Обработка поля «To». В данном поле вызывающий пользователь указывает адрес получателя запроса (если UAS решает отклонить запрос, он должен сформировать ответ с кодом 403 и отправить его);

4. Обработка поля Request-URI. Поле Request-URI идентифицирует UAS, который должен обрабатывать запрос (при использовании в Request-URIадресации, не поддерживаемой сервером, запрос отклоняется и посылается ответ с кодом 416).

5. Обработка заголовка Require.Поле этого заголовка используется UAC, чтобы сообщить UAS о расширениях, которые тот должен поддерживать для правильной обработки запроса (если UAS не понимает какого-либо из расширений, он отправляет ответ с кодом 420 и список непонятных ему опций, указанных в заголовке Require);

6. Обработка содержимого тела сообщения. Сервер изучает тело сообщения и поля заголовков, которые описывают его (если в сообщении содержится тело с непонятным типом, языком или кодеком, и это тело является обязательным, UAS должен отбросить запрос и отправить ответ с кодом 415);

7. Основное правило состоит в том, что UAS должен передавать предварительные ответы только на запрос INVITE и создавать как можно быстрее окончательные ответы на все запросы, кроме INVITE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 28 - Поле аутентификации заголовка SIP-сообщения

В данном случае можно увидеть, что доступ реализуется дайджест-аутентификацией, в которой сформирована хеш-сумма (response) методом алгоритмирования MD5, а также сами значения, к которым были применены функции хеширования (nonce, realm, username, uri).

UASТерминала №2 принимает хеш-код и отсылает ответ Trying с кодом 100, информирующий о том, что последний запрос обрабатывается. Сервер обращается к БД и определяет местоположение вызываемого.

Следом приходит ответ Ringing с кодом 180, информирующий о том, что местоположение определено (вызываемый получает сигнал о входном вызове от своего UA).

60-ый фрейм, сообщает о том, что запрос успешно выполнен на INVATE-запрос (вызываемый согласен принять участие в сеансе связи). Об этом говорит команда OK с кодом 200 (см. рисунок 29).

Рисунок 29 - Подтверждение о принятии участия в сеансе связи от терминала №2

Следом приходит пакет, с помощью которого осуществляются процедуры контроля за качеством и передачей информации об участниках сессии сеанса связи, которые регламентирует протокол RTCP.

Протокол RTCP всегда работает вместе с протоколом RTP, который совместно с протоколом UDP, реализует функции транспортного уровня.

Взглянув на 62-ой кадр, можно увидеть, что происходит передача речевой информации в реальном времени, т.е. задействовался протокол RTP. Об этом говорит поля «Protocol» и «Info» в окне отслеживания трафика сетевого анализатора.

Часть строки выделенного 62-го фрейма «RTP | PT=ITU-TG.711 PCMU» (в соответствии с рисунком 29) дает нам понять, что полезной нагрузкой пакета (PayloadType) является звук, а именно - речь. Что отображает стандартизированныйITU аудиокодек G.711 с алгоритмом сжатия аналогового сигнала с дальнейшей оцифровкой, посредством применения Мю-закона (PCMU).

Рисунок 29 - Активное окно отслеживания сетевого трафика программы Wireshark

Помимо этого приходят ответы с UAS терминала №2 об установленном сеансе связи с терминалом №1. На что тот в свою очередь отправляет запрос о принятом ответе на предыдущий запрос INVATE.

После чего идет обмен речевой информацией без сообщений сигнализации.

Речевую информацию, которая была закодирована можно декодировать и прослушать с помощью сетевого анализатора Wireshark, который обладает инструментами для выполнения данных действий (см. рисунки 30 и 31).

Рисунок 30 - Панель анализа потока данных протокола RTP, с выделенной кнопкой плеера

Выделенными кнопками обозначена операция декодирования и проигрыша.

В момент окончания сессии сеанса связи задействуется также протокол SIP. В данном случае инициатором окончания сессии является пользователь Терминала №2 с IP-адресом 172.16.0.50. Это можно увидеть также в окне отслеживания трафика, где в поле информации находится сообщение BYE, адресованное терминалу с IP-адресом 172.16.0.108, информирующее его о том, что передача информации должна прекратиться и UAS терминала №1 должен отослать ответ OK с кодом 200, в соответствии с рисунком 32.

Рисунок 31 - Графически выведенный сигнал, который был декодирован.

Рисунок 32 - Окончание сеанса связи, путем отсылки запроса в кадре 400 и его подтверждения в кадре 403

Протоколы взаимодействия элементов компьютерной сети для обмена информацией можно также увидеть на рисунке 32. В нашем случае кадры, не содержащие сообщений с информацией о сеансе связи IP-телефонии, не подлежат анализу.

3.3.1 Пример анализа сценария с участием прокси-сервера

IP-адрес Терминала №2 неизвестен, но известно имя пользователя - 306. И в данном случае реализация сессии сеанса связи будет происходить путем начального обращения Терминала пользователя №1 (URI-305@172.24.0.167) к Прокси-серверу с IP-адресом 172.24.0.160, для поиска Терминала пользователя №2.

Для этого сеанса связи выделяются два порта UDP 5062 и 5060 со стороны Терминала №2 и Прокси-сервера,соответственно. Просмотреть информацию о значении портов можно в окне расшифровки поля протокола UDP, в соответствии с рисунком 33.

Рисунок 33 - Окно расшифровки с выделенным полем протокола UDP

В окне отслеживания трафика, с 9-го захваченного кадра будет наблюдаться процесс установления сессии сеанса связи. Где INVATE-запрос вызывающего автоматически адресуется Прокси-серверу, который в свою очередь должен определить местоположение вызываемого пользователя, в соответствии с рисунком 34.

Рисунок 34 - Инициализация сессии сеанса связи путем обмена сообщениями сигнализаций терминала №1 с Прокси-сервером

10-й кадр сигнализирует о том, что Пользователю №1 необходимо аутентифицировать себя Прокси-серверу перед совершением вызова (407ProxyAuthenticationRequired). На что Терминал №1 после отправки запроса о принятом ответе, отсылает новый INVATE-запрос уже с сформированным полем для аутентификации, в соответствии с рисунком 35.

Рисунок 35 - Окно расшифровки с выделенным полем «Proxy-Authorization»в поле заголовка SIP-сообщения

В данном случае аутентификация осуществляется аналогичным методом алгоритмирования, как и со сценарием непосредственного общения двух терминалов.

В результате после определения IP-адреса Терминала №2, в соответствии с рисунком 36. 34-ый кадр сигнализирует о том, что сессия может быть сформирована и вызываемый готов принять участие в сессии.

После чего пойдет установленный сеанс связи обмена речевой информации. А завершится сеанс связи стандартным сообщением BYE.

Рисунок 36 - Установленный сеанс связи двух терминалов с участием прокси-сервера

В окне расшифровки можно будет обнаружить, что в поле «тело сообщения» протокола SDP Прокси-сервер передает нам информацию о соединении, а именно IP-адрес вызываемого, в соответствии с рисунком 37.

Рисунок 37 - Окно расшифровки поля тела SIP-сообщения

Просмотреть информацию об установлении сеанса связи можно с помощью инструмента Wireshark «FlowGraph» в графе «Statistics» на панели управления, в соответствии с рисунком 38, на котором можно также увидеть номера портов UDP для определенного сеанса связи.

Рисунок 38 - Графически отображенный процесс управления сеансом связи с обращением к Прокси-серверу

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

В соответствии с рисунком 39 можно увидеть второй тестовый вариант мониторинга сети.

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

Терминал №1 имеет IP-адрес 172.16.0.163 (URI - 205@172.24.0.163), который является стороной, инициирующей сеанс связи с применением видеоаппаратуры. Терминал №2 является вызываемой стороной, имеющей IP-адрес 172.16.0.164 (URI - 204@172.16.0.164).

Рисунок 39 - Отслеживание процесса установления сеанса связи двух терминалов при передачи видео- и аудио- информации

Процесс попытки установления связи отслеживается с 3-го захваченного пакета. Команды запросов и ответов не отличаются от предыдущих. За то видно как задействовался по протоколу H.263 обмен видеоинформацией.

В сравнении с предыдущими дампами, в данном можно увидеть добавленное поле с информацией о типе видеоданных в протоколе описания сессии сеанса связи (SDP), в соответствии с рисунком 40, в котором поле типа нагрузки протокола SDP информирует идентификатором профиля RTP/AVP об установлении видео-сеанса связи.

40042 - это порт устройства, находящегося по IP-адресу 172.24.0.163, который ожидает прием видео-трафика. Аналогично указан номер порта (40044) устройства, на который будет передаваться аудио-трафик.

Рисунок 40 - Окно расшифровки с выделенным полем типа медиа-данных протокола SDP

Заключение

сетевой трафик телефония сниффер

В ходе проведенного анализа темы диплома: «Анализ сетевого трафика IP-телефонии с помощью пакетных снифферов», была получена и изучена информация, позволяющая сделать выводы о возможностях сетевого анализатора, используемого для мониторинга IP-телефонии. Применение данного сетевого анализатора позволяет отслеживать пути следования трафика и распознавать конечный пункт поступления информации, которая определяется MAC-адресом на канальном уровне и IP-адресом на сетевом уровне.

Таким образом, основная область применения данного сетевого анализатора - это организация и тестирование корпоративных сетей. Анализатор Wireshark позволяет рассмотреть возможные варианты обнаружения «прослушивания» трафика со стороны злоумышленника, а также просмотреть методы шифрования по защите данных.

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

Список используемой литературы

1. Microsoft Corporation. Компьютерные сети: Учебный курс. /Пер. с англ. - М.: Издательский отдел «Русская Редакция» ТОО «ChannelTradingLtd.». - 2-е изд., испр. И доп. - 1998.

2. Гольдштейн А.Б., Саморезов В.В. IP-телефония: методические рекомендации к лабораторным работам (спец. 200900)/СПбГУТб, СПб 2003.

3. Олифер В.Г, Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 2-е изд. - СПб.: Питер, 2005. - 864 с.

4. ITU-T Recommendation H.323. Packet based multimedia communication systems. Geneva, 1998.

5. RFC 2543. SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. March 1999

6. Гольдштейн, Б. С. Г63 Сетевые анализаторы IP сетей: учебное пособие / Б. С. Гольдштейн, В. Ю. Гойхман, Ю. В. Столповская; СПбГУТ. - СПб., 2013. - 56 с.

7. Анализаторы, снифферы. Бесплатные [электронный ресурс] - http://soft.mydiv.net/win/cname72/cname80/index.1.html

8. База знаний протокола RTP [электронный ресурс] - http://asterisk.ru/knowledgebase/RTP

9. СанПин 2.2.2/2.4.1340-03 "Гигиенические требования к персональным электронно-вычислительным машинам и организации работы"

Размещено на Allbest.ru