Radius что это за программа

RADIUS — cлужба удаленной аутентификации входящих звонков пользователей

Протокол авторизации 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 определены следующие типы сообщений:

• Access-Request — «запрос доступа». Запрос клиента RADIUS, с которого начинается собственно аутентификация и авторизация попытки доступа в сеть;
• Access-Accept — «доступ разрешен». С помощью этого ответа на запрос доступа клиенту RADIUS сообщается, что попытка соединения была успешно аутентифицирована и авторизована;
• Access-Reject — «доступ не разрешен». Этот ответ сервера RADIUS означает, что попытка доступа к сети не удалась. Такое возможно в том случае, если пользовательских данных недостаточно для успешной аутентификации или доступ для пользователя не авторизован;
• Access-Challenge — «вызов запроса». Сервер RADIUS передает его в ответ на запрос доступа;
• Accounting-Request — «запрос учета», который клиент RADIUS отсылает для ввода учетной информации после получения разрешения на доступ.

Сообщение 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 извне, рекомендуется установить программное обеспечение для аутентификации с использованием сертификатов. Помимо этого, возможны и другие варианты защиты.

• Используемый «общий секрет» должен иметь длину не менее 32 шестнадцатеричных символов или, соответственно, 22 символов клавиатуры;
• Для всех сообщений с запросом доступа обязательны атрибуты удостоверения сообщения. Для клиента RADIUS это означает, что атрибут удостоверения сообщения нужен и для всех сообщений запроса доступа. Это правило требуется соблюдать также в случае сервера RADIUS;
• С криптографической точки зрения непременным условием является качественное удостоверение запроса.

Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации:

Следует пользоваться ЕАР или схемами типа ЕАР с поддержкой сильных методов аутентификации. Хороший пример подобного метода — ЕАР-TLS. Он требует обмена сертификатами между клиентом, пытающимся получить доступ, и сервером RADIUS. Все сообщения ЕАР должны иметь атрибуты удостоверения сообщения для защиты сообщений запроса доступа.

Желательно выбирать методы аутентификации, рассчитанные на двустороннюю аутентификацию. При таком подходе противоположные конечные точки соединения аутентифицируют свои системы. Если с какой-либо стороны аутентификация пройдет неудачно, то в установлении соединения будет отказано. Примерами подобных методов служат ЕАР-TLS и MS-CHAPv2. Так, в случае ЕАР-TLS сервер 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 обладает механизмом «учета и блокировки аутентификации». Благодаря ему клиент не может превысить заданное количество попыток аутентификации за установленное время. Если же это происходит, система сразу прервет с ним связь.

Источник: expertbilling.ru

Аутентификация, авторизация и учет (AAA) – RADIUS или TACACS+

Для обеспечения безопасности сети необходимо обеспечить контроль за доступом к различным элементам сети со стороны пользователей. Такими элементами могут быть сетевые устройства, серверы, компьютеры, приложения или даже сегменты самой сети. Сценарии разные, а принцип один – аутентификация, авторизация и учет (Authentication, Authorization, Accounting – AAA).

Для чего нужен AAA

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

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

Сценарии разные, а принцип один – аутентификация, авторизация и учет (Authentication, Authorization, Accounting – AAA).

Есть два основных типа AAA для сетей:

• Администрирование сетевых устройств. Осуществляет управление теми, у кого есть доступ для входа в консоль сетевого устройства, Telnet-сессии, Secure Shell (SSH-сессии) или другим способом.
• Доступ к сети. Идентификация пользователя или устройства до того, как ему будет предоставлен доступ к сети.

В современных сетях используют два основных решения для AAA: Remote Authentication Dial-In User Service (RADIUS) и Cisco’s Terminal Access Controller Access-Control System Plus (TACACS+) протоколы. Существует еще и третий AAA-протокол, известный как DIAMETER, но он обычно используется только мобильными операторами. Мы рассмотрим и сравним RADIUS и TACACS+, чтобы помочь вам определить, какой из них лучше подходит для вашей сети.

Основные понятия AAA

Прежде чем мы познакомимся с протоколами RADIUS и TACACS+, разберемся с основными понятиями механизма AAA. Для примера будем использовать процесс законного проникновения в помещение с контролем доступа.

