Про Radius детально

1. Для аутентифікації і авторизації користувачів або організації їх обліку можна порекомендувати використовувати...
2. Розширений протокол автентифікації
3. Неправильно налаштований ЗАГАЛЬНИЙ СЕКРЕТ
4. МЕХАНІЗМ приховування
5. ЗАСТОСУВАННЯ RADIUS
6. ВИКОРИСТАННЯ RADIUS ДЛЯ ВІДДАЛЕНОГО ДОСТУПУ І VPN

Для аутентифікації і авторизації користувачів або організації їх обліку можна порекомендувати використовувати RADIUS. Тим більше, коли мова йде про великі мережах, доступ до яких дозволений чималого числа людей.

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. Ці системи призначені виключно для забезпечення обміну повідомленнями 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 відсилає для введення облікової інформації після отримання дозволу на доступ;
• Accounting-Response - "відповідь обліку". Таким чином сервер 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 - у другій). Крім того, можливе застосування RADIUS разом з PPP, протоколом передачі «точка-точка» (Point-to-Point Protocol). Результати сеансу аутентифікації між сервером доступу і чинним клієнтом передаються на сервер RADIUS, який їх потім засвідчує.

Для захисту повідомлень клієнт і сервер RADIUS володіють «загальним секретом» або, простіше кажучи, ключем. При цьому мова, як правило, йде про ланцюжок символів, наявної як на серверах, так і на клієнті RADIUS.

Розширений протокол автентифікації

