Wêrom it bewurkjen fan in .ovpn-bestân MFA op de tsjinner net oansette kin

Jo foegje auth-user-pass ta oan in profyl, meitsje opnij ferbining, en de klant freget om in brûkersnamme en wachtwurd. It liket as stiet MFA oan. Dan type jo in koade fan it ferkearde akkount, of in koade dy’t tsien minuten lyn ferrûn is, en de tunnel komt dochs omheech. Dat is it symptoom: de klant feroare, de tsjinner net. In ienmalich wachtwurd is allinnich in faktor as in ferifiearder op de tsjinner beslút oft it jildich is foar de identiteit dy’t it opeasket.

De fraach bewisset allinnich dat de klant frege hat, net mear

In .ovpn-bestân is in dokumint oan de klantkant. It kin de klant sizze om beskoattele oanmeldgegevens op te freegjen, se yn it cache te setten of dêrmei op te hâlden. It kin gjin brûker registrearje, in PAM-module ynstallearje, of de tsjinner in twadde faktor easkje litte dy’t er no net kontrolearret.

It ynstallearjen fan in autentikaasje-app op in tillefoan makket dy relaasje ek net. It Google Authenticator PAM-projekt is in OTP-ferifikaasjekomponint dat efter OpenVPN stean kin; it is gjin manier om Google-akkountoanmelding oan in ymportearre profyl fêst te meitsjen.

Registraasje is it diel dat in profyl net dwaan kin

TOTP hat registraasjemateriaal nedich dat dield wurdt tusken de autentikaasje-app en syn ferifiearder. De seis sifers op ’e tillefoan binne útfier; it sied der efter is it geheim, en it heart by ien identiteit.

Dat betsjut dat de operator in registraasjeproses nedich hat dat it goede sied oan de goede VPN-identiteit bynt, plus in ferifiearre ferfangingsrûte foar in ferlern tillefoan. Brûkers in bestân litte uploade dat nei har sels neamd is, makket fan registraasje in kâns foar akkountoername, en it fersiferjen fan de upload feroaret dat net.

In PAM-basearre ûntwerp hoecht net foar elke VPN-brûker in apart Unix-akkount te meitsjen. De moduledokumintaasje stipet alternative geheime paden en in apart akkount foar bestânstoegong, dat is in bestânssysteemidentiteit en net de oanmeldidentiteit dy’t ferifiearre wurdt.

De gewoane flater is in fêst geheim paad dat op ien brûkersnamme einiget, kopiaat fan in ien-brûker-foarbyld. Dat is in demonstraasje fan ien identiteit, gjin opfraach per brûker, en it foar elk fersyk brûken jout nimmen in ûnôfhinklik registrearre autentikaasje-app. Skriuw de identiteitsmaping op, beskermje de siedbestannen en hâld de wachtwurd-, sertifikaat- en akkountkontrôles yn deselde autentikaasjestapel.

Lês de PAM-stapel om te sjen wat eins easke wurdt

In rigel lykas account required pam_permit.so ymplementearret gjin akkountgeskiktheid en foeget gjin faktor ta. It stiet dat PAM-akkountbehearstadium ta, wat in útspraak oer in stadium is en net oer jo brûkers.

Itselde jildt foar tolerante registraasje-opsjes. Brûkers sûnder registrearre geheim akseptearje kin in bewuste útrolkar wêze, mar it is gjin bewiis dat MFA ferplichte is, en it soe as tydlike útsûndering mei in ein datum opskreaun wurde moatte.

Bring de ynteraksje fan de klant yn oerienkomst mei it ûntwerp fan de tsjinner

auth-user-pass

Dy rjochtline freget om ynfier fan brûkersnamme en wachtwurd. It konfigurearret PAM net, makket gjin registraasjerekord en fertelt de tsjinner net dat it wachtwurdfjild in TOTP-wearde befettet. De tsjinner-yntegraasje en de klant moatte it iens wurde oer in ynteraksje dy’t de útrôl eins stipet: in útdaging, in dokumintearre kombinearre oanmeldgegevensformaat, of in produktspesifike stream.

Foegje gjin koade ta oan it wachtwurd allinnich om’t de klant ien fjild sjen lit. Dat wurket allinnich dêr’t de plugin fan de tsjinner krekt dat formaat ferwachtet, en it mislearret betiizjend oeral oars.

Hâld sied en QR-materiaal bûten dielde profylen en routinematige diagnostyske logboeken. In koade dy’t oer it autentisearre oanmeldkanaal yntsjinne wurdt, is net itselde objekt as it sied dat by kontrolearre registraasje levere is, en se yn in stipekaartsje trochinoar helje is hoe’t geheimen ûntsnappe.

Werferbiningen, tokens en de test dy’t it beslist

Plan foar wat der bart nei de earste suksesfolle oanmelding. In earder akseptearre koade kin ferrûn wêze of as werhelling wegere wurde by de folgjende autentikaasje. auth-nocache kontrolearret it behâld fan oanmeldgegevens en ynstallearret gjin MFA, en reneg-sec 0 is gjin definysje fan TOTP-stipe, hoe faak it ek yn forumpostings opkomt.

Guon útrôlen jouwe nei de earste kontrôle autentikaasjetokens út, sadat werferbiningen net opnij freegje. Dat is in ûntwerpsbeslút mei syn eigen jildichheidsfinster en weromlûkingsferhaal, net in standertwearde dy’t jo ervje.

Test dan it talittingsbelied mei de klant dy’t minsken eins brûke. In registrearre brûker mei it goede wachtwurd, sertifikaat en aktuele koade soe ferbine moatte. In ferkearde koade, in brûker sûnder registraasje en in ferbean akkount soene elk mislearje moatte, en de reden soe sichtber wêze moatte yn it tsjinnerlog. Oant jo dy wegings sjoen hawwe, hawwe jo in fraach, gjin belied.