Аутентификация (authentication) – определение личности того, кто пытается проникнуть в помещение. В нашем примере это может быть сканирование отпечатка пальца, ведь у каждого человека он уникален и может являться гарантом подтверждения личности. В сетевом мире стандартная аутентификация заключается в использовании логина и пароля, которые сгенерированы для каждого пользователя и позволяют ему подтвердить свою личность.

Авторизация (authorization) – следующий шаг после успешной аутентификации. Заключается в проверке прав доступа к помещению того человека, который прошел аутентификацию. Возможно, у человека есть право проникнуть в первое помещение, но запрещено прохождение дальше.

На сетевых устройствах права доступа чаще всего определяют перечень команд, которые может выполнить пользователь, прошедший аутентификацию. Например, сетевому инженеру с 1-м уровнем доступа разрешен только просмотр конфигурации устройства с помощью команды show, а инженеру с 2-м уровнем доступно внесение изменений. На AAA-серверах операторов связи право доступа может определять принадлежность абонента к какому-либо тарифному плану.

Учет (аccounting) – параллельный с аутентификацией и авторизацией этап, который записывает в журнал успех или неудачу данных процессов, смог человек проникнуть в помещение или нет, получил ли пользователь доступ к сетевому устройству и, если да, то какие действия на нем совершал. Этот процесс важен с точки зрения безопасности и контроля доступа, так как позволяет определять потенциальные угрозы и искать «дыры» в системе.

На практике в сетях операторов связи AAA-процесс выглядит следующим образом:

1. Абонент подключается к устройству доступа AGW (Access Gateway) или Network Access Server (NAS) и вводит свой логин и пароль.
2. AGW (NAS) формирует и посылает запрос аутентификации к AAA-серверу и ожидает ответ.
3. AAA-сервер обращается к DPI-системе или серверу биллинга по протоколу RADIUS для проверки логина абонента и пароля.
4. AAA-сервер формирует ответ и отсылает его обратно на AGW (NAS).
5. Если аутентификация пройдена, то AGW (NAS) пропускает абонента в сеть, но пока еще не предоставляет ему никаких услуг.
6. Если пользователь пытается выйти в Интернет (вводит URL в строке браузера), AGW (NAS) формирует новый запрос AAA-серверу для авторизации.
7. ААА-сервер вновь обращается к DPI-системе или серверу биллинга, чтобы получить информацию о тарифном плане и подключенных абоненту услугах.
8. Получив положительный ответ от биллинга, ААА-сервер посылает ответ на AGW (NAS), и абонент получает доступ к Интернету в соответствии с настройками, установленными для тарифного плана.

О применении СКАТ DPI для тарификации и политик абонентов мы рассказывали в статье про реализацию L3 BRAS, но вскоре остановимся на этой функции подробнее.

RADIUS

Протокол RADIUS является IETF-стандартом для AAA. Используется с начала 1990-х годов и первоначально применялся для коммутируемых модемных соединений. Изначально использовался для расширения Layer 2 протокола точка-точка (PPP) между конечным пользователем и сервером доступа к сети (NAS), передавая трафик аутентификации с NAS на AAA-сервер. Сведения от аутентификации и авторизации доставляются одним типом пакетов, а учет обрабатывается отдельным процессом. RADIUS имеет широкое распространение и поддерживается большинством производителей устройств и разработчиков программных продуктов.

Современная реализация RADIUS использует порты 1812 (аутентификация) и 1813 (учет) протокола UDP (также возможно использование портов 1645 и 1646). UDP обладает высокой скоростью, но имеет ряд недостатков, которые необходимо учитывать при его применении. Когда разрабатывали RADIUS, вопросы безопасности не были столь актуальны, как сейчас, поэтому он поддерживает довольно малое число типов аутентификации (Clear text и CHAP), шифрует только поле с паролем и в целом имеет среднюю степень безопасности.

TACACS+

