Спершу метод EAP: який хеш пароля може використовувати VPN
VPN перевіряє сам секрет, а не вебхеш. Прочитайте метод, а потім перевірте, що зберігає сховище, перш ніж обіцяти, що ті самі паролі працюватимуть далі.
Багато команд мають робочий вебвхід і VPN, який відхиляє кожен пароль із тієї самої таблиці. Вебзастосунок порівнює хеш, який він обчислив сам, тоді як тунель вимагає від клієнта довести володіння секретом так, щоб сервер міг це перевірити. Це різні вимоги до збереженого матеріалу. Саме в розриві між ними більшість таких проєктів і застрягає.
Спочатку метод, потім схема
Запишіть, який доказ вимагає обраний метод, перш ніж дивитися на будь-яку схему. Методу «запит — відповідь» потрібен матеріал, з якого сервер може обчислити очікувану відповідь, а це на практиці означає пароль або сумісну похідну форму. Методу, який несе пароль усередині захищеного тунелю, потрібен сам пароль у перевіряча. Читайте документацію методу заради вимоги до перевіряча, а не заради конфігурації клієнта, бо вимоги клієнта зазвичай легка частина.
Солоний хеш, створений сучасним вебфреймворком, не дає ні того, ні іншого. Він перевіряє одне конкретне порівняння і не може бути повернутий назад у секрет, з якого постав.
«Запит — відповідь» не може використовувати солоний хеш
MSCHAPv2 — це обмін «запит — відповідь», тому сервер ніколи не отримує пароль і не може порівняти збережений рядок. Він має вивести очікувану відповідь із матеріалу, який уже має, і саме тому сумісні збережені форми такі вузькі. Значення bcrypt або Argon2 із сіллю на користувача є одностороннім настільки, що повністю виключає обмін. Таблиця нижче починається з форми зберігання, а не з назви методу, бо відповідь визначає сама форма зберігання.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
Документація плагіна SQL для strongSwan визначає власну схему для конфігурації та облікових даних, і проєкт досі позначає цей плагін як експериментальний. Ніщо в ній не пристосовується до таблиці користувачів застосунку і не вгадує, яка схема хешування створила збережене значення. Тож реалістичні варіанти — міграція до сховища, яке шлюз може використовувати, або служба автентифікації перед наявним сховищем, здатна виконати обмін. Усе інше — це конектор із прихованим припущенням усередині.
RADIUS переносить роботу, а не вимогу
Делегування EAP серверу RADIUS змінює місце перевірки і зазвичай покращує слід аудиту. Воно не відновлює пароль з одностороннього хешу, тому службі автентифікації все ще потрібен матеріал, сумісний з методом, який вона завершує. Команди дізнаються про це після того, як збудують шлях через RADIUS і натраплять на ту саму стіну з іншого боку.
Там, де сервер RADIUS може читати каталог із сумісними обліковими даними, рішення працює, а VPNшлюз лишається простим. Там, де не може, чесна відповідь — зміна реєстрації, а не ще один конектор. Надання й відкликання належать тому, хто володіє ідентичністю, тому скопійована таблиця без підтримуваного процесу синхронізації — це другий життєвий цикл облікових даних, а не єдиний вхід. Вона розходиться першого разу, коли хтось скидає пароль лише в одному місці, і ця розбіжність непомітна, доки обліковий запис, що існує в обох системах, не почне поводитися по-різному в кожній.
Обмежте обліковий запис, який читає каталог, лише цим читанням і тримайте його окремо від запису, який шлюз використовує для власної конфігурації. Спільний адміністративний запис перетворює схему лише для читання на значно ширший радіус ураження.
Де має жити обліковий запис
Коли питання про матеріал вирішено, залишаються дві архітектури. Шлюз може володіти невеликим сховищем облікових даних, яке читає лише він, або делегувати службі автентифікації, що стоїть перед корпоративним каталогом.
Перша простіша для осмислення і гірша для користувача, якому лишається другий пароль для обслуговування. Друга зберігає одну ідентичність і додає залежність від служби, яка тепер має працювати до того, як хтось підключиться. Жодна не є помилковою, але вибір варто записати поруч із конфігурацією шлюзу, інакше наступний інженер припустить, що обрано іншу. Що б ви не обрали, дві команди нижче показують поточний стан до його зміни.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsАвтентифікація облікового запису також не вирішує авторизацію. Членство в групах, стан пристрою й мережевий дозвіл усе ще потребують явного зіставлення після того, як користувач довів потрібну ідентичність. З'єднання, яке бездоганно автентифікується і нічого не авторизує, — це результат політики, а не дефект методу.