Какое сообщение 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.


Шаги по инсталляции и настройке:

  1. Проинсталлировать FreeRADIUS
  2. Проинсталлировать Samba-сервер
  3. Включить Samba-сервер в домен Active Directory
    • Убедиться, что wbinfo -u и wbinfo -g работает
  4. Изменить настройки FreeRADIUS для использования модуля NTLM-аутентификации
  1. Click on Start, Select Run, and run regedit.exe
  2. Navigate to the key
  3. Right-click on Global and select New and DWORD Value
  4. Name the new value SupplicantMode
  5. Once created, Right click this new option and select Modify
  6. Change the Value data to 3
  7. 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.

RADIUS
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-сервера могут выполнять ряд иных функций

  1. Создание и хранение учётных записей пользователей или абонентов;
  2. Управление учётной записью пользователя из персонального интерфейса, например, веб-кабинета;
  3. Создание карточек доступа (логин/PIN-код) для предоставления услуг, с некоторым лимитом действия (Dial-Up доступа в Интернет и карточной IP-телефонии);
  4. Ручная и автоматическая блокировка учётной записи абонента по достижению заданного критерия или лимита;
  5. Сбор и анализ статистической информации о сессиях пользователя и всей обслуживаемой системы;
  6. Создание отчётов по различным статистическим параметрам;
  7. Создание, печать и отправка счетов к оплате;
  8. Аутентификация всех запросов в 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]

Наз­ва­ние RA­DI­US яв­ля­ет­ся абб­ре­ви­ату­рой от Re­mote Aut­henti­cati­on Di­al In User Ser­vi­ce и предс­тав­ля­ет со­бой се­тевой про­токол, обес­пе­чива­ющий цент­ра­лизо­ван­ную Аутен­ти­фика­цию (Aut­henti­cati­on), Ав­то­риза­цию (Aut­ho­riza­ti­on) и Учет ис­поль­зу­емых се­тевых ре­сур­сов (Ac­co­un­ting). В анг­ло­языч­ной ли­тера­туре для этих трех функ­ций (Aut­henti­cati­on, Aut­ho­riza­ti­on, Ac­co­un­ting) ис­поль­зу­ет­ся абб­ре­ви­ату­ра ААА.

Под Аутен­ти­фика­ци­ей по­нима­ет­ся про­цесс, поз­во­ля­ющий иден­ти­фици­ровать поль­зо­вате­ля по его дан­ным, нап­ри­мер, по ло­гину (имя поль­зо­вате­ля, но­мер те­лефо­на и т. д.) и па­ролю.

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

Тер­мин Учет ис­поль­зо­ван­ных се­тевых ре­сур­сов уже сам по се­бе дос­та­точ­но ин­форма­тивен. Пер­вичны­ми дан­ны­ми, ко­торые пе­реда­ют­ся по про­токо­лу RA­DI­US, яв­ля­ют­ся объемы вхо­дяще­го и ис­хо­дяще­го тра­фиков при пе­реда­че дан­ных, и дли­тель­ность раз­го­вора и наб­ранный но­мер при ис­поль­зо­вании IP те­лефо­нии. Кро­ме оп­ре­делен­ных в про­токо­ле стан­дарт­ных ат­ри­бутов (па­рамет­ров), про­токол пре­дус­матри­ва­ет воз­можность ис­поль­зо­вания про­из­во­дите­лем обо­рудо­вания (вен­до­ром) собс­твен­ных ат­ри­бутов. В анг­ло­языч­ной ли­тера­туре они на­зыва­ют­ся Ven­dor Spe­cific Att­ri­butes или VSA.

Про­токол RA­DI­US был раз­ра­ботан ком­па­ни­ей Li­ving­ston En­terp­ri­ses (конк­рет­но Кар­лом Риг­ней/Carl Rig­ney) для уда­лен­но­го ком­му­тиру­емо­го дос­ту­па че­рез се­тевые сер­ве­ра дос­ту­па (Net­work Ac­cess Ser­ver - NAS) этой ком­па­нии се­рии Port­Mas­ter к се­ти in­ternet. Поз­же, в 1997, про­токол RA­DI­US был опуб­ли­кован как RFC 2058 иRFC 2059. Те­кущие вер­сии RFC 2865 (Re­mote Aut­henti­cati­on Di­al In User Ser­vi­ce (RA­DI­US)) и RFC 2866 (RA­DI­US Ac­co­un­ting). Иног­да вмес­то по­нятия "се­тевой сер­вер дос­ту­па" ис­поль­зу­ет­ся дру­гой: "уда­лен­ный сер­вер дос­ту­па" (Re­mote Ac­cess Ser­ver – RAS).

В нас­то­ящее вре­мя про­токол RA­DI­US ис­поль­зу­ет­ся для дос­ту­па к вир­ту­аль­ным част­ным се­тям (VPN), точ­кам бесп­ро­вод­но­го (Wi-Fi) дос­ту­па, Et­hernet ком­му­тато­рам, DSL и дру­гим ти­пам се­тево­го дос­ту­па. Бла­года­ря отк­ры­тос­ти, прос­то­те внед­ре­ния, пос­то­ян­но­му усо­вер­шенс­тво­ванию, про­токол RA­DI­US сей­час яв­ля­ет­ся фак­ти­чес­ки стан­дартом для уда­лен­ной аутен­ти­фика­ции.

Аутен­ти­фика­ция и ав­то­риза­ция

Для вы­яс­не­ния ра­боты RA­DI­US про­токо­ла расс­мот­рим ри­сунок, при­веден­ный ни­же.



Но­ут­бу­ки и IP те­лефон, предс­тав­ля­ют уст­рой­ства поль­зо­вате­ля, с ко­торых не­об­хо­димо вы­пол­нить аутен­ти­фика­ции и ав­то­риза­ции на се­тевых сер­ве­рах дос­ту­па (NAS):

  • точ­ке Wi-Fi дос­ту­па,
  • марш­ру­тиза­торе,
  • VPN сер­ве­ре и
  • IP АТС.

На ри­сун­ке по­каза­ны не все воз­можные ва­ри­ан­ты NAS. Су­щест­ву­ют и дру­гие се­тевые уст­рой­ства дос­ту­па.

RA­DI­US про­токол ре­али­зовы­ва­ет­ся в ви­де ин­терфей­са меж­ду NAS, ко­торый выс­ту­па­ет как RA­DI­US кли­ент, и RA­DI­US сер­ве­ром – прог­рамм­ным обес­пе­чени­ем, ко­торое мо­жет быть ус­та­нов­ле­но на компьюте­ре (сер­ве­ре) или ка­ком-то спе­ци­али­зиро­ван­ном уст­рой­стве. Та­ким об­ра­зом, RA­DI­US сер­вер, как пра­вило, не вза­имо­дей­ству­ет нап­ря­мую с уст­рой­ством поль­зо­вате­ля, а толь­ко че­рез се­тевой сер­вер дос­ту­па.

Поль­зо­ватель по­сыла­ет зап­рос на се­тевой сер­вер дос­ту­па для по­луче­ния дос­ту­па к оп­ре­делен­но­му се­тево­му ре­сур­су, ис­поль­зуя сер­ти­фикат дос­ту­па. Сер­ти­фикат по­сыла­ет­ся на се­тевой сер­вер дос­ту­па че­рез се­тевой про­токол ка­наль­но­го уров­ня (Link La­yer), нап­ри­мер, Po­int-to-Po­int Pro­tocol (PPP) в слу­чае вы­пол­не­ния ком­му­тиру­емо­го дос­ту­па, Di­gital Subs­cri­ber Li­ne (DLS) – в слу­чае ис­поль­зо­вания со­от­ветс­тву­ющих мо­демов и т.п. NAS пос­ле это­го, в свою оче­редь, по­сыла­ет со­об­ще­ние зап­ро­са дос­ту­па на RA­DI­US сер­вер, так на­зыва­емый RA­DI­US Ac­cess Re­qu­est. Этот зап­рос вклю­ча­ет сер­ти­фика­ты дос­ту­па, ко­торые обыч­но предс­тав­ле­ны в ви­де име­ни поль­зо­вате­ля и па­роля или сер­ти­фика­та бе­зопас­ности, по­лучен­ных от поль­зо­вате­ля. Кро­ме это­го зап­рос мо­жет со­дер­жать до­пол­ни­тель­ные па­рамет­ры, та­кие как се­тевой ад­рес уст­рой­ства поль­зо­вате­ля, его те­лефон­ный но­мер, ин­форма­цию о фи­зичес­ком ад­ре­се, с ко­торо­го поль­зо­ватель вза­имо­дей­ству­ет с NAS.

