PAM മൊഡ്യൂൾ അപരിചിതമാണ്: യഥാർത്ഥത്തിൽ ഏത് പ്രോസസ്സാണ് പരാജയപ്പെട്ടത്

ആ വാക്യത്തെ പാസ്വേഡിനെക്കുറിച്ചല്ല, പങ്കിട്ട ഒരു ഒബ്ജക്ടിനെയും ഫംഗ്ഷൻ പോയിന്ററിനെയും കുറിച്ചുള്ള പ്രസ്താവനയായി വായിക്കുക. അതേ വാക്കുകൾ ഒരു OpenVPN പ്ലഗിനിൽ നിന്നും, ഒരു സേവനത്തിനായി ലോഡ് ചെയ്ത PAM സ്റ്റാക്കിൽ നിന്നും, അല്ലെങ്കിൽ RADIUS ഡീമണിന്റെ ഉള്ളിൽ നിന്നും വരാം, ഇവ മൂന്ന് വ്യത്യസ്ത അന്വേഷണങ്ങളാണ്. ആദ്യം പ്രോസസ്സ് നിർണ്ണയിക്കുക.

താഴെയുള്ള പരിശോധനകൾ സന്ദേശം VPN ലോഗിനിൽ Linux-PAM സംയോജനത്തിലൂടെ വന്നതാണെന്ന് അനുമാനിക്കുന്നു. അത് RADIUS സെർവറിന്റെ സ്വന്തം കോൺഫിഗറേഷനിൽ നിന്നാണ് വന്നതെങ്കിൽ, ആ ഡീമണിന്റെ തെളിവുകളിൽ നിന്ന് തുടങ്ങുക.

പാക്കേജിന് പേരിടുന്നതിന് മുമ്പ് പ്രോസസ്സിന് പേരിടുക

മൂന്ന് ഘടകങ്ങളെ മൊഡ്യൂൾ എന്ന് വിളിക്കുന്നു, അവയൊന്നും പരസ്പരം മാറ്റാവുന്നതല്ല. OpenVPN പ്രാമാണീകരണ പ്ലഗിൻ VPN ഡീമൺ ലോഡ് ചെയ്യുന്നു, അത് ആ ഡീമണിന്റെ കോൾബാക്ക് ഇന്റർഫേസ് നടപ്പാക്കുന്നു. PAM മൊഡ്യൂൾ ഒരു പങ്കിട്ട ഒബ്ജക്ടാണ്, അതിനെ libpam ഒരു നാമിത സേവനത്തിനായി ലോഡ് ചെയ്യുന്നു, കൂടാതെ ഇത്തരം എൻട്രി പോയിന്റുകൾ നടപ്പാക്കുന്നു: pam_sm_authenticate. FreeRADIUS മൊഡ്യൂൾ ആ ഡീമണിന്റെ സ്വന്തം കോൺഫിഗറേഷന്റെ ഒരു ഭാഗമാണ്. അതേ വാക്കുകളുള്ള സന്ദേശം മൂന്നിൽ ഏതിൽ നിന്നും വരാം, അതിനാൽ ആദ്യ ചോദ്യം ഏത് ലോഗ് വരിയാണ് അത് സൃഷ്ടിച്ചത് എന്നതാണ്.

ഒരു പരാജയപ്പെട്ട ശ്രമത്തിന്റെ സമയമുദ്ര VPN ലോഗും സിസ്റ്റം പ്രാമാണീകരണ ലോഗും തമ്മിൽ ചേർത്ത് നോക്കി, ശേഷം സംഗ്രഹത്തിന് മുമ്പുള്ള വരികൾ വായിക്കുക. നിർദ്ദിഷ്ട ലോഡർ സന്ദേശം സാധാരണയായി അവിടെ തന്നെ ഉണ്ടാകും.

ലോഡിംഗ് പിശക് വായിക്കുക, ശേഷം എൻട്രി പോയിന്റ്

തിരഞ്ഞെടുത്ത പങ്കിട്ട ഒബ്ജക്ട് ലോഡ് ചെയ്യാനാകാത്തപ്പോൾ, അല്ലെങ്കിൽ ലോഡ് ചെയ്ത ഒബ്ജക്ട് ആ സ്റ്റാക്ക് എൻട്രിക്ക് ആവശ്യമായ ഫംഗ്ഷൻ നൽകാത്തപ്പോൾ PAM അപരിചിതമായ മൊഡ്യൂൾ റിപ്പോർട്ട് ചെയ്യുന്നു. ഇവ വ്യത്യസ്ത അറ്റകുറ്റപ്പണികളാണ്: ആദ്യത്തേത് പാത, പാക്കേജിംഗ് അല്ലെങ്കിൽ ABI പ്രശ്നമാണ്, രണ്ടാമത്തേത് പൊരുത്തപ്പെടാത്ത എൻട്രി പോയിന്റാണ്. പ്രാമാണീകരണ വരിക്ക് ആവശ്യമാണ് pam_sm_authenticate എന്നാൽ അക്കൗണ്ട് വരിക്ക് ആവശ്യമാണ് pam_sm_acct_mgmt, കൂടാതെ അവയിൽ ഒന്ന് മാത്രം നടപ്പാക്കുന്ന ലൈബ്രറി മറ്റേതിൽ പരാജയപ്പെടും, അയയ്ക്കുന്നവന്റെ കോഡ് കാണിക്കുന്നതുപോലെ. ഡിസ്കിൽ ഫയൽ കണ്ടെത്തുന്നത് രണ്ടും തെളിയിക്കുന്നില്ല.

