Сущность и проблемы IP-телефонии, ее использование в защищенном режиме

В процессе авторизации TACACS+ используется два типа пакетов: REQUEST (запрос) и RESPONSE (ответ). Данный процесс авторизации пользователя контролируется посредством обмена парами «атрибут/значение» между сервером защиты TACACS+ и сервером доступа [20].

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

В процессе аудита TACACS+ использует два типа пакетов - REQUEST (запрос) и RESPONSE (ответ). Данный процесс во многом подобен процессу авторизации. В процессе аудита создаются записи с информацией об активности пользователя в отношении заданных сервисов. Записи, регистрирующие выполненные сетевым оборудованием действия, могут сохраняться в некотором стандартном формате, на сервере защиты с целью дальнейшего анализа.

В рамках TACACS+ аудит ААА не является средством надежной защиты и обычно используется только для учета или управления. Однако с помощью аудита ААА можно контролировать действия пользователя, чтобы, например, вовремя заметить его необычное поведение при работе с сетевым оборудованием [20].

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

3.3.1 Протокол 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].

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

RADIUS поддерживает следующие возможности сервера защиты:

- Пакеты UDP. Для связи RADIUS между сервером доступа и сервером защиты используется протокол UDP и UDP-порт 1812, официально назначенный для этого. Некоторые реализации RADIUS используют UDP-порт 1645. Использование UDP упрощает реализацию клиента и сервера RADIUS.

- Объединение аутентификации и авторизации и выделение аудита. Сервер RADIUS получает запросы пользователя, выполняет аутентификацию и обеспечивает клиенту информацию о конфигурации. Аудит выполняется сервером аудита RADIUS.

- Шифрование паролей пользователей. Пароли, содержащиеся в пакетах RADIUS (а это только пользовательские пароли), шифруются посредством хэширования MD5.

- Аутентификация PAP и CHAP. Обеспечивает управление аутентификацией с помощью средств вызова/ответа PAP и CHAP, а также посредством диалога начала сеанса и ввода пароля наподобие входа в систему UNIX.

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

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

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

- Расширяемость. Все транзакции предполагают использование пар «атрибут/значение» переменной длины. Новые атрибуты могут быть добавлены в существующие реализации протокола.

- Гарантированная сетевая защита. Аутентификация транзакций между клиентом и сервером защиты RADIUS предполагает использование общего секретного значения [20].

3.3.3 Процесс аутентификации и авторизации в протоколе RADIUS

Клиент RADIUS и сервер защиты RADIUS обмениваются пакетами Access-Request (доступ-запрос), Access-Accept (доступ-подтверждение), Access-Reject (доступ-отказ) и Access-Challenge (доступ-вызов). Как показано на рисунке 3.1, при попытке подключиться к серверу сетевого доступа, имеющему конфигурацию клиента RADIUS, выполняются следующие шаги:

- Пользователь инициализирует запрос аутентификации PPP к серверу сетевого доступа.

- У пользователя запрашивается имя пользователя и пароль

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

-

Рисунок 3.1. Процесс аутентификации и авторизации RADIUS

Сервер защиты RADIUS идентифицирует клиента-инициатора, выполняет аутентификацию пользователя, проверяет параметры авторизации пользователя и возвращает один из следующих ответов:

Access-Accept - пользователь аутентифицирован.

Access-Reject - пользователь не аутентифицирован, и сервер сетевого доступа либо предлагает ввести имя пользователя и пароль снова, либо запрещает доступ.

Access-Challenge - вызов является дополнительной возможностью сервера защиты RADIUS.

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

- Ответ Access-Accept или Access-Reject связывается с дополнительными данными (парами «атрибут/значение»), используемыми для сеансов EXEC и авторизации. Процесс аутентификации RADIUS должен быть завершен до начала процесса авторизации [17].

- Сервер защиты RADIUS может периодически посылать пакеты Access-Challenge серверу сетевого доступа, чтобы потребовать повторного введения имени пользователя и пароля пользователем, информировать о состоянии сервера сетевого доступа или выполнить какие-то другие действия, предусмотренные разработчиками сервера RADIUS. Клиент RADIUS не может посылать пакеты Access-Challenge.

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

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

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

Протокол RADIUS был усовершенствован с тем, чтобы обеспечить доставку информации аудита от клиента RADIUS серверу аудита RADIUS через UDP-порт 1813. Клиент RADIUS отвечает за отправку информации аудита пользователя соответствующему серверу аудита RADIUS, для чего используется пакет типа Accounting-Request (аудит-запрос) с соответствующим набором пар «атрибут/значение». Сервер аудита RADIUS должен принять запрос аудита и вернуть ответ, подтверждающий успешное получение запроса. Для этого используется пакет типа Accounting-Response (аудит-ответ).

Рисунок 3.3. Процесс аудита RADIUS

Как видно из рисунка 3.2, при попытке подключиться к серверу сетевого доступа, имеющему конфигурацию клиента RADIUS, выполняются следующие шаги:

1) После исходной аутентификации сервер сетевого доступа посылает серверу защиты RADIUS старт-пакет Accounting-Request.

2) Сервер защиты RADIUS подтверждает получение старт-пакета, возвращая пакет Accounting-Response.

3) По окончании использования сервиса сервер сетевого доступа посылает стоп-пакет Accounting-Request; в этом пакете указывается тип предоставленного сервиса и дополнительные статистические данные.

4) Сервер защиты RADIUS подтверждает получение стоп-пакета, возвращая пакет Accounting-Response.

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

Хотя TACACS и RADIUS очень похожи по своим функциональным возможностям, они имеют несколько важных отличий, указанных в таблице 3.1.

Таблица 3.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.3.6 Технические несоответствия с теоретическими характеристиками протоколов 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].

Заключение