FortiGate VPN MFA: പ്രാദേശിക ടോക്കൺ, RADIUS അതോ SAML?

ഗേറ്റ്വേ, RADIUS ബാക്കെൻഡ് അല്ലെങ്കിൽ SAML ദാതാവ് ഘടകം പരിശോധിക്കാം, ഓരോന്നും വ്യത്യസ്തമായി പരാജയപ്പെടുന്നു. സേവനം, ക്ലയന്റ്, വീണ്ടെടുക്കൽ പാത എന്നിവ ഒരുമിപ്പിക്കുക.

ഓരോ FortiGate VPN MFA രൂപകൽപ്പനയും ആദ്യം ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: രണ്ടാമത്തെ ഘടകം ആരാണ് പരിശോധിക്കുന്നത്? ഗേറ്റ്വേയ്ക്ക് തന്നെ പ്രാദേശിക ടോക്കൺ അല്ലെങ്കിൽ ഇമെയിലിൽ അയയ്ക്കുന്ന കോഡ് ഉപയോഗിച്ച് അത് ചെയ്യാം, RADIUS ബാക്കെൻഡിന് അത് നിർബന്ധിച്ച് ഒരു വെല്ലുവിളി തിരികെ നൽകാം, അല്ലെങ്കിൽ SAML ഐഡന്റിറ്റി ദാതാവിന് മുഴുവൻ ചടങ്ങും ബ്രൗസറിൽ ഏറ്റെടുക്കാം. ഇവയോരോന്നും വ്യത്യസ്ത ലോഗിൻ ക്രമവും വ്യത്യസ്ത പരാജയ അടയാളവും വ്യത്യസ്ത വീണ്ടെടുക്കൽ നടപടിക്രമവും സൃഷ്ടിക്കുന്നു, ഇവയ്ക്കിടയിൽ കമാൻഡ് ബ്ലോക്ക് പകർത്തുന്നത് വിശ്വസനീയമായി തോന്നുന്നതും ആരെയും പ്രാമാണീകരിക്കാത്തതുമായ കോൺഫിഗറേഷൻ ഉണ്ടാക്കുന്നു. ഇത് സംവിധാനത്തെക്കുറിച്ചുള്ള ലേഖനമാണ്: ലോഗിൻ സമയത്ത് ഓരോ രൂപകൽപ്പനയും യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു, എവിടെ തകരുന്നു.

ലോഗിൻ ചടങ്ങാണ് ഘടകത്തിന്റെ ഉടമസ്ഥൻ ആരെന്ന് തീരുമാനിക്കുന്നത്

ആദ്യ രണ്ട് രൂപകൽപ്പനകളിൽ FortiGate ആണ് വിശ്വസിക്കുന്ന കക്ഷി. ഇത് ക്രെഡൻഷ്യൽ ശേഖരിക്കുന്നു, രണ്ടാമത്തെ ഘടകം ആവശ്യമാണോ എന്ന് തീരുമാനിക്കുന്നു, പ്രാദേശികമായോ വെല്ലുവിളിയിലൂടെയോ അത് പരിശോധിക്കുന്നു. മൂന്നാമത്തെ രൂപകൽപ്പനയിൽ ഗേറ്റ്വേ പരിശോധകനല്ലാതായി റിലേ ആകുന്നു: ക്ലയന്റിനെ ഐഡന്റിറ്റി ദാതാവിലേക്ക് തിരിച്ചുവിടുന്നു, ഒരു അവകാശവാദം സ്വീകരിക്കുന്നു, സ്ഥിരീകരിച്ച ഐഡന്റിറ്റി ഉപയോക്താവിനും ഗ്രൂപ്പിനും മാപ്പ് ചെയ്യുന്നു. RADIUS രൂപകൽപ്പനയിൽ ഇത് ഇവയ്ക്കിടയിലാണ്, നയം കൈവശം വയ്ക്കുന്ന ബാക്കെൻഡുമായി അഭ്യർത്ഥന-പ്രതികരണ കൈമാറ്റം നടത്തുന്നു.

