Prečo úprava súboru .ovpn nezapne MFA na serveri

Pridáte auth-user-pass do profilu, znova sa pripojíte a klient si vypýta používateľské meno a heslo. Vyzerá to, že MFA je zapnuté. Potom zadáte kód z iného účtu alebo kód, ktorému pred desiatimi minútami vypršala platnosť, a tunel aj tak naskočí. To je príznak: klient sa zmenil, server nie. Jednorazové heslo je faktorom len vtedy, keď overovateľ na serveri rozhodne, či je platné pre identitu, ktorá ho uplatňuje.

Výzva dokazuje len to, že sa klient spýtal, nič viac

Súbor .ovpn je dokument na strane klienta. Môže klientovi povedať, aby si vyžiadal prihlasovacie údaje, uložil ich do vyrovnávacej pamäte alebo to prestal robiť. Nemôže zaregistrovať používateľa, nainštalovať modul PAM ani prinútiť server vyžadovať druhý faktor, ktorý teraz nekontroluje.

Ani inštalácia autentifikačnej aplikácie do telefónu tento vzťah nevytvorí. Projekt Google Authenticator PAM je komponent overovania OTP, ktorý môže stáť za OpenVPN; nie je to spôsob, ako na importovaný profil prilepiť prihlasovanie do účtu Google.

Registrácia je časť, ktorú profil nezvládne

TOTP potrebuje registračný materiál zdieľaný medzi autentifikačnou aplikáciou a jej overovateľom. Šesť číslic v telefóne je výstup; semienko za nimi je tajomstvo a patrí jednej identite.

Operátor preto potrebuje registračný proces, ktorý spája správne semienko so správnou identitou VPN, a k tomu overenú cestu náhrady za stratený telefón. Keď používateľom dovolíte nahrať súbor pomenovaný po nich, zmeníte registráciu na príležitosť na prevzatie účtu, a šifrovanie nahrávania to nezmení.

Návrh založený na PAM nemusí vytvárať samostatný unixový účet pre každého používateľa VPN. Dokumentácia modulu podporuje alternatívne cesty k tajomstvám a vyhradený účet na prístup k súborom, čo je identita v súborovom systéme, nie prihlasovacia identita, ktorá sa overuje.

Častou chybou je pevná cesta k tajomstvu končiaca jedným používateľským menom, skopírovaná z príkladu pre jedného používateľa. To je ukážka jednej identity, nie vyhľadávanie podľa používateľa, a používanie pre každú požiadavku nikomu nedá nezávisle registrovanú autentifikačnú aplikáciu. Zapíšte mapovanie identít, chráňte súbory so semienkami a udržujte kontroly hesla, certifikátu a účtu v tom istom autentifikačnom zásobníku.

Prečítajte si zásobník PAM a zistite, čo sa skutočne vyžaduje

Riadok ako account required pam_permit.so neimplementuje oprávnenosť účtu a nepridáva faktor. Povoľuje tú fázu správy účtov v PAM, čo je tvrdenie o fáze, nie o vašich používateľoch.

To isté platí pre benevolentné možnosti registrácie. Prijímanie používateľov bez registrovaného tajomstva môže byť zámerné rozhodnutie pri zavádzaní, ale nie je to dôkaz, že MFA je povinné, a malo by sa to zapísať ako dočasná výnimka s dátumom konca.

Zlaďte interakciu klienta s návrhom servera

auth-user-pass

Táto direktíva žiada zadanie používateľského mena a hesla. Nekonfiguruje PAM, nevytvára registračný záznam a nehovorí serveru, že pole hesla obsahuje hodnotu TOTP. Integrácia servera a klient sa musia dohodnúť na interakcii, ktorú nasadenie skutočne podporuje: výzva, dokumentovaný kombinovaný formát prihlasovacích údajov alebo tok špecifický pre produkt.

Nepripájajte kód k heslu len preto, že klient zobrazuje jedno pole. Funguje to len tam, kde plugin servera očakáva presne tento formát, a všade inde zlyháva mätúco.

Držte semienka a QR materiál mimo zdieľaných profilov a bežných diagnostických záznamov. Kód odoslaný overeným prihlasovacím kanálom nie je ten istý objekt ako semienko vydané pri riadenej registrácii, a ich miešanie v podpornom tikete je cesta, ktorou tajomstvá unikajú.

Opätovné pripojenia, tokeny a test, ktorý to rozsekne

Naplánujte, čo sa stane po prvom úspešnom prihlásení. Skôr prijatý kód môže byť pri ďalšej autentifikácii po expirácii alebo odmietnutý ako opakovanie. auth-nocache riadi uchovávanie prihlasovacích údajov a neinštaluje MFA a reneg-sec 0 nie je definíciou podpory TOTP, nech sa vo vláknach fóra objavuje akokoľvek často.

Niektoré nasadenia vydávajú po počiatočnej kontrole autentifikačné tokeny, aby sa opätovné pripojenia znova nepýtali. Je to dizajnové rozhodnutie s vlastným oknom platnosti a históriou odvolania, nie predvolená hodnota, ktorú dedíte.

Potom otestujte politiku prijímania s klientom, ktorý ľudia skutočne používajú. Registrovaný používateľ so správnym heslom, certifikátom a aktuálnym kódom by sa mal pripojiť. Nesprávny kód, používateľ bez registrácie a zakázaný účet by mali každý zlyhať a dôvod by mal byť viditeľný v protokole servera. Kým tie odmietnutia neuvidíte, máte výzvu, nie politiku.