Данный протокол разработан компанией Cisco и является развитием прошлых версий TACACS и XTACACS. Несмотря на схожесть названий, TACACS+ был сильно видоизменен и не имеет обратной совместимости с TACACS, который сейчас практически нигде не применяется. Основная сфера использования TACACS+ – это администрирование сетевых устройств, однако он может применяться для некоторых типов AAA при доступе в сеть. TACACS + использует Transmission Control Protocol (TCP) порт 49, а не UDP, так как он обладает большей надежностью и позволяет заранее получать информацию о потенциальных ошибках благодаря пакету TCP-RST. ТСP более медленный протокол, но обладает дополнительными преимуществами: возможность разделения аутентификации, авторизации и учета в качестве отдельных и независимых функций, множественная авторизация после одной аутентификации, шифрование всего содержимого пакета.

Для наглядности объединим основные характеристики в таблицу:

Источник: vasexperts.ru

Radius

С Radius вы можете сообщать о разрушительном или опасном событии, происходящем вокруг вас, и спасать жизни.
Если вы находитесь в дороге и еще никого не уведомили, то приложение Radius отправит вам уведомление о том, что рядом с вами происходит одно или несколько событий, например:
— Наводнение,
— Землетрясение,
— Взрыв
— Огонь
— Ливень
— Тифон
— мародерство
— Природная катастрофа

Последнее обновление
29 мар. 2022 г.

Безопасность данных

arrow_forward

Чтобы контролировать безопасность, нужно знать, как разработчики собирают ваши данные и передают их третьим лицам. Методы обеспечения безопасности и конфиденциальности могут зависеть от того, как вы используете приложение, а также от вашего региона и возраста. Информация ниже предоставлена разработчиком и в будущем может измениться.

Источник: play.google.com

2. Radius Основные положения

Название протокола складывается из первых букв слов — Remote Authentication Dial In User Service (услуга удаленной ау­тентификации вызывающего пользователя). Это определение описывает скорее область, где чаще всего применяется протокол RADIUS: аутентификация подклю­чений пользователей к серверу для получения доступа у Оператора связи.

Разработка протокола была начата в далеком 1991 году фирмой Livingston, специализирующейся на производстве серверов удаленного доступа. Протокол оказался интересным и перспективным проектом, который заметили и взяли на доработку специалисты из Мичиганского университета. А уже оттуда документа­ция и все работы по описанию и оформлению технологии перешли в IETF.

Работы по специфиации RADIUS увенчались успехом и были оформлены в виде двух базо­вых документов [65] и [66]. С этого времени RADIUS стал и продолжает оставаться открытым стандартом, что обеспечило ему популярность среди производителей оборудования и возможность его доработки и модернизации. Сегодня RADIUS является одним из самых распространенных AAA-протоколов, используемых в се­тях самых разных Операторов связи и провайдеров телекоммуникационных услуг. Рассмотрим архитектуру, структуру организации и особенности протокола RADIUS.

Архитектура radius

RADIUS представляет собой протокол, соответствующий архитектуре «кли­ент-сервер». Обмен сообщениями производится поверх протокола транспортного уровня UDP. Заметим, что использование UDP диктует необходимость реализа­ции схем контроля доставки и повторной передачи средствами самого протокола RADIUS. Общая схема взаимодействия элементов в архитектуре RADIUS пред­ставлена на рис. 2.1.

Рис. 2.1. Архитектура протокола RADIUS

Структурными единицами, участвующими в работе протокола являются:

• RADIUS-сервер — элемент, отвечающий за прием клиентских запросов, аутентификацию и авторизацию пользователей, и возврат клиенту всех параметров, необходимых для предоставления услуги. Кроме того, он может выступать в качестве посредника (прокси) для других RADIUS- серверов или серверов иного типа.
• Сервер доступа к сети NAS (Network Access Server) выступает в качест­ве клиента протокола RADIUS, отвечает за передачу информации о поль­зователе системы RADIUS-серверу и проведение дальнейших действий в соответствии с полученным ответом.
• Пользователь — не входит в архитектуру RADIUS, но является неотъемле­мой частью всей цепи взаимодействия. Подключается к NAS для переда­чи информации авторизации, аутентификации и учета.

