На сегодняшний день проблемы информационной безопасности в мире приобретают всё большую актуальность. В СМИ часто можно наткнуться на новость об очередной успешной хакерской атаке, крупной утечке критичных данных или очередном вирусе-вымогателе, который срывает работу целых компаний. Даже если Вы человек далёкий от информационной безопасности и мира информационных технологий, то Вы всё равно наверняка слышали о вирусе “WannaCry”, уязвимостях “Spectre” и “Meltdown” и может быть даже о недавней атаке на устройства компании Cisco, которая ударила по крупным провайдерам и парализовала много сервисов и сетевых сегментов.

Однако, широкой огласке обычно подвергаются новости об атаках и уязвимостях, носящие массовый характер, направленных на наиболее распространенные инфраструктурные системы. Мы же хотим рассказать о том, как обстоит ситуация с информационной безопасностью в отдельной в отдельно взятой сфере - IP телефонии и решений VoIP. Разберём наиболее важные проблемы и тренды развития данного направления.

Проблемы информационной безопасности в VoIP

Если раньше, выбирая на чём строить офисную телефонию, заказчиков больше всего волновали вопросы стоимости и надёжности, то в связи с нынешним положением, вопросы защиты и безопасности всё чаще начинают преобладать. Хотя IP телефония имеет массу преимуществ по сравнению с системами традиционной телефонии, её намного легче взломать. В случае с традиционной системой PSTN злоумышленник должен получить физический доступ к среде передачи или системам, которые задействованы в обмене голосовой информацией. IP телефония – это прежде всего сеть с коммутацией пакетов, которые передаются на ряду с другими корпоративными сервисами – Интернетом, почтой и другими. Если эта сеть недостаточно защищена, то злоумышленнику даже не обязательно находиться в одной стране с системой IP телефонии, чтобы получить доступ к критичным данным, украсть их или модифицировать.

Вот почему необходимо обеспечивать многоуровневую защиту систем корпоративной IP телефонии. Недостаточно просто поставить стойкий пароль к интерфейсу управления. Это должен быть чёткий набор определённых мер, применяемых в комплексе – межсетевое экранирование, антивирусная защита, регулярные обновления программного обеспечения, шифрование передаваемых данных и другое.

Отдельно следует уделить внимание повышению осведомлённости своих сотрудников об атаках из разряда социальной инженерии. Одним из наиболее распространённых векторов атаки данного типа на сегодняшний день является “фишинг”. Суть его заключается в том, что злоумышленник рассылает “письма счастья” с вредоносными вложениями, в надежде на то, что человек откроет это вложение и тем самым, загрузит на свой компьютер вредонос. Защититься от таких атак можно сразу на нескольких уровнях:

1. Межсетевой экран, на котором адрес отправителя фишинговых писем должен быть заблокирован. Автоматизировать процесс получения актуального списка адресов активных отправителей для блокировки на МСЭ, можно с помощью решений Threat Intelligence. Существуют как платные решения от таких компаний как Anomali, ThreatConnect или EclecticIQ, так и OpenSource, например, YETI и MISP.
2. Решение для защиты почтового сервера, которое проверяет все письма на предмет подозрительных вложений, адреса отправителя, блокирует спам. Примерами таких решений является Kaspersky Security для почтовых серверов, AVG Email Server Edition для ME, McAfee Security for Email Servers. Кстати, в этом случае также можно автоматизировать процесс блокировки с помощью решений TI.
3. Антивирусное ПО для защиты оконечных устройств, которое заблокирует опасное вложение, если всё-таки вредонос сможет пролезть через МСЭ и почтовый сервер. Для этого подойдёт Kaspersky Endpoint Security, Norton, Trend Micro и другие.

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

Существует также телефонный “вишинг”. Этот тип атаки направлен на первую линию сотрудников, которые принимают все входящие звонки в Вашей компании. На общий номер поступает звонок от какой-нибудь известной организации или персоны, а дальше с помощью методов психологического давления, доверчивого сотрудника заставляют что-либо сделать. В самом лучшем случае, позвонивший будет агрессивно требовать соединить его с руководством компании, чтобы предложить какие-нибудь услуги, в самом худшем - выдать конфиденциальную или критически важную информацию. А что, если злоумышленник узнает каким банком обслуживается Ваша компания и позвонит бухгалтеру от лица “Вашего банка”? К такому тоже нужно быть готовым.

Защититься от подобного типа атак можно было бы с помощью некоего аналога Threat Intelligence для VoIP – списка телефонных номеров, с которых поступают “фишинговые” и “вишинговые” звонки, чтобы заблокировать их на АТС. Однако, такого решения пока нет, поэтому придётся просвещать сотрудников на тему безопасности.

Безопасность облачных систем

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

Аналогично обстоят дела и в сфере VoIP. Каждый крупный провайдер IP телефонии имеет в своем наборе услуг облачную АТС, которая настраивается в считанные минуты и способна обеспечить телефонией компанию любого размера и неважно где территориально она расположена. Облачная или виртуальная АТС – это очень удобное решение, которое привлекает заказчиков тем, что не надо держать лишние сервера в здании и обслуживать их. Вместо этого, можно просто арендовать необходимые серверные мощности или сервис телефонии. Однако, с точки зрения информационной безопасности, облачные АТС – это идеальная цель для хакерских атак. Потому что, как правило, аккаунты для доступа к настройкам АТС, находятся в открытом доступе. Если владелец аккаунта не озаботится созданием стойкого пароля, то он рискует оплатить немаленький счёт за телефонные разговоры злоумышленника или предоставить доступ к записям разговоров своих сотрудников. В этой связи при выборе провайдера следует также проверить обеспечивает ли он дополнительные мероприятия по защите целостности и конфиденциальности данных. Используется шифрование при подключении к аккаунту с настройками облачной АТС, шифруются ли данные при их транспортировке.

Тренды развития направления ИБ в VoIP

Наиболее распространённым методом защиты корпоративной инфраструктуры является организация защищённой сети VPN, когда подключение извне осуществляется по зашифрованному каналу, а данные внутри сети передаются в незашифрованном виде. Это относится и к голосовому трафику. Однако, тенденции развития информационных технологий указывают на то, что в недалёком будущем голосовая информация также будет подвергаться шифрованию. Большинство VoIP вендоров уже давно имплементируют в своих решениях поддержку таких протоколов как SIP/TLS, SRTP, ZRTP и д.р, стимулируя пользователей применять внедрять ещё один уровень защиты. Например, большинство IP-телефонов и решений видеоконференцсвязи от компании Cisco, а также системы CUCM, CUBE, Cisco SBC, UCCS и д.р поддерживают TLS 1.2 и SRTP. Самое распространённое Open Source решение IP-АТС Asterisk имеет поддержку защищённых протоколов передачи медиа трафика начиная с версии 1.8. В программной Windows-based АТС 3CX версии V15, поддержка SRTP включена по умолчанию.

VoIP решения зачастую очень тесно интегрируются с другими корпоративными системами, такими как CRM, ERP, CMS, не говоря уже о таких каналах бизнес коммуникаций как email, обмен мгновенными сообщениями (чат) и социальные сети, формируя в совокупности концепцию UC (Unified Communications). Потенциальные преимущества, которые несёт данная концепция очень привлекательны, но вместе с тем, создаётся множество точек уязвимых к возможному взлому. Недостаточный уровень защиты одной из них может быть угрозой всей корпоративной сети. Поэтому разработчики, несомненно, будут усиливать безопасность каналов интеграции данных систем.

