Мережева аутентифікація на практиці, комп'ютерна документація від а до я

Попередня ◈ Наступна

Мережева аутентифікація на практиці

Нещодавно прийнятий стандарт мережевий аутентифікації IEEE 802.1x знайшов широку підтримку у виробників мережевого устаткування і програмного забезпечення. Приклади реалізації цієї технології в ЛВС, а також її основні складові - протоколи EAP і RADIUS - в центрі нашої уваги.

Отже, протокол PPP спочатку використовувався для підключення віддалених користувачів, і тому він повинен був мати механізми аутентифікації користувачів. Спочатку підтримувалася тільки передача імені користувача або пароля в незашифрованому вигляді, що не відповідає сучасним вимогам мережевої безпеки.

Останнім часом для протоколу були розроблені нові механізми аутентифікації під загальною назвою EAP (Extensible Authentication Protocol). Протокол EAP був створений з метою скасування приватних механізмів аутентифікації і поширення стандартизованих підходів - схем типу "запит-відповідь" (challenge-response) та інфраструктури, заснованої на публічних ключах і призначених для користувача сертифікатах. Стандартизація механізмів EAP дозволила зробити процедуру аутентифікації прозорою для серверів доступу різних виробників. Наприклад, при підключенні користувача до сервера віддаленого доступу та використання механізму EAP протоколу PPP для аутентифікації сам сервер доступу не повинен знати або підтримувати конкретні механізми або алгоритми аутентифікації, його завдання в цьому випадку - лише передати пакети EAP-повідомлень RADIUS-сервера, на якому фактично проводиться аутентифікація. У цьому випадку сервер доступу виконує роль посередника між клієнтом і RADIUSсервером, в завдання якого входить передача EAP-повідомлень між ними.

Стандарт 802.1x описує процедуру передачі EAP-повідомлень сервером доступу (наприклад, комутатором або бездротовою точкою доступу) в провідних або бездротових Ethernet-мережах. При цьому стандарт 802.1x безпосередньо упаковує EAPсообщенія в Ethernet-кадри, не застосовуючи для їх передачі протокол PPP. Це викликано тим, що використовувати протокол PPP в багатьох випадках не обов'язково - наприклад, при підключенні Ethernet-робочої станції, що не підтримує протокол TCP / IP, або в тому випадку, коли використання протоколу PPP є надмірною.

У стандарті 802.1x визначається три основних елементи:

  • аплікант - користувач, який потребує мережевий аутентифікації;
  • сервер аутентифікації - зазвичай RADIUSсервер, який виробляє фактичну аутентифікацію;
  • аутентифікатор - мережеве пристрій, що знаходиться між аплікантом і сервером аутентифікації і надає доступ в мережу, наприклад, точка доступу або Ethernetкоммутатор.

Ключовим моментом тут є те, що мережеві пристрої - аутентифікатор - можуть бути досить простими, оскільки для реалізації функцій 802.1x в них потрібні мінімальні апаратні витрати, в той час як весь інтелект концентрується в RADIUS-сервері. Така схема має додаткові вигоди і дозволяє організувати тісну інтеграцію управління мережевим обладнанням і мережевим ПЗ, що значно полегшує управління інформаційною системою великого підприємства в цілому. Протокол передачі EAP-повідомлень в стандарті 802.1x називається EAPOL (EAP encapsulation over LAN) і в даний час визначено для Ethernet ЛВС, а також бездротових мереж стандартів серії IEEE 802.11 і ЛВС, що використовують технології token ring і FDDI.

Схема роботи протоколу EAPOL досить проста. При цьому можна виділити наступні основні режими роботи:

  1. Аутентифікатор надсилає запит на аутентифікацію (EAP-Request / Identity) апліканта, як тільки він визначить, що якийсь із його Ethernetпортов перейшов в активний стан (link active), тобто до нього підключений мережевий адаптер. Таким чином, якщо відключити клієнтську станцію, яка вже пройшла аутентифікацію, і знову підключити до порту, то буде потрібно пройти аутентифікацію ще раз.
  2. Аплікант посилає повідомлення / відповідь (EAPResponse / Identity) аутентифікатору, яке потім передається їм на сервер аутентифікації (RADIUS).
  3. Сервер аутентифікації у відповідь відсилає пакет-запит (challenge) аутентифікатору, який потім переупаковують його з IP-транспорту в EAPOL і передає апліканта. У різних схемах аутентифікації число таких повідомлень може змінюватися. У EAP підтримується як аутентифікація клієнтської сторони, так і взаємна "сильна" аутентифікація клієнта і сервера, але тільки останній варіант вважається прийнятним для використання в бездротових мережах.
  4. Аплікант відповідає на запит відповідно до обраного алгоритму і передає його аутентифікатору, який пересилає його на сервер аутентифікації.
  5. У разі, якщо аплікант надає правильну відповідь на запит, сервер посилає повідомлення про успішну аутентифікації апліканта. У цій ситуації аутентифікатор відкриває клієнту доступ до ЛВС, який може залежати від додаткових параметрів, переданих йому RADIUS-сервером, наприклад, від номера VLAN або певного рівня якості обслуговування.

