Перейти до основного вмісту

Багатофакторна автентифікація RADIUS для VPN та Wi-Fi: TOTP 2FA з сервером RADIUS Casdoor

· Читання за 10 хв
Yang Luo
Yang Luo
Casdoor Maintainer

Щоб налаштувати багатофакторну автентифікацію перед VPN з використанням RADIUS, шлюз VPN надсилає ім'я користувача та пароль на RADIUS-сервер за допомогою PAP; сервер перевіряє пароль і відповідає повідомленням Access-Challenge; клієнт показує запит, і користувач вводить код 2FA з додатка-автентифікатора у другому запиті. Casdoor поставляється з RADIUS-сервером, який робить саме це для користувачів із налаштованим TOTP, тому шлюз, здатний показати запит Access-Challenge (FortiGate SSL VPN — один із тих, чиї вендори це документують), отримує комбінацію пароля та коду 2FA без будь-якого додаткового програмного забезпечення. Wi-Fi з WPA2/WPA3-Enterprise працює інакше: 802.1X використовує EAP, де немає місця для введення коду вручну, тому в Casdoor є перемикач для пропуску коду для таких клієнтів.

Якщо вам потрібна базова інформація про RADIUS та його порівняння з LDAP для мережевих пристроїв, спершу прочитайте RADIUS vs LDAP. Ця стаття присвячена частині MFA: що передається по дроту, які клієнти можуть підтримувати другий фактор автентифікації та як увімкнути це в Casdoor.

Які клієнти можуть використовувати RADIUS MFA з Casdoor​

У таблиці наведено те, що документує кожен вендор. "Підтримка Challenge" означає, що клієнт показує користувачу запит Access-Challenge і надсилає відповідь назад. Там, де перевірена нами сторінка вендора не містить цієї інформації, в таблиці зазначено це явно, замість того щоб припускати.

КлієнтМетод автентифікації RADIUS для використання з CasdoorПідтримка Access-ChallengeПримітки
FortiGate SSL VPNPAP (встановіть метод PAP або залиште Default, який спершу пробує PAP)Так, згідно з документацією FortinetFortinet зазначає, що SSL VPN пересилає challenge клієнту та чекає на відповідь
FortiGate IPsec VPN (включаючи FortiClient)PAPНе пересилається за замовчуваннямРішення від Fortinet вимагає MS-CHAP на RADIUS-сервері, який Casdoor не підтримує; використовуйте SSL VPN або вимкніть MFA
Cisco ASA (AnyConnect / Secure Client)PAP, стандартне значення ASA для всіх типів з'єднаньНе зазначено в посібнику з конфігурації RADIUS для ASAНе вмикайте password-management на tunnel group: це переведе ASA на MS-CHAPv2
OpenVPN Access ServerPAP (також доступні CHAP та MS-CHAPv2)Не зазначено на сторінці налаштувань RADIUSОблік (Accounting) є окремим перемикачем, порт за замовчуванням 1813
pfSense (сервер автентифікації RADIUS, використовується його OpenVPN)PAP (також MD5-CHAP, MS-CHAPv1, MS-CHAPv2)Не зазначено в документації NetgateПриклади OTP від Netgate поміщають код у поле пароля, що Casdoor не приймає
WireGuardНемаєНе застосовуєтьсяПіри автентифікуються лише публічними ключами, тому немає входу для перевірки через RADIUS
Wi-Fi, WPA2/WPA3-Enterprise (802.1X)EAP (PEAP, EAP-TTLS тощо)Немає запиту на введення кодуCasdoor не реалізує EAP; див. розділ про Wi-Fi

Якщо в комірку зазначено "not stated", протестуйте з реальним VPN-клієнтом перед розгортанням і переконайтеся, що запит з'являється, а код проходить валідацію.

Чому лише PAP може передати пароль, який перевіряє Casdoor​

RADIUS має кілька способів передачі пароля, і вони визначають, що сервер зможе перевірити.

За допомогою PAP клієнт поміщає пароль в атрибут User-Password, прихований за хешем MD5 від спільного секрету та автентифікатора запиту (RFC 2865, розділ 5.2). Сервер розшифровує його тим самим секретом, отримує пароль у відкритому тексті і може перевірити його проти збереженого хешу або прив'язки до LDAP. Casdoor читає User-Password і виконує ту саму перевірку пароля, що й на сторінці входу.