Можно также ожидать интеграцию систем корпоративной телефонии в такие средства защиты как DLP (средства защиты от утечек), адаптации метрик VoIP в SIEM системах (система управления информацией и событиями безопасности), а также появление унифицированных репутационных баз (Threat Intelligence) со списками потенциально опасных номеров или других индикаторов компрометации, относящихся к VoIP, которые будут автоматически блокироваться имеющимися средствами защиты.

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас:(Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Введение

1 Построение сети IP-телефонии

1.1 Транспортные технологии пакетной коммутации

1.2 Уровни архитектуры ІР-телефонии

1.3 Различные подходы к построению сетей IP-телефонии

1.3.1 Сеть на базе протокола Н.323

1.3.2 Сеть на базе протокола SIP

1.3.3 Сеть на базе MGCP

1.4 Сравнение подходов к построению сети ІР-телефонии

1.5 Варианты систем ІР-телефонии (сценарии)

2. Типы угроз в IP-телефонии и методы борьбы с ними

2.1 Типы угроз в IP-телефонии

2.2 Методы криптографической защиты информации

2.3 Защита от прослушивания

2.4 Защищенность сети доступа

2.5 Технологии аутентификации

3. Обеспечение безопасности с точки зрения проверки прав доступа к ресурсам (ААА). Сравнение протоколов TACACS+ и RADIUS

3.1 Непрямая аутентификация

3.2 Технологии ААА на основе протокола TACACS+

3.2.1 Протокол TACACS+

3.2.2 Свойства протокола TACACS+

3.2.3 Процессы ААА в протоколе TACACS+

3.3 Технологии ААА на базе протокола RADIUS

3.3.1 Протокол RADIUS

3.3.2 Свойства и возможности протокола RADIUS

3.3.4 Процесс аудита на базе протокола RADIUS

3.3.5 Сравнение возможностей протоколов TACACS+ и RADIUS

3.3.6 Технические несоответствия с теоретическими характеристиками протоколов TACACS и RADIUS

Заключение

Список использованных источников

Введение

У IP-телефонии есть достаточное количество преимуществ, чтобы вскоре распространиться по всей нашей стране; учитывая экономические аспекты и послание Президента Республики Казахстан Нурсултана Абишевича Назарбаева народу Казахстана «Новое десятилетие, новый экономический подъем, новые возможности Казахстана»: «Лидирующие экономики мира будут функционировать в более сложных, конкурентных условиях и предпримут превентивные меры по подготовке к следующему экономическому циклу, наращивая производительность рабочей силы, инвестирование в инфраструктуру и телекоммуникации, укрепляя финансовые системы, повышая эффективность государственного управления, а также создавая благоприятные условия для развития бизнеса».

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

Осталось в прошлом то время, когда операторы с опасением относились к использованию IP-телефонии, считая уровень защищенности таких сетей низким. Сегодня уже можно говорить о том, что IP-телефония стала неким стандартом в телефонных коммуникациях. Это объясняется удобством, относительной надежностью и относительно невысокой стоимостью IP-телефонии по сравнению с аналоговой связью. Можно утверждать, что IP-телефония повышает эффективность ведения бизнеса и позволяет осуществлять такие ранее недоступные операции, как интеграция с различными бизнес-приложениями.

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

Несмотря на то, что при построении инфраструктуры IP-телефонии данную службу обычно отделяют от сегментов сети, в которых «ходят» не голосовые данные, это еще не является гарантией безопасности. Сегодня большое количество компаний интегрируют IP-телефонию с другими приложениями, например с электронной почтой. С одной стороны, таким образом появляются дополнительные удобства, но с другой -- и новые уязвимости. Кроме того, для функционирования сети IP-телефонии требуется большое число компонентов, таких, как серверы поддержки, коммутаторы, маршрутизаторы, межсетевые экраны, IP-телефоны и т. д..

Среди основных угроз, которым подвергается IP-телефонная сеть, можно выделить:

Регистрацию чужого терминала, позволяющую делать звонки за чужой счет;

Подмену абонента;

Завершение сеанса связи;

Отказ в обслуживании;

Удаленный несанкционированный доступ к компонентам инфраструктуры IP-телефонии;

Несанкционированное обновление ПО на IP-телефоне (например, с целью внедрения троянской или шпионской программы);

Взлом биллинговой системы (для операторской телефонии).

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

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

1 . Построение сети IP -телефонии

1.1 Транспортные технологии пакетной коммутации

Большинство производителей, располагающих широким ассортиментом продукции для пакетной телефонии, занимают «технологически нейтральное» положение и предоставляют покупателю возможность самому выбирать ту технологию, которая лучше всего соответствует его интеграционной стратегии. Основные технологии пакетной передачи речи - Frame Relay, ATM и маршрутизация пакетов IP - различаются эффективностью использования каналов связи, степенью охвата разных участков сети, надежностью, управляемостью, защитой информации и доступа, а также стоимостью .

Рисунок 1.1. Речь по АТМ

Рисунок 1.2. Речь по Frame Relay

Рисунок 1.3. Речь по IP

Транспортная технология ATM уже несколько лет успешно используется в магистральных сетях общего пользования и в корпоративных сетях, а сейчас ее начинают активно использовать и для высокоскоростного доступа по каналам xDSL (для небольших офисов) и SDH/Sonet (для крупных предприятий).

Главные преимущества этой технологии - ее зрелость, надежность и наличие развитых средств эксплуатационного управления сетью. В ней имеются непревзойденные по своей эффективности механизмы управления качеством обслуживания и контроля использования сетевых ресурсов. Однако ограниченная распространенность и высокая стоимость оборудования не позволяют считать ATM лучшим выбором для организации сквозных телефонных соединений от одного конечного узла до другого. Технологии Frame Relay суждено было сыграть в пакетной телефонии ту же роль, что и квазиэлектронным АТС в телефонии с коммутацией каналов: они показали пример эффективной программно управляемой техники, но имели ограниченные возможности дальнейшего развития.

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

Технология передачи речевой информации по сетям с маршрутизацией пакетов IP привлекает, в первую очередь, своей универсальностью - речь может быть преобразована в поток IP-пакетов в любой точке сетевой инфраструктуры: на магистрали сети оператора, на границе территориально распределенной сети, в корпоративной сети и даже непосредственно в терминале конечного пользователя. В конце концов, она станет наиболее широко распространенной технологией пакетной телефонии, поскольку способна охватить все сегменты рынка, будучи при этом хорошо адаптируемой к новым условиям применения. Несмотря на универсальность протокола IP, внедрение систем IP-телефонии сдерживается тем, что многие операторы считают их недостаточно надежными, плохо управляемыми и не очень эффективными. Но грамотно спроектированная сетевая инфраструктура с эффективными механизмами обеспечения качества обслуживания делает эти недостатки малосущественными. В расчете на порт стоимость систем IP-телефонии находится на уровне (или немного ниже) стоимости систем Frame Relay, и заведомо ниже стоимости оборудования ATM. При этом уже сейчас видно, что цены на продукты IP-телефонии снижаются быстрее, чем на другие изделия, и что происходит значительное обострение конкуренции на этом рынке.

1.2 Уровни архитектуры IP-телефонии

Архитектура технологии Voice over IP может быть упрощенно представлена в виде двух плоскостей. Нижняя плоскость - это базовая сеть с маршрутизацией пакетов IP, верхняя плоскость - это открытая архитектура управления обслуживанием вызовов (запросов связи).

Нижняя плоскость, говоря упрощенно, представляет собой комбинацию известных протоколов Интернет: это - RTP (Real Time Transport Protocol), который функционирует поверх протокола UDP (User Datagram Protocol), расположенного, в свою очередь, в стеке протоколов TCP/IP над протоколом IP.

Таким образом, иерархия RTP/UDP/IP представляет собой своего рода транспортный механизм для речевого трафика. Здесь же отметим, что в сетях с маршрутизацией пакетов IP для передачи данных всегда предусматриваются механизмы повторной передачи пакетов в случае их потери.

При передаче информации в реальном времени использование таких механизмов только ухудшит ситуацию, поэтому для передачи информации, чувствительной к задержкам, но менее чувствительной к потерям, такой как речь и видеоинформация, используется механизм негарантированной доставки информации RTP/UDPD/IP. Рекомендации ITU-Т допускают задержки в одном направлении не превышающие 150 мс. Если приемная станция запросит повторную передачу пакета IP, то задержки при этом будут слишком велики .

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

Инструмент такого управления - телефонные системы сигнализации, начиная с систем, поддерживаемых декадно-шаговыми АТС и предусматривающих объединение функций маршрутизации и функций создания коммутируемого разговорного канала в одних и тех же декадно-шаговых искателях. Далее принципы сигнализации эволюционировали к системам сигнализации по выделенным сигнальным каналам, к многочастотной сигнализации, к протоколам общеканальной сигнализации №7 и к передаче функций маршрутизации в соответствующие узлы обработки услуг Интеллектуальной сети.

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

Такими протоколами на сегодня являются: RIP - Routing Information Protocol, IGRP - Interior Gateway Routing Protocol, EIGRP - Enhanced Interior Gateway Routing Protocol, IS-IS - Intermediate System-to- intermediate System, OSPF - Open Shortest Path First, BGP - Border Gateway Protocol и др. Точно так же и для IP-телефонии разработан целый ряд протоколов.

Наиболее распространенным является протокол, специфицированный в рекомендации Н.323 ITU-T, в частности, потому, что он стал применяться раньше других протоколов, которых, к тому же, до внедрения Н.323 вообще не существовало.

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

Еще один протокол - SGCP - разрабатывался, начиная с 1998 года, для того, чтобы уменьшить стоимость шлюзов за счет реализации функций интеллектуальной обработки вызова в централизованном оборудовании. Протокол IPDC очень похож на SGCP, но имеет много больше, чем SGCP, механизмов эксплуатационного управления (ОАМ&Р). В конце 1998 года рабочая группа MEGACO комитета IETF разработала протокол MGCP, базирующийся, в основном, на протоколе SGCP, но с некоторыми добавлениями в части ОАМ&Р.

Рабочая группа MEGACO не остановилась на достигнутом, продолжала совершенствовать протокол управления шлюзами и разработала более функциональный, чем MGCP, протокол MEGACO .

1.3 Различные подходы к построению сетей IP-телефонии

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

1.3 .1 Сеть на базе протокола Н.323

Первый в истории подход к построению сетей IP-телефонии на стандартизованной основе предложен Международным союзом электросвязи (ITU) в рекомендации Н.323. Сети на базе протоколов Н.323 ориентированы на интеграцию с телефонными сетями и могут рассматриваться как сети ISDN, наложенные на сети передачи данных.

В частности, процедура установления соединения в таких сетях IP-телефонии базируется на рекомендации Q.931 и аналогична процедуре, используемой в сетях ISDN.

Рекомендация Н.323 предусматривает довольно сложный набор протоколов, который предназначен не просто для передачи речевой информации по IP-сетям с коммутацией пакетов. Его цель - обеспечить работу мультимедийных приложений в сетях с негарантированным качеством обслуживания. Речевой трафик - это только одно из приложений Н.323, наряду с видеоинформацией и данными.

Вариант построения сетей IP-телефонии, предложенный Международным союзом электросвязи в рекомендации Н.323, хорошо подходит тем операторам местных телефонных сетей, которые заинтересованы в использовании сети с коммутацией пакетов (IP-сети) для предоставления услуг междугородной и международной связи. Протокол RAS, входящий в семейство протоколов Н.323, обеспечивает контроль использования сетевых ресурсов, поддерживает аутентификацию пользователей и может обеспечивать начисление платы за услуги.

На рисунке 1.4 представлена архитектура сети на базе рекомендации Н.323. Основными устройствами сети являются: терминал (Terminal), шлюз (Gateway), привратник (Gatekeeper) и устройство управления конференциями (Multipoint Control Unit- MCU).

Рисунок 1.4. Архитектура сети Н.323

Терминал Н.323 - оконечное устройство пользователя сети IP-телефонии, которое обеспечивает двухстороннюю речевую (мультимедийную) связь с другим терминалом Н.323, шлюзом или устройством управления конференциями .

Шлюз IP-телефонии реализует передачу речевого трафика по сетям с маршрутизацией пакетов IP по протоколу Н.323. Основное назначение шлюза - преобразование речевой информации, поступающей со стороны ТФОП, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP. Кроме того, шлюз преобразует сигнальные сообщения систем сигнализации DSS1 и ОКС7 в сигнальные сообщения Н.323 и производит обратное преобразование в соответствии с рекомендацией ITU H.246.

В привратнике сосредоточен весь интеллект сети IP-телефонии.

Сеть, построенная в соответствии с рекомендацией Н.323, имеет зонную архитектуру (рисунок 1.5). Привратник выполняет функции управления одной зоной сети IP-телефонии, в которую входят: терминалы, шлюзы, устройства управления конференциями, зарегистрированные у данного привратника. Отдельные фрагменты зоны сети Н.323 могут быть территориально разнесены и соединяться друг с другом через маршрутизаторы.

Рисунок 1.5. Зона сети Н.323

Наиболее важными функциями привратника являются:

Регистрация оконечных и других устройств;

Контроль доступа пользователей системы к услугам IP-телефонии при помощи сигнализации RAS;

Преобразование вызываемого пользователя (объявленного имени абонента, телефонного номера, адреса электронной почты и др.) в транспортный адрес сетей с маршрутизацией пакетов IP (IP адрес + номер порта TCP);

Контроль, управление и резервирование пропускной способности сети;

Ретрансляция сигнальных сообщений Н.323 между терминалами.

В одной сети IP-телефонии, отвечающей требованиям рекомендации ITU Н.323, может находиться несколько привратников, взаимодействующих друг с другом по протоколу RAS.

Кроме основных функций, определенных рекомендацией Н.323, привратник может отвечать за аутентификацию пользователей и начисление платы (биллинг) за телефонные соединения. Устройство управления конференциями обеспечивает возможность организации связи между тремя или более участниками .

Рекомендация Н.323 предусматривает три вида конференции (рисунок 1.6): централизованная (т.е. управляемая MCU, с которым каждый участник конференции соединяется в режиме точка-точка), децентрализованная (когда каждый участник конференции соединяется с остальными ее участниками в режиме точка-группа точек) и смешанная.

Преимуществом централизованной конференции является сравнительно простое терминальное оборудование, недостатком - большая стоимость устройства управления конференциями.

Для децентрализованной конференции требуется более сложное терминальное оборудование и желательно, чтобы в сети IP поддерживалась передача пакетов IP в режиме многоадресной рассылки (IP multicasting). Если этот режим в сети не поддерживается, терминал должен передавать речевую информацию каждому из остальных участников конференции в режиме точка-точка.

Устройство управления конференциями состоит из одного обязательного элемента - контроллера конференций (Multipoint Controller - МС), и, кроме того, может включать в себя один или более процессоров для обработки пользовательской информации (Multipoint Processor - МР). Контроллер может быть физически совмещен с привратником, шлюзом или устройством управления конференциями, а последнее, в свою очередь, может быть совмещено со шлюзом или привратником.

Рисунок. 1.6. Виды конференции в сетях Н.323

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

Так как контроллеров в сети может быть несколько, для каждой вновь создаваемой конференции должна быть проведена специальная процедура выявления того контроллера, который будет управлять данной конференцией.

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

Существует еще один элемент сети Н.323 - прокси-сервер Н.323, т.е. сервер-посредник. Этот сервер функционирует на прикладном уровне и может проверять пакеты с информацией, которой обмениваются два приложения.

Прокси-сервер может определять, с каким приложением (Н.323 или другим) ассоциирован вызов, и осуществлять нужное соединение. Прокси-сервер выполняет следующие ключевые функции:

Подключение через средства коммутируемого доступа или локальные сети терминалов, не поддерживающих протокол резервирования ресурсов (RSVP). Два таких прокси-сервера могут образовать в IP-сети туннельное соединение с заданным качеством обслуживания;

Маршрутизацию трафика Н.323 отдельно от обычного трафика данных;

Обеспечение совместимости с преобразователем сетевых адресов, поскольку допускается размещение оборудования Н.323 в сетях с пространством адресов частных сетей;

Защиту доступа - доступность только для трафика Н.323.

Протокол RAS (Registration Admission Status) обеспечивает взаимодействие оконечных и других устройств с привратником.

Основными функциями протокола являются: регистрация устройства в системе, контроль его доступа к сетевым ресурсам, изменение полосы пропускания в процессе связи, опрос и индикация текущего состояния устройства. В качестве транспортного протокола используется протокол с негарантированной доставкой информации UDP.

Протокол Н.225.0 (Q.931) поддерживает процедуры установления, поддержания и разрушения соединения. В качестве транспортного протокола используется протокол с установлением соединения и гарантированной доставкой информации TCP.

По протоколу Н.245 происходит обмен между участниками соединения информацией, которая необходима для создания логических каналов. По этим каналам передается речевая информация, упакованная в пакеты RTP/UDP/IP.

Выполнение процедур, предусмотренных протоколом RAS, является начальной фазой установления соединения с использованием сигнализации Н.323. Далее следуют фаза сигнализации Н.225.0 (Q.931) и обмен управляющими сообщениями Н.245. Разрушение соединения происходит в обратной последовательности: в первую очередь закрывается управляющий канал Н.245 и сигнальный канал Н.225.0, после чего привратник по каналу RAS оповещается об освобождении ранее занимавшейся полосы пропускания .

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

Рассмотрим шаг за шагом этот упрощенный сценарий.

1) Оконечное устройство пользователя А посылает запрос соединения - сообщение SETUP - к оконечному устройству пользователя В на ТСР-порт1720;

