Протокол radius что это
RADIUS
Материал из Xgu.ru
 |
| Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной. |
Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.
RADIUS (Remote Authentication Dial In User Service, служба удалённой аутентификации дозванивающихся пользователей) — сетевой протокол, предназначенный для обеспечения централизованной аутентификации, авторизации и учёта (Authentication, Authorization, and Accounting, AAA) пользователей, подключающихся к различным сетевым службам. Используется, например, при аутентификации пользователей WiFi, VPN, в прошлом, dialup-подключений, и других подобных случаях. Описан в стандартах RFC 2865 и RFC 2866.
Содержание
[править] Протокол RADIUS
[править] Свойства RADIUS
В соответствии со стандартом RADIUS, это:
[править] Ограничения RADIUS
Во-вторых, RADIUS, по крайней мере в его основной редакции, не имеет возможности отзыва ресурсов после того как авторизация была произведена. В некоторых случаях эта проблема решается производителем RADIUS-сервера самостоятельно.
В-третьих, RADIUS это протокол без поддержки состояний. Он не сохраняет транзакционную информацию и не использует её в следующих сеансах.
В-четвертых, RADIUS имеет не всегда достаточный уровень масштабируемости. На первой странице RFC замечание от IESG:
 | Experience has shown that [RADIUS] can suffer degraded performance and lost data when used in large scale systems, in part because it does not include provisions for congestion control. Readers of this document may find it beneficial to track the progress of the IETF’s AAA Working Group, which may develop a successor protocol that better addresses the scaling and congestion control issues. |  |
