Какое сообщение radius передается первым при запросе пользователем доступа к услуге
Обновлено: 02.07.2024
RADIUS (Remote Authentication Dial In User Service, служба удалённой аутентификации дозванивающихся пользователей) — сетевой протокол, предназначенный для обеспечения централизованной аутентификации, авторизации и учёта (Authentication, Authorization, and Accounting, AAA) пользователей, подключающихся к различным сетевым службам. Используется, например, при аутентификации пользователей WiFi, VPN, в прошлом, dialup-подключений, и других подобных случаях. Описан в стандартах RFC 2865 и RFC 2866.
Содержание
В соответствии со стандартом RADIUS, это:
- Базирующийся на UDP протокол, который не использует прямых соединений
- Использует модель безопасности hop-by-hop
- Без состояний (stateless)
- Поддерживает аутентификацию PAP и CHAP по PPP
- Использует MD5 для скрытия паролей
- Предоставляет более 50 пар атрибут/значение с возможностью создавать специфичные для производителя пары
- Поддерживает модель AAA
- Поддерживается большинством коммерческих устройств удалённого доступа
Во-первых, недостаточный уровень безопасности в некоторых реализациях. В случае использования нескольких промежуточных серверов 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-серверы:
- FreeRADIUS
- GNU RADIUS
- yard - Yet Another Radius Daemon
- Cistron RADIUS
- IAS - Internet Authentication Service - RADIUS-сервер от MS (Пример настройки RADIUS-сервера в Windows 2003)
Кроме того существует множество RADIUS-серверов, встроенных в биллинговые системы. Например, такие как:
Далее рассматривается FreeRADIUS. Это один из самых популярных и самых мощных RADIUS-серверов, существующих сегодня. Это хорошо масштабируемый, гибкий, настраиваемый и надёжный RADIUS-сервер.
Запуск RADIUS-сервера в режиме отладки:
В версии, поставляющейся в debian, файл называется freeradius (/usr/sbin/freeradius), а запуск в отладочном режиме, согласно официальной документации [1] осуществляется опцией -X, т.е.
Проверка конфигурационного файла FreeRadius-сервера:
FreeRADIUS использует несколько конфигурационных файлов. У каждого файла есть свой man, который описывает формат файла и примеры конфигураций.
radiusd.conf
Главный конфигурационный файл в котором указываются пути к другим конфигурационным файлам, log файлы, устанавливаются различные параметры контролируемые администратором.
Это файл обычно статический и его не надо изменять. Он определяет все возможные атрибуты RADIUS использующиеся в других конфигурационных файлах.
clients.conf
В файле содержится описание клиента. Синтаксис записей следующий:
Обязательные атрибуты secret и shortname, опционально можно задать атрибут nastype, который определяет тип клиента (все возможные типы описаны в man clients.conf)
Пример задания клиента:
Определяет префикс/суффикс для пользовательских имен - атрибут user-name. Используется для отсечения префикса/суффикса в ситуациях когда:
Позволяет определить разные группы NAS, к сожалению критерий для включения в группу один - IP-адрес NAS (дополнительно можно указывать порт или диапазон портов). При разборе users файла конфигурации позволяет использовать различные схемы авторизации/аутентификации/учета исходя из значения атрибута Huntgroup-Name
Для динамического размещения порта коммутатора в VLANе по результатам аутентификации используются туннельные атрибуты (tunnel attributes):
- [64] Tunnel-Type=VLAN (type 13)
- [65] Tunnel-Medium-Type=802 (type 6)
- [81] Tunnel-Private-Group-ID=VLANID (или VLAN name)
Это основные атрибуты, которые нужны для динамического размещения порта в VLAN'е по результатам аутентификации. Другие атрибуты RADIUS относящиеся к использованию 802.1x перечислены в RFC 3580.
Значения этих атрибутов для конкретного пользователя указываются в файле users (/etc/freeradius/users):
Программа dialupadmin предназначена для администрирования RADIUS-сервера через Web.
В данный момент dialupadmin работает только с PHP4 для PHP5 заработчик его еще не адаптировал
В отличие от других LDAP-серверов, active directory не возвращает ничего в атрибуте userPassword. Из-за этого нельзя использовать Active Directory для выполнения аутентификации CHAP, MS-CHAP или EAP-MD5. Можно использовать только аутентификацию PAP. Для этого в секции "authenticate" нужно указать "ldap".
Для выполнения аутентификации MS-CHAP с помощью домена Active Directory, необходимо использовать NTLM-аутентификацию. Для этого потребуется проинсталлировать Samba.
Подробнее об этом в конфигурационном файле radiusd.conf и здесь RLM_LDAP.
Шаги по инсталляции и настройке:
- Проинсталлировать FreeRADIUS
- Проинсталлировать Samba-сервер
- Включить Samba-сервер в домен Active Directory
- Убедиться, что wbinfo -u и wbinfo -g работает
- Изменить настройки FreeRADIUS для использования модуля NTLM-аутентификации
- Click on Start, Select Run, and run regedit.exe
- Navigate to the key
- Right-click on Global and select New and DWORD Value
- Name the new value SupplicantMode
- Once created, Right click this new option and select Modify
- Change the Value data to 3
- Reboot the system for the new registry changes to take effect.
[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 для организации pptp-доступа (да и других тунелирующих протоколов - pppoe, l2tp) из внешней сети (злых интернетов) в локальный сегмент сети. Основное назначение - доступ сотрудников к рабочему месту, доступ администратора к локальной сети предприятия из неожиданных мест. В качестве базы паролей используется файл users с паролями в plain-text (авторизация пользователей при этом происходит по ms-chap/ms-chap-v2). Пользователи получают при подключении ip-адрес, однозначно привязанный к их логину
Предполагаемая конфигурация полностью совместима с обычным windows-режимом создания VPN-соединения (т.е. может быть организована без дополнительного ПО). Доступ с linux-машин осуществляется с помощью пакета ppptp-linux (и команды pon).
192.168.1.1 - radius-сервер 192.168.2.2 - cisco 192.168.3.0/24 - сегмент для vpn-соедиенний
Конфигурация циски (только часть, относящаяся к конфигурированию VPN):
ppp-соединение с пользователем, эта опция указывает, исходя из какого шаблона создаётся этот виртуальный интерфейс)
(обоих версий) и использовать OUR-VPN-NAME (см секцию aaa выше))
Отладка процесса может быть включена командами debug ppp (см варианты подсказки по ?) и debug radius (аналогично). Выключение дебага no debug all. Просмотр лога - sh log, сброс лога - clear log.
Конфигурация сервера
После установки freeradius (положение и имена файлов конфигурации для версии в составе debian lenny).
/etc/freeradius/sites-enabled/default: закомментировать все строчки со словом 'unix' (отключает unix-авторизацию)
/etc/freeradius/users, добавить пользователей:
Перезапуск радиуса /etc/init.d/freeradius restart, запуск в отладочном режиме (после выполнения /etc/init.d/freeradius stop): freeradius -X
(не забудте прописать на маршрутизаторах сети (не циско!) маршрут для сегмента, в котором выдаются адреса (в нашем случае, 192.168.3.0/24).
Протокол авторизации RADIUS является ключевой частью большинства биллинговых систем. Для лучшего понимания принципов работы ExpertBilling System советуем вам ознакомиться с данной статьей.Здесь присутствуют элементы документации RFC 2865 и RFC 2866.
Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выкристаллизовались и другие области применения этой технологии. К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все.
- Access-Request - "запрос доступа". Запрос клиента RADIUS, с которого начинается собственно аутентификация и авторизация попытки доступа в сеть;
- Access-Accept - "доступ разрешен". С помощью этого ответа на запрос доступа клиенту RADIUS сообщается, что попытка соединения была успешно аутентифицирована и авторизована;
- Access-Reject - "доступ не разрешен". Этот ответ сервера RADIUS означает, что попытка доступа к сети не удалась. Такое возможно в том случае, если пользовательских данных недостаточно для успешной аутентификации или доступ для пользователя не авторизован;
- Access-Challenge - "вызов запроса". Сервер RADIUS передает его в ответ на запрос доступа;
- Accounting-Request - "запрос учета", который клиент RADIUS отсылает для ввода учетной информации после получения разрешения на доступ.
RADIUS может совместно работать с различными протоколами аутентификации. Наиболее часто используются протокол аутентификации пароля (Password Authentication Protocol, РАР), протокол аутентификации с предварительным согласованием (Challenge Handshake Authentication Protocol, CHAP), а также MS-CHAP (CHAP от Microsoft в первой версии или MS-CHAPv2 — во второй).
Операционные системы семейства Windows Server 2003 поддерживают протокол MS-CHAP v2, обеспечивающий взаимную проверку подлинности, создание более надежных начальных ключей шифрования данных для MPPE (Microsoft Point-to-Point Encryption) и разные ключи шифрования для отправки и приема данных. Чтобы свести к минимуму риск раскрытия пароля во время обмена паролями, из протокола исключена поддержка старых методов обмена паролями MS-CHAP.
Поскольку версия MS-CHAP v2 обеспечивает более надежную защиту, чем MS-CHAP, при подключении сначала предлагается использовать именно ее (если она доступна), а затем уже MS-CHAP.
Протокол MS-CHAP v2 поддерживается на компьютерах, работающих под управлением Windows XP, Windows 2000, Windows 98, Windows Millennium Edition и Windows NT 4.0. Компьютеры, работающие под управлением Windows 95, поддерживают MS-CHAP v2 только для подключений VPN, но не для подключений удаленного доступа.
НЕПРАВИЛЬНО СКОНФИГУРИРОВАННЫЙ ОБЩИЙ СЕКРЕТ
ПРИМЕНЕНИЕ RADIUS
Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации:
Желательно выбирать методы аутентификации, рассчитанные на двустороннюю аутентификацию. При таком подходе противоположные конечные точки соединения аутентифицируют свои системы. Если с какой-либо стороны аутентификация пройдет неудачно, то в установлении соединения будет отказано. Примерами подобных методов служат ЕАР-TLS и MS-CHAPv2. Так, в случае ЕАР-TLS сервер RADIUS проводит проверку пользовательского сертификата клиента, пытающегося получить доступ, а клиент в свою очередь - сертификата сервера RADIUS.
Если аутентификация производится посредством РАР, то эту опцию следует отключить. При аутентификации с помощью однократных паролей или токенов происходит откат к PAP. Но поскольку IEEE 802.1x не поддерживает РАР, в подобных случаях чаще всего пользуются соединениями РРР.
РАСШИРЕННЫЙ ПРОТОКОЛ АУТЕНТИФИКАЦИИ
В архитектурном плане ЕАР задумывался таким образом, чтобы аутентификацию можно было выполнять с помощью подключенных модулей с обеих сторон соединения: от клиента и от сервера. Если библиотечный файл ЕАР установить на обоих концах, то в любой момент можно применить новую схему аутентификации. Тем самым ЕАР предоставляет гибкую среду для внедрения безопасных методов аутентификации. ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802.
Communications protocol | |
Purpose | Обеспечивает централизованную аутентификацию, авторизацию и учёт пользователей, подключающихся к различным сетевым службам |
---|---|
Developer(s) | Carl Rigney, Livingston Enterprises |
Introduced | 1991 ; 31 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
Протокол RADIUS был разработан Карлом Ригни (Carl Rigney) в фирме Livingston Enterprises для их серверов доступа (Network Access Server) серии PortMaster к сети интернет. На данный момент существует несколько коммерческих и свободно распространяемых RADIUS-серверов. Они несколько отличаются друг от друга по своим возможностям, но большинство поддерживает списки пользователей в текстовых файлах и различных базах данных. Учётные записи пользователей могут храниться в текстовых файлах, различных базах данных, или на внешних серверах. Существуют прокси-серверы для RADIUS, упрощающие централизованное администрирование и/или поз-воляющие реализовать концепцию интернет-роуминга. Популярность RADIUS-протокола, во многом объясняется: открытостью к наполнению новой функциональностью при сохранении работоспособности с устаревающим оборудованием, чрезвычайно высокой реактивностью при обработке запросов ввиду использования UDP в качестве транспорта пакетов, а также хорошо параллелизуемым алгоритмом обработки запросов; способностью функционировать в кластерных, архитектурах и мультипроцессорных платформах — как с целью повышения производительности, так и для реализации отказоустойчивости. [Источник 2]
Назначение
Аутентификация
Аутентификация (Authentication) — процесс, позволяющий аутентифицировать (проверить подлинность) субъекта по его идентификационным данным, например, по логину (имя пользователя, номер телефона и т. д.) и паролю;
Авторизация
Авторизация (Authorization)— процесс, определяющий полномочия идентифицированного субъекта, конкретного пользователя на доступ к определённым объектам или сервисам.
Учет (или контроль) — процесс, позволяющий вести сбор сведений и учётных данных об использованных ресурсах. Первичными данными, традиционно передаваемыми по протоколу RADIUS являются величины входящего и исходящего трафиков: в байтах/октетах (с недавних пор в гигабайтах). Однако протокол предусматривает передачу данных любого типа, что реализуется посредством VSA (Vendor Specific Attributes). Так, например, может учитываться время, проведенное в сети, посещаемые ресурсы и т. д.
Последняя функция делает возможным применение RADIUS-серверов в качестве компонентов биллинговых систем, ответственных за сбор информации об использовании телекоммуникационных услуг, их тарификацию, выставление счетов абонентам, обработку платежей и т. д.
Свойства RADIUS
Помимо непосредственно аутентификации, авторизации и учета, RADIUS-сервера могут выполнять ряд иных функций
- Создание и хранение учётных записей пользователей или абонентов;
- Управление учётной записью пользователя из персонального интерфейса, например, веб-кабинета;
- Создание карточек доступа (логин/PIN-код) для предоставления услуг, с некоторым лимитом действия (Dial-Up доступа в Интернет и карточной IP-телефонии);
- Ручная и автоматическая блокировка учётной записи абонента по достижению заданного критерия или лимита;
- Сбор и анализ статистической информации о сессиях пользователя и всей обслуживаемой системы;
- Создание отчётов по различным статистическим параметрам;
- Создание, печать и отправка счетов к оплате;
- Аутентификация всех запросов в RADIUS-сервер из обслуживаемой системы;
Вышеперечисленное активно используется провайдерами Интернет-услуг, в среде которых RADIUS получил наиболее широкое распространение
Ограничения RADIUS
Во-первых, недостаточный уровень безопасности в некоторых реализациях. В случае использования нескольких промежуточных серверов RADIUS все они имеют возможность просматривать передающиеся через них аутентификационные данные - сертификаты и пароли.
Во-вторых, RADIUS, по крайней мере в его основной редакции, не имеет возможности отзыва ресурсов после того как авторизация была произведена. В некоторых случаях эта проблема решается производителем RADIUS-сервера самостоятельно.
В-третьих, RADIUS это протокол без поддержки состояний. Он не сохраняет транзакционную информацию и не использует её в следующих сеансах.
В-четвертых, RADIUS имеет не всегда достаточный уровень масшта-бируемости.
Механизм работы
Как уже упоминалось, RADIUS — прикладной протокол. На транспортном уровне используется протокол UDP, порты: 1812 и 1813.
Общая структура сети
Несмотря на то, что существует множество способов построения сетей с использованием RADIUS, общая структура может быть представлена в следующем виде:
Структура пакета
Общая структура 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 | Зарезервировано |
Тип (8 бит) | Длина (8 бит) | Значение |
Поле типа служит для указания атрибута, содержащегося в пакете. Выделяют 63 атрибута, в числе которых: имя пользователя и пароль (коды 1 и 2, соответственно), тип сервиса (6), ответ сервера (18), состояние RADIUS-прокси (33), состояние учета (40) и задержка учета (41) и т.д.
Длина указывает размер значения атрибута, которое непосредственно содержится в последнем поле.
Аутентификация и авторизация
Правильность аутентификационных данных может проверяться с по-мощью разных схем аутентификации: PAP, EAP или CHAP. Процедура обмена в рамках операций учета описана в RFC 2086. При подключении клиент посылает серверу запрос обслуживания (Accounting-Request), содержащий параметр acct_type=start. Это является сигналом к началу оказания услуг учета и контроля. В ответ на этот запрос клиенту высылается его уникальный идентификатор в сети, идентификатор сессии и сетевой адрес.
В ходе работы клиент периодически отправляет серверу запрос со значением acct_type=interim_update , что является сигналом к тому, что клиент все еще использует ресурс и операции учета необходимо продолжать. Данный запрос обычно содержит текущую продолжительность сессии и объем переданных данных. По окончании работы в сети, после отключения клиента от NAS, на сервер посылается запрос с параметром acct_type=stop, что означает прекращение работы и окончание предоставления услуг учета. Этот пакет запроса может содержать в себе такие данные, как продолжительность сессии, количество переданных пакетов и объем пересланных данных. В ответ на каждый запрос подобного рода сервер высылает подтвер-ждение (Accounting-Response), гарантирующее дальнейший доступ клиента к ресурсу. Если запрос не получит подтверждения с первого раза, через некоторое время будет произведена попытка повторного запроса — и так, вплоть до получения отклика или принятия решения о недоступности сервера.
Защищенность
Однако, в силу частичной реализации данных функции и недостаточ-ной защиты, предоставляемой ими, на практике необходимо использование дополнительных мер — таких как применение IPsec или физической защиты корпоративных сетей. Это позволяет в дальнейшем защитить трафик между сервером доступа и RADIUS-сервером.
Кроме того, передаваемые данные подвергаются защите лишь частично: защищены логин и пароль, в то время, как другие данные, возможно являющиеся секретными или приватными, не защищены.
Этот недостаток устранен в протоколе RadSec, который, будучи основан на RADIUS содержит ряд улучшений безопасности.
Пример настройки Radius
Начнём с того, что создадим в домене две локальных группы безопасности с ограниченными и полными правами Radius.
Создание группы с полными правами
В первую группу включим пользователей которым нужно предоставить полный административный доступ на управление коммутаторами, во вторую соответственно, — доступ только на чтение текущей конфигурации и состояния устройств. При этом, стоит помнить, что для пользователей, которые будут включаться в эти группы должно быть установлено разрешение в домене, дающее право удалённого доступа (значение настройки Network Access Permission на закладке Dial-In свойств учетной записи пользователя) [Источник 4]
Название RADIUS является аббревиатурой от Remote Authentication Dial In User Service и представляет собой сетевой протокол, обеспечивающий централизованную Аутентификацию (Authentication), Авторизацию (Authorization) и Учет используемых сетевых ресурсов (Accounting). В англоязычной литературе для этих трех функций (Authentication, Authorization, Accounting) используется аббревиатура ААА.
Под Аутентификацией понимается процесс, позволяющий идентифицировать пользователя по его данным, например, по логину (имя пользователя, номер телефона и т. д.) и паролю.
Авторизация - процесс, в течение которого определяются полномочия идентифицированного пользователя на доступ к определённым сетевым ресурсам.
Термин Учет использованных сетевых ресурсов уже сам по себе достаточно информативен. Первичными данными, которые передаются по протоколу RADIUS, являются объемы входящего и исходящего трафиков при передаче данных, и длительность разговора и набранный номер при использовании IP телефонии. Кроме определенных в протоколе стандартных атрибутов (параметров), протокол предусматривает возможность использования производителем оборудования (вендором) собственных атрибутов. В англоязычной литературе они называются Vendor Specific Attributes или VSA.
Протокол RADIUS был разработан компанией Livingston Enterprises (конкретно Карлом Ригней/Carl Rigney) для удаленного коммутируемого доступа через сетевые сервера доступа (Network Access Server - NAS) этой компании серии PortMaster к сети internet. Позже, в 1997, протокол RADIUS был опубликован как RFC 2058 иRFC 2059. Текущие версии RFC 2865 (Remote Authentication Dial In User Service (RADIUS)) и RFC 2866 (RADIUS Accounting). Иногда вместо понятия "сетевой сервер доступа" используется другой: "удаленный сервер доступа" (Remote Access Server – RAS).
В настоящее время протокол RADIUS используется для доступа к виртуальным частным сетям (VPN), точкам беспроводного (Wi-Fi) доступа, Ethernet коммутаторам, DSL и другим типам сетевого доступа. Благодаря открытости, простоте внедрения, постоянному усовершенствованию, протокол RADIUS сейчас является фактически стандартом для удаленной аутентификации.
Аутентификация и авторизация
Для выяснения работы RADIUS протокола рассмотрим рисунок, приведенный ниже.
Ноутбуки и IP телефон, представляют устройства пользователя, с которых необходимо выполнить аутентификации и авторизации на сетевых серверах доступа (NAS):
- точке Wi-Fi доступа,
- маршрутизаторе,
- VPN сервере и
- IP АТС.
На рисунке показаны не все возможные варианты NAS. Существуют и другие сетевые устройства доступа.
RADIUS протокол реализовывается в виде интерфейса между NAS, который выступает как RADIUS клиент, и RADIUS сервером – программным обеспечением, которое может быть установлено на компьютере (сервере) или каком-то специализированном устройстве. Таким образом, RADIUS сервер, как правило, не взаимодействует напрямую с устройством пользователя, а только через сетевой сервер доступа.
Пользователь посылает запрос на сетевой сервер доступа для получения доступа к определенному сетевому ресурсу, используя сертификат доступа. Сертификат посылается на сетевой сервер доступа через сетевой протокол канального уровня (Link Layer), например, Point-to-Point Protocol (PPP) в случае выполнения коммутируемого доступа, Digital Subscriber Line (DLS) – в случае использования соответствующих модемов и т.п. NAS после этого, в свою очередь, посылает сообщение запроса доступа на RADIUS сервер, так называемый RADIUS Access Request. Этот запрос включает сертификаты доступа, которые обычно представлены в виде имени пользователя и пароля или сертификата безопасности, полученных от пользователя. Кроме этого запрос может содержать дополнительные параметры, такие как сетевой адрес устройства пользователя, его телефонный номер, информацию о физическом адресе, с которого пользователь взаимодействует с NAS.
RADIUS сервер проверяет эту информацию на корректность, используя такие схемы аутентификации, как PAP, CHAP, EAP и т.п.
Кратко опишем эти протоколы.
PAP (Password Authentication Protocol) (RFC1334)– простой аутентификационный протокол, который используется для аутентификации пользователя по отношению к сетевому серверу доступа (NAS). РАР используется РРР протоколом. Практически все сервера доступа поддерживают РАР. РАР передает незашифрованный пароль через сеть и, следовательно, является незащищенным протоколом. Поэтому РАР, обычно, используется в том случае, когда сервер не поддерживает защищенные протоколы, такие как СНАР, ЕАР и т.п.
CHAP (англ. Challenge Handshake Authentication Protocol) (RFC 1994) — широко распространённый алгоритм проверки подлинности, предусматривающий передачу не самого пароля пользователя, а косвенных сведений о нём. При использовании CHAP сервер удаленного доступа отправляет клиенту строку запроса. На основе этой строки и пароля пользователя клиент вычисляет хеш-код MD5 (Message Digest-5) и передает его серверу. Хеш-функция является алгоритмом одностороннего (необратимого) шифрования, поскольку значение хеш-функции для блока данных вычислить легко, а определить исходный блок по хеш-коду с математической точки зрения невозможно за приемлемое время. (По хешированию существует много литературы, например, можно прочесть: Хеширование). Сервер, которому доступен пароль пользователя, выполняет те же самые вычисления и сравнивает результат с хеш-кодом, полученным от клиента. В случае совпадения учётные данные клиента удалённого доступа считаются подлинными.
MD5 (Message-Digest algorithm 5) (RFC 1321) — широко используемая криптографическая функция с 128 битовым хешем. Найден ряд уязвимостей в алгоритме MD5, в силу чего в США департамент U. S. Department of Homeland Security не рекомендует использование MD5 в будущем, и для большинства правительственных приложений c 2010 года США требуется перейти на семейство алгоритма SHA-2.
Протокол EAP (Extensible Authentication Protocol) (RFC 3748) позволяет проверять подлинность при подключениях удаленного доступа с помощью различных механизмов проверки подлинности. Точная схема проверки подлинности согласовывается клиентом удаленного доступа и сервером, выполняющим проверку подлинности (им может быть сервер удаленного доступа или RADIUS сервер). По умолчанию в маршрутизацию и удаленный доступ включена поддержка протоколов EAP-TLS и MD5-Challenge (MD5-задача). Подключение других модулей ЕАР к серверу, использующему маршрутизацию и удаленный доступ, обеспечивает поддержку других методов ЕАР.
Протокол EAP позволяет вести свободный диалог между клиентом удаленного доступа и системой проверки подлинности. Такой диалог состоит из запросов системы проверки подлинности на необходимую ей информацию и ответов клиента удаленного доступа. Например, когда протокол EAP используется с генераторами кодов доступа, сервер, выполняющий проверку подлинности, может отдельно запрашивать у клиента удаленного доступа имя пользователя, идентификатор и код доступа. После ответа на каждый такой запрос клиент удаленного доступа проходит определенный уровень проверки подлинности. Когда на все запросы будут получены удовлетворительные ответы, проверка подлинности клиента удаленного доступа успешно завершается.
Схемы проверки подлинности, использующие протокол EAP, называются типами EAP. Для успешной проверки подлинности клиент удаленного доступа и сервер, выполняющий проверку подлинности, должны поддерживать один и тот же тип EAP.
Теперь вернемся к RADIUS серверу, который проверяет информацию, полученную от NAS. Сервер проверяет идентичность пользователя, а также корректность дополнительной информации, которая может содержаться в запросе: сетевой адрес устройства пользователя, телефонный номер, состояние счета, его привилегии при доступе к запрашиваемому сетевому ресурсу.
По результатам проверки RADIUS сервер посылает NAS один из трех типов откликов:
- Access-Reject показывает, что данный пользовательский запрос неверный. При желании сервер может включить текстовое сообщение в Access-Reject, которое может быть передано клиентом пользователю. Никакие другие атрибуты (кроме Proxy-State) не разрешены в Access-Reject.
- Access-Challenge. Запрос дополнительной информации от пользователя, например, второй пароль, пин-код, номер карты и т.п. Этот отклик также используется для более полного аутентификационного диалога, где защитный туннель выполняется между устройством пользователя и RADIUS сервером, так что сертификаты доступа скрываются от NAS.
- Access Accept. Пользователю разрешен доступ. Поскольку пользователь аутентифицирован, то RADIUS сервер проверяет авторизацию на использование запрошенных пользователем ресурсов. Например, пользователю может быть доступ через беспроводную сеть, но запрещен доступ к VPN сети.
Таким образом, работа RADIUS протокола может в общем случае быть представлена, как показано на таблице ниже.
Учет использованных сетевых ресурсов
После того, как NAS разрешил пользователю доступ, NAS посылает RADIUS серверу сообщение о начале учета сетевого доступа – пакет Accounting Request, который содержит атрибут Acct-Status-Type со значением "start". Это сообщение обычно содержит идентификатор пользователя, его сетевой адрес, порт подключения и уникальный идентификатор сессии.
NAS может периодически посылать RADIUS серверу пакет Accounting Request, содержащий атрибут Acct-Status-Type со значением "interim-update". Подобная информация предназначена для обновления статуса пользователя во время активной сессии. Обычно подобная информация сопровождается информацией о текущей дате и продолжительности сессии.
После прекращения пользователем доступа к сети NAS посылает RADIUS серверу последний пакет Accounting Request, который содержит атрибут Acct-Status-Typeсо значением "stop". Также передается информация о времени сессии, количестве переданных пакетов, количестве переданных байтов, причине окончания соединения и другая информация, связанная с сетевым доступом.
Обычно, RADIUS клиент посылает пакет Accounting Request с возможным повтором через некоторый интервал времени, пока не получит в ответ от RADIUS сервера подтверждение приема – пакет Accounting-Response.
Основная цель этих данных – использование их для выставления счетов, однако, они могут использоваться также для получения статистики по предоставляемым услугам и для общего сетевого мониторинга.
Обычно, для аутентификации и авторизации RADIUS сервером используется 1812 UDP порт, а для учета услуг - 1813 UDP порт. Однако, в ряде случаев могут использоваться и другие порты. В частности, устройства Cisco Systems по умолчанию используют 1645 и 1646 порты соответственно.
В настоящее время существует целый ряд реализаций RADIUS серверов различными фирмами. Мы рекомендуем использовать SoftPI RADIUS сервер.
Читайте также: