Dve prijavni preverjanji nista dva dejavnika: VPN in RADIUS

Dodajanje drugega avtentikacijskega backenda dostopu VPN je videti kot dodajanje drugega dejavnika. Običajno doda drugo preverjanje, ki je drug objekt z drugačnimi načini odpovedi. Ali morata oba uspeti, kaj vsak dokazuje in kaj se zgodi, ko eden ni dosegljiv, so tri ločene odločitve. Če se zmotite, je dostop strožji na predstavitvi in šibkejši med izpadom.

Kaj drugi backend v resnici dokazuje

Iskanje v lokalnem računu dokazuje, da ime obstaja v podatkovni bazi in da se je geslo ujemalo z njim. Izmenjava RADIUS dokazuje, da je strežnik RADIUS vrnil Access-Accept za prejete atribute. Nobena od trditev ne omenja vrste dejavnika, ker oba preverjata znanje. In smernice NIST o digitalni identiteti štejejo različne vrste dejavnikov in njihove avtentikatorje, ne strežnikov ali pozivov.

Obstaja zakonita zasnova, pri kateri sodelujeta oba sistema. Centralna storitev lahko avtenticira osebo, medtem ko dostop neodvisno preveri, ali je ta račun upravičen do tega tunela. To je avtorizacija ob avtentikaciji, in če temu rečemo dvojni dejavnik, zamenjamo preverjanje pravilnika z dokazom posedovanja.

RADIUS lahko nosi resnični drugi dejavnik, ko stoji pred nečim, kar enega preverja, kot je potrditev push ali strojni žeton. Ovoj ne pove, katere avtentikatorje je uporabnik predložil, zato berite pravilnik backenda, ne oznake dostopa.

AND, OR in rezervni so različni izdelki

Preden primerjate izvedbe, odločite, kaj oba pomeni v vaši zahtevi. Pravilnik AND zahteva, da prestane vsako imenovano preverjanje, pravilnik OR sprejme tisto, ki uspe, rezervni pa drugo preizkusi le pod navedenimi pogoji odpovedi. Ti trije se med izpadom obnašajo nasprotno, in običajno je le eden tisti, kar je pregled mislil.

Dodajanje dveh vnosov backenda na konfiguracijski zaslon ne razkrije, kateri pravilnik izdelek izvaja. Nekateri dostopi verižijo vtičnike po vrstnem redu in se ustavijo pri prvi zavrnitvi, kar je AND le, ko je vsak vtičnik obvezen. Drugi obravnavajo lokalni račun kot prepis, kar centralni izpad spremeni v obhod. Zanesljiv odgovor je dokumentiran negativni test za vsako pot, izveden na gradnji, ki jo uvajate.

Rezervni si zasluži največ suma, ker obstaja zato, da deluje naprej, ko je nekaj pokvarjeno. Rezervni, ki sprejme lokalno geslo vsakič, ko RADIUS ni dosegljiv, je centralni pravilnik spremenil v druga, šibkejša vrata.

Dvojno preverjanje OpenVPN je konkreten primer

Skupnostni OpenVPN 2.6 zahteva tako odjemalski certifikat kot nastavljeno skripto auth-user-pass-verify, ko sta oba omogočena. To je dokumentiran AND med preverjanjem certifikata in skripto poverilnic, in res gre za dve preverjanji. Še vedno pa nista samodejno dve vrsti dejavnikov, saj lahko skripta preveri le geslo.

Kombinacija pušča odprto tudi vprašanje povezave. Certifikat običajno identificira napravo, medtem ko poverilnice identificirajo osebo, in nič v privzetem toku ne zahteva, da se oba nanašata na isti subjekt. Odločite, kateri pari so dovoljeni, nato to preslikavo uveljavite v skripti za preverjanje ali v poznejšem koraku avtorizacije.

Način samo s certifikatom je eno preverjanje, podprto s ključem, ki je lahko ali ni zaščiten s PIN. PIN spremeni iste poverilnice v znanje plus posedovanje le, če ključa ni mogoče uporabiti brez njega. Če ključ ostane nešifriran na disku, se drugi del skrči na dovoljenje datoteke.

Proizvajalci naprav gradijo svojo napeljavo, pogosto modul PAM ali vtičnik RADIUS za spletno konzolo. Vedenje skupnosti je referenca za to, kako izgledajo dvojna preverjanja, ne opis, kako jih naprava združuje.

Preverite kombinacijo na svojem dostopu

Preberite konfiguracijo, preden zaupate povzetku konzole. Vrstice, ki določajo pravilnik, so način certifikata, skripta poverilnic in vrstni red vtičnikov.

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 pokaže, ali je certifikat potreben in katera skripta se izvede za njim, in vrstni red je pomembnejši, kot nakazujejo imena. Izpis certifikata da identiteto, ki jo bo dostop videl, vključno s CN in serijsko številko, potrebnima za preslikavo povezave. Test RADIUS je negativni primer: napačno geslo mora dati Access-Reject, pravilno pa Access-Accept. Če zavrnjene poverilnice vseeno dajo sejo, skripta sploh ni na poti avtentikacije.

Nato zaženite primer izpada na laboratorijski instanci: ustavite zahtevani backend in se povežite z veljavnimi poverilnicami. Pričakovani rezultat je zavrnitev, vse drugo pa je rezervni pravilnik, ki ga nihče ni dokumentiral.

Zahtevo zapišite kot negativne primere

Uporabna zahteva poimenuje dokaze, račune, ki jih smejo predložiti, in rezultat, ko preverjevalec manjka. Navaja tudi dovoljeno seznanjanje identitete naprave in identitete osebe. To je natančneje od imen izdelkov na naročilu in je preverljivo.

Sprejem naj vključuje štiri zavrnitve: neustrezen lokalni račun, manjkajoč obvezen dokaz, neveljaven drugi dejavnik in nedosegljiv obvezen backend. Vsaka zavrnitev potrebuje vrstico v dnevniku, ki jo loči od drugih, sicer se naslednji incident začne z ugibanjem. Zabeležite, katera komponenta je sprejela vsako odločitev, saj bodo dostop, strežnik RADIUS in imenik krivili drug drugega.

Po vsaki spremembi vtičnika ali vdelane programske opreme znova zaženite štiri zavrnitve. Poceni so, in pravilnik, ki ga varujejo, je del, ki ga napadalec preveri prvi.