ഈ വ്യത്യാസമാണ് എന്ത് തെളിവ് ശേഖരിക്കാമെന്ന് തീരുമാനിക്കുന്നത്. ഗേറ്റ്വേ പരിശോധിക്കുമ്പോൾ അതിന്റെ സ്വന്തം ഡീബഗ് ഔട്ട്പുട്ട് എന്ത് സംഭവിച്ചുവെന്ന് പറയുന്നു. ഐഡന്റിറ്റി ദാതാവ് പരിശോധിക്കുമ്പോൾ ഒരു അവകാശവാദം എത്തിയെന്ന് മാത്രമേ ഗേറ്റ്വേയ്ക്ക് അറിയൂ, «MFA യഥാർത്ഥത്തിൽ ആവശ്യമായിരുന്നോ» എന്നതിന്റെ ഉത്തരം ദാതാവിന്റെ ലോഗുകളിലാണ്, ഫയർവാൾ ലോഗുകളിലല്ല. തെറ്റായ ലോഗ് വായിക്കുന്നതാണ് രൂപകൽപ്പന അനുസരിച്ച് പ്രവർത്തിക്കുന്ന വിന്യാസത്തെ തെറ്റായി രോഗനിർണയം ചെയ്യാനുള്ള ഏറ്റവും സാധാരണ മാർഗം. സേവനവും ചടങ്ങിനെ പരിമിതപ്പെടുത്തുന്നു: FortiOS 7.6.3 SSL VPN ടണൽ മോഡ് നീക്കം ചെയ്യുന്നു IPsec-ന്റെ പക്ഷത്തേക്ക്, എന്നാൽ വെബ് മോഡ് പിന്തുണയുള്ള മോഡലുകളിൽ Agentless VPN ആയി തുടരുന്നു, അതിനാൽ ഒരു സേവനത്തിൽ തെളിയിച്ച ചടങ്ങ് മറ്റൊന്നിൽ യാന്ത്രികമായി ലഭ്യമല്ല.

പ്രാദേശിക പരിശോധന: ടോക്കണുകളും ഇമെയിൽ കോഡുകളും

FortiGate നിയന്ത്രിക്കുന്ന ഘടകങ്ങൾ ഉപയോക്തൃ ഒബ്ജക്റ്റുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു. FortiToken അല്ലെങ്കിൽ രേഖപ്പെടുത്തിയ ടോക്കൺ സംയോജനത്തിന് രജിസ്ട്രേഷൻ, പിന്തുണയുള്ള പരിശോധനാ ചടങ്ങ്, ബാധകമാകുന്നിടത്ത് ലൈസൻസിംഗ്, മാറ്റിസ്ഥാപിക്കൽ നടപടിക്രമം എന്നിവ ആവശ്യമാണ്. ഇമെയിൽ കോഡിന് പ്രവർത്തിക്കുന്ന SMTP പാതയും ടണൽ ഉണ്ടാകുന്നതിന് മുമ്പ് ഉപയോക്താവിന് എത്തിച്ചേരാവുന്ന മെയിൽബോക്സും വേണം; ഇത് ക്രിപ്റ്റോഗ്രഫിയുമായി ബന്ധമില്ലാത്തതും ആർക്കെങ്കിലും ലോഗിൻ ചെയ്യാനാകുമോ എന്നതുമായി പൂർണ്ണമായി ബന്ധപ്പെട്ടതുമായ ആശ്രിതത്വമാണ്.

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

ഇമെയിൽ വിതരണം പ്രാമാണീകരണ ലഭ്യതയുടെ ഭാഗമാണ്. VPN വഴി മാത്രം എത്താവുന്ന മെയിൽബോക്സ് ആർക്കും സ്വയം പരിഹരിക്കാത്ത ഒരു കുരുക്ക് സൃഷ്ടിക്കുന്നു, വിതരണ കാലതാമസം, കോഡിന്റെ സാധുത, വിദൂര പ്രാമാണീകരണത്തിന്റെ സമയപരിധി എന്നിവ മൂന്ന് വേറിട്ട നിയന്ത്രണങ്ങളാണ്. ഒന്ന് ഉയർത്തിയാൽ എത്തിച്ചേരാനാകാത്ത മെയിൽബോക്സ് ശരിയാകില്ല, കുരുക്ക് ഒരിക്കലും പരിശോധിക്കാത്ത രൂപകൽപ്പന അവധിക്ക് ശേഷമുള്ള ആദ്യ പാസ്വേഡ് പുനഃസജ്ജീകരണത്തിൽ അത് കണ്ടെത്തും.

