Безопасность IP-телефонии

     Протоколы  ЕАР и CHAP представляют собой  два метода аутентификации протокола  РРР. ЕАР - это общий протокол  аутентификации РРР, который поддерживает множество идентификационных механизмов. Этот протокол находится в процессе доработки, и в будущем он сможет поддерживать более современные механизмы аутентификации в рамках аутентификации РРР. Аутентификация происходит после согласования LCP и до согласования IP Control Protocol (IPCP), в ходе которого происходит обмен адресами IP. Этот процесс аутентификации проходит в автоматическом режиме и не требует от пользователей ввода в компьютер каких-либо данных при подключении РРР. Часто аутентификация РАР или CHAP занимает место переговорного сценария, который отвечает на запросы о вводе сетевого имени пользователя (login) и пароля. CHAP поддерживает более высокий уровень безопасности, поскольку не передает реальный пароль по каналу РРР. Однако РАР используется чаще. 

Инкапсуляция, или утаивание  информации (information hiding), — это возможность скрыть внутреннее устройство объекта от его пользователей, предоставив через интерфейс доступ

12

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

Протокол TACACS

     TACACS- это простой протокол управления доступом, основанный на стандартах User Datagram Protocol (UDP) и разработанных компанией Bolt, Beranek and Newman, Inc. (BBN). Компания Cisco несколько раз совершенствовала и расширяла протокол TACACS, и в результате появилась ее собственная версия TACACS, известная как TACACS+. TACACS+ пользуется транспортным протоколом TCP. Демон сервера «слушает» порт 49, который является портом протокола IP, выделенным для протокола TACACS. Этот порт зарезервирован для выделенных номеров RFC в протоколах UDP и TCP. Все текущие версии TACACS и расширенные варианты этого протокола используют порт 49. 

     Протокол TACACS+ работает по технологии клиент-сервер, где клиентом TACACS+ обычно является NAS, а сервером TACACS+, как правило,  считается "демон" (процесс,  запускаемый на машине UNIX или NT). Фундаментальным структурным компонентом протокола TACACS+ является разделение аутентификации, авторизации и учета (ААА Authentication, Authorization, Accounting). Это позволяет обмениваться идентификационными сообщениями любой длины и содержания, и, следовательно, использовать для клиентов TACACS+ любой идентификационный механизм, в том числе РРР РАР, РРР CHAP, аппаратные карты и Kerberos (рис. 4.2). Аутентификация не является обязательной. Она рассматривается как опция, которая конфигурируется на месте. В некоторых местах она вообще не требуется, в других местах она может применяться лишь для ограниченного набора услуг. 

Рис. 2. Взаимодействие между пользователем и системой TACACS+ 

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

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

13

пользователь  запускает РРР и пытается использовать поверх РРР протокол IP с конкретным адресом IP. В этих случаях демон сервера TACACS+ может разрешить предоставление услуг, но наложить ограничения по времени или потребовать список доступа IP для канала РРР. 

     Учет  обычно следует за аутентификацией  и авторизацией. Учет представляет собой запись действий пользователя. В системе TACACS+ учет может выполнять две задачи. Во-первых, он может использоваться для учета использованных услуг (например, для выставления счетов). Во-вторых, его можно использовать в целях безопасности. Для этого TACACS+ поддерживает три типа учетных записей. Записи «старт» указывают, что услуга должна быть запущена. Записи «стоп» говорят о том, что услуга только что окончилась. Записи "обновление" (update) являются промежуточными и указывают на то, что услуга все еще предоставляется. Учетные записи TACACS+ содержат всю информацию, которая используется в ходе авторизации, а также другие данные: время начала и окончания (если это необходимо) и данные об использовании ресурсов. 

     Транзакции  между клиентом TACACS+ и сервером TACACS+ идентифицируются с помощью общего «секрета», который никогда не передается по каналам связи. Обычно этот секрет вручную устанавливается на сервере и на клиенте. TACACS+ можно настроить на шифрование всего трафика, который передается между клиентом TACACS+ и демоном сервера TACACS+. 
 

Протокол RADIUS 

     Протокол RADIUS был разработан компанией  Livingston Enterprises, Inc. в качестве протокола  аутентификации серверного доступа  и учета. В настоящее время  спецификация RADIUS (RFC 2058) и стандарт учета RADIUS (RFC 2059) предложены для утверждения в качестве общепринятых стандартов IETF. 
 

