FortiGate VPN MFA: token ya ndani, RADIUS au SAML?

Kila muundo wa FortiGate VPN MFA hujibu swali moja kwanza: nani anathibitisha kipengele cha pili? Lango lenyewe linaweza kufanya hivyo kwa token ya ndani au msimbo unaotumwa kwa barua pepe, backend ya RADIUS inaweza kuilazimisha na kurudisha changamoto, au mtoa huduma wa utambulisho wa SAML anaweza kuchukua sherehe yote katika kivinjari. Kila mmoja wao hutoa mfululizo tofauti wa kuingia, alama tofauti ya kushindwa na utaratibu tofauti wa urejeshaji, na kunakili kizuizi cha amri kati yao hutoa usanidi unaoonekana kuaminika na hauthibitishi mtu yeyote. Hii ni makala kuhusu utaratibu: kila muundo hufanya nini hasa wakati wa kuingia, na wapi unavunjika.

Sherehe ya kuingia huamua nani anamiliki kipengele

Katika miundo miwili ya kwanza FortiGate ni upande unaoamini. Inakusanya kitambulisho, inaamua kama kipengele cha pili kinahitajika, na inathibitisha kwa ndani au kwa kuomba changamoto. Katika muundo wa tatu lango linaacha kuwa mthibitishaji na linakuwa kipitisho: linaelekeza mteja kwa mtoa huduma wa utambulisho, linapokea dai na linabainisha utambulisho uliothibitishwa kwa mtumiaji na kikundi. Katika muundo wa RADIUS liko katikati na linaendesha mabadilishano ya ombi na jibu na backend inayomiliki sera.

Tofauti hiyo huamua ushahidi gani unaweza kukusanya. Lango linapothibitisha, matokeo yake ya utatuzi wa hitilafu yanakuambia kilichotokea. Mtoa huduma wa utambulisho anapothibitisha, lango linajua tu kwamba dai limefika, na jibu la swali «je, MFA ilihitajika kweli» liko katika kumbukumbu za mtoa huduma, si katika kumbukumbu za firewall. Kusoma kumbukumbu isiyo sahihi ni njia ya kawaida zaidi ya kugundua vibaya usambazaji unaofanya kazi kama ilivyoundwa. Huduma yenyewe pia inaweka mipaka kwenye sherehe: FortiOS 7.6.3 inaondoa hali ya handaki ya SSL VPN kwa ajili ya IPsec, wakati hali ya wavuti inaendelea kama Agentless VPN kwenye modeli zinazotumika, kwa hiyo sherehe iliyothibitishwa kwenye huduma moja haipatikani kiotomatiki kwenye nyingine.

Uthibitishaji wa ndani: token na misimbo ya barua pepe

Vipengele vinavyosimamiwa na FortiGate vinaunganishwa na kitu cha mtumiaji. FortiToken au muunganisho wa token ulioandikwa unahitaji usajili, sherehe ya uthibitishaji inayotumika, leseni inapofaa na utaratibu wa kubadilisha. Msimbo unaotumwa kwa barua pepe unahitaji njia ya SMTP inayofanya kazi na sanduku la barua ambalo mtumiaji anaweza kufikia kabla handaki haijakuwepo, utegemezi ambao hauna uhusiano wowote na kriptografia na una uhusiano wote na kama mtu anaweza kuingia.

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

Uwasilishaji wa barua pepe ni sehemu ya upatikanaji wa uthibitishaji. Sanduku la barua linaloweza kufikiwa kwa VPN tu huunda mzunguko ambao hautatuliki wenyewe kwa mtu yeyote, na ucheleweshaji wa uwasilishaji, uhalali wa msimbo na muda wa mwisho wa uthibitishaji wa mbali ni vikwazo vitatu tofauti. Kuinua kimoja hakurekebishi sanduku lisilofikiwa, na muundo ambao haujawahi kujaribu mzunguko utaukuta kwenye urekebishaji wa kwanza wa nenosiri baada ya likizo.