ഉറപ്പ് ആവശ്യകതകളും ഇവിടെ വരുന്നു, ഉൽപ്പന്ന തിരഞ്ഞെടുപ്പിന് മുമ്പ്. NIST SP 800-63B ഇമെയിൽ ഔട്ട്-ഓഫ്-ബാൻഡ് പ്രാമാണീകരണത്തിന് സ്വീകാര്യമല്ലെന്ന് കണക്കാക്കുന്നു, അതിനാൽ അനുരൂപത അവകാശപ്പെടുന്ന വിന്യാസത്തിന് എത്ര സൗകര്യപ്രദമായാലും ഇമെയിൽ കോഡ് രണ്ടാമത്തെ ഘടകമായി ഉപയോഗിക്കാനാവില്ല. ഉപകരണത്തിൽ ഒരു സവിശേഷത ഉണ്ടായിരിക്കുന്നത് ആ സവിശേഷത ഒരു നിശ്ചിത മാനദണ്ഡം പാലിക്കുന്നു എന്ന പ്രസ്താവനയല്ല.

RADIUS: ഗേറ്റ്വേ ചോദിക്കുന്നു, ബാക്കെൻഡ് തീരുമാനിക്കുന്നു

RADIUS-ൽ FortiGate ഘടക നയം കൈവശം വയ്ക്കുന്ന ബാക്കെൻഡിലേക്ക് ക്രെഡൻഷ്യൽ അയയ്ക്കുന്നു. കൈമാറ്റം ലളിതമായ സ്വീകരണമോ നിരസിക്കലോ ആകാം, അല്ലെങ്കിൽ ക്ലയന്റ് ഉത്തരം നൽകേണ്ട ഒരു വെല്ലുവിളി ഉൾപ്പെടാം, അതായത് VPN സേവനവും ക്ലയന്റും ആ വെല്ലുവിളി രൂപം പിന്തുണയ്ക്കണം. പുഷ് അംഗീകാരം നിർബന്ധിക്കുന്ന ബാക്കെൻഡും പാസ്വേഡിൽ ആറ് അക്ക കോഡ് ചേർക്കാൻ മാത്രം അറിയുന്ന ക്ലയന്റും നടുവിൽ കണ്ടുമുട്ടില്ല.

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>

ടണലിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ബാക്കെൻഡ് സ്വതന്ത്രമായി പരിശോധിക്കുക. authserver പരിശോധന വിജയിക്കുകയും VPN ലോഗിൻ പരാജയപ്പെടുകയും ചെയ്താൽ, വ്യത്യാസം ക്രെഡൻഷ്യലിലല്ല, വെല്ലുവിളി കൈകാര്യം ചെയ്യുന്നതിലാണ്, ഗേറ്റ്വേയുടെ പ്രാമാണീകരണ ഡീമണിന്റെ ഡീബഗ് അത് കാണുന്നിടമാണ്:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: ബ്രൗസർ ഗേറ്റ്വേ വിടുന്നു

SAML രൂപകൽപ്പനയിൽ ക്ലയന്റിനെ ഐഡന്റിറ്റി ദാതാവിലേക്ക് തിരിച്ചുവിടുന്നു, അവിടെ പ്രാമാണീകരിക്കുന്നു, ഗേറ്റ്വേ വിശ്വാസബന്ധത്തിനും ഗ്രൂപ്പ് മാപ്പിംഗിനും എതിരെ സാധൂകരിക്കുന്ന ഒരു അവകാശവാദവുമായി മടങ്ങുന്നു. ഗേറ്റ്വേ പാസ്വേഡോ രണ്ടാമത്തെ ഘടകമോ ഒരിക്കലും കാണുന്നില്ല, ഇത് ഒരേസമയം സുരക്ഷാ മെച്ചപ്പെടുത്തലും പ്രവർത്തന സങ്കീർണ്ണതയുമാണ്: പരാജയം ഇപ്പോൾ ഫയർവാൾ പരിശോധിക്കാനാകാത്ത ഒരു ബ്രൗസർ സെഷനിലാണ് സംഭവിക്കുന്നത്.