RA­DI­US сер­вер про­веря­ет эту ин­форма­цию на кор­рект­ность, ис­поль­зуя та­кие схе­мы аутен­ти­фика­ции, как PAP, CHAP, EAP и т.п.
Крат­ко опи­шем эти про­токо­лы.
PAP (Pass­word Aut­henti­cati­on Pro­tocol) (RFC1334)– прос­той аутен­ти­фика­ци­он­ный про­токол, ко­торый ис­поль­зу­ет­ся для аутен­ти­фика­ции поль­зо­вате­ля по от­но­шению к се­тево­му сер­ве­ру дос­ту­па (NAS). РАР ис­поль­зу­ет­ся РРР про­токо­лом. Прак­ти­чес­ки все сер­ве­ра дос­ту­па под­держи­ва­ют РАР. РАР пе­реда­ет не­зашиф­ро­ван­ный па­роль че­рез сеть и, сле­дова­тель­но, яв­ля­ет­ся не­защи­щен­ным про­токо­лом. По­это­му РАР, обыч­но, ис­поль­зу­ет­ся в том слу­чае, ког­да сер­вер не под­держи­ва­ет за­щищен­ные про­токо­лы, та­кие как СНАР, ЕАР и т.п.

CHAP (англ. Chal­lenge Hand­sha­ke Aut­henti­cati­on Pro­tocol) (RFC 1994) — ши­роко расп­рос­тра­нён­ный ал­го­ритм про­вер­ки под­линнос­ти, пре­дус­матри­ва­ющий пе­реда­чу не са­мого па­роля поль­зо­вате­ля, а кос­венных све­дений о нём. При ис­поль­зо­вании CHAP сер­вер уда­лен­но­го дос­ту­па отп­рав­ля­ет кли­ен­ту стро­ку зап­ро­са. На ос­но­ве этой стро­ки и па­роля поль­зо­вате­ля кли­ент вы­чис­ля­ет хеш-код MD5 (Mes­sa­ge Di­gest-5) и пе­реда­ет его сер­ве­ру. Хеш-функ­ция яв­ля­ет­ся ал­го­рит­мом од­носто­рон­не­го (не­об­ра­тимо­го) шиф­ро­вания, пос­коль­ку зна­чение хеш-функ­ции для бло­ка дан­ных вы­чис­лить лег­ко, а оп­ре­делить ис­ходный блок по хеш-ко­ду с ма­тема­тичес­кой точ­ки зре­ния не­воз­можно за при­ем­ле­мое вре­мя. (По хе­широ­ванию су­щест­ву­ет мно­го ли­тера­туры, нап­ри­мер, мож­но про­честь: Хе­широ­вание). Сер­вер, ко­торо­му дос­ту­пен па­роль поль­зо­вате­ля, вы­пол­ня­ет те же са­мые вы­чис­ле­ния и срав­ни­ва­ет ре­зуль­тат с хеш-ко­дом, по­лучен­ным от кли­ен­та. В слу­чае сов­па­дения учёт­ные дан­ные кли­ен­та уда­лён­но­го дос­ту­па счи­та­ют­ся под­линны­ми.
MD5 (Mes­sa­ge-Di­gest al­go­rithm 5) (RFC 1321) — ши­роко ис­поль­зу­емая крип­тогра­фичес­кая функ­ция с 128 би­товым хе­шем. Най­ден ряд уяз­ви­мос­тей в ал­го­рит­ме MD5, в си­лу че­го в США де­пар­та­мент U. S. De­part­ment of Ho­meland Se­curi­ty не ре­комен­ду­ет ис­поль­зо­вание MD5 в бу­дущем, и для боль­шинс­тва пра­витель­ствен­ных при­ложе­ний c 2010 го­да США тре­бу­ет­ся пе­рей­ти на се­мей­ство ал­го­рит­ма SHA-2.

