FortiGate VPN MFA: helyi token, RADIUS vagy SAML?

Az átjáró, egy RADIUS-háttér vagy egy SAML-szolgáltató is ellenőrizheti a faktort, és mindegyik másképp hibázik. Hangolja össze a szolgáltatást, a klienst és a helyreállítási útvonalat.

Minden FortiGate VPN MFA-terv először egy kérdésre válaszol: ki ellenőrzi a második faktort? Maga az átjáró megteheti helyi tokennel vagy e-mailben küldött kóddal, egy RADIUS-háttér kikényszerítheti és visszaküldhet egy kihívást, vagy egy SAML-identitásszolgáltató magára vállalhatja az egész ceremóniát egy böngészőben. Mindegyik más bejelentkezési sorrendet, más hibajelemet és más helyreállítási eljárást eredményez, és a parancsblokk átmásolása közöttük olyan konfigurációt ad, amely hihetőnek látszik, és senkit nem hitelesít. Ez egy mechanizmuscikk: mit tesz valójában az egyes tervek bejelentkezéskor, és hol törik el.

A bejelentkezési ceremónia dönti el, ki birtokolja a faktort

Az első két tervben a FortiGate a bizalmat adó fél. Összegyűjti a hitelesítő adatot, eldönti, kell-e második faktor, és helyben vagy kihívás kérésével ellenőrzi. A harmadik tervben az átjáró megszűnik ellenőrzőnek lenni, és továbbítóvá válik: átirányítja a klienst az identitásszolgáltatóhoz, fogad egy állítást, és az igazolt identitást felhasználóhoz és csoporthoz rendeli. A RADIUS-tervben középen áll, és kérés-válasz cserét folytat egy háttérrel, amelynél a szabályzat van.

Ez a különbség dönti el, milyen bizonyítékokat gyűjthet. Amikor az átjáró ellenőriz, a saját hibakeresési kimenete megmondja, mi történt. Amikor identitásszolgáltató ellenőriz, az átjáró csak annyit tud, hogy állítás érkezett, és a „kellett-e valóban MFA” kérdésre a válasz a szolgáltató naplóiban van, nem a tűzfaléiban. A rossz napló olvasása a leggyakoribb módja annak, hogy félrediagnosztikázzunk egy pontosan a tervek szerint működő bevezetést. Maga a szolgáltatás is korlátozza a ceremóniát: A FortiOS 7.6.3 eltávolítja az SSL VPN alagút módját az IPsec javára, míg a webes mód Agentless VPN-ként folytatódik a támogatott modelleken, így az egyik szolgáltatáson bizonyított ceremónia nem érhető el automatikusan a másikon.

Helyi ellenőrzés: tokenek és e-mail kódok

A FortiGate által kezelt faktorok a felhasználói objektumhoz kapcsolódnak. A FortiToken vagy egy dokumentált tokenintegráció regisztrációt, a támogatott ellenőrzési ceremóniát, ahol alkalmazandó, licencelést és csereeljárást igényel. Az e-mailben küldött kód működő SMTP-útvonalat és olyan postafiókot igényel, amelyet a felhasználó még az alagút létezése előtt elér, ez olyan függőség, amelynek semmi köze a kriptográfiához, és minden köze ahhoz, hogy be tud-e valaki jelentkezni.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

Az e-mail kézbesítése a hitelesítés elérhetőségének része. A csak VPN-en át elérhető postafiók olyan hurkot hoz létre, amely senkinek nem oldódik meg magától, a kézbesítési késés, a kód érvényessége és a távoli hitelesítés időkorlátja pedig három külön korlát. Egyik emelése nem javítja meg az elérhetetlen postafiókot, és a hurkot soha nem tesztelő terv a nyaralás utáni első jelszó-visszaállításnál fogja felfedezni.

