FortiGate VPN MFA: lokal na token, RADIUS o SAML?

Bawat disenyo ng FortiGate VPN MFA ay sinasagot muna ang isang tanong: sino ang nagbe-verify ng ikalawang factor? Maaaring gawin ito ng gateway mismo gamit ang lokal na token o code na ipinapadala sa email, maaaring ipatupad ito ng RADIUS backend at magbalik ng hamon, o maaaring akuin ng SAML identity provider ang buong seremonya sa browser. Bawat isa ay gumagawa ng ibang pagkakasunod-sunod ng pag-login, ibang lagda ng pagpalya at ibang pamamaraan ng pagbawi, at ang pagkopya ng command block sa pagitan nila ay gumagawa ng configuration na mukhang makatwiran at walang naia-authenticate. Ito ay artikulo tungkol sa mekanismo: ano ang aktwal na ginagawa ng bawat disenyo sa pag-login, at saan ito nasisira.

Ang seremonya ng pag-login ang nagtatakda kung sino ang may-ari ng factor

Sa unang dalawang disenyo, ang FortiGate ang partidong nagtitiwala. Kinokolekta nito ang kredensyal, nagpapasya kung kailangan ang ikalawang factor, at vine-verify ito nang lokal o sa pamamagitan ng paghingi ng hamon. Sa ikatlong disenyo, tumitigil ang gateway sa pagiging verifier at nagiging relay: inililipat nito ang kliyente sa identity provider, tumatanggap ng assertion at ini-map ang kumpirmadong pagkakakilanlan sa isang user at grupo. Sa disenyong RADIUS, nasa pagitan ito at nagpapatakbo ng palitan ng request at response sa isang backend na may hawak ng patakaran.

Ang pagkakaibang iyon ang nagtatakda kung anong ebidensya ang makokolekta. Kapag nagbe-verify ang gateway, sinasabi ng sarili nitong debug output kung ano ang nangyari. Kapag nagbe-verify ang identity provider, alam lamang ng gateway na may dumating na assertion, at ang sagot sa «talaga bang kailangan ang MFA» ay nasa mga log ng provider, hindi sa mga log ng firewall. Ang pagbasa ng maling log ang pinakakaraniwang paraan ng maling pagsusuri sa isang deployment na kumikilos nang eksakto ayon sa disenyo. Nililimitahan din ng serbisyo mismo ang seremonya: Inaalis ng FortiOS 7.6.3 ang SSL VPN tunnel mode bilang pabor sa IPsec, habang nagpapatuloy ang web mode bilang Agentless VPN sa mga sinusuportahang modelo, kaya ang seremonyang napatunayan sa isang serbisyo ay hindi awtomatikong magagamit sa iba.

Lokal na veripikasyon: mga token at code sa email

Ang mga factor na pinamamahalaan ng FortiGate ay nakakabit sa user object. Ang FortiToken o dokumentadong token integration ay nangangailangan ng enrollment, ang sinusuportahang seremonya ng veripikasyon, lisensya kung saan naaangkop, at pamamaraan ng pagpapalit. Ang code na ipinadala sa email ay nangangailangan ng gumaganang SMTP path at mailbox na maabot ng user bago pa man umiral ang tunnel, isang dependency na walang kinalaman sa cryptography at may kinalaman sa kung may makakapasok.

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

Ang paghahatid ng email ay bahagi ng availability ng authentication. Ang mailbox na maabot lamang sa pamamagitan ng VPN ay gumagawa ng loop na hindi nalulutas para sa kaninuman, at ang pagkaantala ng paghahatid, bisa ng code at timeout ng remote authentication ay tatlong magkakaibang limitasyon. Ang pagtaas ng isa ay hindi nag-aayos ng hindi maabot na mailbox, at ang disenyong hindi kailanman sumubok sa loop ay matutuklasan ito sa unang pag-reset ng password pagkatapos ng bakasyon.