2) Оконечное устройство вызываемого пользователя В отвечает на сообщение SETUP сообщением ALERTING, означающим, что устройство свободно, а вызываемому пользователю подается сигнал о входящем вызове;

3) После того, как пользователь В принимает вызов, к вызывающей стороне А передается сообщение CONNECT с номером ТСР-порта управляющего канала Н.245;

4) Оконечные устройства обмениваются по каналу Н.245 информацией о типах используемых речевых кодеков (G.729, G.723.1 и т.д.), а также о других функциональных возможностях оборудования, и оповещают друг друга о номерах портов RTP, на которые следует передавать информацию;

5) Открываются логические каналы для передачи речевой информации;

6) Речевая информация передаётся в обе стороны в сообщениях протокола RTP; кроме того, ведется контроль передачи информации при помощи протокола RTCP.

Рисунок 1.7. Упрощённый сценарий установления соединения в сети Н.323

Приведенная процедура обслуживания вызова базируется на протоколе Н.323 версии 1. Версия 2 протокола Н.323 позволяет передавать информацию, необходимую для создания логических каналов, непосредственно в сообщении SETUP протокола Н.225.0 без использования протокола Н.245.

Такая процедура называется «быстрый старт» (Fast Start) и позволяет сократить количество циклов обмена информацией при установлении соединения. Кроме организации базового соединения, в сетях Н.323 предусмотрено предоставление дополнительных услуг в соответствии с рекомендациями ITU H.450.X .

Следует отметить еще одну важную проблему - качество обслуживания в сетях Н.323. Оконечное устройство, запрашивающее у привратника разрешение на доступ, может, используя поле transportQoS в сообщении ARQ протокола RAS, сообщить о своей способности резервировать сетевые ресурсы.

Рекомендация Н.323 определяет протокол резервирования ресурсов (RSVP) как средство обеспечения гарантированного качества обслуживания, что предъявляет к терминалам требование поддержки протокола RSVP. К сожалению, протокол RSVP используется отнюдь не повсеместно, что оставляет сети Н.323 без основного механизма обеспечения гарантированного качества обслуживания. Это - общая проблема сетей IP-телефонии, характерная не только для сетей Н.323.

1.3.2 Сеть на базе протокола SIP

Второй подход к построению сетей IP-телефонии, предложенный рабочей группой MMUSIC комитета IETF в документе RFC 2543, основан на использовании протокола SIP - Session Initiation Protocol .

SIP представляет собой текстоориентированный протокол, который является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force (IETF).

Эта архитектура также включает в себя протокол резервирования ресурсов (Resource Reservation Protocol, RSVP, RFC 2205), транспортный протокол реального времени (Real-Time Transport Protocol, RTP, RFC 1889), протокол передачи потоков в реальном времени (Real-Time Streaming Protocol, RTSP, RFC 2326), протокол описания параметров связи (Session Description Protocol, SDP, RFC 2327), протокол уведомления о связи (Session Announcement Protocol, SAP). Однако функции протокола SIP не зависят от любого из этих протоколов.

Сразу следует отметить, что хотя на сегодня наиболее широкое распространение получил протокол Н.323, всё большее количество производителей старается предусмотреть в своих новых продуктах поддержку протокола SIP.

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

Подход SIP к построению сетей IP-телефонии намного проще в реализации, чем Н.323, но меньше подходит для организации взаимодействия с телефонными сетями. В основном это связано с тем, что протокол сигнализации SIP, базирующийся на протоколе HTTP, плохо согласуется с системами сигнализации, используемыми в ТфОП. Поэтому протокол SIP более подходит поставщикам услуг Интернет для предоставления услуги IP-телефонии, причем эта услуга будет являться всего лишь частью пакета услуг.

Тем не менее, протокол SIP поддерживает услуги интеллектуальной сети (IN), такие как преобразование (мэппинг) имён, переадресация и маршрутизация, что существенно для использования SIP в качестве протокола сигнализации в сети общего пользования, где приоритетной задачей оператора является предоставление широкого спектра телефонных услуг.

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

Это свойство SIP не уникально, и, например, протокол Н.323 тоже в значительной степени поддерживает такую возможность. Сейчас настал момент, когда эта возможность станет главной привлекательной чертой сетей IP-телефонии нового поколения. Данный режим работы потребует дистанционной регистрации пользователей на сервере идентификации и аутентификации .

Перейдем непосредственно к архитектуре сетей, базирующихся на протоколе SIP (рисунок 1.8).

Рисунок 1.8. Пример сети на базе протокола SIP

Сеть SIP содержит основные элементы трех видов: агенты пользователя, прокси-серверы и серверы переадресации.

Агенты пользователя (User Agent или SIP client) являются приложениями терминального оборудования и включают в себя две составляющие: агент пользователя - клиент (User Agent Client - UAC) и агент пользователя - сервер (User Agent Server - UAS), иначе известные как клиент и сервер соответственно.

Клиент UAC инициирует SIP-запросы, т.е. выступает в качестве вызывающей стороны. Сервер UAS принимает запросы и возвращает ответы, т.е. выступает в качестве вызываемой стороны.

Кроме того, существует два типа сетевых серверов SIP: прокси-серверы (серверы-посредники) и серверы переадресации.

Серверы SIP могут работать как в режиме с сохранением состояний текущих соединений (statefull), так и в режиме без сохранения состояний текущих соединений (stateless).

Сервер SIP, функционирующий в режиме stateless, может обслужить сколь угодно большое количество пользователей, в отличие от привратника Н.323, который может одновременно работать с ограниченным количеством пользователей.

Прокси-сервер (Proxy-server) действует «от имени других клиентов» и содержит функции клиента (UAC) и сервера (UAS). Этот сервер интерпретирует и может перезаписывать заголовки запросов перед отправкой их к другим серверам (рисунок 1.9). Ответные сообщения следуют по тому же пути обратно к прокси-серверу, а не к клиенту.

Рисунок 1.9. Сеть SIP с прокси-сервером

На рисунке 1.9 представлен алгоритм установления соединения с помощью протокола SIP при участии прокси-сервера:

1) Прокси-сервер принимает запрос соединения INVITE от оборудования вызывающего пользователя;

2) Прокси-сервер устанавливает местонахождение клиента с помощью сервера определения местоположения (location server);

3) Прокси-сервер передает запрос INVITE вызываемому пользователю;

4) Оборудование вызываемого пользователя уведомляет последнего о входящем вызове и возвращает прокси-серверу сообщение о том, что запрос INVITE обрабатывается (код 100). Прокси-сервер, в свою очередь, направляет эту информацию оборудованию вызывающего пользователя;

5) Когда вызываемый абонент принимает вызов, его оборудование извещает об этом прокси-сервер (код 200), который переправляет информацию о том, что вызов принят, к оборудованию вызывающего пользователя;

6) Вызывающая сторона подтверждает установление соединения передачей запроса АСК, которое прокси-сервер переправляет вызываемой стороне. Установление соединения закончено, абоненты могут обмениваться речевой информацией .

