Чаму рэдагаванне файла .ovpn не можа ўключыць MFA на серверы

Вы дадаяце auth-user-pass у профіль, перападключаецеся, і кліент запытвае імя карыстальніка і пароль. Здаецца, што MFA уключана. Затым вы ўводзіце код з чужога ўліковага запісу або код, які састарэў дзесяць хвілін таму, і тунель усё роўна ўздымаецца. Вось сімптом: кліент змяніўся, сервер — не. Аднаразовы пароль з’яўляецца фактарам толькі тады, калі вярыфікатар на серверы вырашае, ці сапраўдны ён для той ідэнтычнасці, якая яго заяўляе.

Запыт даказвае толькі тое, што кліент запытаў, і нічога больш

Файл .ovpn — гэта дакумент на баку кліента. Ён можа сказаць кліенту запытваць уліковыя даныя, кэшаваць іх або спыніць кэшаванне. Ён не можа зарэгістраваць карыстальніка, усталяваць модуль PAM або прымусіць сервер патрабаваць другі фактар, які той зараз не правярае.

Усталяванне праграмы-аўтэнтыфікатара на тэлефон таксама не стварае гэтай сувязі. Праект Google Authenticator PAM — гэта кампанент праверкі OTP, які можа стаяць за OpenVPN; гэта не спосаб прымацаваць уваход у акаунт Google да імпартаванага профілю.

Рэгістрацыя — гэта тое, чаго профіль зрабіць не можа

TOTP патрабуе матэрыялу рэгістрацыі, агульнага паміж аўтэнтыфікатарам і яго вярыфікатарам. Шэсць лічбаў на тэлефоне — гэта вынік; насенне за імі — гэта сакрэт, і яно належыць адной ідэнтычнасці.

Такім чынам, аператару патрэбны працэс рэгістрацыі, які прывязвае правільнае насенне да правільнай ідэнтычнасці VPN, а таксама правераны шлях замены для страчанага тэлефона. Дазвол карыстальнікам загружаць файл, названы іх імем, ператварае рэгістрацыю ў магчымасць захопу ўліковага запісу, і шыфраванне загрузкі гэтага не змяняе.

Дызайн на базе PAM не абавязаны ствараць асобны ўліковы запіс Unix для кожнага карыстальніка VPN. Дакументацыя модуля падтрымлівае альтэрнатыўныя шляхі да сакрэтаў і асобны ўліковы запіс для доступу да файлаў, што з’яўляецца ідэнтычнасцю файлавай сістэмы, а не ідэнтычнасцю ўваходу, якая правяраецца.

Тыповая памылка — фіксаваны шлях да сакрэту, які заканчваецца адным імем карыстальніка, скапіяваны з прыкладу для аднаго карыстальніка. Гэта дэманстрацыя адной ідэнтычнасці, а не пошук па кожным карыстальніку, і выкарыстанне яго для кожнага запыту не дае нікому незалежна зарэгістраванага аўтэнтыфікатара. Запішыце адпаведнасць ідэнтычнасцей, абараніце файлы насення і трымайце праверкі пароля, сертыфіката і ўліковага запісу ў адным стэку аўтэнтыфікацыі.

Чытайце стэк PAM, каб зразумець, што насамрэч патрабуецца

Радок накшталт account required pam_permit.so не рэалізуе праваздольнасць уліковага запісу і не дадае фактар. Ён дазваляе гэтую стадыю кіравання ўліковымі запісамі PAM, што з’яўляецца сцвярджэннем пра стадыю, а не пра вашых карыстальнікаў.

Тое ж датычыцца ліберальных параметраў рэгістрацыі. Прыём карыстальнікаў без зарэгістраванага сакрэту можа быць свядомым выбарам разгортвання, але гэта не доказ абавязковасці MFA, і гэта трэба зафіксаваць як часовую выключэнне з датай заканчэння.

Узгадніце ўзаемадзеянне кліента з дызайнам сервера

auth-user-pass

Гэтая дырэктыва запытвае ўвод імя карыстальніка і пароля. Яна не наладжвае PAM, не стварае запіс рэгістрацыі і не паведамляе серверу, што поле пароля змяшчае значэнне TOTP. Інтэграцыя сервера і кліент павінны дамовіцца пра ўзаемадзеянне, якое разгортванне сапраўды падтрымлівае: выклік, дакументаваны фармат аб’яднаных уліковых даных або працэс, спецыфічны для прадукту.

Не дадавайце код да пароля толькі таму, што кліент паказвае адно поле. Гэта працуе толькі там, дзе плагін сервера чакае менавіта такі фармат, і ўсюды іншым разам гэта правальваецца заблытана.

Трымайце насенне і QR-матэрыял па-за агульнымі профілямі і звычайнымі дыягнастычнымі журналамі. Код, адпраўлены праз аўтэнтыфікаваны канал уваходу, — гэта не той самы аб’ект, што насенне, выдадзенае падчас кантраляванай рэгістрацыі, і змешванне іх у тыкеце падтрымкі — гэта шлях, якім уцякаюць сакрэты.

Перападлучэнні, токены і тэст, які ўсё вырашае

Плануйце, што адбудзецца пасля першага паспяховага ўваходу. Раней прыняты код можа састарэць або быць адхілены як паўтор пры наступнай аўтэнтыфікацыі. auth-nocache кіруе захаваннем уліковых даных і не ўсталёўвае MFA, а reneg-sec 0 не з’яўляецца вызначэннем падтрымкі TOTP, як бы часта ён ні з’яўляўся ў тэмах форуму.

Некаторыя разгортванні выдаюць токены аўтэнтыфікацыі пасля першай праверкі, каб перападлучэнні не запытвалі зноў. Гэта праектнае рашэнне з уласным акном сапраўднасці і гісторыяй адклікання, а не прадвызначанае значэнне, якое вы атрымліваеце ў спадчыну.

Затым праверце палітыку допуску з тым кліентам, якім людзі сапраўды карыстаюцца. Зарэгістраваны карыстальнік з правільным паролем, сертыфікатам і актуальным кодам павінен падключыцца. Няправільны код, карыстальнік без рэгістрацыі і забаронены ўліковы запіс павінны кожны не прайсці, і прычына павінна быць бачная ў журнале сервера. Пакуль вы не ўбачылі гэтых адхіленняў, у вас ёсць запыт, а не палітыка.