IP телефония

3.4.4.2. Аутентификация по  телефонным номерам  и IP-адресам

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

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

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

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

  Злоумышленник может совершить еще более элегантную кражу адреса, используя атаку типа «человек посередине». Он устраивается в сети между жертвой и ее сервером таким образом, чтобы весь трафик жертвы проходил через этот участок сети, после чего начинает мониторинг трафика жертвы и собирает информацию, которая может ему понадобиться, чтобы взять под контроль существующее соединение. После того, как у злоумышленника оказывается нужная информация, он разрывает сетевую связь, ведущую к машине жертвы и одновременно объявляет в сети, что его машина подлинная. По сути, он сращивает TCP-соединения, а затем переключает их на свою машину. Атаки подобного типа называются TCP-сращиванием. TCP-сращивание представляет собой пример более общей угрозы похищения соединений. Если злоумышленник может похитить соединение пользователя, то ему совсем не нужно красть его пароль доступа: он просто поджидает, пока пользователь входит в систему и затем крадет само аутентификационное соединение. Подобные вещи уже проделывались взломщиками с телефонными соединениями.

3.5. Сценарий работы  безопасного VoIP-соединения

3.5.1. Общий принцип  установления соединений  в VoIP-сетях на  базе

Softswitch

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

  Абонент сети ТФОП (далее абонент А) снимает трубку и набирает телефонный номер, соответствующий карточной платформе IP-телефонии провайдера. АТС, к которой подключен абонент А принимает запрос и устанавливает соединение со шлюзом IP-телефонии. После этого абонент А получает голосовые подсказки со стороны оборудования провайдера, действуя согласно этим подсказкам он переводит телефон в режим тонального набора и набирает свой номер карты и ПиН-код, чтобы получить право доступа к ресурсам сети. Шлюз IP-телефонии, будучи клиентом RADIUS-сервера, передает полученные данные серверу аутентификации в сообщении Access- Request. RADIUS сервер обращается к базе данных, например Oracle, в которой хранятся данные о соответствии номеров карт и ПиН-кодов. В случае успешной аутентификации шлюзу передается сообщение Access-Accept. После получения этого сообщения пользователю проигрываются дальнейшие подсказки и он набирает номер абонента В, который также передается RADIUS серверу для выбора тарифного плана и создания начислений. Далее шлюз передает на общеизвестный ТСР порт 1720 сообщение сигнального канала H.225.0 Setup с целью установить соединение. SoftSwitch (SS) принимает запрос, обрабатывает его, анализирует адресную информацию и направляет запрос Setup либо другому шлюзу, в зоне которого находится абонент В, либо непосредственно ему, если это терминал H.323. После получения сообщения Setup происходит обмен сигнальными сообщениями RAS: ARQ и ACF между SS и оконечным оборудованием. В сообщении ARQ содержится идентификатор оборудования и alias-адрес вызывающего оборудования. В сообщении ACF указывается суммарная скорость полосы пропускания и транспортный адрес сигнального канала. Далее происходит передача сообщений вызывающей стороне H.225.0 Alerting (оборудование не занято и ему подается сигнал вызова) и Connect (содержащее транспортный адрес управляющего канала H.245). После этого между вызывающим шлюзом и вызываемым оборудованием открывается управляющий канал H.245 и происходит обмен сообщениями о функциональных возможностях оборудования TCS, определение ведущего-ведомого MSD и открытие логических каналов OLC. В сообщениях OLC содержится транспортные адреса, на которые необходимо передавать RTP-пакеты. После открытия логических каналов шлюз обменивается с RADIUS-сервером сообщениями, соответствующими началу сеанса связи.

3.5.2. Сценарий безопасной  обработки вызова  в сети IP-телефонии

  Рассмотрим сценарий установления безопасного соединения в сети, представленной на рис. 3.6.  

1. Абонент  набирает местный номер для  доступа к шлюзу. Этот вызов поступает из ТФОП на шлюз через ISDN .

