VPN MFA അഭ്യർത്ഥന നിരസിച്ചു: ക്ലൈന്റ് എന്തു ചെയ്യണം

നിരസിച്ച MFA അഭ്യർത്ഥന ഒരു നെറ്റ്വർക്ക് പ്രശ്നമായി തോന്നും, പക്ഷേ അല്ല. സെർവർ രണ്ടാമതൊരു ഘടകം ആവശ്യപ്പെട്ടു, ഘടകം നെഗറ്റീവായി തിരിച്ചുവന്നു അല്ലെങ്കിൽ ഒരിക്കലും എത്തിയില്ല, ഏതെങ്കിലും ടണൽ ഉണ്ടാകുന്നതിനു മുമ്പുതന്നെ സെഷൻ നിരസിക്കപ്പെട്ടു. ശേഷം സംഭവിക്കുന്നത് ക്ലൈന്റിന്റെ പെരുമാറ്റത്തിന്റെ ചോദ്യമാണ്: പരാജയം കാണിച്ച് ഉപയോക്താവിനെ ഒരു ശുദ്ധമായ ശ്രമം തുടങ്ങാൻ അനുവദിക്കുക, അല്ലെങ്കിൽ കൂടുതൽ അഭ്യർത്ഥനകൾ സൃഷ്ടിച്ച് ഒടുവിൽ അക്കൗണ്ട് സംരക്ഷണം പ്രവർത്തിപ്പിക്കുന്ന രീതിയിൽ വീണ്ടും ശ്രമിക്കുക. രണ്ടാമത്തെ വഴിയാണ് ഒരു തെറ്റായി ടൈപ്പ് ചെയ്ത കോഡിനെ ലോക്ക് ചെയ്ത അക്കൗണ്ടാക്കി മാറ്റുന്നത്.

ഏത് അഭ്യർത്ഥനയാണ് പരാജയപ്പെട്ടതെന്ന് പരിശോധിക്കുക

ഏത് അഭ്യർത്ഥനയാണ് പരാജയപ്പെട്ടതെന്ന് തിരിച്ചറിഞ്ഞുകൊണ്ട് തുടങ്ങുക. പുഷ് അറിയിപ്പ്, TOTP കോഡ്, FIDO സമർത്ഥന, SAML പ്രവാഹം എന്നിവ ഓരോന്നും വ്യത്യസ്തമായാണ് പരാജയപ്പെടുന്നത്, ഏതാണ് ആവശ്യപ്പെട്ടതെന്ന് ക്ലൈന്റിന് സാധാരണ അറിയാം. നിരസിക്കൽ, കാലഹരണപ്പെട്ട ചലഞ്ച്, ഉപകരണത്തിലെത്താത്ത ഡെലിവറി പരാജയം എന്നിവയെല്ലാം ഒരേ പൊതു പിശകിൽ അവസാനിക്കുന്നു, അതിനാൽ വ്യത്യാസം പലപ്പോഴും ക്ലൈന്റിന്റെ സ്വന്തം അവസ്ഥയിൽ മാത്രം അവശേഷിക്കുന്നു.

ആ അവസ്ഥ കൃത്യമായി രേഖപ്പെടുത്താൻ യോഗ്യമാണ്. ചലഞ്ച് ഐഡന്റിഫയർ അല്ലെങ്കിൽ ഇടപാട് റഫറൻസ്, ഘടകത്തിന്റെ തരം, സമയമുദ്ര, ഫലം എന്നിവ രേഖപ്പെടുത്തുക, പക്ഷേ കോഡോ സമർത്ഥനയോ ഒരിക്കലും രേഖപ്പെടുത്തരുത്. ചലഞ്ച് ഐഡന്റിഫയറാണ് അഡ്മിനിസ്ട്രേറ്ററെ ഐഡന്റിറ്റി ദാതാവിന്റെ ഭാഗത്ത് സംഭവം കണ്ടെത്താൻ അനുവദിക്കുന്നത്; അതില്ലാതെ പിന്തുണ സംഭാഷണം “കഴിഞ്ഞ മണിക്കൂറിൽ എവിടെയോ” എന്നു തുടങ്ങി സാധാരണ അവിടെ അവസാനിക്കുന്നു. ഇതിനെ രഹസ്യമല്ലാത്ത ഡയഗ്നോസ്റ്റിക് മെറ്റാഡാറ്റയായി കാണുക.

പുതിയ ചലഞ്ചുമായി ഒരിക്കൽ, ഉദ്ദേശപൂർവ്വം വീണ്ടും ശ്രമിക്കുക

വീണ്ടും ശ്രമിക്കൽ പുതിയ ചലഞ്ചുള്ള പുതിയ ശ്രമമായിരിക്കണം, പഴയതിന്റെ പുനരാവിഷ്കാരമല്ല. ക്ലൈന്റ് മുൻ ചലഞ്ച് വീണ്ടും ഉപയോഗിക്കുമ്പോൾ, ഐഡന്റിറ്റി ദാതാവ് അതിനെ കാലഹരണപ്പെട്ടതായി നിരസിക്കുകയോ, അതിലും മോശമായി, മുൻ ശ്രമത്തിനായി ഉദ്ദേശിച്ച അനുമതി സ്വീകരിക്കുകയോ ചെയ്യുന്നു. പുതിയ ചലഞ്ച് ആവശ്യപ്പെടുക, അത് കാണിക്കുക, ഇപ്പോൾ സ്ക്രീനിലുള്ള ചലഞ്ചിൽ ഉപയോക്താവിനെ പ്രവർത്തിക്കാൻ അനുവദിക്കുക.