Про­токол EAP (Ex­tensib­le Aut­henti­cati­on Pro­tocol) (RFC 3748) поз­во­ля­ет про­верять под­линность при подк­лю­чени­ях уда­лен­но­го дос­ту­па с по­мощью раз­личных ме­ханиз­мов про­вер­ки под­линнос­ти. Точ­ная схе­ма про­вер­ки под­линнос­ти сог­ла­совы­ва­ет­ся кли­ен­том уда­лен­но­го дос­ту­па и сер­ве­ром, вы­пол­ня­ющим про­вер­ку под­линнос­ти (им мо­жет быть сер­вер уда­лен­но­го дос­ту­па или RA­DI­US сер­вер). По умол­ча­нию в марш­ру­тиза­цию и уда­лен­ный дос­туп вклю­чена под­держ­ка про­токо­лов EAP-TLS и MD5-Chal­lenge (MD5-за­дача). Подк­лю­чение дру­гих мо­дулей ЕАР к сер­ве­ру, ис­поль­зу­юще­му марш­ру­тиза­цию и уда­лен­ный дос­туп, обес­пе­чива­ет под­держ­ку дру­гих ме­тодов ЕАР.
Про­токол EAP поз­во­ля­ет вес­ти сво­бод­ный ди­алог меж­ду кли­ен­том уда­лен­но­го дос­ту­па и сис­те­мой про­вер­ки под­линнос­ти. Та­кой ди­алог сос­то­ит из зап­ро­сов сис­те­мы про­вер­ки под­линнос­ти на не­об­хо­димую ей ин­форма­цию и от­ве­тов кли­ен­та уда­лен­но­го дос­ту­па. Нап­ри­мер, ког­да про­токол EAP ис­поль­зу­ет­ся с ге­нера­тора­ми ко­дов дос­ту­па, сер­вер, вы­пол­ня­ющий про­вер­ку под­линнос­ти, мо­жет от­дель­но зап­ра­шивать у кли­ен­та уда­лен­но­го дос­ту­па имя поль­зо­вате­ля, иден­ти­фика­тор и код дос­ту­па. Пос­ле от­ве­та на каж­дый та­кой зап­рос кли­ент уда­лен­но­го дос­ту­па про­ходит оп­ре­делен­ный уро­вень про­вер­ки под­линнос­ти. Ког­да на все зап­ро­сы бу­дут по­луче­ны удов­летво­ритель­ные от­ве­ты, про­вер­ка под­линнос­ти кли­ен­та уда­лен­но­го дос­ту­па ус­пешно за­вер­ша­ет­ся.
Схе­мы про­вер­ки под­линнос­ти, ис­поль­зу­ющие про­токол EAP, на­зыва­ют­ся ти­пами EAP. Для ус­пешной про­вер­ки под­линнос­ти кли­ент уда­лен­но­го дос­ту­па и сер­вер, вы­пол­ня­ющий про­вер­ку под­линнос­ти, долж­ны под­держи­вать один и тот же тип EAP.

Те­перь вер­немся к RA­DI­US сер­ве­ру, ко­торый про­веря­ет ин­форма­цию, по­лучен­ную от NAS. Сер­вер про­веря­ет иден­тичность поль­зо­вате­ля, а так­же кор­рект­ность до­пол­ни­тель­ной ин­форма­ции, ко­торая мо­жет со­дер­жать­ся в зап­ро­се: се­тевой ад­рес уст­рой­ства поль­зо­вате­ля, те­лефон­ный но­мер, сос­то­яние сче­та, его при­виле­гии при дос­ту­пе к зап­ра­шива­емо­му се­тево­му ре­сур­су.
По ре­зуль­та­там про­вер­ки RA­DI­US сер­вер по­сыла­ет NAS один из трех ти­пов отк­ли­ков:

  • Ac­cess-Re­ject по­казы­ва­ет, что дан­ный поль­зо­ватель­ский зап­рос не­вер­ный. При же­лании сер­вер мо­жет вклю­чить текс­то­вое со­об­ще­ние в Ac­cess-Re­ject, ко­торое мо­жет быть пе­реда­но кли­ен­том поль­зо­вате­лю. Ни­какие дру­гие ат­ри­буты (кро­ме Pro­xy-Sta­te) не раз­ре­шены в Ac­cess-Re­ject.
  • Ac­cess-Chal­lenge. Зап­рос до­пол­ни­тель­ной ин­форма­ции от поль­зо­вате­ля, нап­ри­мер, вто­рой па­роль, пин-код, но­мер кар­ты и т.п. Этот отк­лик так­же ис­поль­зу­ет­ся для бо­лее пол­но­го аутен­ти­фика­ци­он­но­го ди­ало­га, где за­щит­ный тун­нель вы­пол­ня­ет­ся меж­ду уст­рой­ством поль­зо­вате­ля и RA­DI­US сер­ве­ром, так что сер­ти­фика­ты дос­ту­па скры­ва­ют­ся от NAS.
  • Ac­cess Ac­cept. Поль­зо­вате­лю раз­ре­шен дос­туп. Пос­коль­ку поль­зо­ватель аутен­ти­фици­рован, то RA­DI­US сер­вер про­веря­ет ав­то­риза­цию на ис­поль­зо­вание зап­ро­шен­ных поль­зо­вате­лем ре­сур­сов. Нап­ри­мер, поль­зо­вате­лю мо­жет быть дос­туп че­рез бесп­ро­вод­ную сеть, но зап­ре­щен дос­туп к VPN се­ти.