Ang mga kinakailangan sa assurance ay kabilang din dito, bago ang pagpili ng produkto. Itinuturing ng NIST SP 800-63B na hindi katanggap-tanggap ang email para sa out-of-band authentication, kaya ang deployment na nag-aangkin ng pagsunod ay hindi maaaring gumamit ng email code bilang ikalawang factor, gaano man ito kaginhawa. Ang pagkakaroon ng feature sa device ay hindi pahayag na ang feature ay tumutugon sa isang partikular na pamantayan.

RADIUS: nagtatanong ang gateway, nagpapasya ang backend

Sa RADIUS, ipinapadala ng FortiGate ang kredensyal sa backend na may hawak ng patakaran ng factor. Ang palitan ay maaaring simpleng pagtanggap o pagtanggi, o maaaring may hamon na kailangang sagutin ng kliyente, na nangangahulugang parehong serbisyo ng VPN at kliyente ay dapat sumuporta sa hugis ng hamon na iyon. Ang backend na nagpapatupad ng push approval at kliyenteng alam lamang ang magdagdag ng anim na digit na code sa password ay hindi magkikita sa gitna.

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>

Subukan ang backend nang hiwalay bago sisihin ang tunnel. Kung nagtagumpay ang authserver test at hindi ang pag-login sa VPN, ang pagkakaiba ay sa paghawak ng hamon at hindi sa kredensyal, at ang debug ng authentication daemon ng gateway ang lugar kung saan ito makikita:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: umaalis ang browser sa gateway

Sa disenyong SAML, ang kliyente ay itinuturo sa identity provider, nagpapatotoo doon, at bumabalik na may assertion na vine-verify ng gateway laban sa isang relasyon ng tiwala at isang group mapping. Hindi kailanman nakikita ng gateway ang password o ang ikalawang factor, na sabay na pagbuti ng seguridad at komplikasyon sa operasyon: nangyayari na ngayon ang pagpalya sa isang browser session na hindi masuri ng firewall.

Ang pagtanggap ng assertion ay hindi nagpapatunay na hiniling ng provider ang MFA para sa pag-login na iyon. Ang patakaran ng provider na naglalapat ng MFA sa ilang aplikasyon at hindi sa iba ay magbibigay ng eksaktong pag-login na hiniling mo at wala sa assurance na inakala mo. Suriin ang patakaran ng provider para sa partikular na aplikasyong ito, at suriin na ang mapping ng mga group claim sa mga grupo ng FortiGate ay tumutugma pa rin pagkatapos ng anumang pagpapalit ng pangalan sa alinmang panig.

Mas mahalaga ang suporta ng kliyente dito kaysa saanman. Ang ilang VPN client ay katutubong humahawak sa browser hand-off, ang iba ay nagbubukas ng system browser, at maaaring hindi matapos ng headless o command-line na kliyente ang daloy. Subukan sa kliyenteng aktwal na pinapatakbo ng mga user, sa mga platform na aktwal nilang ginagamit, bago i-publish ang profile.

Ang pagbawi ay bahagi ng mekanismo

Bawat disenyo sa itaas ay may dependency na maaaring pumalya para sa isang user sa isang pagkakataon: hindi maabot na mailbox, nawalang token, backend na tumatanggi sa hamon, naka-lock na account ng identity provider. Magpasya ngayon kung sino ang makakapagbalik ng access, sa anong sinusuportahang pamamaraan at may anong veripikasyon ng taong humihiling. Ang emergency na lokal na administrator account na inihihiwalay sa VPN path ay isang kontrol; at ang hindi maipaliwanag na paglampas gamit lamang ang password ay isang insidente na naghihintay matuklasan.

Pagkatapos, subukan ang tatlong pag-login bago ang deployment: ang normal, isang tinanggihan o nag-expire na factor, at ang aprubadong pagbawi ng nawalang authenticator. Itala kung sa aling log lumalabas ang bawat isa. Ang talaang iyon ang nagpapalit ng «naka-enable ang MFA» tungo sa disenyong kayang patakbuhin ng ibang tao.