FortiGate VPN MFA: token setempat, RADIUS atau SAML?

Setiap reka bentuk FortiGate VPN MFA menjawab satu soalan dahulu: siapa yang mengesahkan faktor kedua? Gerbang itu sendiri boleh melakukannya dengan token setempat atau kod yang dihantar melalui e-mel, backend RADIUS boleh menguatkuasakannya dan memulangkan cabaran, atau penyedia identiti SAML boleh mengambil alih seluruh upacara dalam pelayar. Setiap daripadanya menghasilkan urutan log masuk yang berbeza, tanda kegagalan yang berbeza dan prosedur pemulihan yang berbeza, dan menyalin blok arahan antara satu sama lain menghasilkan konfigurasi yang kelihatan munasabah dan tidak mengesahkan sesiapa. Ini ialah artikel tentang mekanisme: apa yang sebenarnya dilakukan setiap reka bentuk semasa log masuk, dan di mana ia patah.

Upacara log masuk menentukan siapa yang memiliki faktor

Dalam dua reka bentuk pertama, FortiGate ialah pihak yang mempercayai. Ia mengumpul kelayakan, memutuskan sama ada faktor kedua diperlukan, dan mengesahkannya secara setempat atau dengan meminta cabaran. Dalam reka bentuk ketiga, gerbang berhenti menjadi pengesah dan menjadi penyampai: ia mengalihkan klien ke penyedia identiti, menerima penegasan dan memetakan identiti yang ditegaskan kepada pengguna dan kumpulan. Dalam reka bentuk RADIUS, ia berada di antaranya dan memacu pertukaran permintaan-jawapan dengan backend yang memegang dasar.

Perbezaan itu menentukan bukti apa yang boleh dikumpulkan. Apabila gerbang mengesahkan, output nyahpepijatnya sendiri memberitahu anda apa yang berlaku. Apabila penyedia identiti mengesahkan, gerbang hanya tahu bahawa penegasan telah tiba, dan jawapan kepada «adakah MFA benar-benar diperlukan» terdapat dalam log penyedia, bukan dalam log firewall. Membaca log yang salah ialah cara paling biasa untuk salah mendiagnosis pelaksanaan yang berkelakuan tepat seperti yang direka. Perkhidmatan itu sendiri juga mengehadkan upacara: FortiOS 7.6.3 membuang mod terowong SSL VPN demi IPsec, manakala mod web diteruskan sebagai Agentless VPN pada model yang disokong, jadi upacara yang terbukti pada satu perkhidmatan tidak tersedia secara automatik pada perkhidmatan lain.

Pengesahan setempat: token dan kod e-mel

Faktor yang diuruskan FortiGate terikat pada objek pengguna. FortiToken atau integrasi token yang didokumenkan memerlukan pendaftaran, upacara pengesahan yang disokong, pelesenan di mana ia terpakai, dan prosedur penggantian. Kod melalui e-mel memerlukan laluan SMTP yang berfungsi dan peti mel yang boleh dicapai pengguna sebelum terowong wujud, kebergantungan yang tiada kaitan dengan kriptografi dan semuanya berkaitan dengan sama ada seseorang boleh log masuk.

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

Penghantaran e-mel ialah sebahagian daripada ketersediaan pengesahan. Peti mel yang hanya boleh dicapai melalui VPN mencipta gelung yang tidak selesai dengan sendirinya bagi sesiapa, dan kelewatan penghantaran, kesahan kod dan had masa pengesahan jauh ialah tiga kekangan berasingan. Menaikkan satu tidak membaiki peti mel yang tidak tercapai, dan reka bentuk yang tidak pernah menguji gelung itu akan menemukannya semasa set semula kata laluan pertama selepas cuti.

Keperluan jaminan juga termasuk di sini, sebelum pemilihan produk. NIST SP 800-63B menganggap e-mel tidak boleh diterima untuk pengesahan di luar jalur, jadi pelaksanaan yang mendakwa pematuhan tidak boleh menggunakan kod e-mel sebagai faktor kedua, betapa pun mudahnya. Kewujudan ciri pada peranti bukanlah kenyataan bahawa ciri itu memenuhi standard tertentu.

RADIUS: gerbang bertanya, backend memutuskan

Dengan RADIUS, FortiGate menghantar kelayakan kepada backend yang memiliki dasar faktor. Pertukaran itu boleh menjadi penerimaan atau penolakan biasa, atau ia boleh melibatkan cabaran yang perlu dijawab oleh klien, bermakna perkhidmatan VPN dan klien kedua-duanya mesti menyokong bentuk cabaran itu. Backend yang menguatkuasakan kelulusan push dan klien yang hanya tahu menambah kod enam digit pada kata laluan tidak akan bertemu di tengah.

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>

Uji backend secara berasingan sebelum menyalahkan terowong. Jika ujian authserver berjaya dan log masuk VPN tidak, perbezaannya terletak pada pengendalian cabaran dan bukan pada kelayakan, dan nyahpepijat daemon pengesahan gerbang ialah tempat ia kelihatan:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: pelayar meninggalkan gerbang

Dalam reka bentuk SAML, klien dialihkan ke penyedia identiti, mengesahkan diri di sana, dan kembali dengan penegasan yang disahkan gerbang terhadap hubungan kepercayaan dan pemetaan kumpulan. Gerbang tidak pernah melihat kata laluan atau faktor kedua, yang sekali gus merupakan penambahbaikan keselamatan dan komplikasi operasi: kegagalan kini berlaku dalam sesi pelayar yang tidak dapat diperiksa oleh firewall.

Menerima penegasan tidak membuktikan bahawa penyedia menghendaki MFA untuk log masuk itu. Dasar penyedia yang menggunakan MFA pada sesetengah aplikasi dan tidak pada yang lain akan menghasilkan tepat log masuk yang anda minta dan tiada satu pun daripada jaminan yang anda andaikan. Semak dasar penyedia untuk aplikasi khusus ini, dan semak bahawa pemetaan tuntutan kumpulan ke kumpulan FortiGate masih sepadan selepas sebarang penamaan semula di mana-mana pihak.

Sokongan klien lebih penting di sini daripada di tempat lain. Sesetengah klien VPN mengendalikan penyerahan pelayar secara asli, yang lain membuka pelayar sistem, dan klien tanpa kepala atau baris arahan mungkin tidak melengkapkan aliran itu sama sekali. Uji dengan klien yang benar-benar dijalankan pengguna, pada platform yang benar-benar mereka gunakan, sebelum menerbitkan profil.

Pemulihan ialah sebahagian daripada mekanisme

Setiap reka bentuk di atas mempunyai kebergantungan yang boleh gagal bagi seorang pengguna pada satu masa: peti mel yang tidak tercapai, token yang hilang, backend yang menolak cabaran, akaun penyedia identiti yang dikunci. Putuskan sekarang siapa yang boleh memulihkan akses, melalui prosedur yang disokong, dan dengan pengesahan apa terhadap orang yang meminta. Akaun pentadbir setempat kecemasan yang disimpan berasingan daripada laluan VPN ialah kawalan; dan pemintasan tanpa penjelasan yang hanya menggunakan kata laluan ialah insiden yang menunggu untuk ditemui.

Kemudian uji tiga log masuk sebelum pelaksanaan: yang biasa, faktor yang ditolak atau tamat tempoh, dan pemulihan pengesah hilang yang diluluskan. Catat dalam log mana setiap satu muncul. Catatan itulah yang mengubah «MFA diaktifkan» menjadi reka bentuk yang boleh dikendalikan orang lain.