интернет телефония. курсовая интернет-телефония. История позникновения и принцип работы internetтелефонии
 Скачать 323.82 Kb.
|
3.3 Технологии ААА на базе протокола RADIUSПротокол RADIUS был разработан компанией Livingston Enterprises, Inc. (теперь находящейся в составе Lucent Technologies) в качестве протокола аутентификации серверного доступа и учета. В настоящее время протокол RADIUS описывается в документе RFC 2865, а аудит RADIUS – в RFC 2866. RADIUS (Remote Access Dial-In User Service – сервис идентификации удаленных абонентов) представляет собой распределенный протокол, используемый в рамках технологии клиент/сервер и обеспечивающий защиту сети от несанкционированного доступа. Так например компания Cisco поддерживает RADIUS как одну из составляющих системы защиты ААА. Рассматриваемый протокол скорее объединяет аутентификацию и авторизацию, чем трактует их отдельно, как это делается в отношении аудита [17]. Протокол RADIUS может использоваться с другими протоколами защиты ААА, например с TACACS+, Kerberos и локальными базами данных защиты. Протокол RADIUS реализован во многих сетевых средах, требующих высокого уровня защиты при условии поддержки сетевого доступа для удаленных пользователей. Он представляет собой полностью открытый протокол, поставляемый в формате исходного текста, который можно изменить для того, чтобы он мог работать с любой доступной в настоящий момент системой защиты. Широкую популярность RADIUS обеспечивает возможность добавлять новые пары «атрибут/значение» в дополнение к тем, которые описаны в документе RFC 2865. Протокол RADIUS имеет атрибут поставщика , позволяющий поставщику осуществлять поддержку своих собственных расширенных наборов атрибутов, включающих нестандартные атрибуты. Вследствие использования пар «атрибут/значение» конкретных поставщиков могут возникать трудности при интеграции серверных продуктов защиты RADIUS в другие системы защиты. Серверы защиты RADIUS и соответствующие клиенты должны игнорировать нестандартные пары «атрибут/значение», созданные конкретными поставщиками. Связь между NAS и сервером RADIUS основана на протоколе UDP. В целом считается, что протокол RADIUS не имеет отношения к подключению. Все вопросы, связанные с доступностью сервера, повторной передачей данных и отключениями по истечении времени ожидания, контролируются устройствами, работающими под управлением протокола RADIUS, но не самим протоколом передачи. Протокол RADIUS основан на технологии клиент-сервер. Клиентом RADIUS обычно является NAS, а сервером RADIUS считается «демон», работающий на машине UNIX или NT. Клиент передает пользовательскую информацию на определенные серверы RADIUS, а затем действует в соответствии с полученными от сервера инструкциями. Серверы RADIUS принимают запросы пользователей на подключение, проводят идентификацию пользователей, а затем отправляют всю конфигурационную информацию, которая необходима клиенту для обслуживания пользователя. Для других серверов RADIUS или идентификационных серверов других типов сервер RADIUS может выступать в роли клинта-посредника (proxy) [19]. RADIUS поддерживает следующие возможности сервера защиты: Пакеты UDP. Для связи RADIUS между сервером доступа и сервером защиты используется протокол UDP и UDP-порт 1812, официально назначенный для этого. Некоторые реализации RADIUS используют UDP-порт 1645. Использование UDP упрощает реализацию клиента и сервера RADIUS. Объединение аутентификации и авторизации и выделение аудита. Сервер RADIUS получает запросы пользователя, выполняет аутентификацию и обеспечивает клиенту информацию о конфигурации. Аудит выполняется сервером аудита RADIUS. Шифрование паролей пользователей. Пароли, содержащиеся в пакетах RADIUS (а это только пользовательские пароли), шифруются посредством хэширования MD5. Аутентификация PAP и CHAP. Обеспечивает управление аутентификацией с помощью средств вызова/ответа PAP и CHAP, а также посредством диалога начала сеанса и ввода пароля наподобие входа в систему UNIX. Защита глобальной сети. Обеспечивает поддержку средств ААА удаленного доступа для серверов доступа многих поставщиков, поддерживающих клиентов RADIUS. Дает возможность централизовать управление удаленным доступом. Поддержка ряда протоколов, обеспечивающих терминальный доступ к серверу защиты RADIUS. Функция обратного вызова. Данная функция возвращает телефонные вызовы, заставляя сервер доступа звонить соответствующему пользователю, что может дать дополнительные гарантии защиты пользователям, использующим доступ по телефонным линиям. Расширяемость. Все транзакции предполагают использование пар «атрибут/значение» переменной длины. Новые атрибуты могут быть добавлены в существующие реализации протокола. Гарантированная сетевая защита. Аутентификация транзакций между клиентом и сервером защиты RADIUS предполагает использование общего секретного значения [20]. Клиент RADIUS и сервер защиты RADIUS обмениваются пакетами Access-Request (доступ-запрос), Access-Accept (доступ-подтверждение), Access-Reject (доступ-отказ) и Access-Challenge (доступ-вызов). Как показано на рисунке 9, при попытке подключиться к серверу сетевого доступа, имеющему конфигурацию клиента RADIUS, выполняются следующие шаги: Пользователь инициализирует запрос аутентификации PPP к серверу сетевого доступа. У пользователя запрашивается имя пользователя и пароль Сервер сетевого доступа посылает серверу защиты RADIUS пакет Access-Request, содержащий имя пользователя, шифрованный пароль и другие атрибуты.  Рисунок 9. Процесс аутентификации и авторизации RADIUS Сервер защиты RADIUS идентифицирует клиента-инициатора, выполняет аутентификацию пользователя, проверяет параметры авторизации пользователя и возвращает один из следующих ответов: Access-Accept – пользователь аутентифицирован. Access-Reject – пользователь не аутентифицирован, и сервер сетевого доступа либо предлагает ввести имя пользователя и пароль снова, либо запрещает доступ. Access-Challenge – вызов является дополнительной возможностью сервера защиты RADIUS. Сервер сетевого доступа обращается к параметрам аутентификации, разрешающим использование конкретных служб. Ответ Access-Accept или Access-Reject связывается с дополнительными данными (парами «атрибут/значение»), используемыми для сеансов EXEC и авторизации. Процесс аутентификации RADIUS должен быть завершен до начала процесса авторизации [17]. Сервер защиты RADIUS может периодически посылать пакеты Access-Challenge серверу сетевого доступа, чтобы потребовать повторного введения имени пользователя и пароля пользователем, информировать о состоянии сервера сетевого доступа или выполнить какие-то другие действия, предусмотренные разработчиками сервера RADIUS. Клиент RADIUS не может посылать пакеты Access-Challenge.  Рисунок 10. Взаимодействие между пользователем и системой TACACS+ Авторизация — это процесс определения действий, которые позволены данному пользователю. Обычно аутентификация предшествует авторизации, однако это не обязательно. В запросе на авторизацию можно указать, что аутентификация пользователя не проведена (личность пользователя не доказана). В этом случае лицо, отвечающее за авторизацию, должно самостоятельно решить, допускать такого пользователя к запрашиваемым услугам или нет. Протокол TACACS+ допускает только положительную или отрицательную авторизацию, однако этот результат допускает настройку на потребности конкретного заказчика. Авторизация может проводиться на разных этапах, например, когда пользователь впервые входит в сеть и хочет открыть графический интерфейс иди когда пользователь запускает PPP и пытается использовать поверх PPP протокол IP с конкретным адресом IP. В этих случаях демон сервера TACACS+ может разрешить предоставление услуг, но наложить ограничения по времени или потребовать список доступа IP для канала PPP [16]. Протокол RADIUS был усовершенствован с тем, чтобы обеспечить доставку информации аудита от клиента RADIUS серверу аудита RADIUS через UDP-порт 1813. Клиент RADIUS отвечает за отправку информации аудита пользователя соответствующему серверу аудита RADIUS, для чего используется пакет типа Accounting-Request (аудит-запрос) с соответствующим набором пар «атрибут/значение». Сервер аудита RADIUS должен принять запрос аудита и вернуть ответ, подтверждающий успешное получение запроса. Для этого используется пакет типа Accounting-Response (аудит-ответ).  Рисунок 10. Процесс аудита RADIUS Как видно из рисунке 9, при попытке подключиться к серверу сетевого доступа, имеющему конфигурацию клиента RADIUS, выполняются следующие шаги: 1) После исходной аутентификации сервер сетевого доступа посылает серверу защиты RADIUS старт-пакет Accounting-Request. 2) Сервер защиты RADIUS подтверждает получение старт-пакета, возвращая пакет Accounting-Response. 3) По окончании использования сервиса сервер сетевого доступа посылает стоп-пакет Accounting-Request; в этом пакете указывается тип предоставленного сервиса и дополнительные статистические данные. 4) Сервер защиты RADIUS подтверждает получение стоп-пакета, возвращая пакет Accounting-Response. Хотя TACACS и RADIUS очень похожи по своим функциональным возможностям, они имеют несколько важных отличий, указанных в таблице 1. Таблица 1 – Сравнение протоколов TACACS+ и RADIUS
Помимо этого TACACS+ поддерживает двунаправленный поток вызовов/ответов между серверами сетевого доступа подобно тому, как это сделано в CHAP. RADIUS поддерживает однонаправленный вызов/ответ от сервера защиты RADIUS к клиенту RADIUS [20]. Целостность данных. TACACS+ предполагает шифрование содержимого пакетов. RADIUS предусматривает шифрование только атрибутов пароля в пакете Access-Request. Это означает лучшую защищенность TACACS+. Кроме того, сравнивая TACACS+ и RADIUS, можно отметить следующие: Возможности настройки. Гибкость протокола TACACS+ обеспечивает возможность настройки множества параметров в соответствии с требованиями отдельных пользователей. Из-за недостаточной гибкости RADIUS многие возможности, доступные в рамках TACACS+, при использовании RADIUS недоступны (например, каталоги сообщений). Однако, RADIUS поддерживает возможность изменения наборов пар «атрибут/значение». Процесс авторизации. При использовании TACACS+ сервер принимает или отвергает запрос аутентификации на основании данных пользовательского профиля. Клиенту (NAS) содержимое пользовательского профиля остается неизвестным. В системе RADIUS все посылаемые с ответом атрибуты пользовательского профиля передаются серверу сетевого доступа. Сервер принимает или отвергает запрос аутентификации на основании полученных им значений атрибутов. По большому счету протокол RADIUS не поддерживает авторизацию. То есть RADIUS есть смысл использовать только там, где заранее известно какой сервис предоставляет конкретный RADIUS-клиент. У TACACS+ заложена поддержка авторизации. Но следует отметить, что количество авторизуемых сервисов довольно ограничено в текущей. То есть для доступа к какому-либо сервису RADIUS обрабатывает один запрос (аутентификацию - запрос, ответ), а TACACS+ - два (аутентификацию и авторизацию), но при этом при использовании TACACS+ есть возможность получить доступ к другому сервису. Аудит. Аудит TACACS+ предполагает использование ограниченного числа информационных полей. Аудит RADIUS может предоставить больше информации, чем можно получить из записей аудита TACACS, что является главным преимуществом в сравнении с TACACS+. Возможность перенаправления запроса. В TACACS+ такая возможность просто отсутствует. RADIUS-протокол же имеет такую возможность. Это очень существенное достоинство этого протокола, в случае если есть представительства оператора IP-телефонии в других регионах. В этом случае клиент, находясь в другом регионе, набирает код доступа (номер и пин-код). Далее местный RADIUS-сервер перенаправляет запрос в соответствующий регион. Происходит аутентификация, и ответ отправляется назад. Таким образом, RADIUS позволяет проектировать гибкую распределенную RADIUS схему. Следовательно, RADIUS-клиент на любой запрос должен дожидаться ответа от сервера в течение некоторого времени (timeout'а) и в случае отсутствии оного перепослать пакет еще раз. TACACS+ клиент тоже должен дожидаться всегда ответа от сервера, но в отличии от RADIUS-клиента, в случае отсутствия ответа, пакет еще раз не посылается. Гарантия доставки обеспечивается тем, что для обработки какого-либо запроса TACACS+ сервер и клиент должны установить TCP-соединение (даже если весь процесс будет состоять из посылки и приема 2-ух небольших пакетов), а с точки зрения времени это довольно длительный процесс (по этой причине TACACS+ по определению относительно медленен). На основании этого, можно сказать, что RADIUS будет более эффективен в сетях, где процент потерянных пакетов менее 5-10 %; в других сетях лучше использовать TACACS+. Именно по этой причине в сетях IP-телефонии, где необходимо быстродействие применяется, как правило, протокол RADIUS [16]. 3.4 Технические несоответствия с теоретическими характеристиками протоколов TACACS и RADIUSРазличий между протоколами RADIUS и TACACS+ достаточно много, но выполняемые ими функции, по сути, одинаковы. Протокол RADIUS, являющийся стандартом, использует на транспортном уровне протокол UDP. Протокол же TACACS+, являясь частной разработкой, применяет на транспортном уровне протокол TCP. Протокол RADIUS хорошо работает только в IP-средах, тогда как протокол TACACS+ полезен в многопротокольных средах. В настоящее время протоколом RADIUS поддерживается больше количество атрибутов, и он позволяет передавать клиенту и серверу больше информации, чем протокол TACACS+. Наконец, RADIUS шифрует только пароль, пересылаемый между клиентом и сервером, тогда как TACACS+ шифрует всю пересылаемую информацию. Если сеть в значительной степени гетерогенна, то лучше всего выбрать протокол RADIUS, так как его поддерживают многие поставщики. Если сеть использует главным образом устройства компании Cisco, то, скорее всего, правильным решением будет применение протокола TACACS+. Часто возникает задача проверить пользователя до предоставления ему доступа к определенным ресурсам. Такая проверка называется «перехватывающая аутентификация» (cut-through proxy). Этот сервис использует инфраструктуру ААА (Authentication, Authorization, Accounting) [20]. TACACS+ – протокол, работающий по ТСР/49. Имеет отдельные запросы на аутентификацию, авторизацию и учет. За счет отдельного запроса на авторизацию позволяет учитывать и проверять все вводимые команды. Не расширяемые параметры, слабый «учет». Как правило, используется для административного доступа. RADIUS – стандартный протокол. Работает по UDP/1645,1646 или UDP/1812,1813. Один новый, другой старый стандарт. Первый порт используется для аутентификационного запроса и ответа, в котором заодно передаются авторизационные атрибуты пользователя, если есть. Второй – для учета (как правило, при помощи RADIUS учитывают переданные пакеты, считают трафик и некоторые системные параметры) Таким образом, с аутентификацией все просто: если более ничего не указывать, то пользователю, а вернее, ip-адресу его компьютера, будет можно все. Гораздо более интересный момент – авторизация, то есть ограничение прав пользователя. По протоколу TACACS можно ограничивать доступ к определенным ресурсам (сетям и протоколам), однако формат такого ограничения весьма странный: на сервере описываются все такие протоколы и сети, и обращение с ASA на сервер идёт всякий раз, когда появляется ранее не изученный пакетик. Для этого надо отдельно писать команду для авторизации. Можно использовать тот же список доступа, который был использован для аутентификации, а можно написать новый. Проще использовать протокол RADIUS, у которого предусмотрена возможность в атрибутах пользователя передавать строки списка доступа, который применяется непосредственно к пользователю. Никаких дополнительных команд писать не надо. Правда, такая возможность есть у cisco ACS (Access Control Server). Доподлинно я не знаю, есть ли бесплатные и свободные реализации сервера RADIUS, умеющие также передавать строчки. Понятно, что учет нельзя делать на сервер LOCAL (локально), а также на сервер LDAP. На TACACS передается не так много атрибутов, как хотелось бы, а вот RADIUS подходит лучше всего. Причем использовать можно любой. В частности я, когда настраиваю аутентификацию и авторизацию через LDAP для учета использую IAS (это как раз и есть RADIUS, встроенные в сервер Windows). Отчеты, правда, с него снимать не так удобно, как с ACS или других, более приспособленных решений [1]. Внешняя аутентификация. В данном случае циска не знает пользователей в логин всегда сверяется с внешним сервером по протоколу TACACS или RADIUS (более распространено). Минусы очевидны: есть необходимость в дополнительной органицации и поддержке RADIUS-сервера, а при его недоступности доступ в сеть будет запрещён. Однако при масштабировании системы, добавлении новых серверов доcтупа или резервных серверов RADIUS [17]. ЗАКЛЮЧЕНИЕВ данной работе была изучена IP-телефонии и рассмотрела ее использование в защищенном режиме. Рассмотрены уровни архитектуры IP-телефонии, построение сетей на основе протоколов Н.323, SIP и MGCP; сценарии систем «компьютер-компьютер», «компьютер-телефон», «телефон-телефон». Рассмотрели виды угроз IP-телефонии, такие как регистрацию чужого терминала, позволяющую делать звонки за чужой счет, подмену абонента, внесение изменений в голосовой или сигнальный трафик, снижение качества голосового трафика, перенаправление голосового или сигнального трафика, перехват голосового или сигнального трафика, подделка голосовых сообщений, завершение сеанса связи, отказ в обслуживании и удаленный несанкционированный доступ к компонентам инфраструктуры IP-телефонии. Эти проблемы предлагается решать разными способами: криптографии, защищенности канала, технологии ААА. В данной дипломной работе на основе технологии ААА сравнила протоколы аутентификации TACACS+ и RADIUS. После исследования про-токолов аутентификации, одной из основных составляющих защищенности, сделала вывод, что в административных сетях для защиты информации лучше использовать протокол TACACS+, учитывая особенности каждой сети. Для сети более крупного масштаба лучше использовать протокол RADIUS. СПИСОК ЛИТЕРАТУРЫМирманов А.Б., Наурыз К.Ж., Кенебаева Д.Б., Клюева П.Ю. Методические указания для выполнения дипломной работы (проекта) по специальности 050719 – «Радиотехника, электроника и телекоммуникации»: Астана 2009. Гольдштейн Б. С., Пинчук А. В., Суховицкий А. Л. IP-телефония: Радио и связь, 2008. Стив Мак-Квери, Келли Мак-Грю, Стивен Фой. Передача голосовых данных по сетям Cisco Frame Relay, ATM и IP; Киев, 2007. Росляков А.В. IP-телефония; Москва, 2008. Джонатан Дэвидсон, Джеймс Питерс, Манож Бхатия, Сатиш Калидинди, Судипто М. Основы передачи голосовых данных по сетям IP (IP Voice over IP Fundamentals); Вильямс, 2007. Нопин С. В., Шахов В. Г. Анализ защищенности абонентских систем IP-телефонии от несанкционированного доступа // Информационные технологии. 2008. № 11. С. 67-74. Блоги по технологиям и оборудованию cisco от инструкторов – Режим доступа: http://www.anticisco.ru/blogs. Дата обращения: 03.03.2010. Форум тех.поддержки – Режим доступа: http://voip.jalita.com/literature. Дата обращения: 29.04.2010. Cisco systems – Режим доступа: http://www.cisco.com/russian_win /warp/public/3/ru/solutions/sec/mer_tech_ident-tacacs.html. Дата обращения: 6.02.2010. OpenNET – Режим доступа: http://www.opennet.ru/base/cisco/radius.txt Дата обращения: 7.03.2010. Computer club - Режим доступа: http://www.ccm.kz/article/default. Дата обращения: 6.02.2010. Сайт об IP-телефонии - Режим доступа: http://ukash.idhost.kz. Дата обращения: 8.04.2010. Price zone. IP-телефонии. Обзор технологии - Режим доступа: http://www.price.od.ua/articles.phtml_id=71. Дата обращения: 8.05.2010. Исследования - Режим доступа: http://www.comcon-2.kz/ consultation/konsl_000023.php. Дата обращения: 10.05.2010. Компьютерная документация и софт - Режим доступа: http://www.winsov.ru/net036.php. Дата обращения: 10.05.2010. Стоп вирус - Режим доступа: http://www.stopvirus.kz/index.php. Дата обращения: 11.05.2010. Проект объединения независимых сетей VoIP - Режим доступа: http://voipx.ru/cgi-bin/loscont.cgi?ID=08. Дата обращения: 12.05.2010. Интернет решения - Режим доступа: http://www.gelios.biz/articles/ip-telefoniya-nastoyashhee-i-budushhee.html. Дата обращения: 6.05.2010. IP-телефония - Режим доступа: http://www.ctspi.ru/TechSupp/ IPTEL/Obzor.htm. Дата обращения: 13.05.2010. Современные технологии - Режим доступа: http://www.telda.ru/ connection.html. Дата обращения: 16.05.2010. Официальный сайт Президента Р.К. – Режим доступа: http:// www.akorda.kz. Дата обращения: 01.06.2010. |