മറ്റൊരു വിതരണത്തിൽ നിന്നോ CPU ആർക്കിടെക്ചറിൽ നിന്നോ സമാന നാമമുള്ള ലൈബ്രറി എടുക്കുന്നത് അറ്റകുറ്റപ്പണിയല്ല, അത് ഒരു പ്രോസസ്സിനെ അതിന്റെ libpam-നെതിരെ ഒരിക്കലും പരിശോധിക്കാത്ത മൊഡ്യൂൾ ലോഡ് ചെയ്യാൻ വിട്ടേക്കാം. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഉദ്ദേശിച്ച പാതയുടെ ഉടമസ്ഥ പാക്കേജും ഫയലിന്റെ യഥാർത്ഥ ആർക്കിടെക്ചറും പരിശോധിക്കുക.

സ്റ്റാക്ക് നൽകിയ ഉറപ്പുകൾ നിലനിർത്തുക

ഈ പിശക് നിശ്ശബ്ദമാക്കാനുള്ള ഏറ്റവും വേഗതയുള്ള മാർഗം ഏറ്റവും മോശവുമാണ്: നിർബന്ധിത മൊഡ്യൂളിനെ ഐച്ഛികമായി അടയാളപ്പെടുത്തുക, അക്കൗണ്ട് ഘട്ടം ഇല്ലാതാക്കുക, അല്ലെങ്കിൽ നിരുപാധിക അനുമതി ചേർക്കുക. ഇവയോരോന്നും പരാജയപ്പെട്ട പരിശോധനയെ ഇല്ലാത്ത പരിശോധനയാക്കി മാറ്റുന്നു, പിന്നീട് ലോഗിൻ ആരും ഉദ്ദേശിക്കാത്ത കാരണങ്ങളാൽ വിജയിക്കുന്നു. പാസ്വേഡ് പുനഃസജ്ജീകരണവും പങ്കിട്ട രഹസ്യത്തിന്റെ മാറ്റവും കാണാത്ത ഫംഗ്ഷൻ നൽകുന്നില്ല, കാരണം ഏതെങ്കിലും ക്രെഡൻഷ്യൽ ബാക്ക്എൻഡിൽ എത്തുന്നതിന് മുമ്പേ പരാജയം സംഭവിക്കുന്നു.

ഒന്നിലധികം മൊഡ്യൂളുകളുള്ള സ്റ്റാക്ക് പരാജയപ്പെട്ട എൻട്രിക്ക് മുമ്പ് മറ്റൊരു ബാക്ക്എൻഡ് പ്രവർത്തിപ്പിച്ചിരിക്കാം, അതിനാൽ ഈ പിശക് RADIUS അഭ്യർത്ഥന അയച്ചിട്ടില്ലെന്ന് തെളിയിക്കുന്നില്ല.

മൊഡ്യൂളല്ല, ലോഗിൻ പരിശോധിക്കുക

പൊരുത്തക്കേട് തിരുത്തിയ ശേഷം യഥാർത്ഥ പ്രവേശന പാത പരിശോധിക്കുക. സാധുവായ അക്കൗണ്ട് വിജയിക്കണം, അസാധുവായ ക്രെഡൻഷ്യലുകൾ ഇപ്പോഴും പരാജയപ്പെടണം, നിരോധിത അക്കൗണ്ട് ഇപ്പോഴും നിരസിക്കപ്പെടണം. സർട്ടിഫിക്കറ്റോ അധിക ഘടകമോ ഉള്ള ഏതെങ്കിലും ആവശ്യകത ഇപ്പോഴും നടപ്പാക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക, കാരണം ഘട്ടം ഒഴിവാക്കുന്ന തിരുത്തിയ സ്റ്റാക്ക് ക്ലയന്റിന്റെ ഭാഗത്ത് നിന്ന് വിജയമായി തോന്നുന്നു.

മൊഡ്യൂൾ വ്യക്തമായി ലോഡ് ചെയ്യുന്നത് പുരോഗതിയാണ്, പൂർത്തിയായ പരീക്ഷയല്ല.

ഏത് സേവന നാമം, ഏത് നയ ഫയലുകൾ, ഏത് എൻട്രി പോയിന്റുകൾ എന്നിവ ഉൾപ്പെട്ടിരുന്നുവെന്ന് തെളിവായി ഉപയോഗിച്ച ഏക ശ്രമത്തോടൊപ്പം രേഖപ്പെടുത്തുക. ആ രേഖയാണ് അടുത്ത സംഭവത്തെ പുരാവസ്തു അഭ്യാസത്തിന് പകരം തിരച്ചിലാക്കി മാറ്റുന്നത്.