РАДИУС

Для проверки этой статьи нужны дополнительные цитаты . Помогите улучшить эту статью , добавив ссылки на надежные источники . Неподтвержденные материалы могут быть оспорены и удалены. Найти источники:  "RADIUS" – новости  · газеты  · книги  · ученый  · JSTOR ( апрель 2015 г. ) ( Узнайте, как и когда удалять это сообщение )

Remote Authentication Dial-In User Service ( RADIUS ) — сетевой протокол, который обеспечивает централизованное управление аутентификацией, авторизацией и учетом ( AAA ) для пользователей, которые подключаются и используют сетевую службу. RADIUS был разработан Livingston Enterprises в 1991 году как протокол аутентификации и учета сервера доступа. Позднее он был включен в стандарты IEEE 802 и IETF .

RADIUS — это клиент-серверный протокол, работающий на прикладном уровне и использующий как TCP , так и UDP . Серверы сетевого доступа , которые управляют доступом к сети, обычно содержат клиентский компонент RADIUS, который взаимодействует с сервером RADIUS. ^[1] RADIUS часто является серверной частью для аутентификации 802.1X . ^[2] Сервер RADIUS обычно представляет собой фоновый процесс , работающий в UNIX или Microsoft Windows . ^[1]

Атака Blast-RADIUS нарушает работу RADIUS, когда она выполняется на незашифрованном транспортном протоколе, таком как UDP. ^[3]

RADIUS — это протокол AAA (аутентификация, авторизация и учет), который управляет сетевым доступом. RADIUS использует два типа пакетов для управления полным процессом AAA: Access-Request, который управляет аутентификацией и авторизацией; и Accounting-Request, который управляет учетом. Аутентификация и авторизация определены в RFC 2865, а учет описан в RFC 2866.

Пользователь или машина отправляет запрос на сервер сетевого доступа (NAS) для получения доступа к определенному сетевому ресурсу с использованием учетных данных доступа. Учетные данные передаются на устройство NAS через протокол канального уровня , например, протокол Point-to-Point (PPP) в случае многих провайдеров коммутируемого доступа или DSL, или публикуются в защищенной веб-форме HTTPS .

В свою очередь, NAS отправляет сообщение RADIUS Access Request на сервер RADIUS, запрашивая авторизацию для предоставления доступа по протоколу RADIUS. ^[4]

Этот запрос включает учетные данные доступа, обычно в форме имени пользователя и пароля или сертификата безопасности, предоставленного пользователем. Кроме того, запрос может содержать другую информацию, которую NAS знает о пользователе, например, его сетевой адрес или номер телефона, а также информацию о физической точке подключения пользователя к NAS.

Сервер RADIUS проверяет правильность информации, используя схемы аутентификации, такие как PAP , CHAP или EAP . Проверяется подтверждение личности пользователя, а также, по желанию, другая информация, связанная с запросом, например, сетевой адрес или номер телефона пользователя, статус учетной записи и определенные привилегии доступа к сетевым службам. Исторически серверы RADIUS проверяли информацию пользователя по локально хранящейся базе данных плоских файлов. Современные серверы RADIUS могут делать это или могут ссылаться на внешние источники — обычно SQL , Kerberos , LDAP или серверы Active Directory — для проверки учетных данных пользователя.

Затем сервер RADIUS возвращает NAS один из трех ответов: 1) Отказ в доступе, 2) Запрос доступа или 3) Разрешение доступа.

Отклонить доступ

Пользователю безоговорочно отказано в доступе ко всем запрашиваемым сетевым ресурсам. Причины могут включать непредоставление подтверждения личности или неизвестную или неактивную учетную запись пользователя.

Доступ к вызову

Запрашивает дополнительную информацию от пользователя, такую ​​как дополнительный пароль, PIN-код, токен или карта. Access Challenge также используется в более сложных диалогах аутентификации, где между пользовательским компьютером и сервером Radius устанавливается защищенный туннель таким образом, что учетные данные доступа скрыты от NAS.

