FortiGate VPN MFA: lokal token, RADIUS eller SAML?

Gatewayen, en RADIUS-backend eller en SAML-leverantör kan var och en verifiera faktorn, och var och en misslyckas olika. Matcha tjänst, klient och återställningsväg.

Varje FortiGate VPN MFA-design svarar först på en fråga: vem verifierar den andra faktorn? Gatewayen själv kan göra det med en lokal token eller en kod som skickas via e-post, en RADIUS-backend kan tvinga fram det och returnera en utmaning, eller en SAML-identitetsleverantör kan ta över hela ceremonin i en webbläsare. Var och en av dem ger en annan inloggningssekvens, en annan felsignatur och en annan återställningsprocedur, och att kopiera ett kommandoblock mellan dem ger en konfiguration som ser trovärdig ut och inte autentiserar någon. Det här är en artikel om mekanismen: vad varje design faktiskt gör vid en inloggning, och var den brister.

Inloggningsceremonin avgör vem som äger faktorn

I de två första designerna är FortiGate den part som litar. Den samlar in inloggningsuppgiften, avgör om en andra faktor krävs och verifierar den lokalt eller genom att begära en utmaning. I den tredje designen slutar gatewayen vara verifierare och blir en vidarebefordrare: den omdirigerar klienten till identitetsleverantören, tar emot en assertion och mappar den bekräftade identiteten till en användare och en grupp. I RADIUS-designen ligger den emellan och driver ett förfrågan-svar-utbyte med en backend som har policyn.

Den skillnaden avgör vilka bevis du kan samla in. När gatewayen verifierar berättar dess egen felsökningsutskrift vad som hände. När en identitetsleverantör verifierar vet gatewayen bara att en assertion anlände, och svaret på «krävdes MFA verkligen» finns i leverantörens loggar, inte i brandväggens. Att läsa fel logg är det vanligaste sättet att feldiagnostisera en utrullning som beter sig precis som designat. Tjänsten själv begränsar också ceremonin: FortiOS 7.6.3 tar bort SSL VPN-tunnelläget till förmån för IPsec, medan webbläget fortsätter som Agentless VPN på modeller som stöds, så en ceremoni som bevisats på en tjänst är inte automatiskt tillgänglig på en annan.

Lokal verifiering: tokens och e-postkoder

Faktorer som hanteras av FortiGate är knutna till användarobjektet. En FortiToken eller en dokumenterad tokenintegration kräver registrering, den verifieringsceremoni som stöds, licensiering där det gäller och en ersättningsprocedur. En kod som skickas via e-post kräver en fungerande SMTP-väg och en brevlåda som användaren kan nå innan tunneln finns, ett beroende som inte har något med kryptografi att göra och allt med huruvida någon kan logga in.

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

E-postleverans är en del av autentiseringens tillgänglighet. En brevlåda som bara nås via VPN skapar en slinga som inte löser sig själv för någon, och leveransfördröjning, kodens giltighet och tidsgränsen för fjärrautentisering är tre separata begränsningar. Att höja en av dem reparerar inte en oåtkomlig brevlåda, och en design som aldrig testat slingan upptäcker den vid den första återställningen av lösenordet efter semestern.

Även säkerhetskrav hör hemma här, före produktvalet. NIST SP 800-63B anser att e-post är oacceptabelt för autentisering utanför bandet, så en utrullning som hävdar överensstämmelse kan inte använda en e-postkod som sin andra faktor, hur bekvämt det än är. Att en funktion finns på enheten är inte ett påstående att funktionen uppfyller en given standard.

RADIUS: gatewayen frågar, backend svarar

Med RADIUS skickar FortiGate inloggningsuppgiften till en backend som äger faktorpolicyn. Utbytet kan vara ett enkelt accepterande eller avvisande, eller det kan innebära en utmaning som klienten måste svara på, vilket betyder att både VPN-tjänsten och klienten måste stödja den utmaningsformen. En backend som genomdriver ett push-godkännande och en klient som bara kan lägga till en sexsiffrig kod på ett lösenord möts inte på mitten.

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>

Testa backend separat innan du skyller på tunneln. Om authserver-testet lyckas och en VPN-inloggning inte gör det, ligger skillnaden i hanteringen av utmaningen och inte i inloggningsuppgiften, och felsökningen av gatewayens autentiseringsdaemon är där det syns:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: webbläsaren lämnar gatewayen

I en SAML-design omdirigeras klienten till identitetsleverantören, autentiserar sig där och återvänder med en assertion som gatewayen validerar mot en förtroenderelation och en gruppmappning. Gatewayen ser aldrig lösenordet eller den andra faktorn, vilket samtidigt är en säkerhetsförbättring och en operativ komplikation: felet sker nu i en webbläsarsession som brandväggen inte kan granska.

Att acceptera en assertion bevisar inte att leverantören krävde MFA för den inloggningen. En leverantörspolicy som tillämpar MFA på vissa program och inte på andra ger exakt den inloggning du bad om och inget av den säkerhet du antog. Kontrollera leverantörens policy för just detta program och kontrollera att mappningen av grupppåståenden till FortiGate-grupper fortfarande stämmer efter varje namnbyte på endera sidan.

Klientstöd betyder mer här än någon annanstans. Vissa VPN-klienter hanterar överlämningen till webbläsaren inbyggt, andra öppnar systemwebbläsaren, och headless- eller kommandorads klienter kanske inte slutför flödet alls. Testa med den klient som användarna faktiskt kör, på de plattformar de faktiskt använder, innan du publicerar profilen.

Återställning är en del av mekanismen

Varje design ovan har ett beroende som kan fallera för en användare i taget: en oåtkomlig brevlåda, en förlorad token, en backend som avvisar en utmaning, ett låst konto hos identitetsleverantören. Bestäm nu vem som kan återställa åtkomst, genom vilken procedur som stöds och med vilken verifiering av personen som begär det. Ett lokalt nödadministratörskonto som hålls åtskilt från VPN-vägen är en kontroll; och en oförklarad kringgång med bara lösenord är en incident som väntar på att upptäckas.

Testa sedan tre inloggningar före utrullning: den normala, en avvisad eller utgången faktor och den godkända återställningen av en förlorad autentiserare. Anteckna i vilken logg var och en visas. Den anteckningen är det som förvandlar «MFA är aktiverat» till en design som någon annan kan driva.

Relaterade artiklar