Dy kontrolle hyrjeje nuk janë dy faktorë: VPN dhe RADIUS

Shtimi i një backend-i të dytë të autentikimit në një portë VPN duket si shtim i një faktori të dytë. Zakonisht shton një kontroll të dytë, i cili është një objekt tjetër me mënyra të tjera dështimi. Nëse të dy duhet të kenë sukses, çfarë provon secili dhe çfarë ndodh kur njëri nuk është i disponueshëm janë tre vendime të ndara. Gaboni dhe porta përfundon më strikte në demonstrim dhe më e dobët gjatë një ndërprerjeje.

Çfarë provon vërtet një backend i dytë

Një kërkim në llogarinë lokale provon se një emër ekziston në një bazë të dhënash dhe se një fjalëkalim përputhej me të. Një shkëmbim RADIUS provon se një server RADIUS ktheu Access-Accept për atributet që mori. Asnjë nga pohimet nuk përmend një lloj faktori, sepse të dy verifikojnë njohuri. Dhe udhëzuesi i NIST për identitetin digjital numëron lloje të ndryshme faktorësh dhe autentikuesit e tyre, jo servera ose kërkesa.

Ekziston një dizajn legjitim ku marrin pjesë të dy sistemet. Një shërbim qendror mund të autentikojë personin ndërsa porta kontrollon në mënyrë të pavarur nëse ajo llogari ka të drejtë për këtë tunel. Kjo është autorizim përbri autentikimit, dhe ta quash atë dyfaktorësh ngatërron një kontroll politike me një provë posedimi.

RADIUS mund të mbajë një faktor të dytë të vërtetë kur qëndron përpara diçkaje që verifikon një, si një miratim push ose një shenjë harduerike. Zarfi nuk thotë cilat autentikues paraqiti përdoruesi, prandaj lexoni politikën e backend-it, jo etiketën e portës.

AND, OR dhe rezerva janë produkte të ndryshme

Para se të krahasoni implementimet, vendosni çfarë do të thotë të dyja në kërkesën tuaj. Politika AND kërkon që çdo kontroll i emërtuar të kalojë, politika OR pranon atë që ka sukses, dhe rezerva provon të dytin vetëm në kushtet e deklaruara të dështimit. Këto të tre sillen në mënyrë të kundërt gjatë një ndërprerjeje, dhe zakonisht vetëm njëri prej tyre është ai që kishte parasysh rishikimi.

Shtimi i dy hyrjeve backend në një ekran konfigurimi nuk zbulon cilën politikë zbaton produkti. Disa porta zinxhirojnë shtojcat sipas radhës dhe ndalen në refuzimin e parë, që është AND vetëm kur secila shtojcë është e detyrueshme. Të tjerat e trajtojnë llogarinë lokale si një anulim, që e kthen një ndërprerje qendrore në një anashkalim. Përgjigjja e besueshme është një test negativ i dokumentuar për çdo rrugë, i ekzekutuar kundër build-it që ju vendosni.

Rezerva meriton dyshimin më të madh, sepse ekziston për të vazhduar punën kur diçka është prishur. Një rezervë që pranon një fjalëkalim lokal sa herë RADIUS nuk është i arritshëm ka kthyer një politikë qendrore në një derë të dytë më të dobët.

Kontrolli i dyfishtë i OpenVPN është një rast konkret

OpenVPN komunitar 2.6 kërkon si një certifikatë klienti ashtu edhe skriptin auth-user-pass-verify e konfiguruar kur të dyja janë aktive. Ky është një AND i dokumentuar midis verifikimit të certifikatës dhe një skripti kredencialesh, dhe janë vërtet dy kontrolle. Gjithsesi nuk janë automatikisht dy lloje faktorësh, pasi skripti mund të verifikojë vetëm një fjalëkalim.

Kombinimi lë gjithashtu të hapur çështjen e lidhjes. Një certifikatë zakonisht identifikon një pajisje ndërsa kredencialet identifikojnë një person, dhe asgjë në rrjedhën e paracaktuar nuk kërkon që të dyja t'i referohen të njëjtit principal. Vendosni cilat çifte lejohen, më pas zbatoni atë hartë brenda skriptit të verifikimit ose në një hap më të vonë autorizimi.

Modaliteti vetëm certifikatë është një kontroll i vetëm, i mbështetur nga një çelës që mund ose nuk mund të mbrohet nga një PIN. Një PIN e kthen të njëjtin kredencial në njohuri plus posedim vetëm nëse çelësi nuk mund të përdoret pa të. Lënia e atij çelësi të pakriptuar në disk e zvogëlon pjesën e dytë në një leje skedari.

Prodhuesit e pajisjeve ndërtojnë instalimet e tyre, shpesh një modul PAM ose një shtojcë RADIUS pas një konsole web. Sjellja e komunitetit është një referencë për si duken kontrollet e dyfishta, jo një përshkrim i si një pajisje i kombinon ato.

Kontrolloni kombinimin në portën tuaj

Lexoni konfigurimin përpara se t'i besoni përmbledhjes së konsolës. Rreshtat që vendosin politikën janë modaliteti i certifikatës, skripti i kredencialeve dhe rendi i shtojcave.

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 tregon nëse kërkohet një certifikatë dhe cili skript ekzekutohet pas saj, dhe rendi ka më shumë rëndësi sesa sugjerojnë emrat. Dump-i i certifikatës jep identitetin që do të shohë porta, duke përfshirë CN dhe numrin serial të nevojshëm për hartën e lidhjes. Testi RADIUS është rasti negativ: një fjalëkalim i gabuar duhet të japë Access-Reject, dhe një i saktë Access-Accept. Nëse një kredencial i refuzuar jep gjithsesi një sesion, skripti nuk është fare në rrugën e autentikimit.

Pastaj ekzekutoni rastin e ndërprerjes në një instancë laboratori: ndaloni backend-in e kërkuar dhe lidhuni me kredenciale të vlefshme. Rezultati i pritur është një refuzim, dhe çdo gjë tjetër është politika e rezervës që askush nuk e dokumentoi.

Shkruani kërkesën si raste negative

Një kërkesë e përdorshme emërton provat, llogaritë e lejuara t'i paraqesin ato dhe rezultatin kur mungon një verifikues. Ajo deklaron gjithashtu çiftimin e lejuar midis identitetit të pajisjes dhe identitetit të personit. Kjo është më e saktë se emrat e produkteve në porosi, dhe mund të testohet.

Pranimi duhet të përfshijë katër refuzime: një llogari lokale të papërshtatshme, një provë të detyrueshme që mungon, një faktor të dytë të pavlefshëm dhe një backend të detyrueshëm të paarritshëm. Çdo refuzim ka nevojë për një rresht regjistri që e dallon nga të tjerët, përndryshe incidenti tjetër fillon me hamendje. Regjistroni cili komponent mori çdo vendim, pasi porta, serveri RADIUS dhe drejtoria do të fajësojnë njëra-tjetrën.

Riekzekutoni katër refuzimet pas çdo ndryshimi shtojce ose firmware. Janë të lira, dhe politika që mbrojnë është pjesa që një sulmues kontrollon i pari.