Рис. 3. Взаимодействие между пользователем и системой RADIUS 

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

 

14

   Протокол RADIUS основан на технологии клиент-сервер (рис. 8.3). Клиентом RADIUS обычно является NAS, а сервером RADIUS считается «демон»,  работающий на машине UNIX или NT. Клиент передает пользовательскую  информацию на определенные серверы RADIUS, а затем действует в соответствии с полученными от сервера инструкциями. Серверы RADIUS принимают запросы пользователей на подключение, проводят идентификацию пользователей, а затем отправляют всю конфигурационную информацию, которая необходима клиенту для обслуживания пользователя. Для других серверов RADIUS или идентификационных серверов других типов сервер RADIUS может выступать в роли клиента-посредника (proxy). 

  
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

15

5. Особенности системы безопасности в IP-телефонии 

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

Для обеспечения  системной безопасности используются следующие функции. 

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

Списки доступа, в которые вносятся все известные  шлюзы IP-телефонии.

Запись отказов  в доступе.

Функции безопасности интерфейса доступа, включая:

проверку идентификатора и пароля пользователя с ограничением доступа по чтению/записи; проверку прав доступа к специальному WEB-серверу  для администрирования. 

Функции обеспечения безопасности вызова включают: 

проверку идентификатора и пароля пользователя (необязательно); статус пользователя; профиль абонента. 

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

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

голос ТфОП - ТфОП; 

факс ТфОП - ТфОП; 

компьютер - ТфОП; 

службы, определенные пользователем (при помощи API). 

     Профиль  абонента используется для проверки  права доступа абонента к запрошенным  службам. 
 
 
 
 
 
 
 

16

6. Обеспечение безопасности в системах на базе стандарта Н.323 

     Для  систем IP-телефонии, построенных  на базе Рекомендации ITU-T H.323, вопросы безопасности рассматриваются в Рекомендации Н.235 (рис. 4.4). Эта рекомендация описывает ряд технических требований, включая вопросы безопасности: аутентификация пользователей и шифрование данных. Предложенная схема обеспечения безопасности применима и к простым двухточечным и к многоточечным конференциям для любых терминалов, которые используют протокол управления Н.245. Если для IP-телефонии стандарта Н.323 используются сети с пакетной коммутацией, не обеспечивающие гарантированного качества обслуживания QoS, то по тем же самым техническим причинам не обеспечивается и безопасное обслуживание. Для обеспечения гарантированной связи в реальном масштабе времени по опасным сетям необходимо рассматривать две главных области обеспечения безопасности - аутентификация и секретность.

 
 

Рис. 4. Область действия Рекомендации Н.235 в серии Рекомендаций Н.323 

17

В соответствии с Рекомендацией  Н.235 в системе  должны быть реализованы  четыре основные функции  безопасности: 

-аутентификация; 

-целостность данных; 

-секретность; 

-проверка отсутствия долгов. 

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

     Целостность  данных и секретность обеспечивается  криптозащитой. Проверка отсутствия  долгов гарантируется тем, что  конечная точка может отказать  в обслуживании вызова. Для обеспечения  безопасности согласно рекомендации Н.235 могут использоваться существующие стандарты: IP-безопасность (IP Security - IPSec) и безопасность транспортного уровня (Transport Layer Security - TLS).    

     Для  обеспечения безопасной связи  в системе на базе Рекомендации Н.323 используются механизмы защиты информации канала управления вызовами Q.931, информации канала управления для мультимедиа коммуникаций Н.245, информации каналов передачи мультимедиа. Канал управления вызовом (Н.225.0) и канал сигнализации (Н.245) должны оба работать в защищенном или незащищенном режимах, начинающимся с первой станции. Для канала управления вызовом защита сделана априорно (для систем в соответствии с Рекомендацией Н.323 безопасность транспортного уровня обеспечивается соответствующим протоколом TSAP [порт 1300], который должен использоваться для Q.931 сообщений). Для канала сигнализации режим «защита» определяется информацией, переданной с помощью протокола начальной установки и подключения терминалов стандарта Н.323. 

     В  целом следует отметить, что все основные механизмы аутентификации, определенные в Рекомендации Н.235, идентичны или получены из алгоритмов, разработанных Международной организации по стандартизации ISO, или основаны на протоколах IETF. 
 
 
 
 
 
 
 

18

7. Обеспечение безопасности IP-телефонии на базе VPN(виртуальные частные связи). 

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