Dvije provjere prijave nisu dva faktora: VPN i RADIUS

Dodavanje drugog pozadinskog sistema za autentifikaciju na VPN mrežni prolaz izgleda kao dodavanje drugog faktora. Obično dodaje drugu provjeru, a to je drugi objekat s drugim načinima otkaza. Da li obje moraju uspjeti, šta svaka dokazuje i šta se dešava kad jedna nije dostupna tri su odvojene odluke. Pogriješite li, prolaz završi stroži na demonstraciji i slabiji tokom prekida.

Šta drugi pozadinski sistem zaista dokazuje

Pretraga lokalnog računa dokazuje da ime postoji u bazi podataka i da mu je lozinka odgovarala. RADIUS razmjena dokazuje da je RADIUS server vratio Access-Accept za atribute koje je primio. Nijedna od tvrdnji ne spominje vrstu faktora, jer obje provjeravaju znanje. A NIST smjernice za digitalni identitet broje različite vrste faktora i njihove autentifikatore, a ne servere ili upite.

Postoji legitiman dizajn u kojem učestvuju oba sistema. Centralna usluga može autentifikovati osobu dok prolaz nezavisno provjerava da li taj račun ima pravo na ovaj tunel. To je autorizacija uz autentifikaciju, a nazivati to dvofaktorskim miješa provjeru politike s dokazom posjedovanja.

RADIUS može nositi pravi drugi faktor kada stoji ispred nečega što ga provjerava, kao što je push odobrenje ili hardverski token. Koverta ne kaže koje je autentifikatore korisnik pokazao, pa čitajte pozadinsku politiku, a ne oznaku prolaza.

AND, OR i rezervna politika su različiti proizvodi

Prije poređenja implementacija, odlučite šta oboje znači u vašem zahtjevu. Politika AND zahtijeva da svaka imenovana provjera prođe, politika OR prihvata onu koja uspije, a rezervna pokušava drugu samo pod navedenim uslovima otkaza. Te tri se ponašaju suprotno tokom prekida, i obično je samo jedna ono što je pregled namjeravao.

Dodavanje dva pozadinska unosa na ekran za konfiguraciju ne otkriva koju politiku proizvod primjenjuje. Neki prolazi ulančavaju dodatke po redu i zaustavljaju se na prvom odbijanju, što je AND samo kad je svaki dodatak obavezan. Drugi tretiraju lokalni račun kao nadjačavanje, što centralni prekid pretvara u zaobilaznicu. Pouzdan odgovor je dokumentovan negativan test za svaku stazu, pokrenut na verziji koju postavljate.

Rezervna politika zaslužuje najviše sumnje, jer postoji da bi nastavila raditi kad je nešto pokvareno. Rezervna politika koja prihvata lokalnu lozinku kad god je RADIUS nedostupan pretvorila je centralnu politiku u druga, slabija vrata.

OpenVPN-ova dvostruka provjera je konkretan slučaj

Zajednički OpenVPN 2.6 zahtijeva i klijentski certifikat i konfigurisanu skriptu auth-user-pass-verify kada su oba omogućena. To je dokumentovani AND između provjere certifikata i skripte za akreditive, i to su zaista dvije provjere. Još uvijek to nije automatski dvije vrste faktora, jer skripta može provjeravati samo lozinku.

Kombinacija također ostavlja otvoreno pitanje povezivanja. Certifikat obično identifikuje uređaj, dok akreditivi identifikuju osobu, i ništa u zadanom toku ne zahtijeva da se oba odnose na isti subjekt. Odlučite koje su parove dozvoljene, pa primijenite tu mapu unutar skripte za provjeru ili u kasnijem koraku autorizacije.

Režim samo certifikata je jedna provjera, podržana ključem koji može, ali ne mora biti zaštićen PIN-om. PIN pretvara iste akreditive u znanje plus posjedovanje samo ako se ključ ne može koristiti bez njega. Ostavljanje tog ključa nešifrovanog na disku svodi drugi dio na dozvolu datoteke.

Proizvođači uređaja grade vlastitu instalaciju, često PAM modul ili RADIUS dodatak iza web konzole. Ponašanje zajednice je referenca za to kako dvostruke provjere izgledaju, a ne opis kako ih uređaj kombinuje.

Provjerite kombinaciju na svom prolazu

Pročitajte konfiguraciju prije nego što povjerujete sažetku konzole. Linije koje odlučuju o politici su režim certifikata, skripta za akreditive i redoslijed dodataka.

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 pokazuje da li je certifikat obavezan i koja skripta se izvršava nakon njega, a redoslijed je važniji nego što imena sugerišu. Ispis certifikata daje identitet koji će prolaz vidjeti, uključujući CN i serijski broj potrebne za mapu povezivanja. RADIUS test je negativan slučaj: pogrešna lozinka mora dati Access-Reject, a ispravna Access-Accept. Ako odbijeni akreditivi ipak daju sesiju, skripta uopće nije na stazi autentifikacije.

Zatim pokrenite slučaj prekida na laboratorijskoj instanci: zaustavite obavezni pozadinski sistem i povežite se s važećim akreditivima. Očekivani rezultat je odbijanje, a sve drugo je rezervna politika koju niko nije dokumentovao.

Napišite zahtjev kao negativne slučajeve

Upotrebljiv zahtjev imenuje dokaze, račune kojima je dozvoljeno da ih predstave i rezultat kada provjeravač nedostaje. Također navodi dozvoljeno uparivanje identiteta uređaja i identiteta osobe. To je preciznije od naziva proizvoda na narudžbi i može se testirati.

Prihvatanje treba da uključi četiri odbijanja: nepodoban lokalni račun, nedostajući obavezni dokaz, nevažeći drugi faktor i nedostupni obavezni pozadinski sistem. Svako odbijanje treba zapis u dnevniku koji ga razlikuje od ostalih, inače sljedeći incident počinje nagađanjem. Zabilježite koji je komponent odlučio, jer će prolaz, RADIUS server i direktorij svaki kriviti druga dva.

Ponovite četiri odbijanja nakon svake promjene dodatka ili firmvera. Ona su jeftina, a politika koju štite je dio koji napadač prvi ispituje.