• Необходимость повторной передачи запроса на резервный сервер тре­бует, чтобы реализация RADIUS-протокола сохраняла копию отправлен­ного запроса на прикладном уровне. При этом возникает необходимость добавления таймеров повторной посылки. Так как повторные посылки в таком случае контролируются выше транспортного уровня, RADIUS про­ще реализуется поверх протокола UDP.
• Временные характеристики протокола UDP в значительной степени от­личаются от временных характеристик TCP. С одной стороны, RADIUS не требует «мгновенного» детектирования проблемы на транспортном уровне (то есть детектирование за время порядка десятков или даже сотен миллисекунд не требуется). Время ожидания порядка одной-двух секунд вполне устроит пользователя, выполняющего аутентификацию. В этом отношении политика повторной передачи TCP с подтверждениями транспортного уровня является избыточной для задач, выполняемых про­токолом RADIUS. С другой стороны, проблемы в сети, вызывающие рост параметра RoundTripTime (Я7Т),‘могут стать причиной слишком долгой доставки информации поверх TCP, так как механизм повторных посылок TCP протокола базируется на параметре RTT. В подобной ситуации быс­трее переслать запрос на резервный сервер поверх ненадежного прото­кола UDP и получить ответ на запрос аутентификации.
• Протокол RADIUS, как протокол без сохранения состояния, гораздо про­ще реализовать поверх UDP. В условиях «живой» сети клиенты и серверы RADIUS могут появляться и исчезать — плановые или аварийные перезаг­рузки, сетевые проблемы и прочие обстоятельства приводят к тому, что транспортные соединения TCP-протокола по разным причинам будут требовать переустановки или полного закрытия соединения. Это не явля­ется серьезной проблемой при грамотном конфигурировании процедур проверки соединений и таймеров повторных посылок, однако проще вообще исключить необходимость контроля состояния узлов в сети, ис­пользуя UDP, в котором отсутствует понятие постоянного соединения.
• UDP упрощает реализацию сервера. Ранние реализации серверов RADIUS были однопоточными, что подразумевало последовательную об­работку запросов. При росте сетевой инфраструктуры стало понятно, что однопоточные серверы не могут выдерживать нагрузку, когда время об­работки одного запроса имеет порядок секунд (при выполнении поиска в базе данных или при DNS-запросе). Переполнение очереди на обработку запросов пользователей в таком случае приведет к тому, что процедура аутентификации будет продолжаться пол минуты и более, что является неприемлемым для конечного пользователя. Очевидным выходом из сложившейся ситуации стало использование многопоточных серверов, реализация которых проще выполнялась поверх UDP. Обработка запроса производится в рамках отдельного процесса, который отвечает на дан­ный запрос UDP пакетом без какого-либо контроля ТСР-соединений.

Источник: studfile.net

Сервер RADIUS

Название RADIUS является аббревиатурой от Remote Authentication Dial In User Service и представляет собой сетевой протокол, обеспечивающий централизованную Аутентификацию (Authentication), Авторизацию (Authorization) и Учет используемых сетевых ресурсов (Accounting). В англоязычной литературе для этих трех функций (Authentication, Authorization, Accounting)используется аббревиатура ААА.

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

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

Термин Учет использованных сетевых ресурсов уже сам по себе достаточно информативен. Первичными данными, которые передаются по протоколу RADIUS, являются объемы входящего и исходящего трафиков при передаче данных, и длительность разговора и набранный номер при использовании IP телефонии. Кроме определенных в протоколе стандартных атрибутов (параметров), протокол предусматривает возможность использования производителем оборудования (вендором) собственных атрибутов. В англоязычной литературе они называются Vendor Specific Attributes или VSA.

Протокол RADIUS был разработан компанией Livingston Enterprises (конкретно Карлом Ригней/Carl Rigney) для удаленного коммутируемого доступа через сетевые сервера доступа (Network Access Server — NAS) этой компании серии PortMaster к сети internet. Позже, в 1997, протокол RADIUS был опубликован как RFC 2058 и RFC 2059. Текущие версии RFC 2865 (Remote Authentication Dial In User Service (RADIUS)) и RFC 2866 (RADIUS Accounting). Иногда вместо понятия «сетевой сервер доступа» используется другой: «удаленный сервер доступа» (Remote Access Server — RAS).

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

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

Для выяснения работы RADIUS протокола рассмотрим рисунок 5.

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

точке Wi-Fi доступа,

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

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

