FortiGate VPN MFA: token lokal, RADIUS apo SAML?

Çdo projekt FortiGate VPN MFA përgjigjet fillimisht një pyetjeje: kush e verifikon faktorin e dytë? Vetë porta mund ta bëjë këtë me një token lokal ose një kod të dërguar me email, një backend RADIUS mund ta imponojë dhe të kthejë një sfidë, ose një ofrues identiteti SAML mund të marrë përsipër të gjithë ceremoninë në një shfletues. Secili prej tyre prodhon një sekuencë tjetër hyrjeje, një nënshkrim tjetër dështimi dhe një procedurë tjetër rikuperimi, dhe kopjimi i një blloku komandash midis tyre prodhon një konfigurim që duket i besueshëm dhe nuk vërteton askënd. Ky është një artikull rreth mekanizmit: çfarë bën në të vërtetë çdo projekt gjatë një hyrjeje dhe ku thyhet.

Ceremonia e hyrjes vendos kush e zotëron faktorin

Në dy projektet e para FortiGate është pala që beson. Mbledh kredencialet, vendos nëse kërkohet një faktor i dytë dhe e verifikon atë lokalisht ose duke kërkuar një sfidë. Në projektin e tretë porta pushon së qeni verifikues dhe bëhet një rele: e ridrejton klientin te ofruesi i identitetit, merr një pohim dhe e harton identitetin e konfirmuar te një përdorues dhe një grup. Në projektin RADIUS qëndron në mes dhe drejton një shkëmbim kërkese-përgjigjeje me një backend që mban politikën.

Ky ndryshim vendos çfarë provash mund të mblidhni. Kur porta verifikon, prodhimi i saj i korrigjimit ju tregon çfarë ndodhi. Kur verifikon një ofrues identiteti, porta di vetëm se mbërriti një pohim, dhe përgjigjja për «a kërkohej vërtet MFA» qëndron në regjistrat e ofruesit, jo në ata të murit të zjarrit. Leximi i regjistrit të gabuar është mënyra më e zakonshme për të diagnostikuar gabimisht një vendosje që sillet saktësisht siç është projektuar. Edhe shërbimi vetë e kufizon ceremoninë: FortiOS 7.6.3 heq modalitetin tunel të SSL VPN në favor të IPsec, ndërsa modaliteti web vazhdon si Agentless VPN në modelet e mbështetura, kështu që një ceremoni e provuar në një shërbim nuk është automatikisht e disponueshme në një tjetër.

Verifikim lokal: token dhe kode me email

Faktorët e administruar nga FortiGate lidhen me objektin e përdoruesit. Një FortiToken ose një integrim i dokumentuar i tokenit kërkon regjistrim, ceremoninë e verifikimit të mbështetur, licencim kur zbatohet dhe një procedurë zëvendësimi. Një kod i dërguar me email kërkon një rrugë SMTP funksionale dhe një kuti postare që përdoruesi mund ta arrijë përpara se tuneli të ekzistojë, një varësi që nuk ka asnjë lidhje me kriptografinë dhe ka të gjitha lidhjet me atë nëse dikush mund të hyjë.

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

Dërgimi i emailit është pjesë e disponueshmërisë së vërtetimit. Një kuti postare e arritshme vetëm përmes VPN krijojnë një cikël që nuk zgjidhet vetë për askënd, dhe vonesa e dërgimit, vlefshmëria e kodit dhe afati i vërtetimit në distancë janë tre kufizime të veçanta. Ngritja e njërit nuk riparon një kuti postare të paarritshme, dhe një projekt që nuk e ka testuar kurrë ciklin do ta zbulojë atë në rivendosjen e parë të fjalëkalimit pas pushimeve.

Edhe kërkesat e sigurimit i përkasin këtij vendi, përpara zgjedhjes së produktit. NIST SP 800-63B e konsideron emailin të papranueshëm për vërtetim jashtë brezit, prandaj një vendosje që pretendon përputhshmëri nuk mund të përdorë një kod emaili si faktor të dytë, sado i përshtatshëm të jetë. Ekzistenca e një funksioni në pajisje nuk është deklaratë se funksioni plotëson një standard të caktuar.

RADIUS: porta pyet, backend-i vendos

Me RADIUS, FortiGate i dërgon kredencialet një backend-i që zotëron politikën e faktorëve. Shkëmbimi mund të jetë një pranim ose refuzim i thjeshtë, ose mund të përfshijë një sfidë të cilës klienti duhet t'i përgjigjet, që do të thotë se si shërbimi VPN ashtu edhe klienti duhet të mbështesin atë formë sfide. Një backend që imponon miratim push dhe një klient që di vetëm të shtojë një kod gjashtëshifror te fjalëkalimi nuk do të takohen në mes.

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>

Testoni backend-in në mënyrë të pavarur përpara se të fajësoni tunelin. Nëse testi authserver ka sukses dhe një hyrje VPN jo, ndryshimi është në trajtimin e sfidës dhe jo në kredenciale, dhe korrigjimi i demonit të vërtetimit të portës është vendi ku kjo shihet:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: shfletuesi largohet nga porta

Në një projekt SAML klienti ridrejtohet te ofruesi i identitetit, vërtetohet atje dhe kthehet me një pohim që porta e vleftëson kundrejt një marrëdhënieje besimi dhe një hartë grupi. Porta nuk e sheh kurrë fjalëkalimin ose faktorin e dytë, që është njëkohësisht përmirësim sigurie dhe ndërlikim operativ: dështimi tani ndodh në një sesion shfletuesi që muri i zjarrit nuk mund ta inspektojë.

Pranimi i një pohimi nuk dëshmon se ofruesi kërkoi MFA për atë hyrje. Një politikë e ofruesit që zbaton MFA për disa aplikacione dhe jo për të tjerë do të prodhojë saktësisht hyrjen që kërkuat dhe asgjë nga siguria që supozuat. Kontrolloni politikën e ofruesit për këtë aplikacion konkret dhe kontrolloni që harta e pretendimeve të grupit te grupet FortiGate ende përputhet pas çdo riemërtimi në çdo anë.

Mbështetja e klientit ka më shumë rëndësi këtu sesa kudo tjetër. Disa klientë VPN e trajtojnë në mënyrë origjinale kalimin te shfletuesi, të tjerë hapin shfletuesin e sistemit, dhe klientët pa ndërfaqe ose me rresht komandash mund të mos e përfundojnë fare rrjedhën. Testoni me klientin që përdoruesit ekzekutojnë vërtet, në platformat që përdorin vërtet, përpara se të publikoni profilin.

Rikuperimi është pjesë e mekanizmit

Secili projekt më sipër ka një varësi që mund të dështojë për një përdorues në një herë: një kuti postare e paarritshme, një token i humbur, një backend që refuzon një sfidë, një llogari e bllokuar e ofruesit të identitetit. Vendosni tani kush mund të rivendosë qasjen, me cilën procedurë të mbështetur dhe me çfarë verifikimi të personit që e kërkon. Një llogari lokale administruesi urgjence e mbajtur ndaras nga rruga VPN është një kontroll; dhe një anashkalim i pashpjeguar vetëm me fjalëkalim është një incident që pret të zbulohet.

Më pas testoni tre hyrje përpara vendosjes: atë normale, një faktor të refuzuar ose të skaduar dhe rikuperimin e miratuar të një vërtetuesi të humbur. Shënoni në cilin regjistër shfaqet secili. Ai regjistrim është ai që e kthen «MFA është aktivizuar» në një projekt që dikush tjetër mund ta operojë.