За допомогою CHAP клієнт ніколи не надсилає пароль. Він надсилає хеш пароля та випадковий виклик (challenge). У RFC 2865 чітко зазначено, що для CHAP серверу потрібен пароль користувача у відкритому тексті, щоб перерахувати цей хеш. MS-CHAPv2 має аналогічну структуру з NT-хешем. Постачальник ідентичності, який зберігає паролі як односторонні хеші (вбудована організація Casdoor використовує bcrypt), не може перевірити жоден із них. Сервер RADIUS Casdoor зчитує лише User-Password, тому запит CHAP або MS-CHAPv2 досягає його без пароля і відхиляється.

Оскільки приховування PAP базується лише на MD5 зі спільним секретом, використовуйте довгий випадковий секрет, тримайте RADIUS у приватній мережі або VPN між шлюзом і Casdoor, а також увімкніть атрибут Message-Authenticator на клієнті. Casdoor перевіряє Message-Authenticator, якщо запит містить його, і підписує свою відповідь у цьому випадку, що є захистом від Blast-RADIUS (CVE-2024-3596). Деталі описано в документації сервера RADIUS.

Access-Challenge проти додавання коду до пароля​

Існує два поширені способи передачі коду 2FA через RADIUS.

  1. Access-Challenge. Сервер перевіряє пароль, а потім відповідає повідомленням Access-Challenge, атрибутом State та Reply-Message. Клієнт відображає повідомлення, користувач вводить код, і клієнт надсилає новий Access-Request з кодом в User-Password і тим самим State. Розділ 4.4 RFC 2865 також пояснює, що відбувається на клієнті без підтримки викликів: він ЗМУШЕНИЙ трактувати Access-Challenge як Access-Reject.
  2. Код, доданий до пароля. Користувач вводить password123456 в одне поле пароля, а сервер відокремлює останні шість цифр. Це працює з будь-яким клієнтом, саме тому продукти, розроблені для старих шлюзів, пропонують такий варіант.

Casdoor реалізує лише перший метод. Ось процес у його сервері RADIUS (radius/server.go):

  • Перший Access-Request повинен містити правильний пароль. Користувач із увімкненою MFA отримує Access-Challenge, випадковий State та Reply-Message please enter OTP.
  • State дійсний протягом 120 секунд і може бути використаний лише один раз. Він прив'язаний до організації та імені користувача з першого запиту.
  • Другий Access-Request повинен містити цей State і шестизначний код TOTP з додатка автентифікатора користувача в User-Password. Casdoor перевіряє код проти секрету TOTP користувача і відповідає Access-Accept або Access-Reject.
  • Неправильні коди враховуються в ліміті невдалих входів додатка користувача (за замовчуванням 5 спроб і блокування на 15 хвилин), окремо від неправильних паролів.

Звідси випливають два наслідки. Клієнт, який може тільки надсилати "пароль плюс код в одному полі", зазнає невдачі, оскільки Casdoor перевіряє весь рядок як пароль. І через RADIUS працює лише TOTP: коди SMS та електронної пошти потребують того, щоб Casdoor надіслав повідомлення після кроку з паролем, чого сервер RADIUS не робить. Користувач, єдиним методом MFA якого є SMS або електронна пошта, отримає виклик, а потім відмову, тому налаштуйте для користувачів RADIUS додаток автентифікатора.

Wi-Fi: 802.1X і WPA-Enterprise​

У Wi-Fi з WPA2-Enterprise або WPA3-Enterprise точка доступу сама не збирає пароль. Вона ретранслює діалог EAP між пристроєм (supplicant) і сервером RADIUS, а RADIUS передає пакети EAP в атрибутах EAP-Message. У такій конфігурації Access-Challenge вже використовується: кожен обмін даними в діалозі EAP — це пара Access-Request і Access-Challenge (RFC 3579). RFC 3579 також стверджує, що повідомлення, яке містить EAP-Message, не повинно включати Reply-Message, тому немає поля для "please enter OTP" і немає діалогу на телефоні чи ноутбуці для введення коду.

