IP телефония

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

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

• Сервер сетевого доступа посылает серверу  защиты RADIUS пакет

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

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

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

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

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

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

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

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

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

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

  Как видно из рис. 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. 

  Помимо этого TACACS+ поддерживает двунаправленный поток вызовов/ответов между серверами сетевого доступа подобно тому, как это сделано в CHAP. RADIUS поддерживает однонаправленный вызов/ответ от сервера защиты RADIUS к клиенту RADIUS.

  Целостность данных. 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 базируется  на протоколе UDP (пакетная передача  данных, без гарантии передачи пакета). Следовательно, RADIUS-клиент на любой запрос должен дожидаться ответа от сервера в течение некоторого времени (timeout'а) и в случае отсутствии оного перепослать пакет еще раз. TACACS+ клиент тоже должен дожидаться всегда ответа от сервера, но в отличии от RADIUS- клиента, в случае отсутствия ответа, пакет еще раз не посылается. Гарантия доставки обеспечивается тем, что для обработки какого-либо запроса TACACS+ сервер и клиент должны установить TCP-соединение (даже если весь процесс будет состоять из посылки и приема 2-ух небольших пакетов), а с точки зрения времени это довольно длительный процесс (по этой причине TACACS+ по определению относительно медленен). На основании этого, можно сказать, что RADIUS будет более эффективен в сетях, где процент потерянных пакетов менее 5-10 %; в других сетях лучше использовать TACACS+. Именно по этой причине в сетях IP-телефонии, где необходимо быстродействие применяется, как правило, протокол RADIUS.

3.3.6. Слабые места процессов  ААА с точки  зрения

несанкционированного  доступа в протоколе RADIUS

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

RADIUS

  Рассмотрим более подробно протокол RADIUS. Сегодня, многие провайдеры IP-телефонии отдают предпочтение именно ему (не исключением стали и питерские провайдеры: Петерстар, BCL, Comset и т.д.). Вместе с тем, с точки зрения безопасности протокол RADIUS, на первый взгляд, уступает протоколу TACACS+ . Именно поэтому, наверно, имеет смысл поговорить о возможных проблемах, связанных с использованием этого протокола, и о его уязвимых местах.

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

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

Итак, имеется  три основных типа атак, с которыми должен уметь справляться протокол RADIUS:

- воспроизведение  сообщений, посылаемых в любом  из направлений;

- подделка  сообщений, особенно тех, что посылаются от сервера агенту;

- модификация  сообщений от сервера к агенту.

  Возможно, все эти аспекты работы протокола RADIUS выглядят странными, но они начинают приобретать смысл, если рассмотреть, как этот протокол противостоит подобным атакам. На верхнем уровне протокол RADIUS довольно прост. На рис. 3.3 показано, как он использует одно сообщение, посылаемое от агента серверу, и ответ сервера агенту. 

 

 Когда кто-либо инициирует процедуру регистрации, агент получает имя пользователя и пароль и помещает их в сообщение «Запрос на доступ». В общем случае сообщение содержит следующие данные:

• числовой код, указывающий, что это сообщение  типа «Запрос на доступ»;

• восьмибитовый  идентификатор для этого запроса  на вход;

• длину  всего сообщения протокола RADIUS;

• 128-битовое  случайное одноразовое число, называемое аутентификатором запроса;

• идентификатор  агента, делающего запрос;

• имя  пользователя (эти данные необязательны);

• введенный  пароль, зашифрованный для передачи;

• необязательные данные типа номера порта, с которого пришел запрос на установление соединения.

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

• числовой код, указывающий, что данное сообщение  является сообщением типа «Доступ разрешен»;

• восьмибитовый  идентификатор, скопированный из сообщения «Запрос на доступ»;

• длину  всего сообщения протокола RADIUS;

• хешированное значение, называемое аутентификатором ответа, которое служит для выявления атак;

• необязательную цепочку символов, передаваемых пользователю;

• необязательные данные, описывающие права и полномочия пользователя.

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

3.3.6.2. Защита сообщений  в протоколе RADIUS

  Для надежного использования протокола RADIUS аутентификация выполняется дважды. Сначала надо аутентифицировать сервер, чтобы потом безопасно аутентифицировать пользователя. Когда агент принимает сообщение «Доступ разрешен», он должен быть уверен, что сообщение приходит от сервера, которому он доверяет. Нельзя позволить кому-либо обмануть агента. Более того, весь процесс аутентификации должен быть защищен в возможно большой степени. Основой аутентификации является базовый секрет. В случае протокола RADIUS секрет – это паролевое слово или паролевая фраза, которая известна серверу и агенту. Секрет используется для шифрования пароля перед его отсылкой, а также для вычисления правильного хеша аутентификатора ответа в сообщении «Доступ разрешен» или «В доступе отказано». В сообщении «Доступ разрешен» имеется два средства защиты от атак. Первым средством является 128-разрядное случайное число однократного использования, называемое аутентификатором ответа. Агент выбирает новое значение однократно используемого числа случайным образом для каждого запроса на вход в систему, который он обрабатывает. При правильной процедуре выбора шансы на то, что злоумышленник сможет спрогнозировать значение случайного числа чрезвычайно малы. На рис. 3.4 показано, как сервер использует случайное число для построения хешированного значения аутентификатора ответа, которое он посылает агенту.