Két bejelentkezési ellenőrzés nem két tényező: VPN és RADIUS
A helyi fiók ellenőrzése plusz a RADIUS két igazolás, nem két tényezőtípus. Hasonlítsa össze az AND-, OR- és tartalék szabályzatokat, majd tesztelje a kombinációt.
Egy második hitelesítési háttérrendszer hozzáadása egy VPN-átjáróhoz olyan érzés, mintha egy második tényezőt adnánk hozzá. Általában egy második ellenőrzést ad, amely más objektum, más hiba módokkal. Hogy mindkettőnek sikerülnie kell-e, mit bizonyít mindegyik, és mi történik, ha az egyik nem elérhető, három külön döntés. Ha ezeket elrontja, az átjáró szigorúbb lesz a bemutatóban és gyengébb egy kiesés alatt.
Mit bizonyít valójában egy második háttérrendszer
Egy helyi fiók keresése azt bizonyítja, hogy egy név létezik egy adatbázisban, és hogy egy jelszó illeszkedett hozzá. Egy RADIUS csere azt bizonyítja, hogy egy RADIUS-kiszolgáló Access-Accept-et adott vissza a kapott attribútumokra. Egyik állítás sem említ tényezőtípust, mert mindkettő tudást igazol. És a NIST digitális identitásról szóló útmutatója különböző tényezőtípusokat és hitelesítőiket számolja, nem kiszolgálókat vagy felszólításokat.
Létezik legitim terv, amelyben mindkét rendszer részt vesz. Egy központi szolgáltatás hitelesítheti a személyt, míg az átjáró függetlenül ellenőrzi, hogy ez a fiók jogosult-e erre az alagútra. Ez hitelesítés melletti engedélyezés, és kétfaktorosnak nevezni összekeveri a szabályzatellenőrzést a birtoklás bizonyításával.
A RADIUS valódi második tényezőt hordozhat, ha olyasmi előtt áll, ami igazol egyet, például push jóváhagyás vagy hardvertoken. A boríték nem mondja meg, milyen hitelesítőket mutatott be a felhasználó, ezért a háttérrendszer szabályzatát olvassa, ne az átjáró címkéjét.
Az AND, az OR és a tartalék különböző termékek
A megvalósítások összehasonlítása előtt döntse el, mit jelent a mindkettő a követelményében. Az AND szabályzat megköveteli, hogy minden megnevezett ellenőrzés átmenjen, az OR szabályzat azt fogadja el, amelyik sikerül, a tartalék pedig csak megadott hiba feltételek mellett próbálja a másodikat. Ez a három kiesés alatt ellentétesen viselkedik, és általában csak egyikük az, amire a felülvizsgálat gondolt.
Két háttérrendszer-bejegyzés hozzáadása egy konfigurációs képernyőhöz nem árulja el, milyen szabályzatot valósít meg a termék. Egyes átjárók sorrendben láncolják a bővítményeket, és az első elutasításnál megállnak, ami csak akkor AND, ha minden bővítmény kötelező. Mások felülírásnak tekintik a helyi fiókot, ami egy központi kiesést megkerüléssé alakít. A megbízható válasz minden útvonalra dokumentált negatív teszt, a telepített build ellen futtatva.
A tartalék érdemli a legnagyobb gyanút, mert azért létezik, hogy működjön tovább, amikor valami elromlott. Egy tartalék, amely helyi jelszót fogad el, valahányszor a RADIUS elérhetetlen, központi szabályzatot alakított át második, gyengébb ajtóvá.
Az OpenVPN kettős ellenőrzése konkrét eset
A közösségi OpenVPN 2.6 ügyfél-tanúsítványt és a beállított auth-user-pass-verify szkriptet is megköveteli, ha mindkettő engedélyezett. Ez dokumentált AND a tanúsítvány-ellenőrzés és egy hitelesítő adat szkript között, és valóban két ellenőrzés. Még mindig nem automatikusan két tényezőtípus, mivel a szkript talán csak jelszót ellenőriz.
A kombináció nyitva hagyja a hozzárendelés kérdését is. A tanúsítvány általában egy eszközt azonosít, míg a hitelesítő adatok egy személyt, és az alapértelmezett folyamatban semmi sem követeli meg, hogy mindkettő ugyanarra a főre vonatkozzon. Döntse el, mely párok engedélyezettek, majd kényszerítse ki ezt a leképezést az ellenőrző szkriptben vagy egy későbbi engedélyezési lépésben.
A csak tanúsítványos mód egyetlen ellenőrzés, amelyet olyan kulcs támogat, amely lehet PIN-kóddal védett vagy nem. A PIN-kód ugyanazt a hitelesítő adatot tudássá plusz birtoklássá csak akkor teszi, ha a kulcs nélküle nem használható. A kulcs titkosítatlanul hagyása a lemezen a második részt fájlengedélyre csökkenti.
Az eszközgyártók saját vízvezetéket építenek, gyakran egy PAM-modult vagy RADIUS-bővítményt egy webkonzol mögött. A közösségi viselkedés arra mutat példát, hogyan néznek ki a kettős ellenőrzések, nem arra, hogyan kombinálja őket egy eszköz.
Ellenőrizze a kombinációt az átjáróján
Olvassa el a konfigurációt, mielőtt megbízik a konzol összefoglalójában. A szabályzatot eldöntő sorok a tanúsítvány mód, a hitelesítő adat szkript és a bővítmények sorrendje.
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
A grep megmutatja, kell-e tanúsítvány, és melyik szkript fut utána, a sorrend pedig fontosabb, mint a nevek sugallják. A tanúsítvány kiírása adja azt az identitást, amelyet az átjáró látni fog, beleértve a CN-t és a sorozatszámot, amelyre a hozzárendelési térképhez szükség van. A RADIUS-teszt a negatív eset: rossz jelszónak Access-Reject-et, helyesnek Access-Accept-et kell adnia. Ha egy elutasított hitelesítő adat mégis munkamenetet ad, a szkript egyáltalán nincs a hitelesítési útvonalon.
Ezután futtassa a kiesési esetet egy laborpéldányon: állítsa le a kötelező háttérrendszert, és csatlakozzon érvényes hitelesítő adatokkal. A várt eredmény elutasítás, és bármi más az a tartalék szabályzat, amelyet senki sem dokumentált.
Írja le a követelményt negatív esetekként
Egy használható követelmény megnevezi a bizonyítékokat, az azokat bemutatni jogosult fiókokat és az eredményt, ha egy ellenőrző hiányzik. Azt is rögzíti, milyen párosítás engedélyezett az eszköz identitása és a személy identitása között. Ez pontosabb, mint a beszerzési rendelésen szereplő terméknevek, és tesztelhető.
Az átvételnek négy elutasítást kell tartalmaznia: alkalmatlan helyi fiók, hiányzó kötelező bizonyíték, érvénytelen második tényező és elérhetetlen kötelező háttérrendszer. Minden elutasításhoz olyan naplósor kell, amely megkülönbözteti a többitől, különben a következő incidens találgatással kezdődik. Jegyezze fel, melyik komponens hozta az egyes döntéseket, mert az átjáró, a RADIUS-kiszolgáló és a címtár egymást fogja hibáztatni.
Futtassa újra a négy elutasítást minden bővítmény- vagy firmware-változás után. Olcsók, és az általuk védett szabályzat az a rész, amelyet egy támadó először vizsgál.