Таким чином, використання мережевої аутентифікації дозволяє надавати користувачеві певний номер ВЛВС або рівень якості обслуговування незалежно від точки підключення в корпоративну ЛВС. Це забезпечує як мобільність користувачів, так і постійне дотримання профілю безпеки мережі - якщо навіть мережеві кабелі будуть випадково переплутані, користувач не зможе увійти в ВЛВС, доступ до якої йому заборонений.

Комутатор 3Com SuperStack 3 Switch 4400 використовувався нами для побудови ЛВС з мережевої аутентифікації по протоколу 802.1X

Розглядаючи реалізацію мережевої аутентифікації по протоколу IEEE 802.1x, необхідно розкрити основні особливості протоколу RADIUS, який є одним з головних компонентів даної системи.

Радіус в центрі

Протокол RADIUS часто використовується в різних мережевих пристроях (маршрутизатори, модемні стійки, комутатори і т.д.) для аутентифікації користувачів. Основною причиною цього є те, що мережеві пристрої мають зазвичай дуже обмежені апаратні ресурси і не можуть зберігати в пам'яті інформацію про велику кількість користувачів.

Протокол RADIUS забезпечує централізоване управління користувачами, що дуже важливо в цілому ряді випадків. Наприклад, Iнтернет-можуть мати десятки і навіть сотні тисяч користувачів, і розмістити такий обсяг інформації в пам'яті будь-якого мережевого пристрою просто неможливо. При цьому число користувачів може постійно змінюватись протягом доби, дня або години. Саме тому необхідно мати централізовану базу даних, де зберігається інформація про всіх користувачів. Слід зазначити, що протокол RADIUS підтримується практично всіма виробниками мережевого устаткування, в той час як інші протоколи аутентифікації віддалених користувачів не отримали масової підтримки з боку виробників.

Протокол RADIUS також має вбудовані механізми захисту від цілого ряду мережевих атак, включаючи використання мережевих сніфера для отримання паролів користувачів. Основними суперниками RADIUS на поле віддаленої аутентифікації є протоколи TACACS + і LDAP. Протокол LDAP спочатку не має ніяких засобів захисту від сніфінга паролів, і хоча в протоколі TACACS + (на відміну від RADIUS) шифрується весь трафік, а не тільки паролі, він також не позбавлений ряду слабких сторін.

Структура повідомлення протоколу RADIUS представлена ​​на рис. (RFC 2138), а значення і розшифровка поля Сode - в таблиці під малюнком.

Поле Identifier довжиною один байт встановлюється RADIUS-клієнтом у відповідь на запит RADIUS-сервера. Поле атрибутів містить ім'я користувача та пароль і також дозволяє передавати додаткові дані про клієнта від RADIUS-сервера мережевих пристроїв, до яких безпосередньо підключені користувачі.

А тепер поговоримо про основні режимах функціонування протоколу RADIUS: про запит доступу (Access-Request), в якому передається пароль та ім'я користувача, після чого він супроводжується передачею повідомлень дозволу або відмови в доступі (Access-Accept, Access-Reject). Далі для зручності будемо називати боку, беруть участь в процесі аутентифікації, "клієнт" і "сервер". Сервер містить базу даних користувачів і проводить їх аутентифікацію.

Для проходження аутентифікації на сервері клієнт створює запит доступу (Access-Request) і передає його RADIUS-сервера, поле атрибутів даного повідомлення повинно включати як мінімум ім'я користувача і пароль. Поле ідентифікації запиту доступу також створюється клієнтом. Цей процес не регламентується в самому протоколі RADIUS, але зазвичай поле реалізується як простий лічильник, який збільшується на 1 при кожному новому запиті. Запит доступу містить 16-байтное поле запиту аутентифікатора (Request Authenticator), яке генерується випадковим чином. Дане повідомлення в цілому не захищене, шифруються тільки поля атрибутів, що містять ім'я користувача і пароль. Для цього клієнт і сервер мають загальний секрет. Загальний секрет спільно з полем запиту аутентифікатора використовується для обчислення 16-байтного значення (за допомогою хеш-функції MD5), яке потім завдяки логідіняется з паролем користувача.

Після отримання повідомлення запиту доступу RADIUS-сервер перевіряє, чи володіє він загальним секретом з клієнтом, і якщо немає, то повідомлення просто скидається без повідомлення клієнта. Оскільки сервер також володіє загальним секретом з клієнтом, він може обчислити незашифроване ім'я і пароль клієнта (через проходити зворотній процес вище). Потім ім'я і пароль звіряються з призначеною для користувача базою даних.

У разі успішної перевірки імені та пароля користувача сервер створює повідомлення дозволу доступу і передає його користувачеві, в зворотному випадку він отримує повідомлення про відмову в доступі. Обидва повідомлення мають однакові номери ідентифікаторів, рівні номеру ідентифікатора в запиті доступу клієнта. Поле відповіді аутентифікатора (Response Authenticator) обчислюється за допомогою застосування хеш-функції MD5 над полями запиту аутентифікатора і полями пакета дозволу доступу.

