Спачатку метад 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Аўтэнтыфікацыя ўліковага запісу таксама не вырашае аўтарызацыю. Членства ў групах, стан прылады і дазвол на сетку ўсё яшчэ патрабуюць яўнага супастаўлення пасля таго, як карыстальнік даказаў патрэбную ідэнтычнасць. Злучэнне, якое бездакорна аўтэнтыфікуецца і нічога не аўтарызуе, — гэта вынік палітыкі, а не памылка метаду.