Виконання налаштування обраного методу.
RADIUSPicking Auth-TypeAuthenticating
Ось мій вільний переклад цієї статті, за достовірність не ручаюсь.
І про всяк випадок синхронізує терміни:
Клієнт в даному контексті (з точки зору RADIUS-сервера) - це точка доступу.
Користувач (supplicant) - той, хто хоче отримати доступ в мережу використовуючи точку доступу.
Більшість проблем з конфігурацією пов'язані з нерозумінням концепції FreeRADIUS. Редагування конфігураційних файлів і перебір можливих опцій не допоможе зрозуміти концепцію.
Ні ви, ні радіус не знає і не вирішує, що клієнт вам пришле в запиті. Відповідальність за те, що міститься в запиті лежить 100% на клієнті.
Радіус сервер дивиться на запит і каже:
Відповідь на це питання залежить від того, які типи аутентифікації ви включили, що сервер може знайти в базі даних, і що міститься в запиті.
У якийсь момент один з модулів скаже:
Якщо модуль думає, що у нього є шанс щоб ще і аутентифицировать користувача, він скаже:
Якщо модуль нічого не розпізнає, чи знає, що немає необхідності щось шукати, то він просто нічого не робить.
Давайте припустимо, що клієнт відправив запит з атрибутом User-Password, і модуль pap включений в секції autorize <>. Тоді pap модуль встановить Auth-Type = pap.
Таким чином, сервер знову звернеться до модуля pap, але вже на стадії аутентифікації (вона також має свою секцію в конфіги authenticate <> ), Pap відповість:
Отже, потім йде порівняння локального заздалегідь відомого правильного пароля з тим, який ввів користувач (прийшов в запиті). Це те, як працює аутентифікація.
«Правильний» пароль (заздалегідь відомий правильний пароль) був доданий іншим модулем. Наприклад, модуль pap просто виконує PAP аутентифікацію і нічого більше. Переваги такого підходу в тому, що «правильний» пароль може бути доданий в запит з текстового файлу users. SQL. LDAP. / Etc / passwd. зовнішньої програми і т.д. і т.п. в дуже широких межах.
Наприклад, якщо підключений модуль LDAP в секції authorize <>. і сервер обробляє запит, то якщо модуль знайде у себе запис з паролем (де-небудь в каталозі LDAP), то він додасть цей пароль в запит, щоб інший модуль на етапі аутентифікації міг використовувати його.
Що, якщо клієнт відправить MSCHAP запит? Що буде з цим запитом робити радіус-сервер?
Але сервер вже вичерпав варіанти, його єдиний варіант був mschap, так як це те, що клієнт послав в запиті. Mschap модуль не зміг нічого зробити, тому що йому не надали «правильний» пароль. Таким чином сервер через брак варіантів запит відхиляє. MSCHAP дані могли бути коректними, але у сервера не було способу переконатися в цьому. Тому він відповів відмовою.
FreeRADIUS організований за модульним принципом. Для того щоб FreeRADIUS мав підтримку того чи іншого протоколу, потрібно підключити / відключити модуль в конфігурації. Багато, якщо не всі модулі мають свою секцію конфігурації в загальному конфіге.
Методи аутентифікації налаштовуються в секції authenticate <>. Тут запит надходить в модуль, який заданий в атрибуті Auth-Type. На підставі даних вставлених в запит з модуля-сховища ще на попередньому етапі відбувається порівняння атрибутів прийшли від клієнта з атрибутами зі сховища. На підставі цього порівняння вже приймається рішення про дозвіл або відхилення доступу, або про уточнення параметрів у клієнта.
Ось така концепція у радіус-сервера, в даному випадку до неподобства спрощена.
На наявних бездротових маршрутизаторах TP-Link TL-WR842ND із заводською прошивкою у нас є можливість використовувати такі типи захисту: WPA2-PSK, WPA2-Enterprise. Решта варіанти не розглядалися через їх неактуальність: відкрита мережа не відповідає поставленій меті; WEP - давно скомпрометований; WPA-PSK / Enterprise - є ж WPA2 c більш суворим підходом до шифрування.
WPA2-Enterprise підтримує ряд методів аутентифікації EAP. Для Window актуальні EAP-TLS і EAP-PEAPv0. EAP-TLS - допоможе позбавити користувача від введення логіна і пароля, але тут постане інше завдання з розгортання інфраструктури відкритих ключів та розподілу сертифікатів. Причому постане проблема установки сертифікатів на мобільних пристроях. Хоч даний метод найнадійніший, але через складність розгортання і супроводу для наших потреб він відпадає.
EAP-PEAPv0 з MS-CHAPv2 - від користувача потрібно довіру до точки доступу / сервера і знання зв'язки логін / пароль. Довіра до точки доступу / сервера досягається перевіркою висунутого сервером сертифіката, або відключенням цієї перевірки. Суть методу полягає в створенні захищеного тунелю всередині якого здійснюється аутентифікація користувача за методом MS-CHAPv2. Просте розгортання та супровід, особливо якщо сліпо довіряти точки доступу / сервера. Але страждає безпеку від «активних» зловмисників.
Слід зазначити, що наведені команди і фрагменти конфігурації тестувалися на Debian 7.5 c FreeRADIUS 2.1.12 + dfsg-1.2
2.1 Створення production-сертифікатів
Так як більшість методів корпоративного WPA2 вимагають наявності сертифіката та закритого ключа як мінімум на сервері, то доведеться його створити. Щоб створити самоподпісанний сертифікат нам потрібен сертифікат і закритий ключ власного засвідчувального центру, які теж доведеться створити.
Інструменти для створення сертифікатів потрібних freeradius у Debian лежать по шляху / usr / share / doc / freeradius / examples / certs. Вміст цього каталогу слід скопіювати в / etc / freeradius / certs. Необхідні файли:
А також можна скопіювати README, в якому розписано що і навіщо потрібно і як цим користуватися, тому далі підуть необхідні команди з короткими поясненнями, за більш детальною інфою в README.
Для роботи скриптів знадобиться openssl і make.
Створюємо файл з параметрами Діффі-Хеллмана, якщо він раптом відсутній в каталозі / etc / freeradius / certs:
Результат роботи: файл dh
Створюємо кореневий сертифікат або сертифікат засвідчує центру. Якщо до цього вже були якісь сертифікати (зазвичай тестові), то видаляємо:
Редагуємо під себе файл ca.cnf. Слід звернути увагу на default_md = md5 (краще поставити sha1), default_days = 365 (можливо через рік не захочеться генерувати новий сертифікат, тоді краще ставити побільше), input_password / output_password і потрібно відредагувати під себе всю секцію [certificate_authority].
Результати роботи: ca.pem. ca.key і ca.der - сертифікат засвідчує центру, його закритий ключ і сертифікат у форматі зрозумілому для Windows відповідно.
Створення серверного сертифіката. Редагуємо під себе файл server.cnf. Слід звернути увагу на default_md = md5 (краще поставити sha1), default_days = 365 (можливо через рік не захочеться генерувати новий сертифікат, тоді краще ставити побільше), input_password / output_password і потрібно відредагувати під себе всю секцію [server]. Важливо щоб значення commonName відрізнялася від відповідного сертифіката засвідчує центру.
Результат роботи: крім інших файли server.pem і server.key - сертифікат і закритий ключ сервера.
У конфігурації шляху до сертифікатів згенерував в папці / etc / freeradius / certs прописані за замовчуванням.
2.2 Описуємо RADIUS-клієнтів (точки доступу)
Додаємо в файл /etc/freeradius/clietns.conf наступне:
2.3 Заводимо облікові дані для аутентифікації за логіном і паролем
У файл / etc / freeradius / users додаємо перший рядок такого змісту:
Для запиту з ім'ям користувача user буде перевірятися пароль і порівнюватися атрибут Calling-Station-Id. Щоб це працювало в разі ЕAP-PEAP слід в файлі /etc/freeradius/eap.conf встановити параметр сopy_request_to_tunnel = yes в секції наведеної нижче:
Досить в файл users в саме його початок додавати потрібних користувачів з параметром Calling-Station-Id. якщо облікові дані потрібні однакові, то можна їх просто повторити, наприклад:
Слід зазначити, що атрибут Calling-Station-Id вказаний у файлі users для певної пари логін / пароль також буде діяти, але його перевірка буде здійснюватися на етапі, який проходить пізніше. Так що якщо надійде запит із значенням Calling-Station-Id. Не вказано в файлі authorized_macs, то цей запит відразу відхилиться, незалежно, що зазначено в файлі users.
При зміні файлів конфігурації, в тому числі файлів users і authorized_macs потрібно примусове перечитування конфіга сигналом SIGHUP.
При змінах в конфіги radiusd.conf краще демон перезавантажити:
Щоб перевірити конфігурацію слід запускати демон в режимі налагодження:
При такому запуску можна побачити як freeradius розпарсити конфиг і побачити як він обробляє запити. Дуже допомагає при знаходженні різних проблем або при поясненні несподіваного поведінки.
У комплекті йде корисна утилитка radtest - простий RADIUS-клієнт. З нею можна проводити деякі прості тести для перевірки конфігурації. Можливий приклад використання (тестування внутрітуннельной аутентифікації по порту 18120):
Щоб в логах відображалася інформація про спроби аутентифікації слід включити наступні параметри в radiusd.conf.