A biztosítási követelmények is ide tartoznak, a termékválasztás előtt. A NIST SP 800-63B az e-mailt sávon kívüli hitelesítésre elfogadhatatlannak tartja, ezért a megfelelőséget állító telepítés nem használhat e-mail kódot második faktorként, bármennyire kényelmes is. Egy funkció megléte az eszközön nem állítás arról, hogy a funkció megfelel egy adott szabványnak.

RADIUS: az átjáró kérdez, a háttér dönt

RADIUS-szal a FortiGate a hitelesítő adatot egy olyan háttérnek küldi, amelynél a faktor-szabályzat van. A csere lehet egyszerű elfogadás vagy elutasítás, vagy tartalmazhat olyan kihívást, amelyre a kliensnek válaszolnia kell, ami azt jelenti, hogy a VPN-szolgáltatásnak és a kliensnek is támogatnia kell ezt a kihívásformát. Egy push-jóváhagyást kikényszerítő háttér és egy olyan kliens, amely csak hatjegyű kód hozzáfűzését ismeri a jelszóhoz, nem találkozik félúton.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

Tesztelje a hátteret önállóan, mielőtt az alagutat hibáztatná. Ha az authserver-teszt sikerül, a VPN-bejelentkezés pedig nem, a különbség a kihívás kezelésében van, nem a hitelesítő adatban, és az átjáró hitelesítési daemonjának hibakeresése az a hely, ahol ez megmutatkozik:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: a böngésző elhagyja az átjárót

SAML-tervben a klienst átirányítják az identitásszolgáltatóhoz, ott hitelesít, és egy állítással tér vissza, amelyet az átjáró egy bizalmi kapcsolat és egy csoportleképezés ellenében érvényesít. Az átjáró soha nem látja a jelszót vagy a második faktort, ami egyszerre biztonsági javulás és üzemeltetési bonyodalom: a hiba most egy olyan böngésző-munkamenetben történik, amelyet a tűzfal nem tud megvizsgálni.

Egy állítás elfogadása nem bizonyítja, hogy a szolgáltató MFA-t követelt arra a bejelentkezésre. Az a szolgáltatói szabályzat, amely egyes alkalmazásokra alkalmaz MFA-t, másokra nem, pontosan a kért bejelentkezést adja, és semmit a feltételezett biztosításból. Ellenőrizze a szolgáltató szabályzatát erre a konkrét alkalmazásra, és ellenőrizze, hogy a csoportállítások FortiGate-csoportokba való leképezése bármely oldali átnevezés után is egyezik-e.

Az ügyféltámogatás itt fontosabb, mint bárhol máshol. Egyes VPN-kliensek natívan kezelik a böngészőnek való átadást, mások a rendszer böngészőjét nyitják meg, és a fej nélküli vagy parancssori kliensek egyáltalán nem tudják befejezni a folyamatot. Teszteljen azzal a klienssel, amelyet a felhasználók ténylegesen futtatnak, azokon a platformokon, amelyeket ténylegesen használnak, mielőtt közzéteszi a profilt.

A helyreállítás a mechanizmus része

A fenti tervek mindegyikének van olyan függősége, amely egyszerre egy felhasználónál hibázhat: elérhetetlen postafiók, elveszett token, kihívást elutasító háttér, zárolt identitásszolgáltatói fiók. Döntse el most, ki állíthatja helyre a hozzáférést, melyik támogatott eljárással és a kérelmező melyik ellenőrzésével. A VPN-útvonaltól elkülönítve tartott vészhelyzeti helyi rendszergazdai fiók egy kontroll; a megmagyarázatlan, csak jelszavas megkerülés pedig olyan incidens, amely felfedezésre vár.

Ezután teszteljen három bejelentkezést a bevezetés előtt: a normált, egy elutasított vagy lejárt faktort, és az elveszett hitelesítő jóváhagyott helyreállítását. Jegyezze fel, melyik naplóban jelenik meg mindegyik. Ez a feljegyzés az, ami a „MFA be van kapcsolva” mondatot olyan tervvé alakítja, amelyet más is tud üzemeltetni.

Kapcsolódó cikkek