Kāpēc .ovpn faila rediģēšana nevar ieslēgt MFA serverī

Jūs pievienojat auth-user-pass profilam, atkārtoti savienojaties, un klients pieprasa lietotājvārdu un paroli. Izskatās, ka MFA ir ieslēgts. Tad jūs ievadāt kodu no nepareiza konta vai kodu, kura derīguma termiņš beidzās pirms desmit minūtēm, un tunelis tomēr ceļas. Tas ir simptoms: klients mainījās, serveris nē. Vienreizēja parole ir faktors tikai tad, kad pārbaudītājs serverī izlemj, vai tā ir derīga identitātei, kas to pieprasa.

Uzvedne pierāda tikai to, ka klients jautāja, ne vairāk

.ovpn fails ir klienta puses dokuments. Tas var likt klientam pieprasīt akreditācijas datus, saglabāt tos kešatmiņā vai pārtraukt to darīt. Tas nevar reģistrēt lietotāju, instalēt PAM moduli vai likt serverim pieprasīt otru faktoru, ko tas pašlaik nepārbauda.

Arī autentifikācijas lietotnes instalēšana tālrunī šo saistību nerada. Google Authenticator PAM projekts ir OTP pārbaudes komponents, kas var atrasties aiz OpenVPN; tas nav veids, kā Google konta pieteikšanos pielīmēt importētam profilam.

Reģistrācija ir tā daļa, ko profils nevar izdarīt

TOTP nepieciešams reģistrācijas materiāls, kas ir kopīgs autentifikācijas lietotnei un tās pārbaudītājam. Seši cipari tālrunī ir izvade; aiz tiem esošā sēkla ir noslēpums, un tā pieder vienai identitātei.

Tāpēc operatoram nepieciešams reģistrācijas process, kas saista pareizo sēklu ar pareizo VPN identitāti, kā arī pārbaudīts aizstāšanas ceļš pazaudētam tālrunim. Ļaujot lietotājiem augšupielādēt failu, kas nosaukts viņu vārdā, reģistrācija kļūst par konta pārņemšanas iespēju, un augšupielādes šifrēšana to nemaina.

Uz PAM balstītam dizainam nav jāveido atsevišķs Unix konts katram VPN lietotājam. Moduļa dokumentācija atbalsta alternatīvus noslēpumu ceļus un atsevišķu kontu failu piekļuvei, kas ir failu sistēmas identitāte, nevis pārbaudāmā pieteikšanās identitāte.

Biežā kļūda ir fiksēts noslēpuma ceļš, kas beidzas ar vienu lietotājvārdu, nokopēts no viena lietotāja piemēra. Tā ir vienas identitātes demonstrācija, nevis meklēšana pēc lietotāja, un tā izmantošana katram pieprasījumam nevienam nedod neatkarīgi reģistrētu autentifikācijas lietotni. Pierakstiet identitāšu kartējumu, aizsargājiet sēklu failus un turiet paroles, sertifikāta un konta pārbaudes tajā pašā autentifikācijas stekā.

Izlasiet PAM steku, lai redzētu, kas patiešām tiek prasīts

Rinda kā account required pam_permit.so neievieš konta atbilstību un nepievieno faktoru. Tā atļauj to PAM kontu pārvaldības posmu, kas ir apgalvojums par posmu, nevis par jūsu lietotājiem.

Tas pats attiecas uz pieļāvīgiem reģistrācijas parametriem. Lietotāju bez reģistrētas sēklas pieņemšana var būt apzināta ieviešanas izvēle, taču tas nav pierādījums, ka MFA ir obligāts, un tas būtu jāpieraksta kā pagaidu izņēmums ar beigu datumu.

Saskaņojiet klienta mijiedarbību ar servera dizainu

auth-user-pass

Šī direktīva pieprasa lietotājvārda un paroles ievadi. Tā nekonfigurē PAM, neveido reģistrācijas ierakstu un nepasaka serverim, ka paroles laukā ir TOTP vērtība. Servera integrācijai un klientam ir jāvienojas par mijiedarbību, ko izvietošana patiešām atbalsta: izaicinājums, dokumentēts apvienots akreditācijas datu formāts vai produktam raksturīga plūsma.

Nepievienojiet kodu parolei tikai tāpēc, ka klients rāda vienu lauku. Tas darbojas tikai tur, kur servera spraudnis gaida tieši šo formātu, un visur citur tas neizdodas mulsinoši.

Turiet sēklas un QR materiālu ārpus kopīgiem profiliem un ikdienas diagnostikas žurnāliem. Kods, kas iesniegts autentificētā pieteikšanās kanālā, nav tas pats objekts kā sēkla, kas izsniegta kontrolētas reģistrācijas laikā, un to sajaukšana atbalsta biļetenā ir ceļš, pa kuru noslēpumi izplūst.

Atkārtoti savienojumi, pilnvara un tests, kas visu izšķir

Plānojiet, kas notiek pēc pirmās veiksmīgās pieteikšanās. Iepriekš pieņemts kods var būt beidzies vai noraidīts kā atkārtojums nākamajā autentifikācijā. auth-nocache kontrolē akreditācijas datu saglabāšanu un neinstalē MFA, un reneg-sec 0 nav TOTP atbalsta definīcija, lai cik bieži tas parādītos foruma diskusijās.

Dažas izvietošanas pēc sākotnējās pārbaudes izsniedz autentifikācijas pilnvaras, lai atkārtoti savienojumi neprasītu vēlreiz. Tas ir dizaina lēmums ar savu derīguma logu un atsaukšanas vēsturi, nevis noklusējums, ko jūs manto.

Pēc tam pārbaudiet uzņemšanas politiku ar klientu, ko cilvēki patiešām izmanto. Reģistrētam lietotājam ar pareizu paroli, sertifikātu un pašreizējo kodu vajadzētu savienoties. Nepareizam kodam, lietotājam bez reģistrācijas un aizliegtam kontam katram vajadzētu neizdoties, un iemeslam jābūt redzamam servera žurnālā. Kamēr neesat redzējis šos atteikumus, jums ir uzvedne, nevis politika.