FortiGate VPN MFA: lokaal token, RADIUS of SAML?

De gateway, in RADIUS-backend of in SAML-provider kinne elk de faktor ferifiearje, en elk mislearret oars. Stem tsjinst, klant en herstelpaad op elkoar ôf.

Elk FortiGate VPN MFA-ûntwerp beantwurdet earst ien fraach: wa ferifiearret de twadde faktor? De gateway sels kin dat dwaan mei in lokaal token of in koade dy't mei e-mail stjoerd wurdt, in RADIUS-backend kin it ôftwinge en in útdaging weromstjoere, of in SAML-identiteitsprovider kin de hiele seremoanje yn in browser oernimme. Elk fan dy leveret in oare oanmeldsekwinsje, in oare flaterhantekening en in oare herstelproseduere, en in kommando-blok tusken harren kopiearje leveret in konfiguraasje op dy't leaudich liket en nimmen ferifiearret. Dit is in meganisme-artikel: wat elk ûntwerp wier by in oanmelding docht, en wêr't it brekt.

De oanmeldsemoanje beslút wa't de faktor hat

Yn de earste twa ûntwerpen is de FortiGate de partij dy't fertrout. It sammellet de bewiisrigel, beslút oft in twadde faktor nedich is, en ferifiearret dy lokaal of troch in útdaging te freegjen. Yn it tredde ûntwerp hâldt de gateway op ferifiearder te wêzen en wurdt in trochjaan: it ferwiist de klant nei de identiteitsprovider, ûntfangt in bewearing en mappet de befêstige identiteit nei in brûker en in groep. Yn it RADIUS-ûntwerp sit it der tuskenyn en driuwt in fraach-en-antwurd-útwikseling mei in backend dy't it belied hat.

Dat ferskil beslút hokker bewiis jo sammelje kinne. As de gateway ferifiearret, fertelt syn eigen debug-útgong jo wat der barde. As in identiteitsprovider ferifiearret, wit de gateway allinnich dat der in bewearing oankaam, en it antwurd op „wie MFA wier nedich“ leit yn 'e logboeken fan 'e provider, net yn dy fan 'e firewall. It ferkearde logboek lêze is de meast foarkommende manier om in útrôljen ferkeard te diagnostisearjen dat him krekt hâldt sa't it ûntwurpen is. De tsjinst sels begrinst de seremoanje ek: FortiOS 7.6.3 ferwideret de SSL VPN-tunnelmodus ten behoewe fan IPsec, wylst de webmodus trochgiet as Agentless VPN op stipe modellen, sadat in seremoanje dy't op ien tsjinst bewiisd is net automatysk op in oare beskikber is.

Lokale ferifikaasje: tokens en e-mailkoades

Faktors dy't troch FortiGate beheard wurde, hechtsje oan it brûkersobjekt. In FortiToken of in dokumintearre token-yntergraasje hat registraasje nedich, de stipe ferifikaasjeseremoanje, lisinsje wêr't dat jildt, en in ferfangingsproseduere. In e-mailkoade hat in wurkjend SMTP-paad nedich en in postfak dat de brûker berikke kin foardat de tunnel bestiet, in ôfhinklikens dy't neat mei kryptografy te krijen hat en alles mei de fraach oft immen oanmelde kin.

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

E-mailbesoarging is part fan 'e beskikberens fan autentikaasje. In postfak dat allinnich fia de VPN berikber is, makket in lus dy't him foar nimmen fansels oplost, en besoargingsfertraging, jildigens fan 'e koade en de tiidlimit fan autentikaasje op ôfstân binne trije aparte beheiningen. Ien ferheegje reparearret gjin ûnberikber postfak, en in ûntwerp dat de lus nea test hat, sil it by de earste wachtwurdweromset nei in fekânsje ûntdekke.

Ek garânsje-easken hearre hjir, foar de produktkar. NIST SP 800-63B beskôget e-mail as net akseptabel foar autentikaasje bûten de bân, dus in útrôljen dy't konformiteit beweart kin in e-mailkoade net as twadde faktor brûke, hoe handich ek. Dat in funksje op it apparaat bestiet, is gjin ferklearring dat de funksje oan in beskaat standert foldocht.

RADIUS: de gateway freget, de backend beslút

Mei RADIUS stjoert de FortiGate de bewiisrigel nei in backend dy't it faktorbelied hat. De útwikseling kin in gewoane akseptaasje of ôfwizing wêze, of it kin in útdaging befetsje dy't de klant beantwurdzje moat, wat betsjut dat sawol de VPN-tsjinst as de klant dy foarm fan útdaging stypje moatte. In backend dy't in push-goedkarring ôftwingt en in klant dy't allinnich wit hoe't er in seis-sifers koade oan in wachtwurd taheakket, sille elkoar net yn 'e midden treffe.

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>

Test de backend selsstannich foardat jo de tunnel de skuld jouwe. As de authserver-test slagget en in VPN-oanmelding net, sit it ferskil yn 'e ôfhanneling fan 'e útdaging en net yn 'e bewiisrigel, en de debug fan 'e autentikaasjedaemon fan 'e gateway is wêr't dat te sjen is:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: de browser ferlit de gateway

Yn in SAML-ûntwerp wurdt de klant nei de identiteitsprovider ferwiisd, dêr autentisearre, en komt werom mei in bewearing dy't de gateway falidearret tsjin in fertrouwensrelaasje en in groepsmapping. De gateway sjocht nea it wachtwurd of de twadde faktor, wat tagelyk in feiligensferbettering en in operasjonele komplikaasje is: de flater bart no yn in browsersesje dy't de firewall net ynspektearje kin.

It akseptearjen fan in bewearing bewiist net dat de provider MFA foar dy oanmelding easke. In providerbelied dat MFA op guon applikaasjes tapast en op oaren net, sil krekt de oanmelding leverje dy't jo fregen en neat fan 'e garânsje dy't jo oannaam. Kontrolearje it belied fan 'e provider foar dizze spesifike applikaasje, en kontrolearje dat de mapping fan groepbewearings nei FortiGate-groepen noch altiten oerienkomt nei hokker omneamen dan ek oan wjerskanten.

Klantstipe is hjir wichtiger as earne oars. Guon VPN-klanten ôfhannelje it oerdragen nei de browser natyf, oaren iepenje de systeembrowser, en headless- of kommandorigel-klanten meie de stream hielendal net foltôgje. Test mei de klant dy't brûkers wier rinne, op 'e platfoarms dy't se wier brûke, foardat jo it profyl publisearje.

Herstel is part fan it meganisme

Elk ûntwerp hjirboppe hat in ôfhinklikens dy't foar ien brûker tagelyk mislearje kin: in ûnberikber postfak, in ferlern token, in backend dy't in útdaging ôfwiist, in beskoattele akkount by de identiteitsprovider. Beslis no wa't tagong weromsette kin, fia hokker stipe proseduere en mei hokker ferifikaasje fan 'e persoan dy't it freget. In needlokale beheardersakkount dat apart fan it VPN-paad holden wurdt, is in kontrôle; en in ûnferklearre omgong mei allinnich wachtwurd is in ynsidint dat wachtet om ûntdutsen te wurden.

Test dêrnei trije oanmeldingen foar de útrôljen: de normale, in ôfwiisde of ferrûne faktor, en it goedkarde herstel fan in ferlern autentikator. Skriuw op yn hokker logboek elk ferskynt. Dat ferslach is wat „MFA is ynskeakele“ feroaret yn in ûntwerp dat immen oars betsjinje kin.

Relatearre artikelen