Принцип работы IP-телефонии (стр. 7 )

Рисунок 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).

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

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

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

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

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

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

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

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

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

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

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

IP-адрес Терминала №2 неизвестен, но известно имя пользователя – 306. И в данном случае реализация сессии сеанса связи будет происходить путем начального обращения Терминала пользователя №1 (URI–[email protected]) к Прокси-серверу с 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 – [email protected]), который является стороной, инициирующей сеанс связи с применением видеоаппаратуры. Терминал №2 является вызываемой стороной, имеющей IP-адрес 172.16.0.164 (URI – [email protected]).

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

Microsoft Corporation. Компьютерные сети: Учебный курс. /Пер. с англ. – М.: Издательский отдел «Русская Редакция» ТОО «ChannelTradingLtd.». – 2-е изд., испр. И доп. – 1998. , IP-телефония: методические рекомендации к лабораторным работам (спец. 200900)/СПбГУТб, СПб 2003. , Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 2-е изд. – СПб.: Питер, 2005. – 864 с. ITU-T Recommendation H.323. Packet based multimedia communication systems. Geneva, 1998. RFC 2543. SIP: Session Initiation Protocol. M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. March 1999 Гольдштейн, Б. С. Г63 Сетевые анализаторы IP сетей: учебное пособие / , , ; СПбГУТ. – СПб., 2013. – 56 с. Анализаторы, снифферы. Бесплатные [электронный ресурс] – http://soft. /win/cname72/cname80/index.1.html База знаний протокола RTP [электронный ресурс] – http://asterisk. ru/knowledgebase/RTP СанПин 2.2.2/2.4.1340-03 "Гигиенические требования к персональным электронно-вычислительным машинам и организации работы"

1адрес передачи широковещательных пакетов, также как и адрес маски зарезервирован