Mahitaji ya uhakikisho pia ni sehemu ya hapa, kabla ya uchaguzi wa bidhaa. NIST SP 800-63B inachukulia barua pepe kuwa isiyokubalika kwa uthibitishaji nje ya mkondo, kwa hiyo usambazaji unaodai kufuata hauwezi kutumia msimbo wa barua pepe kama kipengele cha pili, hata uwe rahisi kiasi gani. Kuwepo kwa kipengele kwenye kifaa si tamko kwamba kipengele kinakidhi kiwango fulani.

RADIUS: lango linauliza, backend inaamua

Kwa RADIUS, FortiGate hutuma kitambulisho kwa backend inayomiliki sera ya vipengele. Mabadilishano yanaweza kuwa kukubali au kukataa tu, au yanaweza kuhusisha changamoto ambayo mteja anapaswa kujibu, ikimaanisha huduma ya VPN na mteja wote wanapaswa kuunga mkono umbo hilo la changamoto. Backend inayolazimisha idhini ya push na mteja anayejua tu kuongeza msimbo wa tarakimu sita kwenye nenosiri hawatakutana katikati.

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>

Jaribu backend kwa kujitegemea kabla ya kulaumu handaki. Ikiwa jaribio la authserver linafanikiwa na kuingia kwa VPN hakufanikiwi, tofauti iko katika utunzaji wa changamoto na si katika kitambulisho, na utatuzi wa hitilafu wa daemon ya uthibitishaji wa lango ndipo hilo linapoonekana:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: kivinjari kinaondoka kwenye lango

Katika muundo wa SAML mteja anaelekezwa kwa mtoa huduma wa utambulisho, anajithibitisha huko, na anarudi na dai ambalo lango linathibitisha kwa mujibu wa uhusiano wa uaminifu na uchoraji wa vikundi. Lango haliwezi kuona nenosiri au kipengele cha pili, ambayo ni wakati mmoja uboreshaji wa usalama na ugumu wa uendeshaji: kushindwa sasa kunatokea katika kikao cha kivinjari ambacho firewall haiwezi kukagua.

Kukubali dai hakuthibitishi kwamba mtoa huduma alihitaji MFA kwa kuingia huko. Sera ya mtoa huduma inayotumia MFA kwa baadhi ya programu na si kwa nyingine itatoa kuingia hasa ulizoomba na hakuna chochote cha uhakikisho uliodhani. Angalia sera ya mtoa huduma kwa programu hii mahususi, na angalia kwamba uchoraji wa madai ya kikundi kwa vikundi vya FortiGate bado unalingana baada ya mabadiliko yoyote ya jina upande wowote.

Msaada wa mteja ni muhimu zaidi hapa kuliko mahali pengine popote. Baadhi ya wateja wa VPN hushughulikia uwasilishaji kwa kivinjari kwa asili, wengine hufungua kivinjari cha mfumo, na wateja wasio na kichwa au wa mstari wa amri wanaweza kutokamilisha mtiririko hata kidogo. Jaribu na mteja ambao watumiaji huwasha kweli, kwenye majukwaa wanayotumia kweli, kabla ya kuchapisha wasifu.

Urejeshaji ni sehemu ya utaratibu

Kila muundo hapo juu una utegemezi unaoweza kushindwa kwa mtumiaji mmoja kwa wakati: sanduku la barua lisilofikiwa, token iliyopotea, backend inayokataa changamoto, akaunti ya mtoa huduma wa utambulisho iliyofungwa. Amua sasa nani anaweza kurejesha ufikiaji, kwa utaratibu gani unaotumika na kwa uthibitisho gani wa mtu anayeomba. Akaunti ya msimamizi wa ndani ya dharura inayotunzwa kando na njia ya VPN ni udhibiti; na upitishaji usioelezeka wa nenosiri pekee ni tukio linalosubiri kugunduliwa.

Kisha jaribu kuingia mara tatu kabla ya usambazaji: ile ya kawaida, kipengele kilichokataliwa au kilichoisha muda, na urejeshaji ulioidhinishwa wa kithibitishaji kilichopotea. Andika ni kumbukumbu gani kila moja inaonekana. Rekodi hiyo ndiyo inayobadilisha «MFA imewezeshwa» kuwa muundo ambao mtu mwingine anaweza kuuendesha.