Доступ Принять

Пользователю предоставляется доступ. После аутентификации пользователя сервер RADIUS часто проверяет, имеет ли пользователь право использовать запрошенную сетевую службу. Например, определенному пользователю может быть разрешено использовать беспроводную сеть компании, но не ее службу VPN. Опять же, эта информация может храниться локально на сервере RADIUS или может быть найдена во внешнем источнике, таком как LDAP или Active Directory.

Каждый из этих трех ответов RADIUS может включать атрибут Reply-Message, который может содержать причину отклонения, приглашение для вызова или приветственное сообщение для принятия. Текст в атрибуте может быть передан пользователю на ответной веб-странице.

Атрибуты авторизации передаются в NAS, определяя условия доступа, который должен быть предоставлен. Например, следующие атрибуты авторизации могут быть включены в Access-Accept:

• Конкретный IP-адрес , который будет назначен пользователю
• Пул адресов, из которого следует выбрать IP-адрес пользователя.
• Максимальный период времени, в течение которого пользователь может оставаться подключенным
• Список доступа, приоритетная очередь или другие ограничения доступа пользователя
• Параметры L2TP
• Параметры VLAN
• Параметры качества обслуживания (QoS)

Когда клиент настроен на использование RADIUS, любой пользователь клиента предоставляет клиенту информацию аутентификации. Это может быть настраиваемое приглашение на вход, где пользователь должен ввести свое имя пользователя и пароль. В качестве альтернативы пользователь может использовать протокол кадрирования ссылок, такой как протокол Point-to-Point (PPP), который имеет пакеты аутентификации, несущие эту информацию.

Получив такую ​​информацию, клиент может выбрать аутентификацию с использованием RADIUS. Для этого клиент создает "Access-Request", содержащий такие атрибуты, как имя пользователя, пароль пользователя, идентификатор клиента и идентификатор порта, к которому пользователь получает доступ. Если пароль присутствует, он скрывается с помощью метода, основанного на алгоритме RSA Message Digest MD5.

Бухгалтерский учет описан в RFC 2866.

Когда сетевой доступ предоставляется пользователю NAS , NAS отправляет Accounting Start (пакет Accounting Request RADIUS, содержащий атрибут Acct-Status-Type со значением «start») на сервер RADIUS, чтобы сигнализировать о начале сетевого доступа пользователя. Записи «Start» обычно содержат идентификацию пользователя, сетевой адрес, точку присоединения и уникальный идентификатор сеанса. ^[5]

Периодически записи Interim Update (пакет запроса на учет RADIUS, содержащий атрибут Acct-Status-Type со значением «interim-update») могут отправляться NAS на сервер RADIUS для обновления его статуса активного сеанса. «Промежуточные» записи обычно передают текущую продолжительность сеанса и информацию о текущем использовании данных.

Наконец, когда доступ пользователя к сети закрыт, NAS отправляет на сервер RADIUS окончательную запись об остановке учета (пакет запроса на учет RADIUS, содержащий атрибут Acct-Status-Type со значением «stop»), предоставляя информацию о конечном использовании с точки зрения времени, переданных пакетов, переданных данных, причины отключения и другую информацию, связанную с доступом пользователя к сети.

Обычно клиент отправляет пакеты Accounting-Request до тех пор, пока не получит подтверждение Accounting-Response, используя некоторый интервал повтора.

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

RADIUS обычно используется для упрощения роуминга между интернет-провайдерами , в том числе:

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

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

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

Области также можно объединять с использованием как префиксной, так и постфиксной нотации, что позволяет реализовывать сложные сценарии роуминга; например, somedomain.com\username@anotherdomain.com может быть допустимым именем пользователя с двумя областями.

Хотя области часто напоминают домены, важно отметить, что области на самом деле являются произвольным текстом и не обязательно содержат реальные доменные имена. Форматы областей стандартизированы в RFC 4282, который определяет идентификатор доступа к сети (NAI) в форме «user@realm». В этой спецификации часть «realm» должна быть доменным именем. Однако эта практика не всегда соблюдается. RFC 7542 ^[6] заменил RFC 4282 в мае 2015 года.

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

Цепочка прокси возможна в RADIUS, а пакеты аутентификации/авторизации и учета обычно маршрутизируются между устройством NAS и домашним сервером через ряд прокси. Некоторые из преимуществ использования цепочек прокси включают в себя улучшение масштабируемости, реализацию политик и корректировку возможностей. Но в сценариях роуминга NAS, прокси и домашний сервер обычно могут управляться разными административными субъектами. Следовательно, фактор доверия между прокси приобретает большее значение в таких междоменных приложениях. Кроме того, отсутствие сквозной безопасности в RADIUS увеличивает критичность доверия между задействованными прокси. Цепочки прокси описаны в RFC 2607.

Роуминг с RADIUS подвергает пользователей различным проблемам безопасности и конфиденциальности. В более общем плане, некоторые партнеры по роумингу устанавливают защищенный туннель между серверами RADIUS, чтобы гарантировать, что учетные данные пользователей не могут быть перехвачены во время проксирования через Интернет. Это вызывает беспокойство, поскольку хэш MD5, встроенный в RADIUS, считается небезопасным. ^[7]

RADIUS транспортируется по UDP/IP через порты 1812 и 1813. ^[8]

Формат данных пакета RADIUS показан справа. Поля передаются слева направо, начиная с кода, идентификатора, длины, аутентификатора и атрибутов.

Назначенные коды RADIUS (десятичные) включают следующее: ^[9]

Поле «Идентификатор» помогает сопоставлять запросы и ответы.

Поле «Длина» указывает длину всего пакета RADIUS, включая поля «Код», «Идентификатор», «Длина», «Аутентификатор» и необязательные поля «Атрибут».

Аутентификатор используется для аутентификации ответа от сервера RADIUS и используется при шифровании паролей; его длина составляет 16 байт.

Пары значений атрибутов RADIUS (AVP) переносят данные как в запросе, так и в ответе для транзакций аутентификации, авторизации и учета. Длина пакета RADIUS используется для определения конца AVP.

RADIUS является расширяемым; многие поставщики оборудования и программного обеспечения RADIUS реализуют свои собственные варианты с использованием Vendor-Specific Attributes (VSA). Microsoft опубликовала некоторые из своих VSA. ^[10] Определения VSA от многих других компаний остаются проприетарными и/или специальными, тем не менее, многие словари VSA можно найти, загрузив исходный код реализаций RADIUS с открытым исходным кодом, например FreeRADIUS .

Раздел 5.26 RFC 2865 содержит рекомендуемую кодировку, которой придерживается большинство поставщиков:

Некоторые поставщики используют другие форматы. Например, некоторые поставщики опускают поле «Vendor Length» или используют 2 октета для полей «Vendor Type» и/или «Vendor Length».

Раздел 3.14 RFC 8044 определяет тип данных «vsa», который предписывает формат раздела 5.26 RFC 2865.

Протокол RADIUS передает запутанные пароли с использованием общего секрета и алгоритма хеширования MD5 . Поскольку эта конкретная реализация обеспечивает лишь слабую защиту учетных данных пользователя, ^[11] следует использовать дополнительную защиту, такую ​​как туннели IPsec или физически защищенные сети центров обработки данных, для дальнейшей защиты трафика RADIUS между устройством NAS и сервером RADIUS. Кроме того, учетные данные безопасности пользователя являются единственной частью, защищенной самим RADIUS, однако другие атрибуты, специфичные для пользователя, такие как идентификаторы групп туннелей или членство в VLAN , передаваемые через RADIUS, также могут считаться конфиденциальной (полезной для злоумышленника) или частной (достаточной для идентификации отдельного клиента) информацией. ^{[ необходима цитата ]} .

