Radius accounting что это
08. RADIUS
8.1.1. Общие сведения о AAA и RADIUS
8.1.2. Общие сведения о AAA и RADIUS
Протокол RADIUS использует UDP для транспорта. Формат заголовка пакета показан ниже.
Code – тип пакета RADIUS, возможные значения для данного поля:
8.2. Конфигурация RADIUS
Команда
Описание
! В режиме глобальной конфигурации
Включить функцию аутентификации AAA. Команда no отключает эту функцию.
no aaa-accounting enable
! В режиме глобальной конфигурации
Включить функцию учета AAA. Команда no отключает эту функцию.
! В режиме глобальной конфигурации
Включить или выключить (по-умолчанию) периодическую отправку данных об онлайн-пользователях.
2. Настроить ключ сервера RADIUS:
Команда
Описание
no radius-server key
! В режиме глобальной конфигурации
Задать глобальный ключ RADIUS-сервера. Команда no удаляет заданный ключ.
3. Настроить параметры RADIUS сервера:
Команда
Описание
radius-server authentication host < | >[port
no radius-server authentication host
! В режиме глобальной конфигурации
Настроить параметры RADIUS-сервера | для аутентификации. Если параметр Radius accounting что это не будет задан, то будет использован параметр заданный глобально. Команда no удаляет заданный сервер.
radius-server accounting host < | >[port
no radius-server accounting host
! В режиме глобальной конфигурации
Настроить параметры RADIUS-сервера | для учета. Если параметр Radius accounting что это не будет задан, то будет использован параметр заданный глобально. Команда no удаляет заданный сервер.
4. Настроить параметры сервиса RADIUS:
Команда
Описание
no radius-server dead-time
! В режиме глобальной конфигурации
no radius-server retransmit
! В режиме глобальной конфигурации
no radius-server timeout
! В режиме глобальной конфигурации
no radius-server accounting-interim-update timeout
! В режиме глобальной конфигурации
5. Настроить адреса RADIUS NAS:
Команда
Описание
! В режиме глобальной конфигурации
Задать IPv4-адрес источника пакетов RADIUS, отправляемых коммутатором. Команда no устанавливает в качестве источника адрес IP-интерфейса, с которого были отправлены пакеты (по-умолчанию
! В режиме глобальной конфигурации
Задать IPv6-адрес источника пакетов RADIUS, отправляемых коммутатором. Команда no устанавливает в качестве источника адрес IP-интерфейса, с которого были отправлены пакеты (по-умолчанию
8.3. Пример конфигурации RADIUS
Конфигурация выглядит следующим образом:
8.4. Устранение проблем при конфигурации RADIUS
БИЛЛИНГОВАЯ СИСТЕМА
Протокол авторизации RADIUS является ключевой частью большинства биллинговых систем. Для лучшего понимания принципов работы ExpertBilling System советуем вам ознакомиться с данной статьей.Здесь присутствуют элементы документации RFC 2865 и RFC 2866.
Oсновные составные части службы идентификации удаленных пользователей (Remote Authentication Dial-In User Service, RADIUS) описываются двумя RFC от IETF: RFC 2865 под названием Remote Authentication Dial-In User Service (RADIUS) в форме проекта стандарта и RFC 2866 под названием RADIUS Accounting в виде «информационного RFC».
Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выкристаллизовались и другие области применения этой технологии. К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все.
Концепция службы идентификации удаленных пользователей подразумевает, что клиент RADIUS — обычно сервер доступа, сервер VPN или точка доступа беспроводной локальной сети — отсылает серверу RADIUS параметры доступа пользователя (в англоязычной документации они часто называются Credentials, т. е. мандат, куда, к примеру, входят его настройки безопасности и права доступа), а также параметры соответствующего соединения. Для этого клиент использует специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-response. После этого клиент передает на сервер RADIUS учетную информацию.
Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем информация об аутентификации направляется на порт UDP с номером 1812. Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об аутентификации) или, соответственно, 1646 (для учета) — выбор должен определять своим решением администратор. В поле данных пакета UDP (так называемая полезная нагрузка) всегда помещается только одно сообщение RADIUS. В соответствии с RFC 2865 и RFC 2866 определены следующие типы сообщений:
Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами и серверами RADIUS. Атрибуты RADIUS определены в нескольких RFC, а именно: RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869 и RFC 3162.
RADIUS может совместно работать с различными протоколами аутентификации. Наиболее часто используются протокол аутентификации пароля (Password Authentication Protocol, РАР), протокол аутентификации с предварительным согласованием (Challenge Handshake Authentication Protocol, CHAP), а также MS-CHAP (CHAP от Microsoft в первой версии или MS-CHAPv2 — во второй).
Протокол CHAP (Challenge Handshake Authentication Protocol)— это протокол проверки подлинности типа «запрос-ответ», использующий стандартную схему хеширования Message Digest 5 (MD5) для шифрования ответа. Протокол CHAP используется множеством поставщиков серверов и клиентов доступа к сети. Сервер, использующий маршрутизацию и удаленный доступ, поддерживает CHAP таким образом, что выполняется проверка подлинности клиента удаленного доступа, требующего данный протокол. Так как CHAP требует использования обратимо зашифрованного пароля, рекомендуется использовать другой протокол проверки подлинности, например MS-CHAP версии 2.
Операционные системы семейства 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 вместе с PPP, протоколом передачи «точка-точка» (Point-to-Point Protocol). Результаты сеанса аутентификации между сервером доступа и действующим клиентом передаются на сервер RADIUS, который их потом удостоверяет.
Для защиты сообщений клиент и сервер RADIUS обладают «общим секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке символов, имеющейся как на серверах, так и на клиенте RADIUS.
НЕПРАВИЛЬНО СКОНФИГУРИРОВАННЫЙ ОБЩИЙ СЕКРЕТ
Еще одна потенциально слабая точка реализации RADIUS касается «общего секрета» (Shared Secret). Это связано с тем, что очень часто один и тот же «общий секрет» служит для поддержки максимального количества пар «клиент-сервер» в службе RADIUS. К тому же в большинстве случаев криптологически он недостаточно устойчив против атаки с перебором слов по словарю в автономном режиме. Значение поля Response Authenticator и содержимое атрибута Message Authenticator легко вычисляются. Потом эти данные сравниваются с перехваченным сообщением Access-Accept, Access-Reject или Access-Challenge. Таким образом, легко разгадываемый «общий секрет» может быть быстро скомпрометирован.
Сложившаяся ситуация усугубляется также некоторыми вариантами реализации RADIUS — довольно часто длина «общего секрета» не может превышать определенной величины, или же набор символов, из которых образуется ключевое слово, ограничен. В качестве примера приведем распространенную установку на использование только тех символов из набора ASCII, которые находятся непосредственно на клавиатуре — то есть лишь 94 из доступных 256 символов ASCII.
Важно знать, что в случае, если выбор ограничен только возможностями клавиатуры, последовательность символов должна состоять как минимум из 22 знаков и при этом содержать примерно в одинаковой пропорции строчные и прописные буквы, цифры и специальные символы. Если же «общий секрет» может быть задан в виде строки из шестнадцатеричных чисел, следует задавать не менее 32 цифр.
RFC 2865 предписывает использование 16 символов в «общем ключе». Однако для достижения энтропии (в теории информации энтропия отражает количество информации в последовательности символов) равной 128 бит каждый отдельный символ должен иметь энтропию 8 бит. В случае же, когда выбор символов ограничен имеющимися на клавиатуре, энтропия 8-битного символа уменьшается до 5,8 бит. Поэтому, чтобы добиться уровня энтропии в 128 бит, необходимо 22 символа. В среде Windows 2000 максимально возможная длина «общего секрета» может быть равна 64 символам (из имеющихся на клавиатуре).
Качественно улучшить результаты позволяет использование программ для генерирования «общего секрета», поскольку при этом обычно получаются лучшие, по сравнению с ручным вводом, значения энтропии. Кроме того, пара «клиент-сервер», использующая RADIUS, всегда должна быть защищена одним и тем же «общим секретом».
ПРИМЕНЕНИЕ RADIUS
Соблюдение некоторых принципов при вводе RADIUS в эксплуатацию поможет свести различные риски к минимуму. При этом следует использовать алгоритм шифрования Triple DES. Такой метод описан также в документе RFC 3162. Путем шифрования всего сообщения RADIUS защищаются особо чувствительные его части — такие, как поле удостоверения запроса в сообщении запроса доступа — и атрибуты RADIUS (к примеру, пароль пользователя или атрибуты ключа МРРЕ). Тому, кто предпримет попытку проникновения в систему, понадобится сначала расшифровать защищенное с помощью ESP сообщение RADIUS, и лишь после этого он сможет анализировать его содержимое. Чтобы предотвратить атаки на сервер RADIUS извне, рекомендуется установить программное обеспечение для аутентификации с использованием сертификатов. Помимо этого, возможны и другие варианты защиты.
Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации:
Если аутентификация производится посредством РАР, то эту опцию следует отключить. При аутентификации с помощью однократных паролей или токенов происходит откат к PAP. Но поскольку IEEE 802.1x не поддерживает РАР, в подобных случаях чаще всего пользуются соединениями РРР.
РАСШИРЕННЫЙ ПРОТОКОЛ АУТЕНТИФИКАЦИИ
Расширенный протокол аутентификации (Extensible Authentication Protocol, EAP) изначально задумывался как дополнение к РРР для поддержки различных механизмов аутентификации доступа к сети. Протоколы аутентификации для РРР, например CHAP, MS-CHAP и MS-CHAPv2, определяют механизм аутентификации во время фазы установления соединения. На этом этапе необходимо применять согласованный протокол аутентификации, с целью «верификации» соединения. В данном случае речь идет о заранее определенной последовательности сообщений, причем они должны отсылаться в соответствии с заданной схемой, а точнее, в указанной очередности.
При использовании EAP в процессе установления соединения в рамках РРРспециальный механизм аутентификации не определяется. Лишь на этапе аутентификации участники взаимодействуют по специальной схеме аутентификации EAP, обозначаемой также как «схема типа EAP». ЕАР позволяет осуществлять обмен сообщениями между клиентом, запрашивающим доступ, и аутентифицирующим сервером (в его роли часто выступает сервер RADIUS). При этом обмен сообщениями может варьироваться с учетом особенностей различных соединений; он состоит собственно из запросов, в которых требуется предоставление информации об аутентификации, а также из соответствующих ответов. Длительность и конкретные детали сеанса аутентификации зависят от заданной схемы EAP.
В архитектурном плане ЕАР задумывался таким образом, чтобы аутентификацию можно было выполнять с помощью подключенных модулей с обеих сторон соединения: от клиента и от сервера. Если библиотечный файл ЕАР установить на обоих концах, то в любой момент можно применить новую схему аутентификации. Тем самым ЕАР предоставляет гибкую среду для внедрения безопасных методов аутентификации. ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802.
К примеру, службу RRAS операционной системы Windows 2000 можно настроить таким образом, что система с каждым сообщением запроса доступа станет отправлять атрибут удостоверение сообщения (Message-Authenticator). При этом в соответствующем диалоговом окне необходимо выбрать в свойствах опцию always use digital signatures («всегда использовать цифровую подпись»). Служба аутентификации в Internet (Internet Authentication Service, IAS) настраивается со стороны Windows 2000 так, чтобы при получении любого сообщения запроса доступа проверялось наличие атрибута Message-Authenticator. Администратор должен установить соответствующий флажок в свойствах клиента RADIUS, чтобы клиент постоянно пересылал в запросе атрибут подписи.
Если по каким-либо причинам такой вариант невозможен, в этом случае остается один выход: Windows 2000 обладает механизмом «учета и блокировки аутентификации». Благодаря ему клиент не может превысить заданное количество попыток аутентификации за установленное время. Если же это происходит, система сразу прервет с ним связь.
Radius accounting что это
Название RADIUS является аббревиатурой от Remote Authentication Dial In User Service и представляет собой сетевой протокол, обеспечивающий централизованную Аутентификацию (Authentication), Авторизацию (Authorization) и Учет используемых сетевых ресурсов (Accounting). В англоязычной литературе для этих трех функций (Authentication, Authorization, Accounting) используется аббревиатура ААА.
Под Аутентификацией понимается процесс, позволяющий идентифицировать пользователя по его данным, например, по логину (имя пользователя, номер телефона и т. д.) и паролю.
Термин Учет использованных сетевых ресурсов уже сам по себе достаточно информативен. Первичными данными, которые передаются по протоколу RADIUS, являются объемы входящего и исходящего трафиков при передаче данных, и длительность разговора и набранный номер при использовании IP телефонии. Кроме определенных в протоколе стандартных атрибутов (параметров), протокол предусматривает возможность использования производителем оборудования (вендором) собственных атрибутов. В англоязычной литературе они называются Vendor Specific Attributes или VSA.
В настоящее время протокол RADIUS используется для доступа к виртуальным частным сетям (VPN), точкам беспроводного (Wi-Fi) доступа, Ethernet коммутаторам, DSL и другим типам сетевого доступа. Благодаря открытости, простоте внедрения, постоянному усовершенствованию, протокол RADIUS сейчас является фактически стандартом для удаленной аутентификации.
Аутентификация и авторизация
Для выяснения работы RADIUS протокола рассмотрим рисунок, приведенный ниже.
Ноутбуки и IP телефон, представляют устройства пользователя, с которых необходимо выполнить аутентификации и авторизации на сетевых серверах доступа (NAS):
На рисунке показаны не все возможные варианты 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 один из трех типов откликов:
Таким образом, работа RADIUS протокола может в общем случае быть представлена, как показано на таблице ниже.
| Сервер доступа | Направление | RADIUS сервер |
| Access-Request: NAS-Identifier, NAS-Port, User-Name, User-Password (пароль может быть проигнорирован) | → | |
| ← | Access-Challenge: State (0 или 1) и Reply-Message (Например: «Challenge 12345678, enter your response at the prompt») | |
| Access-Request: с новым ID, NAS-Identifier, NAS-Port, User-Name, User-Password (пароль криптографируется). State (тот же, что и в Access-Challenge) | → | |
| ← | Access-Challenge: State (0 или 1) и Reply-Message (Например: «Challenge 12345678, enter your response at the prompt») |
Учет использованных сетевых ресурсов
После того, как 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 серверов различными фирмами. Мы рекомендуем использовать SoftPI RADIUS сервер.