Рейтинг:  3 / 5

Звезда активнаЗвезда активнаЗвезда активнаЗвезда не активнаЗвезда не активна
 

Восстановление голоса из перехваченных RTP-потоков

На наших страницах не один раз появлялись материалы о том, как можно осуществлять аппаратный перехват трафика в сети. В тех случаях, когда перехват осуществляется с помощью SOHO-маршрутизаторов, у администратора нет возможности сохранять большие объёмы данных, либо делать перехват с большой скоростью. Казалось бы, для современных сетей это теряет актуальность, однако сегодня мы хотим представить одну ситуацию, в которой возможностей существующих продуктов будет достаточно. Речь идёт о перехвате голосового трафика для его последующего анализа и восстановления аудиоданных с помощью утилиты Wireshark.

Кроме описанных уже на нашем сайте способов аппаратного перехвата трафика существует и традиционный перехват с помощью самого же Wireshark, но для этого требуется, чтобы все необходимые потоки попадали и на компьютер со снифером. Этого можно достичь подключением всех узлов к концентратору, что, к сожалению, приведёт к падению производительности всей сети, поэтому такой вариант считаем неприемлемым. Ещё одним вариантом является возможность зеркалирования проходящих данных в специальный порт. Так, например, коммутаторы Catalyst 2950 компании Cisco Systems позволяют выделить отдельный интерфейс, в который будут перенаправляться интересующие потоки. В приведённой ниже конфигурации передаваемые через порт Fa0/5 данные будут копироваться в порт Fa0/10.

Switch(config)# monitor session 1 source interface fastEthernet0/5
Switch(config)# monitor session 1 destination interface fastEthernet0/10

Недостатком такой схемы будет невозможность обычной работы хоста, подключённого к порту Fa0/10. Другими словами узел, подключённый к интерфейсу Fa0/10 сможет только получать зеркалированные данные, но не сможет отправлять и получать свои собственные фреймы.

В проводных маршрутизаторах Linksys RVS4000 указанная выше проблема отсутствует, однако существует другая – администратор может получить только входящие данные, но не исходящие из порта. Конечно же, можно было бы зеркалировать все порты, но использование IPSec с WAN-порта может существенно усложнить задачу, если за RVS4000 расположен только один из собеседников, и телефонный трафик шифруется при передаче через интернет с помощью IPSec. Мы обращались в Linksys с этой проблемой несколько раз, но, к сожалению, не смогли получить никакого вразумительного ответа или обещания решить указанную проблему в будущих прошивках. Настроить зеркалирование входящего потока данных можно в пункте Port Mirroring меню L2 Switch.

Маршрутизатор ASUS RX3042H позволяет отдельно указать какие потоки и из каких портов необходимо зеркалировать. Увы, среди этих портов нет WAN-интерфейса. Настройка обсуждаемой возможности в данной модели производится с помощью пункта Port Mirroring меню Router Setup.

Предположим, что каким-то образом нам всё-таки удалось перехватить заветные пакеты и сохранить их. Откроем этот файл в Wireshark. В случае, когда пакеты RTP теряются среди огромного количества других данных, можно настроить фильтр, указав rtp в соответствующем поле.

Выберем один RTP-пакет из разговора и обратимся к меню Telephony-RTP-Stream Analysis.

Изучение статистической информации о перехваченном голосовом потоке не входит в наши планы, поэтому мы сразу перейдём к сохранению аудиоданных, для чего необходимо нажать кнопку Save payload…

В окне сохранения аудио-файла требуется указать его имя и местоположение, формат, а также выбрать сохраняемый канал-направление. К сожалению, в Wireshark с сохранением аудио-файла тоже не всё хорошо, вам придётся установить самую последнюю версию (хотя бы новее версии 1.2.4, в которой исправлена ошибка 4120) для того, чтобы иметь возможность сохранять в один файл оба направления.
Кроме непосредственного сохранения перехваченного телефонного разговора может возникнуть необходимость предварительного прослушивания записи. Для решения указанной проблемы требуется обратиться к меню Telephony-VoIP Calls, в котором будут представлены все перехваченные разговоры.

Далее требуется выбрать нужный разговор и нажать кнопку Player. В появившемся окне следует нажать кнопку Decode. Опция Use RTP timestamp позволяет использовать встроенные в RTP отметки времени вместо того, чтобы ориентироваться на время прибытия пакетов. Изменение параметра Jitter buffer [ms] позволяет эмулировать воспроизведение реального голосового потока с конкретного устройства с фиксированным объёмом входного буфера.

Сразу же после декодирования появляется возможность прослушивания перехваченного потока аудио-данных с помощью кнопок Play, Pause и Stop.

Краткий обзор голосовых возможностей Wireshark на этом завершается. В заключении добавим, что по похожему принципу строятся офисные системы записи телефонных переговоров: перехватывается весь поток данных SIP или H.323 сервера, а также трафик с самих телефонных аппаратов для последующего детального анализа. Задача существенно упрощается в том случае, когда под телефонию выделяется отдельный VLAN.

Добавить комментарий


Защитный код
Обновить