[править] Доступные RADIUS-серверы
Существует огромнейшее количество RADIUS-серверов, отличающихся своими возможностями и лицензией, по которой они распространяются.
Свободно распространяемые RADIUS-серверы:
Кроме того существует множество RADIUS-серверов, встроенных в биллинговые системы. Например, такие как:
Далее рассматривается FreeRADIUS. Это один из самых популярных и самых мощных RADIUS-серверов, существующих сегодня. Это хорошо масштабируемый, гибкий, настраиваемый и надёжный RADIUS-сервер.
[править] Инсталляция и настройка FreeRADIUS
[править] Инсталляция и настройка FreeRADIUS
Запуск RADIUS-сервера в режиме отладки:
Проверка конфигурационного файла FreeRadius-сервера:
[править] Конфигурационные файлы FreeRADIUS
FreeRADIUS использует несколько конфигурационных файлов. У каждого файла есть свой man, который описывает формат файла и примеры конфигураций.
Главный конфигурационный файл в котором указываются пути к другим конфигурационным файлам, log файлы, устанавливаются различные параметры контролируемые администратором.
Это файл обычно статический и его не надо изменять. Он определяет все возможные атрибуты RADIUS использующиеся в других конфигурационных файлах.
В файле содержится описание клиента. Синтаксис записей следующий:
Обязательные атрибуты secret и shortname, опционально можно задать атрибут nastype, который определяет тип клиента (все возможные типы описаны в man clients.conf)
Пример задания клиента:
[править] Настройка атрибутов FreeRADIUS для динамического размещения порта коммутатора в VLAN’е по результатам аутентификации
Для динамического размещения порта коммутатора в VLANе по результатам аутентификации используются туннельные атрибуты (tunnel attributes):
RADIUS-сервер включает туннельные атрибуты в Access-Accept сообщение.
Это основные атрибуты, которые нужны для динамического размещения порта в VLAN’е по результатам аутентификации. Другие атрибуты RADIUS относящиеся к использованию 802.1x перечислены в RFC 3580.
Значения этих атрибутов для конкретного пользователя указываются в файле users (/etc/freeradius/users):
[править] Инсталляция и настройка dialupadmin
Программа dialupadmin предназначена для администрирования RADIUS-сервера через Web.
В данный момент dialupadmin работает только с PHP4 для PHP5 заработчик его еще не адаптировал
[править] Совместное использование ActiveDirectory и FreeRADIUS
В отличие от других LDAP-серверов, active directory не возвращает ничего в атрибуте userPassword. Из-за этого нельзя использовать Active Directory для выполнения аутентификации CHAP, MS-CHAP или EAP-MD5. Можно использовать только аутентификацию PAP. Для этого в секции «authenticate» нужно указать «ldap».
Для выполнения аутентификации MS-CHAP с помощью домена Active Directory, необходимо использовать NTLM-аутентификацию. Для этого потребуется проинсталлировать Samba.
Подробнее об этом в конфигурационном файле radiusd.conf и здесь RLM_LDAP.
Шаги по инсталляции и настройке:
Note: By default, Windows XP can take up to two minutes to prompt for 802.1x authentication credentials. This process can be expedited by modifying the registry using the following procedure:
[3] I am assuming your domain is uing Internet Authentication Server (IAS) and 802.1x to authenticate the access by wireless user. In this case where 802.1x authentication is enabled, there is a registry key that controls how your wireless client authenticates to the backend IAS server. If you set the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\EAPOL\Parameters\General\Global\AuthMo de to 1, what will happen is that the machine will authenticate to the domain before any user log on using machine credential (Machine Authentication) so that it will pull down any security setting the domain enforces, assuming the authentication succeeds. When the user logs on later, the user will need to do User Authentication as you normally do. By the way, if this reg key is not present, by default it is already to set to 1 and you already get the above behavior.
[править] cisco VPN-сервер и RADIUS
Предполагаемая конфигурация полностью совместима с обычным windows-режимом создания VPN-соединения (т.е. может быть организована без дополнительного ПО). Доступ с linux-машин осуществляется с помощью пакета ppptp-linux (и команды pon).
Конфигурация циски (только часть, относящаяся к конфигурированию VPN):
ppp-соединение с пользователем, эта опция указывает, исходя из какого шаблона создаётся этот виртуальный интерфейс)
(обоих версий) и использовать OUR-VPN-NAME (см секцию aaa выше))
После установки freeradius (положение и имена файлов конфигурации для версии в составе debian lenny).
/etc/freeradius/sites-enabled/default: закомментировать все строчки со словом ‘unix’ (отключает unix-авторизацию)
/etc/freeradius/users, добавить пользователей:
(не забудте прописать на маршрутизаторах сети (не циско!) маршрут для сегмента, в котором выдаются адреса (в нашем случае, 192.168.3.0/24).
RADIUS (Remote Authentication in Dial-In User Service)
| Communications protocol | |
| Purpose | Обеспечивает централизованную аутентификацию, авторизацию и учёт пользователей, подключающихся к различным сетевым службам |
|---|---|
| Developer(s) | Carl Rigney, Livingston Enterprises |
| Introduced | 1991 ; 30 years ago ( 1991 ) |
| Based on | TCP, UDP |
| OSI layer | Application layer |
| Port(s) | 1812, 1813 |
| RFC(s) | RFC 2548, RFC 2809, RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869, RFC 2882, RFC 3162 |
RADIUS — сетевой протокол, предназначенный для обеспечения централизованной аутентификации, авторизации и учёта пользователей, подключающихся к различным сетевым службам. Используется, например, при аутентификации пользователей WiFi, VPN, в прошлом, dialup-подключений, и других подобных случаях. [Источник 1]
Аббревиатура «RADIUS» расшифровывается как «Remote Authentification Dial In User Services» — «аутентификация для удаленного доступа к пользовательским сервисам»
Создание RADIUS
Протокол RADIUS был разработан Карлом Ригни (Carl Rigney) в фирме Livingston Enterprises для их серверов доступа (Network Access Server) серии PortMaster к сети интернет. На данный момент существует несколько коммерческих и свободно распространяемых RADIUS-серверов. Они несколько отличаются друг от друга по своим возможностям, но большинство поддерживает списки пользователей в текстовых файлах и различных базах данных. Учётные записи пользователей могут храниться в текстовых файлах, различных базах данных, или на внешних серверах. Существуют прокси-серверы для RADIUS, упрощающие централизованное администрирование и/или поз-воляющие реализовать концепцию интернет-роуминга. Популярность RADIUS-протокола, во многом объясняется: открытостью к наполнению новой функциональностью при сохранении работоспособности с устаревающим оборудованием, чрезвычайно высокой реактивностью при обработке запросов ввиду использования UDP в качестве транспорта пакетов, а также хорошо параллелизуемым алгоритмом обработки запросов; способностью функционировать в кластерных, архитектурах и мультипроцессорных платформах — как с целью повышения производительности, так и для реализации отказоустойчивости. [Источник 2]
Назначение
RADIUS — клиент-серверный протокол, работающий на прикладном уровне. Он является так называемым «протоколом ААА» (англ. «Protocol AAA»), что указывает на его назначение и области использования:
Аутентификация
Аутентификация (Authentication) — процесс, позволяющий аутентифицировать (проверить подлинность) субъекта по его идентификационным данным, например, по логину (имя пользователя, номер телефона и т. д.) и паролю;
Авторизация
Авторизация (Authorization)— процесс, определяющий полномочия идентифицированного субъекта, конкретного пользователя на доступ к определённым объектам или сервисам.
Учет (или контроль) — процесс, позволяющий вести сбор сведений и учётных данных об использованных ресурсах. Первичными данными, традиционно передаваемыми по протоколу RADIUS являются величины входящего и исходящего трафиков: в байтах/октетах (с недавних пор в гигабайтах). Однако протокол предусматривает передачу данных любого типа, что реализуется посредством VSA (Vendor Specific Attributes). Так, например, может учитываться время, проведенное в сети, посещаемые ресурсы и т. д.
Последняя функция делает возможным применение RADIUS-серверов в качестве компонентов биллинговых систем, ответственных за сбор информации об использовании телекоммуникационных услуг, их тарификацию, выставление счетов абонентам, обработку платежей и т. д.
Свойства RADIUS
Помимо непосредственно аутентификации, авторизации и учета, RADIUS-сервера могут выполнять ряд иных функций
Вышеперечисленное активно используется провайдерами Интернет-услуг, в среде которых RADIUS получил наиболее широкое распространение
Ограничения RADIUS
Механизм работы
Как уже упоминалось, RADIUS — прикладной протокол. На транспортном уровне используется протокол UDP, порты: 1812 и 1813.
Общая структура сети
Несмотря на то, что существует множество способов построения сетей с использованием RADIUS, общая структура может быть представлена в следующем виде:
Место NAS (Network Access Server) может занимать VPN-сервер, RAS (Remote Access Server), сетевой коммутатор и т. д.
Конечный RADIUS-сервер может быть частью исключительно локальной сети или же иметь доступ к сети Интернет.
Базы аутентификации хранят информацию о пользователях (абонентах) и правах их доступа к различным сервисам. Термин «база» в данном случае является собирательным, так как данные могут хранится как в локально, в текстовых файлах и различного рода базах данных, так и на удаленных серверах (SQL, Kerberos, LDAP, Active Directory и т. д.).
Структура пакета
Общая структура RADIUS-пакета имеет вид:
Код показывает тип операции, к которой принадлежит данный код. Так, выделяют следующие коды:
| Код | Операция |
|---|---|
| 1 | Access-Request |
| 2 | Access-Accept |
| 3 | Access-Reject |
| 4 | Accounting-Request |
| 5 | Accounting-Response |
| 11 | Access-Challenge |
| 12 | Status-Server (экспериментальная возможность) |
| 13 | Status-Client (экспериментальная возможность) |
| 255 | Зарезервировано |
Идентификатор служит для различения запросов и ответов.
Поле длины указывает размер всего пакета, с учетом длины кода, идентификатора, самого поля длины, аутентификатора и AVP.
Аутентификатор используется для аутентификации ответа от сервера и шифрования пароля.
AVP или пары «атрибут — значение» (англ. «Atribute-Value Pairs») содержат непосредственно сами передаваемые данные — как запроса, так и ответа, и участвуют во всех стадиях обмена данными: аутентификации, авторизации и учете. Структура AVP:
| Тип (8 бит) | Длина (8 бит) | Значение |
Поле типа служит для указания атрибута, содержащегося в пакете. Выделяют 63 атрибута, в числе которых: имя пользователя и пароль (коды 1 и 2, соответственно), тип сервиса (6), ответ сервера (18), состояние RADIUS-прокси (33), состояние учета (40) и задержка учета (41) и т.д.
Длина указывает размер значения атрибута, которое непосредственно содержится в последнем поле.
Аутентификация и авторизация
Аутентификация и авторизация Механизмы аутентификации и авторизации описаны в RFC 2058. Они протекают по следующей схеме: RADIUS-клиент отправляет RADIUS-серверу запрос доступа (AccessRequest), в котором содержатся данные аутентификации (логин и пароль, сертификат доступа). После сличения полученных данных с имеющимися в базе, сервер может отправить один из нескольких ответов [Источник 3] :
Защищенность
Пароли от NAS к RADIUS-серверу не пересылаются в открытом виде (даже в случае с PAP). Для шифрования паролей используется принцип «разделения секрета» и хэш-функция MD5.
Однако, в силу частичной реализации данных функции и недостаточ-ной защиты, предоставляемой ими, на практике необходимо использование дополнительных мер — таких как применение IPsec или физической защиты корпоративных сетей. Это позволяет в дальнейшем защитить трафик между сервером доступа и RADIUS-сервером.
Кроме того, передаваемые данные подвергаются защите лишь частично: защищены логин и пароль, в то время, как другие данные, возможно являющиеся секретными или приватными, не защищены.
Этот недостаток устранен в протоколе RadSec, который, будучи основан на RADIUS содержит ряд улучшений безопасности.
Пример настройки Radius
Начнём с того, что создадим в домене две локальных группы безопасности с ограниченными и полными правами Radius.
Создание группы с полными правами
В первую группу включим пользователей которым нужно предоставить полный административный доступ на управление коммутаторами, во вторую соответственно, — доступ только на чтение текущей конфигурации и состояния устройств. При этом, стоит помнить, что для пользователей, которые будут включаться в эти группы должно быть установлено разрешение в домене, дающее право удалённого доступа (значение настройки Network Access Permission на закладке Dial-In свойств учетной записи пользователя) [Источник 4]
Русские Блоги
Основные принципы протокола RADIUS
Введение в RADIUS
Обзор RADIUS:
Соглашение определяетUDP (протокол дейтаграмм пользователя) формат сообщения RADIUS и механизм его передачи, а также укажите порты UDP 1812 и 1813 как порты аутентификации и учета соответственно.
Изначально RADIUS был только протоколом AAA для пользователей с коммутируемым доступом.Позже, с разнообразным развитием методов доступа пользователей, RADIUS также адаптируется к нескольким методам доступа пользователей, таким как доступ через Ethernet. Он предоставляет услуги доступа посредством аутентификации и авторизации, а также собирает и записывает использование сетевых ресурсов пользователями посредством взимания платы.
Архитектура Radius:
Модель клиент / сервер.
Клиент RADIUS: Обычно расположен на сервере сетевого доступа NAS (Network Access Server), который может распространяться по всей сети и отвечает за передачу информации о пользователе на указанный сервер RADIUS, а затем за соответствующую обработку (например, принятие / отклонение доступа пользователя) на основе информации, возвращаемой с сервера.
Как клиент протокола RADIUS устройство реализует следующие функции:
RADIUS сервер: Обычно запускается на центральном компьютере или рабочей станции, поддерживает соответствующую аутентификацию пользователей и информацию о доступе к сетевым службам, отвечает за получение запросов на подключение пользователей и аутентификацию пользователей, а затем за возврат всей необходимой информации клиенту (например, прием / отклонение запросов аутентификации). Сервер RADIUS обычно поддерживает три базы данных.
Особенности RADIUS:
кибербезопасность
Взаимодействие с сообщением аутентификации между клиентом RADIUS и сервером RADIUS завершается с участием общего ключа, и общий ключ не может быть передан по сети, что повышает безопасность обмена информацией. Кроме того, чтобы предотвратить кражу паролей пользователей во время передачи в незащищенных сетях, протокол RADIUS использует общие ключи для шифрования паролей в сообщениях RADIUS.
Хорошая масштабируемость
Сообщение RADIUS состоит из заголовка и определенного количества атрибутов. Добавление новых атрибутов не приведет к разрушению исходной реализации протокола.
Пакет RADIUS
Формат сообщения RADIUS:
Протокол RADIUS использует пакеты UDP для передачи сообщений.
Рис.: Структура сообщения RADIUS
Объяснение каждого поля следующее:
Тип сообщения RADISU:
В настоящее время RADIUS определяет шестнадцать типов сообщений.
Сообщение аутентификации RADIUS:
Учетный пакет RADIUS:
| Имя сообщения | Описание |
|---|---|
| Accounting-Request(Start) | Сообщение запроса на начало учета. Если клиент использует режим RADIUS для учета, клиент отправит на сервер сообщение с запросом на начало учета, когда пользователь начнет доступ к сетевым ресурсам. |
| Accounting-Response(Start) | Пакет ответа на начало учета. После того, как сервер получит и успешно запишет сообщение с запросом на начало начисления платы, он должен ответить ответным сообщением о начале начисления платы. |
| Accounting-Request(Interim-update) | Сообщение с запросом на оплату в реальном времени. Чтобы сервер начисления платы не смог получить сообщение с запросом на прекращение начисления платы и продолжить начисление платы за пользователя, можно настроить функцию начисления платы в реальном времени на клиенте. Клиент периодически отправляет на сервер сообщения учета в реальном времени, чтобы уменьшить количество ошибок учета. |
| Accounting-Response(Interim-update) | Ответное сообщение бухгалтерского учета в реальном времени. После того, как сервер получает и успешно записывает сообщение с запросом о начислении платы в реальном времени, он должен ответить сообщением с ответом о начислении платы в реальном времени. |
| Accounting-Request(Stop) | Сообщение запроса на завершение учета. Когда пользователь отключен (соединение также может быть отключено сервером доступа), клиент отправляет на сервер сообщение с запросом на завершение биллинга, которое включает статистическую информацию о сетевых ресурсах, используемых пользователем (онлайн-время, вход / выход Байтов и т. Д.), Запросить у сервера остановку зарядки. |
| Accounting-Response(Stop) | Сообщение об окончании учета. После того, как сервер получит сообщение с запросом об остановке зарядки, он должен ответить ответным сообщением об остановке зарядки. |
Сообщение авторизации RADIUS:
Как работает RADIUS
RADIUS аутентификация, авторизация и учет:
В качестве клиента RADIUS устройство доступа отвечает за сбор информации о пользователе (например, имя пользователя, пароль и т. Д.) И отправку этой информации на сервер RADIUS. Сервер RADIUS завершает аутентификацию пользователя и авторизацию пользователя и учет после аутентификации на основе этой информации. Процесс взаимодействия между пользователем, клиентом RADIUS и сервером RADIUS выглядит следующим образом:
Рис.: Интерактивный процесс аутентификации, авторизации и учета RADIUS
Пример конфигурации радиуса
Конфигурация на основном коммутаторе:
Затем настройте его на сервере Radius для использования вместе с dot1x, Portal и другими технологиями.
Справочный документ: документ Huawei HedEx
О Radius подробно
Для аутентификации и авторизации пользователей или организации их учета можно порекомендовать использовать RADIUS. Тем более, когда речь идет об обширных сетях, доступ к которым разрешен немалому числу людей.
Oсновные составные части службы идентификации удаленных пользователей (Remote Authentication Dial-In User Service, RADIUS) описываются двумя RFC от IETF: RFC 2865 под названием Remote Authentication Dial-In User Service (RADIUS) в форме проекта стандарта и RFC 2866 под названием RADIUS Accounting в виде «информационного RFC». Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выкристаллизовались и другие области применения этой технологии. К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все.
Концепция службы идентификации удаленных пользователей подразумевает, что клиент RADIUS — обычно сервер доступа, сервер VPN или точка доступа беспроводной локальной сети — отсылает серверу RADIUS параметры доступа пользователя (в англоязычной документации они часто называются Credentials, т. е. мандат, куда, к примеру, входят его настройки безопасности и права доступа), а также параметры соответствующего соединения. Для этого клиент использует специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-response. После этого клиент передает на сервер RADIUS учетную информацию.
Еще одна особенность — поддержка агентов RADIUS. Эти системы предназначены исключительно для обеспечения обмена сообщениями RADIUS между клиентами, серверами и другими агентами. Отсюда можно сделать вывод, что сообщения никогда не передаются непосредственно от клиента к серверу.
Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем информация об аутентификации направляется на порт UDP с номером 1812. Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об аутентификации) или, соответственно, 1646 (для учета) — выбор должен определять своим решением администратор. В поле данных пакета UDP (так называемая полезная нагрузка) всегда помещается только одно сообщение RADIUS. В соответствии с RFC 2865 и RFC 2866 определены следующие типы сообщений:
Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами, серверами и прочими агентами RADIUS. Атрибуты RADIUS определены в нескольких RFC, а именно: RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869 и RFC 3162.
RADIUS может совместно работать с различными протоколами аутентификации. Наиболее часто используются протокол аутентификации пароля (Password Authentication Protocol, РАР), протокол аутентификации с предварительным согласованием (Challenge Handshake Authentication Protocol, CHAP), а также MS-CHAP (CHAP от Microsoft в первой версии или MS-CHAPv2 — во второй). Кроме того, возможно применение RADIUS вместе с PPP, протоколом передачи «точка-точка» (Point-to-Point Protocol). Результаты сеанса аутентификации между сервером доступа и действующим клиентом передаются на сервер RADIUS, который их потом удостоверяет.
Для защиты сообщений клиент и сервер RADIUS обладают «общим секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке символов, имеющейся как на серверах, так и на клиенте RADIUS.
РАСШИРЕННЫЙ ПРОТОКОЛ АУТЕНТИФИКАЦИИ
Расширенный протокол аутентификации (Extensible Authentication Protocol, EAP) изначально задумывался как дополнение к РРР для поддержки различных механизмов аутентификации доступа к сети. Протоколы аутентификации для РРР, например CHAP, MS-CHAP и MS-CHAPv2, определяют механизм аутентификации во время фазы установления соединения. На этом этапе необходимо применять согласованный протокол аутентификации, с целью «верификации» соединения. В данном случае речь идет о заранее определенной последовательности сообщений, причем они должны отсылаться в соответствии с заданной схемой, а точнее, в указанной очередности.
При использовании EAP в процессе установления соединения в рамках РРР специальный механизм аутентификации не определяется. Лишь на этапе аутентификации участники взаимодействуют по специальной схеме аутентификации EAP, обозначаемой также как «схема типа EAP».
ЕАР позволяет осуществлять обмен сообщениями между клиентом, запрашивающим доступ, и аутентифицирующим сервером (в его роли часто выступает сервер RADIUS). При этом обмен сообщениями может варьироваться с учетом особенностей различных соединений; он состоит собственно из запросов, в которых требуется предоставление информации об аутентификации, а также из соответствующих ответов. Длительность и конкретные детали сеанса аутентификации зависят от заданной схемы EAP.
В архитектурном плане ЕАР задумывался таким образом, чтобы аутентификацию можно было выполнять с помощью подключенных модулей с обеих сторон соединения: от клиента и от сервера. Если библиотечный файл ЕАР установить на обоих концах, то в любой момент можно применить новую схему аутентификации. Тем самым ЕАР предоставляет гибкую среду для внедрения безопасных методов аутентификации.
ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802.
К примеру, службу RRAS операционной системы Windows 2000 можно настроить таким образом, что система с каждым сообщением запроса доступа станет отправлять атрибут удостоверение сообщения (Message-Authenticator). При этом в соответствующем диалоговом окне необходимо выбрать в свойствах опцию always use digital signatures («всегда использовать цифровую подпись»). Служба аутентификации в Internet (Internet Authentication Service, IAS) настраивается со стороны Windows 2000 так, чтобы при получении любого сообщения запроса доступа проверялось наличие атрибута Message-Authenticator. Администратор должен установить соответствующий флажок в свойствах клиента RADIUS, чтобы клиент постоянно пересылал в запросе атрибут подписи.
Если по каким-либо причинам такой вариант невозможен, в этом случае остается один выход: Windows 2000 обладает механизмом «учета и блокировки аутентификации». Благодаря ему клиент не может превысить заданное количество попыток аутентификации за установленное время. Если же это происходит, система сразу прервет с ним связь.
НЕПРАВИЛЬНО СКОНФИГУРИРОВАННЫЙ ОБЩИЙ СЕКРЕТ
Еще одна потенциально слабая точка реализации RADIUS касается «общего секрета» (Shared Secret). Это связано с тем, что очень часто один и тот же «общий секрет» служит для поддержки максимального количества пар «клиент-сервер» в службе RADIUS. К тому же в большинстве случаев криптологически он недостаточно устойчив против атаки с перебором слов по словарю в автономном режиме. Значение поля Response Authenticator и содержимое атрибута Message Authenticator легко вычисляются. Потом эти данные сравниваются с перехваченным сообщением Access-Accept, Access-Reject или Access-Challenge. Таким образом, легко разгадываемый «общий секрет» может быть быстро скомпрометирован.
Сложившаяся ситуация усугубляется также некоторыми вариантами реализации RADIUS — довольно часто длина «общего секрета» не может превышать определенной величины, или же набор символов, из которых образуется ключевое слово, ограничен. В качестве примера приведем распространенную установку на использование только тех символов из набора ASCII, которые находятся непосредственно на клавиатуре — то есть лишь 94 из доступных 256 символов ASCII.
Важно знать, что в случае, если выбор ограничен только возможностями клавиатуры, последовательность символов должна состоять как минимум из 22 знаков и при этом содержать примерно в одинаковой пропорции строчные и прописные буквы, цифры и специальные символы. Если же «общий секрет» может быть задан в виде строки из шестнадцатеричных чисел, следует задавать не менее 32 цифр.
RFC 2865 предписывает использование 16 символов в «общем ключе». Однако для достижения энтропии (в теории информации энтропия отражает количество информации в последовательности символов) равной 128 бит каждый отдельный символ должен иметь энтропию 8 бит. В случае же, когда выбор символов ограничен имеющимися на клавиатуре, энтропия 8-битного символа уменьшается до 5,8 бит. Поэтому, чтобы добиться уровня энтропии в 128 бит, необходимо 22 символа. В среде Windows 2000 максимально возможная длина «общего секрета» может быть равна 64 символам (из имеющихся на клавиатуре).
Качественно улучшить результаты позволяет использование программ для генерирования «общего секрета», поскольку при этом обычно получаются лучшие, по сравнению с ручным вводом, значения энтропии. Кроме того, пара «клиент-сервер», использующая RADIUS, всегда должна быть защищена одним и тем же «общим секретом».
МЕХАНИЗМ СОКРЫТИЯ
Для шифрования пароля пользователя и прочих атрибутов применяются «общий секрет», аутентификатор запросов и алгоритм хэширования MD5. Эту комбинацию нельзя назвать верхом совершенства с точки зрения надежности шифрования, что отражено и в RFC 2865 — в документе рекомендуется как можно лучше позаботиться о надежности передачи.
Примером лучшей защиты атрибутов является применение IPSec. В комплекте с протоколом инкапсуляции защищаемой полезной нагрузки (Encapsulated Security Payloаd, EPS) и мощным шифровальным механизмом, наподобие Triple DES, можно добиться очень высокой надежности передачи данных и конфиденциальности сообщения RADIUS.
Если же совместная работа IPSec, ESP и алгоритма шифрования невозможна, у администратора сети остается еще один способ уменьшения вероятности взлома выполненной реализации RADIUS:
ПРИМЕНЕНИЕ RADIUS
Соблюдение некоторых принципов при вводе RADIUS в эксплуатацию поможет свести различные риски к минимуму. Для повышения достоверности передаваемых сообщений RADIUS рекомендуется применение IPSec и EPS. При этом следует использовать алгоритм шифрования Triple DES. Такой метод описан также в документе RFC 3162. Путем шифрования всего сообщения RADIUS при помощи IPSec защищаются особо чувствительные его части — такие, как поле удостоверения запроса в сообщении запроса доступа — и атрибуты RADIUS (к примеру, пароль пользователя или атрибуты ключа МРРЕ). Тому, кто предпримет попытку проникновения в систему, понадобится сначала расшифровать защищенное с помощью ESP сообщение RADIUS, и лишь после этого он сможет анализировать его содержимое. Чтобы предотвратить атаки на сервер RADIUS извне, рекомендуется установить программное обеспечение для аутентификации IPSec с использованием сертификатов. Помимо этого, возможны и другие варианты защиты, которые могут использоваться как в совокупности с IPSec, так и отдельно.
Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации.
ИСПОЛЬЗОВАНИЕ RADIUS ДЛЯ УДАЛЕННОГО ДОСТУПА И VPN
 |