Два практичні моменти для Casdoor:

  • Сервер RADIUS Casdoor не реалізує EAP. Точка доступу не може спілкуватися з ним безпосередньо для WPA-Enterprise. Вам потрібен сервер EAP попереду, який завершує тунель TLS і пересилає простий запит PAP. FreeRADIUS може це зробити з EAP-TTLS і PAP як внутрішнім методом, проксуючи внутрішній запит до іншого сервера RADIUS, а пристрої мають бути налаштовані на TTLS з PAP всередині. PEAP з MS-CHAPv2, типовий варіант на багатьох пристроях, не працюватиме з Casdoor з причини, наведеної в розділі про PAP.
  • Для таких користувачів увімкніть Skip MFA for RADIUS в організації. Тоді Casdoor прийматиме користувачів із MFA лише після перевірки пароля. MFA на веб-сторінці входу не зазнає змін.

Порти, спільний секрет і облік​

RFC 2865 призначає UDP-порт 1812 для автентифікації RADIUS, а RFC 2866 призначає 1813 для обліку. Casdoor прослуховує один UDP-порт, radiusServerPort, і обробляє там і Access-Request, і Accounting-Request. Тому спрямовуйте облік шлюзу на той самий порт, що й автентифікацію (за замовчуванням 1812), а не на 1813, інакше пакети обліку нікуди не потраплять. Якщо Casdoor працює в контейнері, опублікуйте порт як UDP, наприклад -p 1812:1812/udp.

Спільний секрет є одним значенням для всіх клієнтів, radiusSecret. Кожен шлюз, який спілкується з Casdoor, використовує його.

Для обліку Casdoor записує повідомлення Start, Interim-Update та Stop у своїй базі даних (таблиця radius_accounting) разом з ID сесії, часом сесії, адресою NAS, IP-адресою кадрування та лічильниками байтів і пакетів. Він робить це лише для організацій з увімкненим RADIUS.

Налаштування Casdoor​

1. Налаштуйте параметри RADIUS. У conf/app.conf або як змінні середовища з тими самими іменами:

radiusServerPort = 1812
radiusDefaultOrganization = "my-company"
radiusSecret = "a-long-random-string-shared-with-the-gateway"

radiusDefaultOrganization — це організація, яку Casdoor використовує, коли запит не містить атрибута Class. Якщо ваш шлюз не може додати атрибут Class до своїх запитів, цей параметр визначає, користувачі якої організації входитимуть через RADIUS. Усі ключі перелічені в довіднику конфігурації.

2. Увімкніть RADIUS для організації. На сторінці редагування організації увімкніть Enable RADIUS. За замовчуванням він вимкнений, і змінити це можуть лише глобальні адміністратори. Поки він вимкнений, Casdoor відхиляє кожен запит Access-Request для цієї організації та ігнорує її облік.

3. Визначтеся з MFA для RADIUS. Залиште Skip MFA for RADIUS вимкненим для VPN-шлюзів, які підтримують Access-Challenge. Увімкніть його для організації, чий RADIUS-клієнти не можуть відповідати на виклик (challenge), наприклад, для Wi-Fi WPA-Enterprise.

4. Налаштуйте користувачів на TOTP. Користувачі налаштовують додаток автентифікації зі своєї сторінки профілю, як описано в багатофакторна автентифікація. Щоб зробити це обов'язковим, додайте елемент TOTP із правилом Required у розділі елементи MFA організації. Зверніть увагу на послідовність: користувач, якому ще потрібно налаштувати обов'язкову MFA або спочатку змінити пароль, буде відхилений через RADIUS, доки він не завершить це на сторінці входу Casdoor.

5. Протестуйте з командного рядка. radclient від FreeRADIUS надсилає запити PAP і виводить відповідь:

echo 'User-Name = "alice", User-Password = "her-password"' \
  | radclient -x casdoor.example.com:1812 auth a-long-random-string-shared-with-the-gateway

Для користувача з TOTP ви повинні побачити Access-Challenge з параметром State та Reply-Message. Надішліть код назад із цим State протягом 120 секунд:

echo 'User-Name = "alice", User-Password = "123456", State = 0x...' \
  | radclient -x casdoor.example.com:1812 auth a-long-random-string-shared-with-the-gateway

Вставте значення State з першої відповіді замість 0x.... Access-Accept означає, що налаштування правильні, і наступним кроком є шлюз.

Якщо ви також хочете, щоб Casdoor використовував зовнішній сервер RADIUS як другий фактор для власного веб-входу, це протилежний напрям, і він охоплений у статті про провайдера MFA RADIUS.

Посилання​