Додаємо користувачів в Active Directory

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

А тепер варто докладніше розповісти про практичну реалізацію схеми мережевої аутентифікації 802.1X.

налаштовуємо 802.1X

Для реалізації схеми мережевої аутентифікації 802.1X як RADIUS-сервера іспользоента - Windows XP (про реалізацію 802.1X-клієнтів в інших операційних системах см. Вставку на с. 38), а в якості сервера доступу - комутатор 3Com Superstack 3 Switсh 4400.

Далі слід додати кілька користувачів, яким буде дозволено доступ до мережі (рис. Зліва). Після того як користувачі будуть створені, необхідно встановити, щоб їх паролі зберігалися з так званим "реверсним шифруванням" (reversible encryption). Для цього у властивостях користувачів треба вибрати закладку Account і встановити поле Store password using reversible encryption. Після цього необхідно обов'язково повторно ввести пароль для даного користувача.

Встановлюємо тип аутентифікації: MD5 або Certificate

Слід враховувати, що в RFC 2865 пропонується використання 16 символів в "загальному ключі". При цьому для досягнення ентропії (в теорії інформації ентропія відображає кількість інформації в послідовності символів), що дорівнює 128 біт, кожен окремий символ повинен мати ентропію 8 біт.

Однак в разі, коли вибір символів обмежується набором, що вводиться на клавіатурі, ентропія 8-бітного символу зменшується до 5,8 біт. Тому щоб добитися рівня ентропії в 128 біт, необхідно використовувати як мінімум 22 символу.

Налаштовуємо комутатор 3Com 4400 для роботи з 802.1X

Перевіряємо роботу служб аутентифікації на клієнтському ПК

Заключним етапом є налаштування комутатора 3Сom 4400 для роботи з RADIUSсервером. Для цього, підключившись до консольного порту даного пристрою і використовуючи какуюлибо термінальну програму, слід в режимі командного рядка увійти в текстове підменю Security / Radius і виконати команду Setup).

За допомогою журналу подій перевіряємо параметри аутентифікації

Входимо в мережу

Якщо всі налаштування пройшли успішно, вводимо логін і пароль для доступу в мережу

Тепер, якщо вами не були допущені помилки на якомусь з етапів, при спробі доступу до мережевих ресурсів на клієнтській машині з'явиться спеціальна заставка (рис. Вище), що пропонує ввести ім'я користувача / домену та його пароль. Якщо ці параметри введені правильно, то користувач отримує доступ до мережевих ресурсів. Необхідно враховувати, що навіть при короткостроковому відключенні мережевого кабелю від порту комутатора і підключенні його знову користувачеві доведеться повторно пройти мережеву аутентифікацію.

Після того як користувачі успішно автентифіковані в мережі за допомогою протоколу 802.1х, можна перейти до автоматичної настройки номера VLAN і параметрів якості обслуговування для кожного користувача.

Налаштовуємо функції авто * QoS / VLAN

А тепер повернемося до політиків, визначеним у налаштуваннях служби IAS. Як уже згадувалося, було визначено дві політики - vlan1 і demo. Ці назви не випадкові, так як ми хочемо, щоб користувачі, які потрапляють під дію політики vlan1, автоматично опинялися в віртуальної ЛВС під номером 1. У цьому випадку у властивостях даної політики в розділі Advanced необхідно додати наступні параметри і встановити їх значення, які автоматично повертаються комутатора RADIUS-сервером при успішної аутентифікації користувача:

  • Tunnel-Medium type - 802;
  • Tunnel-Pvt Group ID - 1 (номер VLAN);
  • Tunnel-Type - (VLAN).

Останнім етапом є налагодження аутентифікації не тільки користувачів через RADIUSсервер, але і адміністраторів, що підключаються до комутатора через консольний порт або Web / Telnet. Для цього в настройках комутатора (security / device) необхідно дозволити аутентифікацію за допомогою RADIUS (enable RADIUS auth).

Далі в Active Directory треба створити користувача, якому дозволено доступ до управління пристроєм, наприклад, admin, і визначити для нього в IAS політику, в якій необхідно встановити, щоб RADIUS-сервер повертав комутатора при успішної аутентифікації параметр Vendor Specific Attribute. У властивостях даного поля необхідно встановити код виробника 43 (3Com), номер атрибуту (1) і десяткове значення цього атрибута від 1 до 3:

  • Monitor (1) дозволяє користувачеві проводити моніторинг установок комутатора;
  • Manager (2) дає можливість виробляти зміна окремих установок комутатора;
  • Administrator (3) дає користувачеві повний доступ до установок комутатора.

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

В цілому ж можна констатувати той факт, що з впровадженням технології 802.1x збуваються мрії системного адміністратора - тепер не треба встановлювати мережеві параметри для сотень і навіть тисяч користувачів вручну. При цьому перевести користувача з однієї VLAN в іншу можна одним рухом мишки без необхідності зміни налаштувань мережевих пристроїв. І це крім того, що протокол 802.1x допомагає значно підвищити рівень безпеки самої мережі, захистивши її від несанкціонованого доступу.

Попередня ◈ Наступна