Сервер переадресации (Redirect server) определяет текущее местоположение вызываемого абонента и сообщает его вызывающему пользователю (рисунок 1.10). Для определения текущего местоположения вызываемого абонента сервер переадресации обращается к серверу определения местоположения, принципы работы которого в документе RFC 2543 не специфицированы.

Алгоритм установления соединения с использованием протокола SIP при участии сервера переадресации выглядит следующим образом:

1) Сервер переадресации принимает от вызывающей стороны запрос соединения INVITE и связывается с сервером определения местонахождения, который выдает текущий адрес вызываемого клиента;

2) Сервер переадресации передает этот адрес вызывающей стороне. В отличие от прокси-сервера, запрос INVITE к оборудованию вызываемого пользователя сервер переадресации не передает;

3) Оборудование вызывающего пользователя подтверждает завершение транзакции с сервером переадресации запросом АСК;

5) Оборудование вызываемого пользователя уведомляет последнего о входящем вызове и возвращает вызывающему оборудованию сообщение о том, что запрос INVITE обрабатывается (код 100);

6) Когда вызываемый абонент принимает вызов, об этом извещается оборудование вызывающего пользователя (код 200).Установление соединения закончено, абоненты могут обмениваться речевой информацией.

Рисунок 1.10. Сеть SIP с сервером переадресации

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

Сигнализация SIP дает возможность пользовательским агентам и сетевым серверам определять местоположение, выдавать запросы и управлять соединениями.

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

АСК - запрос подтверждает прием от вызываемой стороны ответа на команду INVITE и завершает транзакцию.

OPTIONS - запрос позволяет получить информацию о функциональных возможностях пользовательских агентов и сетевых серверов. Однако этот запрос не используется для организации сеансов связи.

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

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

1. 3.3 Сеть на базе MGCP

Третий подход к построению сетей IP-телефонии, основанный на использовании протокола MGCP, также предложен комитетом IETF, рабочей группой MEGACO.

При разработке этого протокола рабочая группа MEGACO опиралась на сетевую архитектуру, содержащую основные функциональные блоки трех видов (рисунок 1.11):

Шлюз - Media Gateway (MG), который выполняет функции преобразования речевой информации, поступающей со стороны ТфОП с постоянной скоростью передачи, в вид, пригодный для передачи по сетям с маршрутизацией пакетов IP (кодирование и упаковку речевой информации в пакеты RTP/UDP/IP, а также обратное преобразование);

Контроллер шлюзов - Call Agent, которой выполняет функции управления шлюзами;

Шлюз сигнализации - Signaling Gateway (SG), который обеспечивает доставку сигнальной информации, поступающей со стороны ТфОП, к контроллеру шлюзов и перенос сигнальной информации в обратном направлении.

Таким образом, весь интеллект функционально распределенного шлюза сосредоточен в контроллере, функции которого могут быть распределены между несколькими компьютерными платформами .

Рисунок 1.11. Архитектура сети на базе протокола MGCP

Шлюз сигнализации выполняет функции STP - транзитного пункта сети сигнализации ОКС7. Сами шлюзы выполняют только функции преобразования речевой информации. Один контроллер управляет одновременно несколькими шлюзами.

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

В ряде работ, посвященных исследованию возможностей протокола MGCP, для этой цели предлагается использовать протоколы Н.323, SIP или ISUP/IP. Сообщения протокола MGCP переносятся протоколом без гарантированной доставки сообщений UDP. Рабочая группа SIGTRAN комитета IETF в настоящее время разрабатывает механизм взаимодействия контроллера шлюзов и шлюза сигнализации.

Шлюз сигнализации должен принимать поступающие из ТфОП пакеты трех нижних уровней системы сигнализации ОКС7 (уровней подсистемы переноса сообщений МТР) и передавать сигнальные сообщения верхнего, пользовательского, уровня к контроллеру шлюзов. Шлюз сигнализации также должен уметь передавать по IP-сети приходящие из ТфОП сигнальные сообщения Q.931.

Основное внимание рабочей группы SIGTRAN уделяется вопросам разработки наиболее эффективного механизма передачи сигнальной информации по IP-сетям.

Следует отметить, что существует несколько причин, по которым пришлось отказаться от использования для этой цели протокола TCP. Рабочая группа SIGTRAN предлагает использовать для передачи сигнальной информации протокол Stream Control Transport Protocol (SCTP), имеющий ряд преимуществ перед протоколом ТСР, основным из которых является значительное снижение времени доставки сигнальной информации и, следовательно, времени установления соединения - одного из важнейших параметров качества обслуживания.

Если в ТфОП используется сигнализация по выделенным сигнальным каналам (ВСК), то сигналы сначала поступают вместе с пользовательской информацией в транспортный шлюз, а затем передаются в контроллер шлюзов без посредничества шлюза сигнализации .

Отметим, что протокол MGCP является внутренним протоколом для обмена информацией между функциональными блоками распределенного шлюза, который извне представляется одним шлюзом. Протокол MGCP является master/slave протоколом. Это означает, что контроллер шлюзов является ведущим, а сам шлюз - ведомым устройством, которое должно выполнять все команды, поступающие от контроллера Call Agent.

Вышеописанное решение обеспечивает масштабируемость сети и простоту управления сетью через контроллер шлюзов. Шлюзы не должны быть интеллектуальными устройствами, требуют меньшей производительности процессоров и, следовательно, становятся менее дорогими. Кроме того, очень быстро вводятся новые протоколы сигнализации или дополнительные услуги, так как эти изменения затрагивают только контроллер шлюзов, а не сами шлюзы.

Третий подход, предлагаемый организацией IETF (рабочая группа MEGACO), хорошо подходит для развертывания глобальных сетей IP-телефонии, приходящих на смену традиционным телефонным сетям.

Рассмотрим алгоритмы установления и разрушения соединения с использованием протокола MGCP. Первый пример охватывает взаимодействие протокола MGCP с протоколом ОКС7 (рисунок 1.12).

Рисунок 1.12. Установление и разрушение соединения с использованием протокола MGCP (Пример 1)

1) От телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения в виде сообщения IAM протокола ISUP. На рисунке 1.12 шлюз сигнализации SG1 и SG2 совмещены с транспортными шлюзами TGW1 и TGW2 соответственно. Шлюз SG1 передает сообщение IAM к контроллеру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к АТС-Б посредством шлюза TGW2.

2) Контроллер резервирует порт шлюза TGW1 (разговорный канал). С этой целью он передает к шлюзу команду CreateConnection. Отметим, что порт шлюза TGW1 может только принимать информацию (режим «recvonly»), так как он еще не осведомлен о том, по какому адресу и каким образом ему следует передавать информацию.

3) В ответе на эту команду шлюз TGW1 возвращает описание параметров сеанса связи.

4) Приняв ответ шлюза TGW1, контроллер передает команду CRCX второму шлюзу TGW2 с целью зарезервировать порт в этом шлюзе.

5) Шлюз TGW2 выбирает порт, который будет участвовать в соединении, и подтверждает прием команды CRCX. При помощи двух команд CRCX создается однонаправленный разговорный канал для передачи вызывающему абоненту акустических сигналов или речевых подсказок и извещений. В то же время, порт шлюза TGW2 уже может не только принимать, но и передавать информацию, так как он получил описание параметров связи от встречного шлюза.

7) На сообщение IAM станция АТС-Б отвечает подтверждением АСМ, которое немедленно пересылается к станции АТС-А.

8) После того как вызываемый абонент примет вызов, АТС-Б передает к контроллеру шлюзов сообщение ANM.

10) Шлюз TGW1 выполняет и подтверждает изменение режима.

11) Контроллер передает сообщение ANM к АТС-А, после чего начинается разговорная фаза соединения.

12) Завершение разговорной фазы происходит следующим образом. В нашем случае вызвавший абонент Б дает отбой первым. АТС-Б передает через шлюз сигнализации сообщение REL к контроллеру шлюзов.

13) Приняв сообщение REL, контроллер шлюзов завершает соединение с вызванным абонентом.

14) Шлюз подтверждает завершение соединения и передает к контроллеру собранные за время соединения статистические данные.

15) Контроллер шлюзов передает сообщение RLC к АТС-Б с целью подтвердить разъединение.

16) Параллельно контроллер завершает соединение с вызвавшей стороной

17) ШлюзТGW1 подтверждает завершение соединения и передает к контроллеру собранные за время соединения статистические данные.

18) АТС-А подтверждает завершение соединения передачей сообщения RLC, после чего соединение считается разрушенным .

Рисунок 1.13. Установление и разрушение соединения с использованием протокола MGCP (Пример 2)

Второй пример иллюстрирует взаимодействие протокола MGCP с протоколами ОКС7 и Н.323 (рисунок 1.13).

1) С телефонной станции АТС-А к шлюзу сигнализации SG1 по общему каналу сигнализации поступает запрос соединения (сообщение IAM). На рисунке 1.13 шлюз сигнализации SG1 также совмещен с транспортным шлюзом TGW1. Шлюз SG1 передает сообщение IAM контроллеру шлюзов, который обрабатывает запрос и определяет, что вызов должен быть направлен к оконечному устройству вызываемого пользователя - терминалу Н.323.

2) Контроллер шлюзов резервирует порт шлюза TGW1 (разговорный канал). С этой целью он передает к шлюзу команду CreateConnec-tion. И в этом примере порт шлюза TGW1 может только принимать информацию (режим «recvonly»).

3) В ответе на принятую команду шлюз TGW1 возвращает описание параметров связи.

4) Приняв ответ от шлюза TGW1, контроллер передает к привратнику сети Н.323 сообщение ARQ с alias адресом вызываемого абонента.

5) В ответ на сообщение ARQ привратник передает сообщение ACF с указанием транспортного адреса своего сигнального канала.

6) Контроллер передает запрос соединения SETUP на транспортный адрес сигнального канала привратника, при этом используется процедура Fast Start. Привратник пересылает сообщение SETUP к вызываемому терминалу.

7) Вызываемый терминал передает запрос допуска к ресурсам сети ARQ.

8) В ответ на запрос ARQ привратник передает подтверждение запроса ACF.

9) Вызываемый терминал передает сообщение ALERTING, которое привратник маршрутизирует к контроллеру шлюзов. При этом вызываемому пользователю подается визуальный или акустический сигнал о входящем вызове, а вызывающему пользователю подается индикация того, что вызываемый пользователь не занят и получает сигнал о вызове.

10) Контроллер преобразует сообщение ALERTING в сообщение АСМ, которое немедленно пересылается к АТС-А.

11) После того как вызываемый пользователь примет входящий вызов, контроллер получит сообщение CONNECT.

12) Контроллер шлюзов меняет в шлюзе TGW1 режим «recvonly» на полнодуплексный режим.

13) Шлюз TGW1 выполняет и подтверждает изменение режима соединения.

