FortiGate VPN MFA: vietinis raktas, RADIUS ar SAML?

Kiekvienas FortiGate VPN MFA sprendimas pirmiausia atsako į vieną klausimą: kas tikrina antrąjį veiksnį? Patys vartai gali tai padaryti vietiniu raktu arba elektroniniu paštu siunčiamu kodu, RADIUS backend'as gali tai įvesti ir grąžinti iššūkį, arba SAML tapatybės tiekėjas gali perimti visą ceremoniją naršyklėje. Kiekvienas iš jų sukuria skirtingą prisijungimo seką, skirtingą gedimo požymį ir skirtingą atkūrimo procedūrą, o komandų bloko kopijavimas tarp jų sukuria konfigūraciją, kuri atrodo patikimai ir nieko neautentifikuoja. Tai straipsnis apie mechanizmą: ką kiekvienas sprendimas iš tikrųjų daro prisijungimo metu ir kur jis lūžta.

Prisijungimo ceremonija nusprendžia, kam priklauso veiksnys

Pirmuosiuose dviejuose sprendimuose FortiGate yra pasitikinti šalis. Jis surenka prisijungimo duomenis, nusprendžia, ar reikia antrojo veiksnio, ir patikrina jį vietiškai arba per iššūkį. Trečiajame sprendime vartai nustoja būti tikrintoju ir tampa rele: nukreipia klientą į tapatybės tiekėją, gauna teiginį ir susieja patvirtintą tapatybę su vartotoju ir grupe. RADIUS sprendime jie yra tarp jų ir vykdo užklausos-atsakymo mainus su backend'u, kuris turi politiką.

Šis skirtumas nusprendžia, kokius įrodymus galite surinkti. Kai vartai tikrina, jų pačių derinimo išvestis pasako, kas įvyko. Kai tikrina tapatybės tiekėjas, vartai žino tik tai, kad atėjo teiginys, o atsakymas į „ar MFA tikrai buvo reikalingas“ yra tiekėjo žurnaluose, o ne firewall žurnaluose. Neteisingo žurnalo skaitymas yra labiausiai paplitęs būdas neteisingai diagnozuoti diegimą, kuris elgiasi tiksliai taip, kaip suprojektuotas. Pati paslauga taip pat riboja ceremoniją: FortiOS 7.6.3 pašalina SSL VPN tunelio režimą IPsec naudai, o žiniatinklio režimas tęsiasi kaip Agentless VPN palaikomuose modeliuose, todėl vienoje paslaugoje įrodytas ceremonijos scenarijus automatiškai neveikia kitoje.

Vietinis tikrinimas: raktai ir elektroninio pašto kodai

FortiGate valdomi veiksniai priskiriami vartotojo objektui. FortiToken arba dokumentuota rakto integracija reikalauja registracijos, palaikomos tikrinimo ceremonijos, licencijavimo, kur taikoma, ir pakeitimo procedūros. Elektroniniu paštu siunčiamas kodas reikalauja veikiančio SMTP kelio ir pašto dėžutės, kurią vartotojas pasiekia prieš atsirandant tuneliui; tai priklausomybė, neturinti nieko bendra su kriptografija ir visiškai susijusi su tuo, ar kas nors gali prisijungti.

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

Elektroninio pašto pristatymas yra autentifikavimo prieinamumo dalis. Pašto dėžutė, pasiekiama tik per VPN, sukuria kilpą, kuri niekam savaime neišsisprendžia, o pristatymo vėlavimas, kodo galiojimas ir nuotolinio autentifikavimo laiko limitas yra trys atskiri apribojimai. Vieno padidinimas nesutaiso nepasiekiamos pašto dėžutės, o sprendimas, kuris niekada neišbandė kilpos, ją atras per pirmąjį slaptažodžio atkūrimą po atostogų.