Протокол RadSec решает проблему с устаревшей безопасностью RADIUS/UDP, «оборачивая» протокол RADIUS в TLS . Однако пакеты внутри транспорта TLS по-прежнему используют MD5 для проверки целостности пакетов и для сокрытия содержимого определенных атрибутов.

Атака Blast-RADIUS нарушает работу RADIUS при передаче по простому UDP, атакуя MD5 внутри RADIUS. ^[3] RadSec блокирует эту атаку. ^[3] Другим рекомендуемым способом смягчения является требование атрибутов Message-Authenticator для всех запросов и ответов. ^[3] Атаке Blast-RADIUS присвоена CVE - 2024-3596.

Поскольку все больше клиентов dial-up использовали NSFNET, в 1991 году Merit Network разослала запрос на предложение по консолидации своих различных фирменных систем аутентификации, авторизации и учета. Среди первых респондентов была Livingston Enterprises, и после встречи была написана ранняя версия RADIUS. Ранний сервер RADIUS был установлен на операционной системе UNIX . Livingston Enterprises была приобретена Lucent Technologies , и совместно с Merit были предприняты шаги по получению признания отраслью RADIUS как протокола. Обе компании предлагали сервер RADIUS бесплатно. ^[12] В 1997 году RADIUS был опубликован как RFC 2058 и RFC 2059, текущие версии — RFC 2865 и RFC 2866. ^[13]

Исходный стандарт RADIUS указывал, что RADIUS не имеет состояния и должен работать по протоколу User Datagram Protocol (UDP). Для аутентификации предполагалось, что RADIUS должен поддерживать протокол аутентификации пароля (PAP) и протокол аутентификации вызова-рукопожатия (CHAP) по протоколу точка-точка . Пароли скрываются путем взятия MD5 -хеша пакета и общего секрета, а затем выполнения операции XOR этого хеша с паролем. Исходный RADIUS также предоставлял более 50 пар атрибут-значение с возможностью для поставщиков настраивать свои собственные пары. ^[14]

Выбор модели безопасности hop-by-hop вместо сквозного шифрования означал, что если используется несколько прокси-серверов RADIUS, каждый сервер должен проверять, выполнять логику и передавать все данные в запросе. Это раскрывает такие данные, как пароли и сертификаты на каждом хопе. Серверы RADIUS также не имели возможности останавливать доступ к ресурсам после выдачи авторизации. Последующие стандарты, такие как RFC 3576 и его преемник RFC 5176, позволяли серверам RADIUS динамически изменять авторизацию пользователей или полностью отключать пользователя. ^[15]

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

Протокол Diameter был задуман как замена RADIUS. Хотя оба являются протоколами аутентификации, авторизации и учета (AAA), варианты использования двух протоколов с тех пор разошлись. Diameter в основном используется в пространстве 3G . RADIUS используется в других местах. Одним из самых больших препятствий для замены RADIUS на Diameter является то, что коммутаторы и точки доступа обычно реализуют RADIUS, но не Diameter. Diameter использует SCTP или TCP, в то время как RADIUS обычно использует UDP в качестве транспортного уровня . С 2012 года RADIUS также может использовать TCP в качестве транспортного уровня с TLS для безопасности.

Протокол RADIUS в настоящее время определен в следующих документах IETF RFC.

• Язык разметки утверждений безопасности
• ТАКАКС

• Хассел, Джонатан (2002). RADIUS — Обеспечение публичного доступа к частным ресурсам. O'Reilly & Associates. ISBN 0-596-00322-6. Получено 17.04.2009 .

• Типы радиуса
• Анализ протокола аутентификации RADIUS
• Расшифровка следа сниффера транзакции RADIUS
• Использование Wireshark для отладки RADIUS