14) Контроллер передает сообщение ANM к АТС-А, после чего начинается разговорная фаза соединения, в ходе которой оборудование вызвавшего пользователя передает речевую информацию, упакованную в пакеты RTP/UDP/IP, на транспортный адрес RTP-канала терминала вызванного абонента, а тот передает пакетированную речевую информацию на транспортный адрес RTP-канала терминала вызвавшего абонента. При помощи канала RTCP ведется контроль передачи информации по RTP каналу.

15) После окончания разговорной фазы начинается фаза разрушения соединения. Оборудование пользователя, инициирующего разрушение соединения, должно прекратить передачу речевой информации, закрыть логические каналы и передать сообщение RELEASE COMPLETE, после чего сигнальный канал закрывается.

16) Контроллер шлюзов передает сообщение RELEASE к АТС-А с целью завершения соединения.

17) Кроме того, контроллер передает к шлюзу команду DLCX.

18) Шлюз подтверждает завершение соединения и передает к контролеру собранные за время соединения статистические данные.

19) После вышеописанных действий контроллер и оконечное оборудование извещают привратник об освобождении занимавшейся полосы пропускания. С этой целью каждый из участников соединения посылает привратнику по каналу RAS запрос выхода из соединения DRQ, на который привратник должен передать подтверждение DCF.

20) От АТС-А приходит подтверждение разъединения RLC, после чего соединение считается разрушенным .

Следует заметить, что алгоритм взаимодействия протоколов SIP и MGCP не сильно отличается от вышеописанного алгоритма.

Рабочая группа MEGACO комитета IETF продолжает работу по усовершенствованию протокола управления шлюзами, в рамках которой разработан более функциональный, чем MGCP, протокол MEGACO.

Международный союз электросвязи в проекте версии 4 рекомендации Н.323 ввел принцип декомпозиции шлюзов. Управление функциональными блоками распределенного шлюза будет осуществляться контроллером шлюза - Media Gateway Controller - при помощи адаптированного к Н.323 протокола MEGACO, который в рекомендации Н.248 назван Gateway Control Protocol.

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

1.4 Сравнение подходов к построению сети IP-телефонии

ip телефония криптографический аутентификация tacacs+

В настоящее время для построения хорошо функционирующих и совместимых с ТфОП сетей IP-телефонии подходят протоколы Н.323 и MGCP. Как уже отмечалось, протокол SIP несколько хуже взаимодействует с системами сигнализации, используемыми в ТфОП .

Подход, основанный на использовании протокола MGCP, обладает весьма важным преимуществом перед подходом, предложенным ITU в рекомендации Н.323: поддержка контроллером шлюзов сигнализации ОКС7 и других видов сигнализации, а также прозрачная трансляция сигнальной информации по сети IP-телефонии.

Основным недостатком третьего из приведенных в данном параграфе подходов является незаконченность стандартов.

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

Функции контроллера шлюзов точно не определены. Не стандартизированы механизмы переноса сигнальной информации от шлюза сигнализации к контроллеру и в обратном направлении.

К недостаткам можно отнести также отсутствие стандартизированного протокола взаимодействия между контроллерами. Кроме того, протокол MGCP является протоколом управления шлюзами, но не предназначен для управления соединениями с участием терминального оборудования пользователей (IP-телефонов).

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

Стоит также отметить, что в существующих приложениях IP-телефонии, таких как предоставление услуг международной и междугородной связи, использовать протокол MGCP (также, как и протокол SIP) нецелесообразно в связи с тем, что подавляющее количество сетей IP-телефонии сегодня построено на базе протокола Н.323. Оператору придется строить отдельную сеть IP-телефонии на базе протокола MGCP (или SIP), что связано со значительными капиталовложениями. В то же время, оператор связи, имеющий оборудование стандарта Н.323, может присоединиться к существующим сетям IP-телефонии .

В последнем из упомянутых подходов (в проекте версии 4 рекомендации Н.323) ITU-Т ввел принцип декомпозиции шлюзов, использованный в третьем подходе.

Управление функциональными блоками распределенного шлюза будет осуществляться контроллером шлюза - MGC (Media Gateway Controller) при помощи протокола MEGACO/H.248. В проекте версии 4 рекомендации Н.323 предусмотрена также возможность прозрачной передачи сигнализации ОКС7 и других видов сигнализации по сетям IP-телефонии и обработка сигнализации всех видов привратником без преобразования в сигнальные сообщения Н.225.0.

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

1.5 Варианты систем IP-телефонии (сценарии)

Существуют три наиболее часто используемых сценария IP-телефонии:

- «компьютер-компьютер»;

- «компьютер-телефон»;

- «телефон-телефон».

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

Компоненты модели IP-телефонии по сценарию «компьютер-компьютер» показаны на рисунке 1.14. В этом сценарии аналоговые речевые сигналы от микрофона абонента А преобразуются в цифровую форму с помощью аналого-цифрового преобразователя (АЦП), обычно при 8000 отсчетов/с, 8 битов/отсчет, в итоге - 64 Кбит/с.

Отсчеты речевых данных в цифровой форме затем сжимаются кодирующим устройством для сокращения нужной для их передачи полосы в отношении 4:1, 8:1 или 10:1. Алгоритмы сжатия речи подробно рассматриваются в следующей главе. Выходные данные после сжатия формируются в пакеты, к которым добавляются заголовки протоколов, после чего пакеты передаются через IP-сеть в систему IP-телефонии, обслуживающую абонента Б.

Когда пакеты принимаются системой абонента Б, заголовки протокола удаляются, а сжатые речевые данные поступают в устройство, развертывающее их в первоначальную форму, после чего речевые данные снова преобразуются в аналоговую форму с помощью цифро-аналогового преобразователя (ЦАП) и попадают в телефон абонента Б.

Для обычного соединения между двумя абонентами системы IP-телефонии на каждом конце одновременно реализуют как функции передачи, так и функции приема.

Под IP-сетью, изображенной на рисунке 1.14, подразумевается либо глобальная сеть Интернет, либо корпоративная сеть предприятия Intranet. Описанию протоколов, используемых в IP-сетях, в том числе протоколов передачи речевой информации по IP-сети.

Рисунок 1.14 Сценарий IP-телефонии "компьютер-компьютер"

Для поддержки сценария «компьютер - компьютер» поставщику услуг Интернет желательно иметь отдельный сервер (привратник), преобразующий имена пользователей в динамические адреса IP. Сам сценарий ориентирован на пользователя, которому сеть нужна, в основном, для передачи данных, а программное обеспечение IP-телефонии требуется лишь иногда для разговоров с коллегами.

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

Подобные документы

Рассмотрение особенностей разработки комплекса по автоматизации анализа попыток внешних проникновений и контроля локальных соединений для сервера телефонии. Общая характеристика протокола SSH, основные версии. Анализ обычной парольной аутентификации.

курсовая работа , добавлен 22.02.2013


Перспективы развития IP-телефонии (Интернет-телефонии). Сеть Интернет и протокол IP. История развития IP-телефонии. Преимущества использования IP-телефонии. Показатель качества IP-телефонии. Система расчетов за услуги IP-телефонии биллинга и менеджмента.

курсовая работа , добавлен 16.05.2008


Структура протокола TCP/IP. Взаимодействие систем коммутации каналов и пакетов. Характеристика сети с коммутацией пакетов. Услуги, предоставляемые ОАО "МГТС" с использованием сети с пакетной коммутацией. Расчет эффективности внедрения проектируемой сети.

дипломная работа , добавлен 22.05.2012


Основные понятия IP телефонии, строение сетей IP телефонии. Структура сети АГУ. Решения Cisco Systems для IP-телефонии. Маршрутизаторы Cisco Systems. Коммутатор серии Catalyst 2950. IP телефон. Настройка VPN сети. Способы и средства защиты информации.

дипломная работа , добавлен 10.09.2008


Зарождение концепции многоуровневой иерархической структуры сети телефонной связи. Электронная технология, позволившая перевести все средства телефонии на элементную базу. Развитие IР-телефонии, обеспечивающей передачу речи по сетям пакетной коммутации.

реферат , добавлен 06.12.2010


Использование IP-адреса в протоколе TCP/IP, его роль в организации подключения к сети Интернет. Понятие маски подсети. Данные, необходимые для настройки протокола TCP/IP. Механизм тестирования его конфигурации и соединения с сетями с помощью утилит.

презентация , добавлен 02.11.2014


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

контрольная работа , добавлен 20.02.2011


Основы IP-телефонии: способы осуществления связи, преимущества и стандарты. Разработка схемы основного канала связи для организации IP-телефонии. Функции подвижного пункта управления. Разработка схемы резервного канала связи для организации IP-телефонии.

курсовая работа , добавлен 11.10.2013


Технология IP-телефонии и Wi-Fi. Необходимость внедрения мобильной офисной сети IP-телефонии, план ее проектирования. Настройка сервера Yeastar MyPBX 400 для подключения к оператору Зебра телеком. Расчет капитальных затрат и эксплуатационных расходов.

дипломная работа , добавлен 19.02.2013


История деятельности Московской городской телефонной сети. Структура протокола TCP/IP. Взаимодействие систем коммутации каналов и пакетов. Характеристика сети с коммутацией пакетов. Услуги перспективной сети, экономическая эффективность ее внедрения.

Статья написана специально для linkmeup.

=======================

Здравствуйте, коллеги и друзья, я, Семенов Вадим, совместно с командой проекта network-class.net представляем вниманию обзорную статью, которая затрагивает основные тенденции и угрозы в IP телефонии, и самое главное, те инструменты защиты, что на данный момент предлагает производитель в качестве защиты (если выражаться языком специалистов по безопасности, то рассмотрим какие инструменты предлагает производитель для уменьшения уязвимостей, которыми смогут воспользоваться нелегитимные лица). Итак, меньше слов– переходим к делу.
Для многих читающих термин IP телефония уже давно сформировался, а также и то, что данная телефония «лучше», дешевле по сравнению с телефонией общего пользования (ТФОП), богата различными дополнительными функциями и т.д. И это действительно так, однако… отчасти. По мере перехода от аналоговой (цифровой) телефонии со своими абонентскими линиями (от абонентского телефона до станции или станционного выноса) и соединительными линиями (меж станционная линия связи) ни много ни мало были только лишь в зоне доступа и управления провайдера телефонии. Иными словами, обычным обывателям туда доступа не было (ну или практически так, если не учитывать кабельную канализацию). Вспоминается один вопрос на старом добром форуме хакеров «Подскажите, как получить доступ к АТС? – ответ: «Ну как, берешь бульдозер – таранишь стену здания АТС и вуаля». И эта шутка имеет свою долю правды) Однако с переносом телефонии в дешевую IP среду мы получили в довесок и те угрозы, которые несет в себе открытая IP среда. Примером приобретенных угроз может служить следующее:

• Сниффинг сигнальных портов с целью совершения платных вызовов за чужой счет
• Подслушивание за счет перехвата голосовых IP пакетов
• Перехват звонка, представление нелегитимным пользователем как легитимный пользователь, атака «человек по середине»
• DDOS атаки на сигнальные сервера станции с целью вывода из строя всей телефонии
• Спам-атаки, обрушение большого количества фантомных вызовов на станцию с целью занять все её свободные ресурсы

Несмотря на очевидность в необходимости устранять все возможные уязвимости дабы уменьшить вероятность реализации той или иной атаки - по факту внедрение тех или иных мер защиты необходимо начинать с составления графика, учитывающего стоимость внедрения защитных мер от конкретной угрозы и убытков предприятия от реализации злоумышленниками этой угрозы. Ведь глупо тратить денег на безопасность актива больше, чем стоит сам актив, который мы защищаем.
Определив бюджет на безопасность, начнем устранение именно тех угроз, которые наиболее вероятны для компании, например для малой организации больнее всего будет получить большой счет за несовершенные междугородние и международные звонки, в то время как для государственных компаний важнее всего сохранить конфиденциальность разговоров. Начнем же постепенное рассмотрение в текущей статье с базовых вещей – это обеспечение безопасного способа доставки служебных данных от станции к телефону. Далее рассмотрим аутентификацию телефонов перед подключением их к станции, аутентификацию станции со стороны телефонов ну и шифрование сигнального трафика (для скрытия информации кто и куда звонит) и шифрование разговорного трафика.
У многих производителей голосового оборудования (в том числе и у Cisco Systems) есть уже интегрированные инструменты безопасности от обычного ограничения диапазона ip адресов, с которых можно совершать вызовы, до аутентификации оконечных устройств по сертификату. Например, у производителя Cisco Systems с его голосовой линейкой продуктов CUCM (Cisco Unified CallManager) с версии продукта 8.0 (дата выхода в свет май 2010г.; на данный момент доступна версия 10.5 от мая 2014г.) стала интегрироваться функция «Безопасность по умолчанию». Что она в себя включает:

• Аутентификация всех скачиваемых по/с TFTP файлов (конфигурационные файлы, файлы прошивки для телефонов т.д.)
• Шифрование конфигурационных файлов
• Проверка сертификата с инициализации телефоном HTTPS соединения

Давайте рассмотрим пример атаки «человека по середине», когда нелегитимное лицо перехватывает конфигурационный файлы для телефонов, из которого телефон узнает на какую станцию ему регистрироваться, на каком протоколе работать, какую прошивку скачивать и т.д. Перехватив файл, злоумышленник сможет вносить в него свои изменения либо полностью затереть файл конфигурации, тем самым не дав телефонам всего офиса (см. рисунок) зарегистрироваться на станции, а, следовательно, лишив офиса возможности совершать звонки.

Рис.1 Атака «человек посередине»

Для защиты от этого нам понадобятся знания по несимметричному шифрованию, инфраструктуре открытых ключей и представления о составляющих «Безопасности по умолчанию», с которыми мы сейчас познакомимся: Identity Trust List (ITL) и Trust Verification Service (TVS). TVS – сервис, предназначенный для обработки запросов с IP телефонов, у которых нет ITL или CTL файла во внутренней памяти. IP телефон обращается к TVS в случае необходимости удостовериться может ли он доверять тому или иному сервису перед тем, как начать обращаться к нему. Станция к тому же выступает в роли репозитория, хранящем сертификаты доверенных серверов. В свою очередь ITL представляет собой список из открытых ключей составляющих кластер станции элементов, но для нас важно, что там хранится открытый ключ TFTP сервера и открытый ключ TVS сервиса. При первоначальной загрузке телефона, когда телефон получил свой IP адрес и адрес TFTP сервера, он запрашивает наличие ITL файла (рис.2). Если он есть на TFTP сервере, то, слепо доверяя, загружает его в свою внутреннюю память и хранит до следующей перезагрузки. После скачивания ITL файла телефон запрашивает подписанный конфигурационный файл.

Теперь рассмотрим как мы сможем использовать инструменты криптографии – подписывание файла с помощью хеш-функций MD5 или SHA и шифрование с помощью закрытого ключа TFTP сервера (рис.3). Особенность хеш-функций заключается в том, что это однонаправленные функции. По полученному хешу с какого-либо файла, нельзя проделать обратную операцию и получить в точности оригинальный файл. При изменении файла - изменяется и сам хеш, полученный с этого файла. Стоит отметить, что хеш не записывается в сам файл, а просто добавляется к нему и передается совместно с ним.

Рис.3 Подписывание файла конфигурации телефона

При формировании подписи берется сам конфигурационный файл, извлекается с него хеш и шифруется закрытым ключом TFTP сервера (который обладает только TFTP-сервер).
При получении данного файла с настройками, телефон первоначально проверяет его на целостность. Мы помним, что хеш - это однонаправленная функция, поэтому телефону не остается ничего делать, кроме как отделить зашифрованный TFTP сервером хеш от конфигурационного файла, расшифровать его с помощью открытого ключа TFTP (а откуда его знает IP телефон? – а как раз из ITL файла), из чистого конфигурационного файла вычислить хеш и сравнить его с тем, что мы получили при расшифровании. Если хеш совпадает - значит при передаче в файл не вносились никакие изменения и его можно смело применять на телефоне (рис.4).

Рис.4 Проверка файла конфигурации IP телефоном

Подписанный конфигурационный файл для телефона представлен ниже:

Рис. 5 Подписанный файл IP телефона в Wireshark

Подписав конфигурационный файл, мы смогли обеспечить целостность передаваемого файла с настройками, однако мы не защитили его от просмотра. Из пойманного файла конфигурации можно получить достаточно много полезной информации, например ip адрес телефонной станции (в нашем примере это 192.168.1.66) и открытые порты на станции (2427) и т.д. Не правда ли достаточно важная информация, которую не хотелось бы просто так «светить» в сети? Для скрытия данной информации производители предусматривают использование симметричного шифрования (для шифрования и дешифрования используется один и тот же ключ). Ключ в одном случае может быть введен на телефон вручную, в другом случае шифрование файла конфигурации телефона на станции происходит с использованием открытого ключа телефона. Перед отправлением файла телефону – tftp сервер, на котором хранится этот файл, шифрует его с помощью открытого ключа телефона и подписывает с помощью своего закрытого ключа (тем самым мы обеспечиваем не только скрытость, но и целостность передаваемых файлов). Здесь главное не запутаться, кто какой ключ использует, но давайте разберем по порядку: tftp сервер, зашифровав файл открытым ключом IP телефона, обеспечил тем самым, что этот файл сможет открыть только владелец парного открытого ключа. Подписав файл своим закрытым ключом, tftp сервер подтверждает, что именно он создал его. Зашифрованный файл представлен на рисунке 6:

Рис.6 Зашифрованный файл IP телефона

Итак, на данный момент мы рассмотрели возможность защищать наши конфигурационные файлы для телефонов от просмотра и обеспечивать их целостность. На этом функции «Безопасности по умолчанию» заканчиваются. Для обеспечения шифрования голосового трафика, скрытия сигнальной информации (о том кто звонит и куда звонит), необходимы дополнительные инструменты, основанные на списке доверенных сертификатов – CTL, который мы рассмотрим далее.

Аутентификация телефонной станции

Когда телефону необходимо взаимодействие с телефонной станцией (например, согласовать TLS соединение для обмена сигнализации), IP телефону необходимо аутентифицировать станцию. Как можно догадаться, для решения данной задачи также широко используются сертификаты. На данный момент современные IP станции состоят из большого количества элементов: несколько сигнальных серверов для обработки вызовов, выделенный сервер администрирования (через него добавляются новые телефоны, пользователи, шлюзы, правила маршрутизации и т.д.), выделенный TFTP сервер для хранения файлов конфигурации и программного обеспечения для телефонов, сервер для вещания музыки на удержании и проч, кроме этого в голосовой инфраструктуре может быть голосовая почта, сервер определения текущего состояния абонента (online, offline, «на обеде») – список набирается внушительный и, что самое главное, каждый сервер имеет свой самоподписанный сертификат и каждый работает как корневой удостоверяющий центр (рис.7). По этой причине любой сервер в голосовой инфраструктуре не будет доверять сертификату другого сервера, например голосовой сервер не доверяет TFTP серверу, голосовая почта – сигнальному серверу и к тому же телефоны должны хранить у себя сертификаты всех участвующих в обмене сигнального трафика элементов. Сертификаты телефонной станции изображены на рисунке 7.

Рис.7 Самоподписанные сертификаты Cisco IP станции

Для задач установления доверительных отношений между вышеописанными элементами в голосовой инфраструктур, а также шифрования голосового и сигнального трафика в игру входит так называемый список доверенных сертификатов Certificate Trust List (CTL). CTL содержит все самоподписанные сертификаты всех серверов в кластере голосовой станции, а также участвующих в обмене сигнальными сообщениями телефонии (например, файервол) и этот файл подписывается закрытым ключом доверенного центра сертификации (рис.8). CTL файл эквивалентен проинсталлированным сертификатам, которые используются в работе веб браузеров при работе с https протоколом.

Рис.8 Список доверенных сертификатов

Для того чтобы создать CTL файл на оборудовании Cisco, потребуется ПК с USB разъемом, установленная на нем программа CTL client и сам токен Site Administrator Security Token (SAST) (рис.9), содержащий закрытый ключ и X.509v3 сертификат, подписанный центром аутентификации производителя (Cisco).

Рис.9 eToken Cisco

CTL client - программа, которая устанавливается на Windows ПК и с которой можно перевести ВСЮ телефонную станцию в так называемый mixed mode, то есть смешанный режим поддержки регистрации оконечных устройств в безопасном и небезопасном режимах. Запускаем клиент, указываем IP адрес телефонной станции, вводим логин/пароль администратора и CTL client устанавливает TCP соединение по порту 2444 со станцией (рис.10). После этого будет предложено всего лишь два действия:

Рис.10 Cisco CTL Client

После создания CTL файла, остается перезагрузить TFTP сервера для того, чтобы они подкачали к себе новый созданный CTL файл, и далее перезагрузить голосовые сервера, чтобы IP телефоны также перезагрузились и загрузили новый CTL файл (32 килобайта). Загруженный CTL файл можно просмотреть из настроек IP телефона (рис.11)

Рис.11 CTL файл на IP телефоне

Аутентификация оконечных устройств

Для обеспечения подключения и регистрации только доверенных оконечных устройств необходимо внедрение аутентификации устройств. На этот случай многие производители используют уже проверенный способ – аутентификация устройств по сертификатам (рис.12). Например, в голосовой архитектуре Cisco это реализовано следующим образом: имеются два вида сертификатов для аутентификации с соответствующими открытыми и закрытыми ключами, которые хранятся на телефоне:
Manufacturer Installed Certificate - (MIC) . Сертификат, установленный производителем, содержит 2048 битный ключ, который подписан центром сертификации компании производителя (Cisco). Данный сертификат установлен не на все модели телефонов, и если он установлен, то в наличии другого сертификата (LSC) нет необходимости.
Locally Significant Certificate – (LSC) Локально значащий сертификат, содержит открытый ключ IP телефона, который подписан закрытым ключом локального центра аутентификации, который работает на самой телефонной станции Сertificate Authority Proxy Function (CAPF).
Итак, если у нас есть телефоны с предустановленным MIC сертификатом, то каждый раз, когда телефон будет регистрироваться на станцию, станция будет запрашивать для аутентификации предустановленный производителем сертификат. Однако, в случае компрометации MIC-а для его замены необходимо обращение в центр сертификации производителя, что может потребовать большого количества времени. Дабы не зависеть от времени реакции центра сертификации производителя на перевыпуск скомпрометированного сертификата телефона, предпочтительней использование локального сертификата.

Рис.12 Сертификаты для аутентификации оконечных устройств

По умолчанию на IP телефон не установлен LSC сертификат и его установка возможна, используя MIB сертификат (при его наличии), или через TLS соединение (Transport Layer Security) по разделяемому общему ключу, сгенерированному администратором вручную на станции и введенном на телефоне.
Процесс установки на телефон локально значащего сертификата (LSC), содержащий открытый ключ телефона, подписанного локальным центром сертификации изображен на рисунке 13:

Рис.13 Процесс установки локально значащего сертификата LSC

1. После загрузки IP телефон запрашивает доверенный список сертификатов (CTL-файл) и файл с конфигурацией
2. Станция отправляет запрашиваемые файлы
3. Из полученной конфигурации телефон определяет – нужно ли ему загружать локально значащий сертификат (LSC) со станции
4. Если мы на станции выставили для телефона, чтобы он установил LSC сертификат (см.ниже), который станция будет использовать для аутентификации данного IP телефона, то мы должны позаботиться о том, чтобы на запрос об выдаче LSC сертификата – станция выдала его тому, кому он предназначается. Для этих целей мы можем использовать MIC-сертификат (если он есть), сгенерировать одноразовый пароль на каждый телефон и ввести его на телефоне вручную либо не использовать авторизацию вообще.
На примере продемонстрирован процесс установки LSC с использованием сгенерированного ключа.
На станции в режиме настроек IP телефона указываем, что мы хотим установить LSC сертификат на телефон и при этом установка будет произведена успешна, если на телефоне ввести аутентификационный ключ, который мы определили как 12345 (рис.14).

Рис.14 Режим настроек CAPF на телефоне

Заходим в режим настройки телефона и вводим наш ключ (рис.15):

Рис.15 Аутентификационный ключ для установки LSC

После этого установка LSC сертификата на телефон прошла успешна (рис.16):

Рис.16 Настройки безопасности на IP телефоне

Особенностью же использования LSC сертификата для аутентификации оконечных устройств является то, что при компрометации самого сертификата – он может быть переподписан новым закрытым ключом центром сертификации CAPF телефонной станции.

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

Шифрование разговоров - SRTP

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

Рис.17 Открытое сообщение SIP

Secure Real Time Protocol (SRTP) – это специально разработанный протокол RTP, призванный для передачи голоса и видео, однако дополненный механизмами обеспечения конфиденциальности, целостности передаваемой информации не только через RTP, но и RTCP. Голосовое приложение, поддерживающие SRTP, должно конвертировать RTP пакеты в SRTP перед отправкой их по сети. Обратная операция должна быть продела на приемной стороне. В архитектуре SRTP определены два типа ключей: мастер-ключ и сессионный ключ (для шифрования и аутентификации) (рис. 18). Однако SRTP не регламентирует порядок обмена мастер-ключами, для данных целей необходимо использовать TLS или IPSec. Для обмена ключами стандартизованным решением для SRTP является MIKEY (Multimedia Internet Keying), однако могут быть использованы и такие протоколы как SDES и ZRTP.

Рис.18 Совершение звонка с помощью SRTP

Процесс обмена сообщениями SRTP:

• Телефон и сервер обмениваются сертификатами;
• Телефон и сервер аутентифицируют друг друга;
• Телефон создает TLS ключи для SHA аутентификации и для шифрования AES;
• Телефон шифрует ключи с помощью открытого ключа станции и отправляет. Станция расшифровывает с помощью своего закрытого ключа;
• Станция обменивается TLS ключами с каждым из телефонов и приступает к безопасному обмену телефонных сигнальных сообщений (телефон вызываемого абонента звонит);
• Станция создает сессионные ключи для SRTP SHA аутентификации и SRTP AES шифрованию;
• Станция распространяет сессионные ключи обоим телефонам через защищенное сигнальное соединение;
• Телефоны приступают обмен голосового трафика через защищенное SRTP соединение (вызываемый поднял трубку).

Включением шифрования и аутентификации на оборудовании Cisco заведуют профайлы безопасности. Выглядит он следующим образом (рис.19):

Рис.19 Профайл безопасности на Cisco CallManager

В нем мы определяем в каком режиме будут регистрироваться и работать оконечные устройства (телефоны). При выборе опции Non Secure – не шифруются ни сигнальные данные, ни голос; Authenticated – шифруются сигнальные сообщения, но не шифруется голос; Encrypted – шифруется и сигнализация и голос. Есть возможность выбора шифрования конфигурационных данных. После создания профайла необходимо его назначить на телефон (рис.20).

Рис.20 Профайл безопасности телефона на Cisco CallManager

На данный момент мы рассмотрели основные моменты в безопасности IP телефонии, позволяющие бороться против основных угроз телефонии, однако это только шапка айсберга всей безопасности голосовой инфраструктуры) Отдельно необходимо рассмотрение физической безопасности инфраструктуры (например здесь: ГОСТ Р ИСО/МЭК 17799-2005 Практические правила управления информационной безопасностью), и отдельную тему можно посвятить сетевой безопасности. Надеюсь, что тот, кто дочитал статью до конца, остался ей доволен и информация была полезной.
На любые вопросы готов ответить по почте: [email protected]
При поддержке проекта network-class.net

Информационная безопасность ,

Разработка систем связи

• Tutorial

Привет, Хабр!
В этот раз хочу рассказать о технологиях шифрования VoIP звонков, о том какую защиту дают разные подходы и как организовать наиболее защищенную от прослушивания голосовую связь с технологическими гарантиями безопасности.
В статье я постараюсь доступно изложить особенности таких технологий как SIP\TLS, SRTP и ZRTP. И продемонстрирую конкретные схемы использования на примере нашего сервиса ppbbxx.com

Немного теории

Любой VoIP вызов состоит из 2-х основных составляющих: обмена сигнальной информацией и передачи между пользователями media потоков с голосом и/или видео.
На первом этапе, в процессе обмена сигнальной информацией, клиенты напрямую либо посредством сервера договариваются между собой о параметрах устанавливаемого вызова. Если связь устанавливается с помощью сервера, на основе сигнальной информации сервер авторизует клиента, устанавливает кто и кому звонит, проводит маршрутизацию и коммутацию. Благодаря данным сигнального протокола клиенты и сервер согласуют метод шифрования, используемые media кодеки, обмениваются ip адресами и номерами портов, где ожидается приём media и тд. Происходит это по таким протоколам как SIP, XMPP и прочим.
Непосредственно «разговор», то есть обмен между клиентами голосовыми данными, как правило происходит по протоколу RTP. Данные внутри передаются в том виде, о котором договорились клиенты и сервер на «сигнальном» этапе. Обмен голосом возможен как напрямую между клиентами, так и через сервер - посредник. Во втором случае сервер может помочь клиентам с прохождением NAT и в выборе кодеков.

Итак, что же собой представляет шифрованный VoIP вызов? Дальше речь пойдёт о SIP протоколе как наиболее популярном.
Как мы уже выяснили, звонок состоит из сигнальной и media частей, каждая из которых может быть зашифрована отдельно с применением специальных методов-протоколов. Для шифрования сигнальной информации применяется SIP\TLS, для шифрования «голоса» ZRTP и SRTP протоколы.

SIP\TLS - грубо говоря, аналог HTTPS для обычного SIP. Протокол позволяет клиенту убедиться, что он общается с нужным сервером при условии, что клиент доверяет предоставленному сервером сертификату. Подробнее можно прочитать на википедии

SRTP и ZRTP - это два разных способа шифровать RTP потоки. Принципиальное отличие между ними в том, что обмен ключами для SRTP происходит в сигнализации (на первой сигнальной стадии установки вызова). А для ZRTP непосредственно в начале обмена RTP пакетами (во второй, «медийной» части) по специальному протоколу , основанному на методе криптографии Диффи - Хеллмана.
Важно то, что для SRTP обязательным условием надёжности шифрования звонка является одновременное использование SIP\TLS + SRTP, иначе злоумышленнику не составит труда получить ключи (которые будут переданы по не шифрованному SIP) и прослушать разговор. В то время как для ZRTP это не важно, RTP поток будет надёжно зашифрован не зависимо от того, шифруется сигнализация или нет. Более того протокол умеет определять наличие «man in the middle» (в том числе серверов услуг!) между непосредственно говорящими клиентами. Это позволяет быть уверенным в том, что разговор невозможно прослушать, по крайней мере с точки зрения прослушивания сети/среды передачи данных.

Схема подключения SIP клиентов с различными настройками шифрования:

Можно выделить следующие схемы установки шифрованного звонка:

