FortiGate VPN MFA: loka ĵetono, RADIUS aŭ SAML?

La enirejo, RADIUS-malantaŭo aŭ SAML-provizanto povas ĉiu kontroli la faktoron, kaj ĉiu malsukcesas alimaniere. Kongruigu servon, klienton kaj reakiran vojon.

Ĉiu FortiGate VPN MFA-aranĝo unue respondas unu demandon: kiu kontrolas la duan faktoron? La enirejo mem povas fari tion per loka ĵetono aŭ per retpoŝta kodo, RADIUS-malantaŭo povas devigi ĝin kaj resendi defion, aŭ SAML-identecprovizanto povas preni la tutan ceremonion en retumilo. Ĉiu el ili produktas malsaman ensalutsinsekvon, malsaman malsukcesan subskribon kaj malsaman reakiran proceduron, kaj kopii komandblokon inter ili produktas agordon, kiu aspektas kredinda kaj aŭtentigas neniun. Ĉi tio estas artikolo pri mekanismo: kion ĉiu aranĝo efektive faras dum ensaluto, kaj kie ĝi rompiĝas.

La ensaluta ceremonio decidas, kiu posedas la faktoron

En la unuaj du aranĝoj FortiGate estas la fidanta partio. Ĝi kolektas la akreditaĵon, decidas ĉu dua faktoro necesas, kaj kontrolas ĝin loke aŭ petante defion. En la tria aranĝo la enirejo ĉesas esti kontrolanto kaj iĝas relajso: ĝi alidirektas la klienton al la identecprovizanto, ricevas aserton kaj mapas la asertitan identecon al uzanto kaj grupo. En la RADIUS-aranĝo ĝi staras meze kaj pelas peto-respondan interŝanĝon kun malantaŭo, kiu tenas la politikon.

Tiu diferenco decidas, kiujn pruvojn vi povas kolekti. Kiam la enirejo kontrolas, ĝia propra sencimiga eligo diras al vi, kio okazis. Kiam identecprovizanto kontrolas, la enirejo scias nur, ke aserto alvenis, kaj la respondo al „ĉu MFA efektive necesis“ loĝas en la protokoloj de la provizanto, ne en tiuj de la fajroŝirmilo. Legi la malĝustan protokolon estas la plej kutima maniero misdiagnozi enkondukon, kiu kondutas precize laŭ la plano. La servo mem ankaŭ limigas la ceremonion: FortiOS 7.6.3 forigas la tunelreĝimon de SSL VPN favore al IPsec, dum la retreĝimo daŭras kiel Agentless VPN sur subtenataj modeloj, do ceremonio pruvita sur unu servo ne aŭtomate haveblas sur alia.

Loka kontrolo: ĵetonoj kaj retpoŝtaj kodoj

Faktoroj administrataj de FortiGate ligiĝas al la uzanta objekto. FortiToken aŭ dokumentita ĵetona integriĝo bezonas registriĝon, la subtenatan kontrolceremonion, licencadon kie ĝi aplikiĝas, kaj anstataŭigan proceduron. Retpoŝta kodo bezonas funkciantan SMTP-vojon kaj poŝtkeston, kiun la uzanto povas atingi antaŭ ol la tunelo ekzistas, kio estas dependeco tute senrilata al kriptografio kaj plene rilata al ĉu iu ajn povas ensaluti.

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

Retpoŝta liverado estas parto de la havebleco de aŭtentigo. Poŝtkesto atingebla nur per VPN kreas buklon, kiu solviĝas por neniu, kaj livera prokrasto, kodvalideco kaj la tempolimo de fora aŭtentigo estas tri apartaj limigoj. Altigi unu ne riparas neatingeblan poŝtkeston, kaj aranĝo, kiu neniam testis la buklon, malkovros ĝin ĉe la unua pasvorta restarigo post ferioj.