Пользователь посылает запрос на сетевой сервер доступа для получения доступа к определенному сетевому ресурсу, используя сертификат доступа. Сертификат посылается на сетевой сервер доступа через сетевой протокол канального уровня (Link Layer), например, Point-to-Point Protocol (PPP) в случае выполнения коммутируемого доступа, Digital Subscriber Line (DLS) — в случае использования соответствующих модемов и т.п. NAS после этого, в свою очередь, посылает сообщение запроса доступа на RADIUS сервер, так называемый RADIUS Access Request. Этот запрос включает сертификаты доступа, которые обычно представлены в виде имени пользователя и пароля или сертификата безопасности, полученных от пользователя. Кроме этого запрос может содержать дополнительные параметры, такие как сетевой адрес устройства пользователя, его телефонный номер, информацию о физическом адресе, с которого пользователь взаимодействует с NAS.

RADIUS сервер проверяет эту информацию на корректность, используя такие схемы аутентификации, как PAP, CHAP, EAP и т.п.

Кратко опишем эти протоколы.

PAP (Password Authentication Protocol) (RFC1334)- простой аутентификационный протокол, который используется для аутентификации пользователя по отношению к сетевому серверу доступа (NAS). РАР используется РРР протоколом. Практически все сервера доступа поддерживают РАР. РАР передает незашифрованный пароль через сеть и, следовательно, является незащищенным протоколом. Поэтому РАР, обычно, используется в том случае, когда сервер не поддерживает защищенные протоколы, такие как СНАР, ЕАР и т.п.

CHAP (англ. Challenge Handshake Authentication Protocol) (RFC 1994) — широко распространённый алгоритм проверки подлинности, предусматривающий передачу не самого пароля пользователя, а косвенных сведений о нём. При использовании CHAP сервер удаленного доступа отправляет клиенту строку запроса. На основе этой строки и пароля пользователя клиент вычисляет хеш-код MD5 (Message Digest-5) и передает его серверу.

Хеш-функция является алгоритмом одностороннего (необратимого) шифрования, поскольку значение хеш-функции для блока данных вычислить легко, а определить исходный блок по хеш-коду с математической точки зрения невозможно за приемлемое время. (По хешированию существует много литературы, например, можно прочесть: Хеширование). Сервер, которому доступен пароль пользователя, выполняет те же самые вычисления и сравнивает результат с хеш-кодом, полученным от клиента. В случае совпадения учётные данные клиента удалённого доступа считаются подлинными.

MD5 (Message-Digest algorithm 5) (RFC 1321) — широко используемая криптографическая функция с 128 битовым хешем. Найден ряд уязвимостей в алгоритме MD5, в силу чего в США департамент U. S. Department of Homeland Security не рекомендует использование MD5 в будущем, и для большинства правительственных приложений c 2010 года США требуется перейти на семейство алгоритма SHA-2.

Протокол EAP (Extensible Authentication Protocol) (RFC 3748) позволяет проверять подлинность при подключениях удаленного доступа с помощью различных механизмов проверки подлинности. Точная схема проверки подлинности согласовывается клиентом удаленного доступа и сервером, выполняющим проверку подлинности (им может быть сервер удаленного доступа или RADIUS сервер). По умолчанию в маршрутизацию и удаленный доступ включена поддержка протоколов EAP-TLS и MD5-Challenge (MD5-задача). Подключение других модулей ЕАР к серверу, использующему маршрутизацию и удаленный доступ, обеспечивает поддержку других методов ЕАР.

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

Схемы проверки подлинности, использующие протокол EAP, называются типами EAP. Для успешной проверки подлинности клиент удаленного доступа и сервер, выполняющий проверку подлинности, должны поддерживать один и тот же тип EAP.

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

По результатам проверки RADIUS сервер посылает NAS один из трех типов откликов:

Access-Reject показывает, что данный пользовательский запрос неверный. При желании сервер может включить текстовое сообщение в Access-Reject, которое может быть передано клиентом пользователю. Никакие другие атрибуты (кроме Proxy-State) не разрешены в Access-Reject.

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

Access Accept. Пользователю разрешен доступ. Поскольку пользователь аутентифицирован, то RADIUS сервер проверяет авторизацию на использование запрошенных пользователем ресурсов. Например, пользователю может быть доступ через беспроводную сеть, но запрещен доступ к VPN сети.

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

Access-Request: NAS-Identifier, NAS-Port, User-Name, User-Password (пароль может быть проигнорирован)

Источник: studwood.net