1. Оба пользователя используют SIP\TLS и SRTP. В этом случае обмен ключами для шифрования media происходят по защищенному сигнальному протоколу. Предполагается доверие к серверу, участвующему в установке связи. Посторонние не могут получить доступ ни к сигнальной информации, ни к голосовым данным. Недостаток в том, что пользователь не уведомлен на уровне протокола (клиента) и не убежден, что второй пользователь также использует шифрованное подключение к серверу.
2. Оба пользователя используют ZRTP, голос при этом проходит через сервер. В этом случае сервер определяется ZRTP протоколом как Trusted MitM (man in the middle). Обмен ключами происходит по алгоритму, основанному на методе Диффи - Хеллмана (что и гарантирует невозможность прослушки) по протоколу RTP. Если при этом используется защищенный SIP\TLS - посторонние так же не могут получить доступ ни к сигнальной информации, ни к «голосу». Как и в первом варианте предполагается доверие к коммутирующему серверу, но в отличии от него для надёжного шифрования голоса не требуется обязательное использование защищенного SIP\TLS. Также, в отличии от первого варианта, каждый пользователь видит, что разговор шифруется до сервера с обоих сторон, а также то, что оба подключены к одному и тому же (доверенному) серверу.
3. Оба пользователя используют ZRTP, но media устанавливается напрямую между клиентами. Так как обмен ключами проходит напрямую между клиентами, даже сервер, осуществивший коммутацию, не может прослушать разговор. В этом случае оба клиента отображают информацию о том, что установлен безопасный прямой сеанс связи. Убедиться в этом можно сверив SAS (короткие строки авторизации) - они будут одинаковыми. Если требуется скрыть от посторонних сигнальную информацию, следует использовать SIP\TLS. Это самый безопасный вариант, но в этом случае сервер не сможет выполнять многие функции, которые в других ситуациях выполняются на нем, к примеру запись непосредственно разговора, перекодирование голоса для клиентов с разными настройками аудиокодеков и тд.
4. Один пользователь использует первый метод, описанный выше, а другой - второй. В этом случае так же требуется доверие к серверу. Сигнальная информация шифруется с помощью SIP\TLS. Для пользователя с ZRTP протокол сообщит, что шифрованное соединение установлено до сервера (End at MitM). Используется ли шифрование с другой стороны на уровне протокола узнать не удастся.

На этом закончим с теорией и перейдём к практике! Настроим собственный SIP сервер, создадим SIP пользователей, установим SIP клиенты и научимся совершать шифрованные звонки c помощью бесплатного

Настройка сервера

Для начала нужно создать собственный сервер. Для этого нужно зайти на сайт услуги ppbbxx.com , пройти простую регистрацию и войти в интерфейс настроек.

Первым делом пройдём в раздел "Internal network -> Domains " и создадим собственный домен, чтобы не быть ограниченным в выборе имён SIP пользователей. Можно припарковать свой домен либо создать личный субдомен в одной из зон сервиса.
Далее необходимо в разделе "Internal network -> Sip Users " создать SIP пользователей и настроить некоторые параметры их клиентов. Имена SIP пользователей могут быть произвольными, но так как на программных и аппаратных телефонах удобнее набирать цифры, мы будем заводить идентификаторы вида [email protected] и подобные. Я завёл 1000, 1001, 1002, 1003. После создания SIP идентификатора нужно не забыть нажать кнопку «Сохранить». Если никаких недозаполненных форм в интерфейсе настроек не осталось, система не будет ругаться и покажет лог изменений со статусом «Done».

Дальше необходимо настроить используемые кодеки и методы шифрования. Для этого нужно нажать значок с шестерёнкой слева от SIP идентификатора. Я планирую использовать SIP клиент (CSipSimple) на смартфоне и хочу использовать метод шифрования ZRTP поэтому в "basic " вкладке настроек выбираю кодеки G729 и SILK, а во вкладке "protection " ZRTP метод.

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

В целом, для настройки простейшей конфигурации этого достаточно. Можно настраивать SIP клиенты и звонить между ними, набирая их номера 1000, 1001, 1002, 1003. При желании к этому можно добавить общий SIP шлюз для звонков в телефонную сеть и настроить соответствующую маршрутизацию звонков. Но, в таком случае, это уже несколько иная схема использования услуги, которая требует скорее другого рода мер безопасности, нежели шифрование трафика до шлюза.

Перейдём к настройке SIP клиентов

Как я уже сказал, я планирую использовать CSipSimple на андроид смартфонах. Первым делом нужно установить клиент, используя стандартный Play Market, либо скачать на сайте производителя , который кстати открывает исходники своего клиента, что в отдельных случаях может иметь едва ли не сакральное значение. Установить нужно сам клиент и дополнительно кодеки. У меня установлены «CSipSimple», «Codec Pack for CSipSimple» и «G729 codec for CSipSimple». Последний платный и использовать его не обязательно, бесплатные SILK и OPUS обеспечивают достойное качество звонков по 3G сетям.

Запускаем CSipSimple и переходим в интерфейс настройки. Выбираем мастер «Вasic» и настраиваем, используя данные из веб интерфейса. Должно получиться так:

Далее в общих настройках CSipSimple в разделе "Медиа -> Аудиокодеки " нужно выбрать предпочитаемые кодеки. Для звонков через 3G я рекомендую использовать SILK, OPUS, iLBC, G729. Поскольку настройки в интерфейсе сервера и в интерфейсе клиента должны совпадать , а на сервере я выбрал SILK и G729, то в списке аудиокодеков CSipSimple я ставлю галочки только напротив этих кодеков, а остальные снимаю.
В разделе клиента "Сеть -> Безопасный протокол " нужно выбрать желаемые параметры шифрования. Я включаю только ZRTP. Остальное оставляю выключенным. При желании можно использовать SIP\TLS - нужно учитывать что сервер ожидает TLS соединения на 443-м порту. Это сделано специально для слишком умных операторов мобильной связи, блокирующих стандартные для VoIP порты.
Так же нужно учитывать, что SRTP и ZRTP не всегда совместимы и крайне желательно выбирать в клиенте только один из них.

Совершение звонков с использованием ZRTP

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

Сразу после выполнения инструкции звонок SIP пользователя 1001 пользователю 1000 будет выглядит таким образом.
CSipSimple показывает, что в звонке участвует MitM сервер, к которому подключены оба клиента. Параметр EC25 означает, что используется протокол Диффи-Хеллмана на эллиптических кривых с параметром 256 бит. AES-256 - алгоритм симметричного шифрования, который применяется. Статус ZRTP - Verifyed означает, что контрольная строка SAS подтверждена пользователем.

Изменим режим передачи медиа в настройках ppbbxx для обоих клиентов. Установка direct media = yes позволит передавать голос напрямую. В этом случае стороны видят одинаковые строки SAS, используется алгоритм симметричного шифрования Twofish-256. Использование ZRTP в этом режиме требует от клиентов намного большей свместимости и менее надежно с точки зрения установки связи, поскольку сервер не участвует в передаче данных. Обязательно использование одинаковых аудиокодеков на всех клиентах и корректная работа NAT.

Если у SIP пользователя 1001 шифрование не установлено, тогда как 1000 использует ZRTP, то второй клиент покажет, что зашифрованная передача голоса происходит только до сервера (End at MitM).

Резюмируем

Связь полностью защищенную от прослушивания организовать можно. Это сделать не сложно. Наиболее подходящий способ для этого - использование протокола IP-телефонии SIP и метода шифрования медиа данных ZRTP. Сервис

Спецификацией IETF, где описаны стандартные методы для всех компонентов VPN, является протокол Internet Protocol Security, или IPSec, - иногда его называют туннелирова-нием третьего уровня (Layer-3 Tunneling). IPSec предусматривает стандартные методы идентификации пользователей или компьютеров при инициации туннеля, стандартные способы использования шифрования конечными точками туннеля, а также стандартные методы обмена и управления ключами шифрования между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнения каждой задачи. Выбранные методы для одной задачи обычно не зависят от методов реализации других задач. Идентификацию можно выполнять с помощью спецификации IPSec, причем она является обязательным компонентом протокола IPv6.

IPSec может работать совместно с L2TP, в результате эти два протокола обеспечивают более надежную идентификацию, стандартизованное шифрование и целостность данных. Следует отметить, что спецификация IPSec ориентирована на IP и, таким образом, бесполезна для трафика любых других протоколов сетевого уровня. Туннель IPSec между двумя локальными сетями может поддерживать множество индивидуальных каналов передачи данных, в результате чего приложения данного типа получают преимущества с точки зрения масштабирования по сравнению с технологией второго уровня.

Некоторые поставщики VPN используют другой подход под названием «посредники каналов» (circuit proxy), или VPN пятого уровня. Этот метод функционирует над транспортным уровнем и ретранслирует трафик из защищенной сети в общедоступную сеть Internet для каждого сокста в отдельности. (Сокет IP идентифицируется комбинацией TCP-соединения и конкретного порта или заданным портом UDP. Протокол IP не имеет пятого - сеансового -уровня, однако ориентированные на сокеты операции часто называют операциями сеансового уровня).

Шифрование информации, передаваемой между инициатором и терминатором туннеля, часто осуществляется с помощью защиты транспортного уровня (Transport Layer Security, TLS), ранее протокола защищенных сокетов (Secure Sockets Layer, SSL). Для стандартизации аутентифицированного прохода через брандмауэры IETF определил протокол под названием SOCKS, и в настоящее время SOCKS 5 применяется для стандартизованной реализации посредников каналов.

В SOCKS 5 клиентский компьютер устанавливает аутентифицированный сокет (или сеанс) с сервером, выполняющим роль посредника (proxy). Этот посредник - единственный способ связи через брандмауэр. Посредник, в свою очередь, проводит любые операции, запрашиваемые клиентом. Поскольку посреднику известно о трафике на уровне сокета, он может осуществлять тщательный контроль, например, блокировать конкретные приложения пользователей, если они не имеют необходимых полномочий. Для сравнения, виртуальные частные сети уровня 2 и 3 обычно просто открывают или закрывают канал для всего трафика по аутентифицированному туннелю. Это может представлять проблему, если нет гарантии защиты информации на другом конце туннеля.

Следует отметить на наличие взаимосвязи между брандмауэрами и VPN. Если туннели завершаются на оборудовании провайдера Интернет, то трафик будет передаваться по вашей локальной сети или по линии связи с провайдером Интернет в незащищенном виде. Если конечная точка расположена за брандмауэром, то туннелируемый трафик можно контролировать с помощью средств контроля доступа брандмауэра, но никакой дополнительной защиты при передаче по локальной сети это не даст. В этом случае конечную точку будет связывать с брандмауэром незащищенный канал.

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

Как и любая другая вычислительная функция, работа по созданию сетей VPN проводится с помощью программного обеспечения. Между тем программное обеспечение для VPN может выполняться на самых разных аппаратных платформах. Маршрутизаторы или коммутаторы третьего уровня могут поддерживать функции VNP по умолчанию (или в качестве дополнительной возможности, предлагаемой за отдельную плату). Аппаратно и программно реализуемые брандмауэры нередко предусматривают модули VPN со средствами управления трафиком или без них. Некоторые пограничные комбинированные устройства включают в себя маршрутизатор, брандмауэр, средства управления пропускной способностью и функции VPN (а также режим конфигурации). Наконец, ряд чисто программных продуктов выполняется на соответствующих серверах, кэширует страницы Web, реализует функции брандмауэра и VPN.

Механизм VPN немыслим без идентификации. Инфраструктура с открытыми ключами (Public Key Infrastructure, PKI) для электронной идентификации и управления открытыми ключами является в настоящее время основной. Данные PKI целесообразнее всего хранить в глобальном каталоге, обращаться к которому можно по упрощенному протоколу доступа к каталогу (Lightweight Directory Access Protocol, LDAP).