Та­ким об­ра­зом, ра­бота RA­DI­US про­токо­ла мо­жет в об­щем слу­чае быть предс­тав­ле­на, как по­каза­но на таб­ли­це ни­же.

Учет ис­поль­зо­ван­ных се­тевых ре­сур­сов

Пос­ле то­го, как NAS раз­ре­шил поль­зо­вате­лю дос­туп, NAS по­сыла­ет RA­DI­US сер­ве­ру со­об­ще­ние о на­чале уче­та се­тево­го дос­ту­па – па­кет Ac­co­un­ting Re­qu­est, ко­торый со­дер­жит ат­ри­бут Acct-Sta­tus-Ty­pe со зна­чени­ем "start". Это со­об­ще­ние обыч­но со­дер­жит иден­ти­фика­тор поль­зо­вате­ля, его се­тевой ад­рес, порт подк­лю­чения и уни­каль­ный иден­ти­фика­тор сес­сии.

NAS мо­жет пе­ри­оди­чес­ки по­сылать RA­DI­US сер­ве­ру па­кет Ac­co­un­ting Re­qu­est, со­дер­жа­щий ат­ри­бут Acct-Sta­tus-Ty­pe со зна­чени­ем "in­te­rim-up­da­te". По­доб­ная ин­форма­ция пред­назна­чена для об­новле­ния ста­туса поль­зо­вате­ля во вре­мя ак­тивной сес­сии. Обыч­но по­доб­ная ин­форма­ция соп­ро­вож­да­ет­ся ин­форма­ци­ей о те­кущей да­те и про­дол­жи­тель­нос­ти сес­сии.

Пос­ле прек­ра­щения поль­зо­вате­лем дос­ту­па к се­ти NAS по­сыла­ет RA­DI­US сер­ве­ру пос­ледний па­кет Ac­co­un­ting Re­qu­est, ко­торый со­дер­жит ат­ри­бут Acct-Sta­tus-Ty­peсо зна­чени­ем "stop". Так­же пе­реда­ет­ся ин­форма­ция о вре­мени сес­сии, ко­личест­ве пе­редан­ных па­кетов, ко­личест­ве пе­редан­ных бай­тов, при­чине окон­ча­ния со­еди­нения и дру­гая ин­форма­ция, свя­зан­ная с се­тевым дос­ту­пом.

Обыч­но, RA­DI­US кли­ент по­сыла­ет па­кет Ac­co­un­ting Re­qu­est с воз­можным пов­то­ром че­рез не­кото­рый ин­тервал вре­мени, по­ка не по­лучит в от­вет от RA­DI­US сер­ве­ра подт­вер­жде­ние при­ема – па­кет Ac­co­un­ting-Res­ponse.

Ос­новная цель этих дан­ных – ис­поль­зо­вание их для выс­тавле­ния сче­тов, од­на­ко, они мо­гут ис­поль­зо­вать­ся так­же для по­луче­ния ста­тис­ти­ки по пре­дос­тавля­емым ус­лу­гам и для об­ще­го се­тево­го мо­нито­рин­га.

Обыч­но, для аутен­ти­фика­ции и ав­то­риза­ции RA­DI­US сер­ве­ром ис­поль­зу­ет­ся 1812 UDP порт, а для уче­та ус­луг - 1813 UDP порт. Од­на­ко, в ря­де слу­ча­ев мо­гут ис­поль­зо­вать­ся и дру­гие пор­ты. В част­нос­ти, уст­рой­ства Cis­co Sys­tems по умол­ча­нию ис­поль­зу­ют 1645 и 1646 пор­ты со­от­ветс­твен­но.

В нас­то­ящее вре­мя су­щест­ву­ет це­лый ряд ре­али­заций RA­DI­US сер­ве­ров раз­личны­ми фир­ма­ми. Мы ре­комен­ду­ем ис­поль­зо­вать Soft­PI RA­DI­US сер­вер.

Читайте также: