Du ensalutaj kontroloj ne estas du faktoroj: VPN kaj RADIUS

Aldoni duan aŭtentigan servaron al VPN-enirejo sentiĝas kiel aldoni duan faktoron. Ĝi kutime aldonas duan kontrolon, kiu estas alia objekto kun aliaj malsukcesaj reĝimoj. Ĉu ambaŭ devas sukcesi, kion ĉiu pruvas kaj kio okazas kiam unu ne disponeblas estas tri apartaj decidoj. Se vi eraras, la enirejo fariĝas pli severa en la demonstro kaj pli malforta dum interrompo.

Kion dua servaro vere pruvas

Serĉo en loka konto pruvas, ke nomo ekzistas en datumbazo kaj ke pasvorto kongruis al ĝi. RADIUS-interŝanĝo pruvas, ke RADIUS-servilo redonis Access-Accept por la ricevitaj atributoj. Neniu el la asertoj mencias faktoran specon, ĉar ambaŭ kontrolas scion. Kaj la gvidilo de NIST pri cifereca identeco kalkulas malsamajn faktorajn specojn kaj iliajn aŭtentigilojn, ne servilojn aŭ instigojn.

Ekzistas laŭleĝa dezajno, en kiu partoprenas ambaŭ sistemoj. Centra servo povas aŭtentigi la personon, dum la enirejo sendepende kontrolas ĉu tiu konto rajtas al tiu tunelo. Tio estas rajtigo apud aŭtentigo, kaj nomi ĝin dufaktora konfuzas politikan kontrolon kun pruvo de posedo.

RADIUS povas porti veran duan faktoron kiam ĝi staras antaŭ io, kio kontrolas unu, kiel puŝa aprobo aŭ aparata ĵetono. La koverto ne diras, kiujn aŭtentigilojn la uzanto montris, do legu la servaran politikon, ne la etikedon de la enirejo.

AND, OR kaj rezerva estas malsamaj produktoj

Antaŭ ol kompari realigojn, decidu, kion ambaŭ signifas en via postulo. Politiko AND postulas, ke ĉiu nomita kontrolo sukcesu, politiko OR akceptas tiun, kiu sukcesas, kaj rezerva provas la duan nur sub deklaritaj malsukcesaj kondiĉoj. Tiuj tri kondutas kontraŭe dum interrompo, kaj kutime nur unu el ili estas tio, kion la revizio intencis.

Aldoni du servarajn enskribojn al agorda ekrano ne malkaŝas, kiun politikon la produkto aplikaĵas. Kelkaj enirejoj ĉenumas kromaĵojn laŭ ordo kaj haltas ĉe la unua rifuzo, kio estas AND nur kiam ĉiu kromaĵo estas postulata. Aliaj traktas lokan konton kiel superregadon, kio igas centran interrompon pretervojo. La fidinda respondo estas dokumentita negativa testo por ĉiu vojo, farita kontraŭ la konstruaĵo, kiun vi lanĉas.

La rezerva meritas la plej grandan suspekton, ĉar ĝi ekzistas por daŭre funkcii kiam io paneas. Rezerva, kiu akceptas lokan pasvorton ĉiam kiam RADIUS neatingeblas, transformis centran politikon en duan, pli malfortan pordon.

La duobla kontrolo de OpenVPN estas konkreta kazo

Komunuma OpenVPN 2.6 postulas kaj klientan atestilon kaj la agordan skripton auth-user-pass-verify, kiam ambaŭ estas ŝaltitaj. Tio estas dokumentita AND inter atestila kontrolo kaj akreditaĵa skripto, kaj ĝi estas vere du kontroloj. Ĝi tamen ne aŭtomate estas du faktoraj specoj, ĉar la skripto eble nur validigas pasvorton.

La kombino ankaŭ lasas malfermita la demandon pri asociado. Atestilo kutime identigas aparaton, dum la akreditaĵoj identigas personon, kaj nenio en la defaŭlta fluo postulas, ke ambaŭ rilatas al la sama subjekto. Decidu, kiuj paroj estas permesataj, poste plenumu tiun mapon ene de la kontrola skripto aŭ en posta rajtiga paŝo.

La reĝimo nur-atestila estas unu kontrolo, subtenata de ŝlosilo, kiu povas aŭ ne povas esti protektita per PIN. PIN igas la saman akreditaĵon scio plus posedo nur se la ŝlosilo ne uzeblas sen ĝi. Lasi tiun ŝlosilon neĉifrita sur disko reduktas la duan parton al dosiera permeso.

Fabrikantoj de aparatoj konstruas sian propran instalaĵon, ofte PAM-modulon aŭ RADIUS-kromaĵon malantaŭ retkonsolo. La konduto de la komunumo estas referenco por tio, kiel aspektas duoblaj kontroloj, ne priskribo de tio, kiel aparato ilin kombinas.

Kontrolu la kombinon ĉe via enirejo

Legu la agordon antaŭ ol fidi la resumon de la konsolo. La linioj, kiuj decidas la politikon, estas la atestila reĝimo, la akreditaĵa skripto kaj la ordo de kromaĵoj.

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 montras, ĉu atestilo estas postulata kaj kiu skripto ruliĝas post ĝi, kaj la ordo gravas pli ol la nomoj sugestas. La atestila elprenaĵo donas la identecon, kiun la enirejo vidos, inkluzive de la CN kaj seria numero, kiujn vi bezonas por la asocia mapo. La RADIUS-testo estas la negativa kazo: malĝusta pasvorto devas doni Access-Reject, kaj ĝusta Access-Accept. Se rifuzita akreditaĵo ankoraŭ donas sesion, la skripto tute ne estas sur la aŭtentiga vojo.

Poste rulu la interrompan kazon en laboratoria ekzemplero: haltigu la postulatan servaron kaj konektu kun validaj akreditaĵoj. La atendata rezulto estas rifuzo, kaj io ajn alia estas la rezerva politiko, kiun neniu dokumentis.

Skribu la postulon kiel negativajn kazojn

Uzebla postulo nomas la pruvojn, la kontojn rajtigitajn prezenti ilin, kaj la rezulton kiam kontrolanto mankas. Ĝi ankaŭ deklaras la permesatan parigon inter aparata identeco kaj persona identeco. Tio estas pli preciza ol la produktonomoj sur la aĉetordo, kaj ĝi estas testebla.

Akcepto devus inkluzivi kvar rifuzojn: netaŭga loka konto, mankanta postulata pruvo, malvalida dua faktoro kaj neatingebla postulata servaro. Ĉiu rifuzo bezonas protokollinion, kiu distingas ĝin de la aliaj, alie la sekva okazaĵo komenciĝas per konjektado. Notu, kiu komponanto faris ĉiun decidon, ĉar la enirejo, la RADIUS-servilo kaj la adresaro ĉiu kulpigos la aliajn du.

Rerulu la kvar rifuzojn post ajna kromaĵa aŭ firmvara ŝanĝo. Ili estas malmultekostaj, kaj la politiko, kiun ili protektas, estas la parto, kiun atakanto unue esploras.