Užtikrinimo reikalavimai taip pat priklauso čia, prieš renkantis produktą. NIST SP 800-63B laiko elektroninį paštą nepriimtinu autentifikavimui už juostos ribų, todėl diegimas, teigiantis atitiktį, negali naudoti elektroninio pašto kodo kaip antrojo veiksnio, kad ir koks patogus jis būtų. Funkcijos buvimas įrenginyje nėra teiginys, kad funkcija atitinka tam tikrą standartą.

RADIUS: vartai klausia, backend'as nusprendžia

Su RADIUS FortiGate siunčia prisijungimo duomenis backend'ui, kuris turi veiksnių politiką. Mainai gali būti paprastas priėmimas arba atmetimas, arba gali apimti iššūkį, į kurį klientas turi atsakyti, o tai reiškia, kad ir VPN paslauga, ir klientas turi palaikyti tokią iššūkio formą. Backend'as, kuris reikalauja push patvirtinimo, ir klientas, kuris moka tik prirašyti šešių skaitmenų kodą prie slaptažodžio, nesusitiks per vidurį.

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>

Išbandykite backend'ą atskirai, prieš kaltindami tunelį. Jei authserver testas pavyksta, o VPN prisijungimas ne, skirtumas yra iššūkio apdorojime, o ne prisijungimo duomenyse, ir vartų autentifikavimo demono derinimas yra vieta, kur tai matosi:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: naršyklė palieka vartus

SAML sprendime klientas nukreipiamas į tapatybės tiekėją, ten autentifikuojasi ir grįžta su teiginiu, kurį vartai patikrina pagal pasitikėjimo santykį ir grupių susiejimą. Vartai niekada nemato slaptažodžio ar antrojo veiksnio, o tai kartu yra saugumo pagerinimas ir operacinė komplikacija: gedimas dabar įvyksta naršyklės sesijoje, kurios firewall negali patikrinti.

Teiginio priėmimas neįrodo, kad tiekėjas reikalavo MFA tam prisijungimui. Tiekėjo politika, taikanti MFA kai kurioms programoms ir netaikanti kitoms, duos būtent tą prisijungimą, kurio prašėte, ir nieko iš to užtikrinimo, kurį numatėte. Patikrinkite tiekėjo politiką šiai konkrečiai programai ir patikrinkite, ar grupinių teiginių susiejimas su FortiGate grupėmis vis dar sutampa po bet kokio pervadinimo bet kurioje pusėje.

Kliento palaikymas čia svarbesnis nei bet kur kitur. Kai kurie VPN klientai natūraliai apdoroja perdavimą naršyklei, kiti atidaro sistemos naršyklę, o be sąsajos ar komandinės eilutės klientai gali visai neužbaigti srauto. Išbandykite su klientu, kurį vartotojai iš tikrųjų naudoja, platformose, kurias jie iš tikrųjų naudoja, prieš publikuodami profilį.

Atkūrimas yra mechanizmo dalis

Kiekvienas aukščiau pateiktas sprendimas turi priklausomybę, kuri gali sugesti vienam vartotojui vienu metu: nepasiekiama pašto dėžutė, prarastas raktas, iššūkį atmetantis backend'as, užrakinta tapatybės tiekėjo paskyra. Nuspręskite dabar, kas gali atkurti prieigą, kokia palaikoma procedūra ir kaip patikrinant prašantį asmenį. Avarinis vietinis administratoriaus accountas, laikomas atskirai nuo VPN kelio, yra kontrolė; o nepaaiškintas apeinimas vien tik slaptažodžiu yra incidentas, laukiantis atradimo.

Tada prieš diegimą išbandykite tris prisijungimus: įprastą, atmestą arba pasibaigusį veiksnį ir patvirtintą prarasto autentifikatoriaus atkūrimą. Užrašykite, kuriame žurnale kiekvienas pasirodo. Būtent šis įrašas paverčia „MFA įjungtas“ sprendimu, kurį gali valdyti kas nors kitas.