| Рисунок 2. Пункт «Конфигурация RAS» в Windows 2000 предлагает несколько опций. |
 |
| Рисунок 3. Сервер RAS должен понимать протоколы, посредством которых отдельные клиенты пытаются получить к нему доступ. |
Подключение работающего сервера RADIUS к виртуальной частной сети (Virtual Private Network, VPN) или службе удаленного доступа (Remote Access Service, RAS) выполняется сравнительно просто. В операционной системе Windows 2000 для этого предусмотрены опции Remote Access Service (RAS) и VPN Server. Начать следует с пункта «Конфигурация сервера». Затем пользователю будут помогать различные программные эксперты. Для конфигурации RAS посредством «Ассистента настройки для сервера маршрутизации и RAS» в меню «Пуск — Программы — Управление» нужно выбрать пункт «Маршрутизация и удаленный доступ». Затем указать желаемое имя сервера, щелкнуть мышью на пункте «Конфигурация и активизация маршрутизации и RAS» в исходном меню и нажать кнопку «Далее». Администратору предоставится возможность выбора нескольких опций (см. Рисунок 2). Он должен выбрать пункт «cервер RAS», перейти к окну выбора протокола поддержки удаленного клиента (см. Рисунок 3) и отметить в нем тип соединения, через которое происходит связь с Intranet.
 |
| Рисунок 4. Соединение сервера RAS с сервером Radius. |
Далее необходимо указать способ распределения IP-адресов в диалоговом окне «Распределение IP-адресов». Если администратор выберет пункт «Автоматически», тогда сервер удаленного доступа для распределения IP-адресов между удаленными клиентами будет использовать протокол динамической конфигурации хоста (Dynamic Host Configuration Protocol, DHCP). С другой стороны, одну или даже несколько специальных областей IP-адресов можно распределить статично. По завершении этого этапа появляется окно «Управление несколькими серверами RAS». После чего в игру вступает соединение с RADIUS (см. Рисунок 4). Если администратор остановит выбор на пункте «Да, должен использоваться сервер RADIUS», то он обязан сразу же специфицировать первый сервер RADIUS, а при необходимости и второй (но это необязательно). После чего выполняются завершающие действия, и службу RAS можно запускать. Если применяется сервер VPN, то конфигурацию осуществляют соответствующим образом.