Розширений протокол аутентифікації (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 стосується «загального секрету» (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, завжди повинна бути захищена одним і тим же «загальним секретом».

МЕХАНІЗМ приховування

Для шифрування пароля користувача і інших атрибутів застосовуються «загальний секрет», аутентифікатор запитів і алгоритм хешування MD5. Цю комбінацію можна назвати вершиною досконалості з точки зору надійності шифрування, що відображено і в RFC 2865 - в документі рекомендується якомога краще подбати про надійність передачі.

Прикладом кращого захисту атрибутів є застосування IPSec. У комплекті з протоколом інкапсуляції захищається корисного навантаження (Encapsulated Security Payloаd, EPS) і потужним шифрувальним механізмом, на кшталт Triple DES, можна домогтися дуже високої надійності передачі даних і конфіденційності повідомлення RADIUS.

Якщо ж спільна робота IPSec, ESP і алгоритму шифрування неможлива, у адміністратора мережі залишається ще один спосіб зменшення ймовірності злому виконаної реалізації RADIUS:

• застосування атрибутів аутентифікації повинно бути обов'язковим для всіх повідомлень із запитом доступу;
• в якості посвідчень запитів необхідно використовувати криптологічну сильні величини;
• до використання повинні допускатися тільки важко вгадувані паролі;
• для запобігання атак з перебором по словнику кращий механізм "обліку та блокування аутентифікації";
• "Загальний секрет" повинен мати ентропію, що дорівнює щонайменше 128 біт.

ЗАСТОСУВАННЯ RADIUS

Дотримання деяких принципів при введенні RADIUS в експлуатацію допоможе звести різні ризики до мінімуму. Для підвищення достовірності переданих повідомлень RADIUS рекомендується застосування IPSec і EPS. При цьому слід використовувати алгоритм шифрування Triple DES. Такий метод описаний також у документі RFC 3162. Шляхом шифрування всього повідомлення RADIUS за допомогою IPSec захищаються особливо чутливі його частини - такі, як поле посвідчення запиту в повідомленні запиту доступу - і атрибути RADIUS (наприклад, пароль користувача або атрибути ключа МРРЕ). Тому, хто зробить спробу проникнення в систему, знадобиться спочатку розшифрувати захищений ESP повідомлення RADIUS, і лише після цього він зможе аналізувати його вміст. Щоб запобігти атакам на сервер RADIUS ззовні, рекомендується встановити програмне забезпечення для аутентифікації IPSec з використанням сертифікатів. Крім цього, можливі і інші варіанти захисту, які можуть використовуватися як в сукупності з IPSec, так і окремо.

• Використовуваний "загальний секрет" повинен мати довжину не менше 32 шістнадцяткових символів або, відповідно, 22 символів клавіатури.
• Для всіх повідомлень із запитом доступу обов'язкові атрибути посвідчення повідомлення. Для клієнта RADIUS це означає, що атрибут посвідчення повідомлення потрібен і для всіх повідомлень запиту доступу. Це правило потрібно дотримуватися також у разі сервера RADIUS.
• З криптографічного точки зору неодмінною умовою є якісне посвідчення запиту.

Нижченаведені поради допоможуть в реалізації додаткового захисту аутентифікації.

• Слід користуватися ЕАР або схемами типу ЕАР з підтримкою сильних методів аутентифікації. Хороший приклад подібного методу - ЕАР-TLS. Він вимагає обміну сертифікатами між клієнтом, які намагаються отримати доступ, і сервером RADIUS. Всі повідомлення ЕАР повинні мати атрибути посвідчення повідомлення для захисту тих повідомлень запиту доступу, до яких IPSec не застосовується.
• Бажано вибирати методи аутентифікації, розраховані на двосторонню аутентифікацію. При такому підході протилежні кінцеві точки з'єднання аутентифицируют свої системи. Якщо з будь-якої сторони аутентифікація пройде невдало, то у встановленні з'єднання буде відмовлено. Прикладами подібних методів служать ЕАР-TLS і MS-CHAPv2. Так, в разі ЕАР-TLS сервер RADIUS проводить перевірку призначеного для користувача сертифіката клієнта, намагається отримати доступ, а клієнт в свою чергу - сертифіката сервера RADIUS.
• Якщо аутентифікація проводиться за допомогою РАР, то цю опцію слід відключити. При аутентифікації за допомогою одноразових паролів або токенів відбувається відкат до PAP. Але оскільки IEEE 802.1x не підтримує РАР, в подібних випадках найчастіше користуються сполуками РРР.

ВИКОРИСТАННЯ RADIUS ДЛЯ ВІДДАЛЕНОГО ДОСТУПУ І VPN

Підключення працюючого сервера RADIUS до віртуальної приватної мережі (Virtual Private Network, VPN) або віддаленого доступу (Remote Access Service, RAS) виконується порівняно просто. В операційній системі Windows 2000 для цього передбачені опції Remote Access Service (RAS) і VPN Server. Почати слід з пункту «Конфігурація сервера». Потім користувачеві допомагатимуть різні програмні експерти. Для конфігурації RAS за допомогою «Асистента налаштування для сервера маршрутизації і RAS» в меню «Пуск - Програми - Управління» потрібно вибрати пункт «Маршрутизація та віддалений доступ». Потім вказати бажане ім'я сервера, клацнути мишею на пункті «Конфігурація і активізація маршрутизації і RAS» у вихідному меню і натиснути кнопку «Далі». Адміністратору надасться можливість вибору декількох опцій (див. Малюнок 2). Він повинен вибрати пункт «cервер RAS», перейти до вікна вибору протоколу підтримки віддаленого клієнта (див. Малюнок 3) і відзначити в ньому тип з'єднання, через яке відбувається зв'язок з Intranet.

Далі необхідно вказати спосіб розподілу IP-адрес в діалоговому вікні «Розподіл IP-адрес». Якщо адміністратор вибере пункт «Автоматично», тоді сервер віддаленого доступу для розподілу IP-адрес між віддаленими клієнтами буде використовувати протокол динамічної конфігурації хоста (Dynamic Host Configuration Protocol, DHCP). З іншого боку, одну або навіть кілька спеціальних областей IP-адрес можна розподілити статично. По завершенні цього етапу з'являється вікно «Керування кількома серверами RAS». Після чого в гру вступає з'єднання з RADIUS (див. Малюнок 4). Якщо адміністратор зупинить вибір на пункті «Так, повинен використовуватися сервер RADIUS», то він зобов'язаний відразу ж уточняти перший сервер RADIUS, а при необхідності і другий (але це необов'язково). Після чого виконуються завершальні дії, і службу RAS можна запускати. Якщо застосовується сервер VPN, то конфігурацію здійснюють відповідним чином.

Роберт Шотт - незалежний автор. З ним можна зв'язатися за адресою: [email protected] .

? AWi Verlag