ഒരു അവകാശവാദം സ്വീകരിക്കുന്നത് ആ ലോഗിനിന് ദാതാവ് MFA ആവശ്യപ്പെട്ടു എന്ന് തെളിയിക്കുന്നില്ല. ചില ആപ്ലിക്കേഷനുകളിൽ MFA പ്രയോഗിക്കുകയും മറ്റുള്ളവയിൽ പ്രയോഗിക്കാതിരിക്കുകയും ചെയ്യുന്ന ദാതാവ് നയം കൃത്യമായി നിങ്ങൾ ആവശ്യപ്പെട്ട ലോഗിൻ നൽകും, നിങ്ങൾ അനുമാനിച്ച ഉറപ്പിൽ ഒന്നും നൽകില്ല. ഈ നിർദ്ദിഷ്ട ആപ്ലിക്കേഷനുവേണ്ടി ദാതാവിന്റെ നയം പരിശോധിക്കുക, ഏതെങ്കിലും വശത്ത് പേരുമാറ്റിയ ശേഷവും ഗ്രൂപ്പ് ക്ലെയിമുകളുടെ FortiGate ഗ്രൂപ്പുകളിലേക്കുള്ള മാപ്പിംഗ് ഇപ്പോഴും ഒത്തുപോകുന്നുണ്ടെന്ന് പരിശോധിക്കുക.

ക്ലയന്റ് പിന്തുണ ഇവിടെ മറ്റെവിടെയും നിന്ന് കൂടുതൽ പ്രധാനമാണ്. ചില VPN ക്ലയന്റുകൾ ബ്രൗസർ കൈമാറ്റം സ്വാഭാവികമായി കൈകാര്യം ചെയ്യുന്നു, മറ്റുള്ളവ സിസ്റ്റം ബ്രൗസർ തുറക്കുന്നു, കൂടാതെ ഹെഡ്ലെസ് അല്ലെങ്കിൽ കമാൻഡ് ലൈൻ ക്ലയന്റുകൾക്ക് പ്രവാഹം പൂർത്തിയാക്കാൻ കഴിയായിരിക്കില്ല. പ്രൊഫൈൽ പ്രസിദ്ധീകരിക്കുന്നതിന് മുമ്പ് ഉപയോക്താക്കൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിപ്പിക്കുന്ന ക്ലയന്റുമായും യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന പ്ലാറ്റ്ഫോമുകളിലും പരിശോധിക്കുക.

വീണ്ടെടുക്കൽ സംവിധാനത്തിന്റെ ഭാഗമാണ്

മുകളിലുള്ള ഓരോ രൂപകൽപ്പനയ്ക്കും ഒരേസമയം ഒരു ഉപയോക്താവിന് പരാജയപ്പെടാവുന്ന ഒരു ആശ്രിതത്വമുണ്ട്: എത്തിച്ചേരാനാകാത്ത മെയിൽബോക്സ്, നഷ്ടപ്പെട്ട ടോക്കൺ, വെല്ലുവിളി നിരസിക്കുന്ന ബാക്കെൻഡ്, ലോക്ക് ചെയ്ത ഐഡന്റിറ്റി ദാതാവ് അക്കൗണ്ട്. ആർക്ക് പ്രവേശനം വീണ്ടെടുക്കാമെന്ന്, ഏത് പിന്തുണയുള്ള നടപടിക്രമത്തിലൂടെ, അഭ്യർത്ഥിക്കുന്ന വ്യക്തിയെ എങ്ങനെ പരിശോധിച്ച് എന്നിവ ഇപ്പോൾ തീരുമാനിക്കുക. VPN പാതയിൽ നിന്ന് വേർതിരിച്ച് സൂക്ഷിക്കുന്ന അടിയന്തര പ്രാദേശിക അഡ്മിനിസ്ട്രേറ്റർ അക്കൗണ്ട് ഒരു നിയന്ത്രണമാണ്; വിശദീകരണമില്ലാത്ത പാസ്വേഡ്-മാത്രം ബൈപ്പാസ് കണ്ടെത്താനായി കാത്തിരിക്കുന്ന ഒരു സംഭവമാണ്.

തുടർന്ന് വിന്യാസത്തിന് മുമ്പ് മൂന്ന് ലോഗിനുകൾ പരിശോധിക്കുക: സാധാരണത്, നിരസിക്കപ്പെട്ടതോ കാലഹരണപ്പെട്ടതോ ആയ ഘടകം, അംഗീകരിച്ച നഷ്ടപ്പെട്ട പ്രാമാണീകർത്താവിന്റെ വീണ്ടെടുക്കൽ. ഓരോന്നും ഏത് ലോഗിൽ പ്രത്യക്ഷപ്പെടുന്നു എന്ന് രേഖപ്പെടുത്തുക. ആ രേഖയാണ് «MFA സജീവമാണ്» എന്നതിനെ മറ്റൊരാൾക്ക് പ്രവർത്തിപ്പിക്കാവുന്ന രൂപകൽപ്പനയാക്കി മാറ്റുന്നത്.

അനുബന്ധ ലേഖനങ്ങൾ