Ankaŭ certigaj postuloj apartenas ĉi tie, antaŭ la produkta elekto. NIST SP 800-63B konsideras retpoŝton neakceptebla por eksterbenda aŭtentigo, do enkonduko, kiu asertas konformecon, ne povas uzi retpoŝtan kodon kiel sian duan faktoron, kiom ajn oportune ĝi estas. Tio, ke funkcio ekzistas sur la aparato, ne estas aserto, ke la funkcio plenumas difinitan normon.

RADIUS: la enirejo demandas, la malantaŭo decidas

Kun RADIUS, FortiGate sendas la akreditaĵon al malantaŭo, kiu posedas la faktoran politikon. La interŝanĝo povas esti simpla akcepto aŭ rifuzo, aŭ ĝi povas enhavi defion, kiun la kliento devas respondi, kio signifas, ke kaj la VPN-servo kaj la kliento devas subteni tiun defiformon. Malantaŭo, kiu devigas puŝan aprobon, kaj kliento, kiu nur scias aldoni sesciferan kodon al pasvorto, ne renkontiĝos meze.

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>

Testu la malantaŭon sendepende antaŭ ol kulpigi la tunelon. Se la authserver-testo sukcesas kaj VPN-ensaluto ne, la diferenco estas en la traktado de la defio, ne en la akreditaĵo, kaj la sencimigo de la aŭtentiga demono de la enirejo estas kie tio montriĝas:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: la retumilo forlasas la enirejon

En SAML-aranĝo la kliento alidirektiĝas al la identecprovizanto, aŭtentiĝas tie kaj revenas kun aserto, kiun la enirejo validigas kontraŭ fida rilato kaj grupa mapado. La enirejo neniam vidas la pasvorton aŭ la duan faktoron, kio samtempe estas sekureca plibonigo kaj operacia komplikaĵo: la malsukceso nun okazas en retumila sesio, kiun la fajroŝirmilo ne povas inspekti.

Akcepti aserton ne pruvas, ke la provizanto postulis MFA por tiu ensaluto. Provizanta politiko, kiu aplikas MFA al iuj aplikoj kaj ne al aliaj, produktos ĝuste la ensaluton, kiun vi petis, kaj neniom da la certigo, kiun vi supozis. Kontrolu la politikon de la provizanto por ĉi tiu konkreta aplikaĵo, kaj kontrolu, ke la mapado de grupaj asertoj al FortiGate-grupoj ankoraŭ kongruas post ajna alinomigo ĉe ajna flanko.

Klienta subteno gravas ĉi tie pli ol ie ajn aliloke. Iuj VPN-klientoj traktas la retumilan transdonon indiĝene, iuj malfermas la sisteman retumilon, kaj senkapaj aŭ komandliniaj klientoj eble tute ne povas fini la fluon. Testu per la kliento, kiun la uzantoj efektive rulas, sur la platformoj, kiujn ili efektive uzas, antaŭ ol publikigi la profilon.

Reakirado estas parto de la mekanismo

Ĉiu aranĝo supre havas dependecon, kiu povas malsukcesi por unu uzanto samtempe: neatingebla poŝtkesto, perdita ĵetono, malantaŭo, kiu rifuzas defion, ŝlosita konto de identecprovizanto. Decidu nun, kiu povas restarigi aliron, per kiu subtenata proceduro kaj kun kiu kontrolo de la petanta persono. Urĝa loka administranta konto tenata aparte de la VPN-vojo estas kontrolo; kaj neklarigita preteriro nur per pasvorto estas okazaĵo atendanta malkovron.

Poste testu tri ensalutojn antaŭ la enkonduko: la normalan, rifuzitan aŭ eksvalidiĝintan faktoron, kaj la aprobitan reakiradon de perdita aŭtentigilo. Notu, en kiu protokolo ĉiu aperas. Tiu registro estas tio, kio transformas „MFA estas ŝaltita“ en aranĝon, kiun iu alia povas funkciigi.

Rilataj artikoloj