ഇടയിൽ ചെറിയ ഇടവേളയുള്ള രണ്ട് ശ്രമങ്ങൾ ന്യായമായ സ്വതേ മൂല്യമാണ്; അനന്തമായ ലൂപ്പല്ല. രണ്ടാമത്തെ ശ്രമം അതേ രീതിയിൽ പരാജയപ്പെട്ടാൽ, തുടരുന്നതിനുപകരം നിർത്തി റിപ്പോർട്ട് ചെയ്യുക.

ക്ലൈന്റ് ചെയ്യരുതാത്തത്

സഹായകരമെന്നു തോന്നുന്ന പക്ഷേ അല്ലാത്ത കുറച്ച് കാര്യങ്ങൾ ക്ലൈന്റ് ചെയ്യരുത്. ആരെങ്കിലും “അനുമതി” ടാപ്പ് ചെയ്യുന്നതുവരെ പുഷ് അറിയിപ്പുകൾ അയച്ചുകൊണ്ടിരിക്കരുത്, കാരണം അത് ഉപയോക്താക്കളെ തങ്ങൾ ആരംഭിക്കാത്ത അഭ്യർത്ഥനകൾ അനുവദിക്കാൻ പഠിപ്പിക്കുന്നു, ഫിഷിംഗ് കിറ്റുകൾ കൃത്യമായി ആ പെരുമാറ്റത്തെയാണ് ആശ്രയിക്കുന്നത്. ശക്തമായ ഘടകം പരാജയപ്പെട്ടതിനാൽ ദുർബലമായ ഘടകത്തിലേക്ക് പിന്മാറരുത്, അതേസമയം പ്രത്യക്ഷപ്പെട്ട സർട്ടിഫിക്കറ്റ് പരാതി ഒഴിവാക്കാൻ സെർവർ ഐഡന്റിറ്റി പരിശോധന നിർത്തലാക്കരുത്. ഈ മൂന്ന് കുറുക്കുവഴികളിൽ ഓരോന്നും ഒരു പ്രാമാണീകരണ പരാജയത്തെ സുരക്ഷാ സംഭവമാക്കി മാറ്റുന്നു.

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

അഭ്യർത്ഥന കീബോർഡിനു മുന്നിലുള്ള വ്യക്തി ആരംഭിച്ചതല്ലെങ്കിൽ, ശരിയായ പ്രവർത്തനം അത് നിരസിച്ച നിലയിൽ വിട്ട് പരിശോധിച്ച പിന്തുണാ മാർഗത്തിലൂടെ റിപ്പോർട്ട് ചെയ്യുകയാണ്. ബഹളം നിർത്താൻ അഭ്യർത്ഥന അനുവദിക്കുന്നത് പരാജയ മാതൃകയാണ്, പരിഹാരമല്ല.

പിന്തുണയ്ക്കായി എന്ത് രേഖപ്പെടുത്തണം

പിന്തുണയ്ക്ക് ഉപയോഗപ്രദമായ രേഖ ചെറുതാണ്. സമയ മേഖലയോടുകൂടിയ ഏകദേശ സമയം, അക്കൗണ്ട്, ക്ലൈന്റും പതിപ്പും, ഘടകത്തിന്റെ തരം, ഓരോ ശ്രമത്തിന്റെയും രഹസ്യമല്ലാത്ത നില: ആവശ്യപ്പെട്ടു, നിരസിച്ചു, കാലഹരണപ്പെട്ടു, അനുവദിച്ചു പക്ഷേ നയം നിരസിച്ചു.

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

വീണ്ടെടുപ്പിന്റെ വഴി ലോഗിന്റെ വഴിയോളം പരിചരണം അർഹിക്കുന്നു. നഷ്ടപ്പെട്ട ഉപകരണത്തിനുള്ള പ്രവാഹം നിരസിക്കൽ പ്രാമാണീകരണം ഒഴിവാക്കാനുള്ള അനുമതിയാകാതിരിക്കാൻ വേണ്ടിത്തന്നെ നിലനിൽക്കുന്നു, സ്വന്തമായി ഒന്ന് കെട്ടിച്ചമയ്ക്കുന്നതിനുപകരം സംഘടനയുടെ രേഖപ്പെടുത്തിയ പ്രക്രിയയിലേക്ക് ക്ലൈന്റ് ലിങ്ക് ചെയ്യണം.

കെട്ടിപ്പടുക്കേണ്ട നിയമം ഇതാണ്: നിരസിക്കൽ ഒരു ഫലമാണ്, തടസ്സമല്ല. ഒരിക്കൽ, വ്യക്തമായി, പ്രവർത്തിക്കാൻ മതിയായ സന്ദർഭത്തോടെ റിപ്പോർട്ട് ചെയ്യുക, അടുത്ത ശ്രമം പുതിയതാകട്ടെ. ഫിഷിംഗ് പ്രതിരോധ MFA സംബന്ധിച്ച CISA മാർഗനിർദ്ദേശം “അനുമതി ലഭിക്കുന്നതുവരെ ചോദിക്കുക” എന്ന മാതൃക തുടക്കം മുതലേ അപകടകരമാകുന്നത് എന്തുകൊണ്ടെന്ന് വിശദീകരിക്കുന്നു, ആരെങ്കിലും വീണ്ടും ശ്രമിക്കുന്ന ലൂപ്പ് നിർദ്ദേശിക്കുമ്പോൾ ഉദ്ധരിക്കാൻ യോഗ്യമായ ആധാരം അതാണ്. നിരസിക്കലിനു ശേഷം ക്ലൈന്റ് ചേർക്കുന്നതെല്ലാം അടുത്ത തീരുമാനം മനുഷ്യന് എളുപ്പമാക്കണം, തീരുമാനം അവനിൽനിന്ന് എടുത്തുകളയരുത്.