FortiGate VPN MFA: staðbundið tóken, RADIUS eða SAML?

Hvert FortiGate VPN MFA-hönnun svarar fyrst einni spurningu: hver sannreynir annan þáttinn? Gáttin sjálf getur gert það með staðbundnu tókeni eða kóða sem sendur er með tölvupósti, RADIUS-bakendi getur knúð það fram og skilað áskorun, eða SAML-auðkennisveitandi getur tekið yfir alla athöfnina í vafra. Hvert þeirra framleiðir aðra innskráningaröð, annað bilunarmynstur og aðra endurheimtaraðferð, og að afrita skipanablokk á milli þeirra framleiðir stillingu sem virðist trúverðug og sannreynir engan. Þetta er grein um verkferilinn: hvað hver hönnun gerir í raun við innskráningu og hvar hún brotnar.

Innskráningarathöfnin ræður því hver á þáttinn

Í fyrstu tveimur hönnununum er FortiGate sá aðili sem treystir. Það safnar skírteininu, ákveður hvort annar þáttur sé nauðsynlegur og sannreynir hann staðbundið eða með áskorun. Í þriðju hönnuninni hættir gáttin að vera sannreynandi og verður milliliður: hún beinir biðlaranum til auðkennisveitandans, tekur við fullyrðingu og varpar staðfestu auðkenni á notanda og hóp. Í RADIUS-hönnuninni stendur hún þar á milli og rekur beiðni-svar-skipti við bakenda sem hefur stefnuna.

Sá munur ræður því hvaða sönnunargögn þú getur safnað. Þegar gáttin sannreynir segir eigin aflúsunarúttak þér hvað gerðist. Þegar auðkennisveitandi sannreynir veit gáttin aðeins að fullyrðing barst, og svarið við „var MFA í raun krafist“ er í annálum veitandans, ekki í annálum eldveggjarins. Að lesa rangann annál er algengasta leiðin til að misgreina útgáfu sem hagar sér nákvæmlega eins og hún var hönnuð. Þjónustan sjálf takmarkar athöfnina líka: FortiOS 7.6.3 fjarlægir SSL VPN-gönguhátt í þágu IPsec, á meðan vefháttur heldur áfram sem Agentless VPN á studdum gerðum, svo athöfn sem sönnuð er á einni þjónustu er ekki sjálfkrafa tiltæk á annarri.

Staðbundin sannreyning: tóken og tölvupóstkóðar

Þættir sem FortiGate stýrir festast við notandahlutinn. FortiToken eða skjalfest tóken-samþætting krefst skráningar, studdrar sannreyningarathafnar, leyfis þar sem við á og skiptiaðferðar. Tölvupóstkóði krefst virkrar SMTP-slóðar og pósthólfs sem notandinn nær í áður en göngin eru til, háð sem hefur ekkert með dulritun að gera og allt með það að gera hvort nokkur komist inn.

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

Tölvupóstsending er hluti af framboði auðkenningar. Pósthólf sem aðeins er hægt að ná í gegnum VPN býr til lykkju sem leysist ekki sjálfkrafa fyrir neinn, og sendingartöf, gildistími kóðans og tímamörk fjartengdrar auðkenningar eru þrjár aðskildar takmarkanir. Að hækka eina lagar ekki óaðgengilegt pósthólf, og hönnun sem hefur aldrei prófað lykkjuna mun uppgötva hana við fyrstu lykilorðsbreytingu eftir frí.

Tryggingarkröfur eiga líka heima hér, áður en vara er valin. NIST SP 800-63B telur tölvupóst óviðunandi fyrir auðkenningu utan bands, svo uppsetning sem segist uppfylla kröfur getur ekki notað tölvupóstkóða sem annan þátt, hversu þægilegt sem er. Að eiginleiki sé til staðar í tækinu er ekki yfirlýsing um að eiginleikinn uppfylli tiltekinn staðal.

RADIUS: gáttin spyr, bakendinn ákveður

Með RADIUS sendir FortiGate skírteinið til bakenda sem hefur stefnu þáttanna. Skiptin geta verið einfalt samþykki eða höfnun, eða falið í sér áskorun sem biðlarinn verður að svara, sem þýðir að bæði VPN-þjónustan og biðlarinn verða að styðja þá áskorunarform. Bakendi sem knýr fram push-samþykki og biðlari sem kann aðeins að bæta sex stafa kóða við lykilorð munu ekki hittast í miðju.

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>

Prófaðu bakendann sjálfstætt áður en þú kennir göngunum um. Ef authserver-prófið tekst en VPN-innskráning ekki, er munurinn í meðhöndlun áskorunarinnar en ekki skírteininu, og aflúsun auðkenningardaemons gáttarinnar er þar sem það kemur í ljós:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: vafrinn yfirgefur gáttina

Í SAML-hönnun er biðlaranum beint til auðkennisveitandans, hann auðkennir sig þar og kemur aftur með fullyrðingu sem gáttin staðfestir gegn traustssambandi og hópavörpun. Gáttin sér aldrei lykilorðið né annan þáttinn, sem er bæði öryggisbót og rekstrarleg flækja: bilunin á sér nú stað í vafralotu sem eldveggurinn getur ekki skoðað.

Að samþykkja fullyrðingu sannar ekki að veitandinn hafi krafist MFA fyrir þá innskráningu. Stefna veitanda sem beitir MFA á sum forrit en ekki önnur mun gefa nákvæmlega þá innskráningu sem þú baðst um og ekkert af þeirri tryggingu sem þú gerðir ráð fyrir. Athugaðu stefnu veitandans fyrir þetta tiltekna forrit, og athugaðu að vörpun hópafullyrðinga á FortiGate-hópa passi enn eftir hvaða endurskírnun sem er á hvorum sem er aðilanna.

Stuðningur biðlara skiptir hér meira máli en nokkurs staðar annars staðar. Sumir VPN-biðlarar meðhöndla afhendinguna til vafrans innbyggt, aðrir opna kerfisvafrann, og biðlarar án viðmóts eða skipanalínubiðlarar klára ferlið kannski ekki að neinu leyti. Prófaðu með biðlaranum sem notendur keyra í raun, á þeim kerfum sem þeir nota í raun, áður en þú birtir sniðið.

Endurheimt er hluti af verkferlinum

Hver hönnunin hér að ofan hefur háð sem getur bilað fyrir einn notanda í einu: óaðgengilegt pósthólf, týnt tóken, bakendi sem hafnar áskorun, læstur aðgangur hjá auðkennisveitanda. Ákveddu nú hver getur endurheimt aðgang, með hvaða studdu aðferð og með hvaða sannreyningu á þeim sem biður. Neyðarstaðbundinn stjórnandaaðgangur sem haldinn er aðskilinn frá VPN-slóðinni er stjórn; og óútskýrð framhjáhlaup með aðeins lykilorði eru atvik sem bíður þess að uppgötvast.

Prófaðu síðan þrjár innskráningar fyrir útgáfu: hina venjulegu, hafnaðan eða útrunnið þátt og samþykkta endurheimt týnds auðkennara. Skráðu í hvaða annál hver þeirra birtist. Það skráningaratriði er það sem breytir „MFA er virkt“ í hönnun sem einhver annar getur rekið.