РАДИУС

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

Служба удаленной аутентификации пользователей с телефонным подключением ( RADIUS ) - это сетевой протокол, работающий на портах 1812 и 1813, который обеспечивает централизованное управление аутентификацией, авторизацией и учетом ( AAA ) для пользователей, которые подключаются к сетевой службе и используют ее. RADIUS был разработан Livingston Enterprises в 1991 году как протокол аутентификации и учета сервера доступа. Позже он был внесен в стандарты IETF .

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

Компоненты протокола [ править ]

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

Аутентификация и авторизация [ править ]

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

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

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

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

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

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

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

Access Challenge

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

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

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

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

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

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

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

Как только клиент получит такую ​​информацию, он может выбрать аутентификацию с использованием RADIUS. Для этого клиент создает «запрос доступа», содержащий такие атрибуты, как имя пользователя, пароль пользователя, идентификатор клиента и идентификатор порта, к которому пользователь обращается. Если пароль присутствует, он скрывается с помощью метода, основанного на алгоритме дайджеста сообщений RSA MD5.

Бухгалтерский учет [ править ]

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

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

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

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

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

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

Роуминг [ править ]

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

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

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

Царства [ править ]

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

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

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

Прокси-операции [ править ]

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

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

Безопасность [ править ]

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

Структура пакета [ править ]

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

Коды RADIUS (десятичные) назначаются следующим образом:

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

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

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

Пары значений атрибутов [ править ]

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

Атрибуты, зависящие от поставщика [ править ]

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

Безопасность [ править ]

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

История [ править ]

Чем больше модемное клиенты использовали NSFnet запрос предложений был разослан Merit Network в 1991 году , чтобы объединить их различные запатентованную аутентификации, авторизации и учета. Среди первых респондентов была компания Livingston Enterprises, и первая версия RADIUS была написана после встречи. Ранний сервер RADIUS был установлен в операционной системе UNIX . Компания Livingston Enterprises была приобретена Lucent, и вместе с Merit были предприняты шаги для получения отраслевого признания RADIUS в качестве протокола. Обе компании бесплатно предложили сервер RADIUS. ^[9] RADIUS был в 1997 году опубликован как RFC 2058 и RFC 2059, текущие версии - RFC 2865 и RFC 2866.^[10]

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

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

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

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

Документация по стандартам [ править ]

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

См. Также [ править ]

• 802.1X
• Диаметр (протокол)
• Kerberos (протокол)
• Язык разметки утверждения безопасности
• TACACS
• TACACS +

Ссылки [ править ]

Библиография [ править ]

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

Внешние ссылки [ править ]

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