2. Шлюз  отвечает на вызов. После голосовой  подсказки, абонент набирает персональный код.

3. Шлюз (выступающий в данном случае  в качестве сервера сетевого доступа) отправляет серверу RADIUS пакет Access-Request, содержащий полученные от пользователя данные для подтверждения.

4. Сервер  защиты RADIUS идентифицирует посылающего  клиента, выполняет аутентификацию пользователя, проверяет параметры авторизации пользователя и возвращает один из следующих ответов: Access-Accept – пользователь аутентифицирован, Access-Reject – пользователь не аутентифицирован, Access-Challenge – вызов является дополнительной возможностью сервера защиты RADIUS, позволяющей получить дополнительные данные о пользователе.

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

6. Шлюз  принимает набранный номер вызываемого  абонента и передает его RADIUS-серверу для дальнейшего аудита.

7. Шлюз  посылает SoftSwitch запрос на соединение Setup

8. SoftSwitch анализирует полученное сообщение  и посылает запрос Setup терминалу H.323.

9. Softswitch и терминал H.323 обмениваются сообщениями  в рамках протокола RAS: ARQ и ACF.

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

11. Время  начала и окончания разговора записывается на вызываемом и вызывающем шлюзах и передается на сервер RADIUS; по окончании использования сервиса шлюз посылает стоп-пакет Accounting-Request, в этом пакете указывается тип предоставленного сервиса и дополнительные статистические данные. RADIUS-сервер подтверждает получение стоп-пакета, возвращая пакет Accounting- Response.

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

4. Обеспечение безопасности  передачи голосового  трафика в

сети IP-телефонии

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

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

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

  Безопасность же передачи информации в таком случае внушает явное

опасение. Как быть в такой ситуации?

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

4.1. VPN как механизм обеспечения  безопасности сети IP-телефонии

  Для создания сетей VPN разработано множество протоколов. Каждый из этих протоколов обеспечивает определенные возможности VPN. Например, протокол IPSec - Internet Protocol Security (упоминание об этом протоколе уже встречалось ранее, когда речь шла о безопасности в рамках рекомендации H.235) предлагает методы шифрования сетевого уровня, обеспечивающие возможности аутентификации и сервис шифрования между конечными точками в общедоступных IP-сетях. Технология IPSec и связанные с ней протоколы защиты соответствуют открытым стандартам, которые поддерживаются группой IETF (проблемная группа проектирования Интернет) и описаны в спецификациях RFC и проектах IETF. IPSec действует на сетевом уровне, обеспечивая защиту и аутентификацию пакетов IP, пересылаемых между устройствами (сторонами) IPSec – такими как маршрутизаторы, брандмауэры Firewall, клиенты и концентраторы VPN, а также многие другие продукты, поддерживающие данный протокол.

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

• Протокол GRE (Generic Routing Encapsulation – общая инкапсуляция для маршрутизации). Разработанный Cisco туннельный протокол, обеспечивающий инкапсуляцию многих типов протокольных пакетов в туннели IP, создает виртуальную двухточечную связь с маршрутизаторами в удаленных точках IP-сети.

• Протокол L2F (Layer 2 Forwarding – протокол пересылки уровня 2). Протокол, позволяющий создать сеть VPDN – виртуальную частную коммутируемую сеть – систему, обеспечивающую существование коммутируемых сетей, распространяющихся на удаленные домашние офисы, которые кажутся при этом непосредственной частью единой сети организации.

• Протокол PPTP (Point-to-Point Tunneling Protocol – протокол туннелирования двухточечного соединения). Разработанный Microsoft сетевой протокол, обеспечивающий защищенную передачу данных от удаленного клиента к частному серверу организации с помощью создания сети VPN над IP-сетями. Протокол PPTP поддерживает маршрутизацию по требованию, многопотокольный обмен и виртуальные частные сети в открытых сетях типа Internrt.

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