To innloggingskontrollar er ikkje to faktorar: VPN og RADIUS

Å leggje til ein ekstra autentiseringsbackend på ein VPN-gateway kjennest som å leggje til ein ekstra faktor. Vanlegvis legg det til ein ekstra kontroll, som er eit anna objekt med andre feilmodusar. Om begge må lukkast, kva kvar av dei bevisar, og kva som skjer når éin ikkje er tilgjengeleg, er tre separate avgjerder. Tek du feil, endar gatewayen strengare i demonstrasjonen og svakare under eit avbrot.

Kva ein ekstra backend faktisk bevisar

Eit lokalt kontoopslag bevisar at eit namn finst i ein database og at eit passord passa til det. Ei RADIUS-utveksling bevisar at ein RADIUS-server returnerte Access-Accept for attributta han mottok. Ingen av påstandane nemner ein faktortype, fordi begge verifiserer kunnskap. Og NIST-veiledninga om digital identitet tel ulike faktortypar og autentisatorane deira, ikkje serverar eller oppfordringar.

Det finst eit legitimt design der begge systema deltek. Ein sentral teneste kan autentisere personen medan gatewayen uavhengig kontrollerer om kontoen har rett til denne tunnelen. Det er autorisasjon ved sida av autentisering, og å kalle det tofaktor forvekslar ein politikkontroll med bevis på eigedom.

RADIUS kan bere ein ekte ekstra faktor når han står framfor noko som verifiserer éin, som ei push-godkjenning eller eit maskinvaretoken. Konvolutten fortel ikkje kva autentisatorar brukaren viste, så les backendpolitikken i staden for etiketten til gatewayen.

AND, OR og reserve er ulike produkt

Før du samanliknar implementasjonar, avgjer kva begge betyr i kravet ditt. Ein AND-politikk krev at kvar namngitt kontroll består, ein OR-politikk godtek den som lukkast, og ein reserve prøver den andre berre under angjevne feilvilkår. Desse tre oppfører seg motsett under eit avbrot, og vanlegvis er berre éin av dei det meldinga meinte.

Å leggje to backend-oppføringar til ein konfigurasjonsskjerm avdekkjer ikkje kva politikk produktet implementerer. Nokre gateways kjedar plugins i rekkjefølgje og stoppar ved første avvising, noko som berre er AND når kvar plugin er påkravd. Andre behandlar ein lokal konto som ei overstyring, noko som gjer eit sentralt avbrot til ein omgang. Det pålitelege svaret er ein dokumentert negativ test for kvar veg, køyrd mot bygget du rullar ut.

Reserve fortener mest mistanke, fordi han finst for å halde fram med å verke når noko er øydelagt. Ein reserve som godtek eit lokalt passord når RADIUS er utilgjengeleg, har gjort ein sentral politikk om til ei andre, svakare dør.

Den doble kontrollen til OpenVPN er eit konkret tilfelle

Fellesskaps-OpenVPN 2.6 krev både eit klientsertifikat og det konfigurerte auth-user-pass-verify-skriptet når begge er aktiverte. Det er ein dokumentert AND mellom sertifikatverifisering og eit legitimasjonsskript, og det er verkeleg to kontrollar. Det er framleis ikkje automatisk to faktortypar, sidan skriptet kanskje berre validerer eit passord.

Kombinasjonen lèt òg assosiasjonsspørsmålet stå ope. Eit sertifikat identifiserer ofte ein eining medan legitimasjonen identifiserer ein person, og ingenting i standardflyten krev at begge viser til same prinsipal. Avgjer kva par som er tillatne, og handhev deretter det kartet i verifiseringsskriptet eller i eit seinare autorisasjonstrinn.

Modusen berre sertifikat er éin kontroll, støtta av ein nøkkel som kanskje eller kanskje ikkje er verna av ein PIN. Ein PIN gjer same legitimasjon til kunnskap pluss eigedom berre viss nøkkelen ikkje kan brukast utan han. Å la nøkkelen liggje ukryptert på disken reduserer den andre delen til ei filrett.

Apparatleverandørar byggjer sitt eige røyrleggjararbeid, ofte ein PAM-modul eller ein RADIUS-plugin bak ein nettkonsoll. Åtferda til fellesskapet er ei referanse for korleis doble kontrollar ser ut, ikkje ei skildring av korleis eit apparat kombinerer dei.

Kontroller kombinasjonen på gatewayen din

Les konfigurasjonen før du stolar på konsollsamanfatninga. Linjene som avgjer politikken, er sertifikatmodusen, legitimasjonsskriptet og plugin-rekkjefølgja.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep viser om eit sertifikat er påkravd og kva skript som køyrer etter det, og rekkjefølgja betyr meir enn namna antydar. Sertifikatdumpen gir identiteten gatewayen vil sjå, inkludert CN og serienummeret du treng for assosiasjonskartet. RADIUS-testen er det negative tilfellet: eit feil passord må gi Access-Reject, og eit riktig Access-Accept. Viss ein avvist legitimasjon likevel gir ein sesjon, er skriptet ikkje på autentiseringsvegen i det heile.

Køyr deretter avbrotstilfellet på ein laboratorieinstans: stopp den påkravde backenden og kople til med gyldig legitimasjon. Det forventa resultatet er ei avvising, og alt anna er reservepolitikken som ingen dokumenterte.

Skriv kravet som negative tilfelle

Eit brukbart krav namngir prova, kontoane som har lov til å presentere dei, og resultatet når ein verifiserar manglar. Det angir òg den tillatne samankoplinga mellom einingidentitet og personidentitet. Det er meir presist enn produktnamna på innkjøpsordren, og det kan testast.

Aksept bør omfatte fire avvisingar: ein ueigna lokal konto, eit manglande påkravd prov, ein ugyldig andre faktor og ein utilgjengeleg påkravd backend. Kvar avvising treng ei logglinje som skil ho frå dei andre, elles byrjar neste hending med gissing. Registrer kva komponent som tok kvar avgjerd, sidan gatewayen, RADIUS-serveren og katalogen kvar vil klandre dei to andre.

Køyr dei fire avvisingane på nytt etter kvar plugin- eller fastvareendring. Dei er billege, og politikken dei vernar, er den delen ein åtakar undersøkjer først.