ProtectHome vs TOTP വിത്ത്: VPN ലോഗിൻ എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

ഓതന്റിക്കേറ്റർ പുതിയ ആറ് അക്ക സംകേതം കാണിക്കുന്നു, VPN അത് നിരസിക്കുന്നു, അതേ സംകേതം നിങ്ങളുടെ സ്വന്തം ഷെല്ലിൽ നിന്ന് പരീക്ഷിക്കുമ്പോൾ കൃത്യമായി സ്ഥിരീകരിക്കുന്നു. ഈ വിടവാണ് മുഴുവൻ കഥ. രജിസ്ട്രേഷൻ രഹസ്യം തുറക്കാനാകാത്ത PAM മൊഡ്യൂൾ തെറ്റായ സംകേതത്തിന് സമാനമായി കാണുന്ന പരാജയം തിരികെ നൽകുന്നു, ഹോം ഡയറക്ടറികൾ മറയ്ക്കുന്ന സേവന പരിസ്ഥിതിയാണ് ഇതിന് സാധാരണ കാരണം. ഏതെങ്കിലും അനുമതി ലഘൂകരിക്കുന്നതിന് മുമ്പ് നിങ്ങൾ മൂന്ന് സാഹചര്യങ്ങളിൽ ഏതിലാണെന്ന് തീരുമാനിക്കുക.

മൂന്ന് പരാജയങ്ങളിൽ ഏതാണ് ഇത്?

ആദ്യത്തേത് മൊഡ്യൂളിന് വായിക്കാൻ കഴിയാത്ത രഹസ്യമാണ്. രണ്ടാമത്തേത് വായിക്കാം പക്ഷേ പുതുക്കാൻ കഴിയാത്ത രഹസ്യമാണ്. മൂന്നാമത്തേത് യഥാർത്ഥത്തിൽ തെറ്റായ സംകേതം ആണ്, സാധാരണയായി ക്ലോക്ക് ഡ്രിഫ്റ്റ് അല്ലെങ്കിൽ വീണ്ടും ഉപയോഗിച്ച മൂല്യം കാരണം.

ഒരു പരാജയപ്പെട്ട ശ്രമത്തിനായി സേവന ജേണലും സിസ്റ്റം ഓതന്റിക്കേഷൻ ലോഗും വായിച്ച് അവയെ വേർതിരിക്കുക, തുടർന്ന് പ്ലഗിൻ ഏത് PAM സേവനം ലോഡ് ചെയ്യുന്നുവെന്നും ആ സേവനം ഏത് മൊഡ്യൂൾ വരി ഉപയോഗിക്കുന്നുവെന്നും സ്ഥിരീകരിക്കുക. സാധാരണ ഓതന്റിക്കേഷൻ പരാജയ സന്ദേശം അവയെ വേർതിരിക്കുന്നില്ല, വിജയകരമായ കൈയിൽ പരീക്ഷയും ഇല്ല, കാരണം നിങ്ങളുടെ ഷെൽ സേവനത്തിന്റെ പരിസ്ഥിതിയല്ല.

സേവനം മാത്രം പരാജയപ്പെടുമ്പോൾ യൂണിറ്റിന്റെ ഫയൽസിസ്റ്റം കാഴ്ചയാണ് സാധാരണ കുറ്റവാളി.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

ഓപ്ഷൻ A: രഹസ്യം ഹോമിന് പുറത്തേക്ക് മാറ്റുക

സേവനം /home മറയ്ക്കുകയും ആ സംരക്ഷണം നിലനിർത്താൻ നിങ്ങൾ ആഗ്രഹിക്കുകയും ചെയ്യുമ്പോൾ, അത് കാണാൻ കഴിയുന്ന ഇടത്ത് രഹസ്യം സൂക്ഷിക്കുക. മൊഡ്യൂൾ secret= പാതയും ഫയൽ പ്രവർത്തനങ്ങൾ ചെയ്യുന്ന user= അക്കൗണ്ടും സ്വീകരിക്കുന്നു, ഇത് ഒരു കേന്ദ്ര സംഭരണിയെ നിരവധി ഐഡന്റിറ്റികൾക്ക് സേവനം നൽകാൻ അനുവദിക്കുന്നു.

ഇതാണ് വൃത്തിയുള്ള ഓപ്ഷൻ, ഇതിനാണ് ഏറ്റവും കൂടുതൽ ശ്രദ്ധ വേണ്ടത്, കാരണം പങ്കിട്ട സംഭരണി ഒരു ഡയറക്ടറിയെ ഓരോ അക്കൗണ്ടിന്റെയും സുരക്ഷാ അതിർത്തിയാക്കുന്നു.

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

അതിൽ വിശ്വസിക്കുന്നതിന് മുമ്പ് മൂന്ന് കാര്യങ്ങൾ പരിശോധിക്കുക: അക്കൗണ്ട് നിലവിലുണ്ട്, മൊഡ്യൂളിന്റെ പ്രവർത്തന പ്രക്രിയ അതിലേക്ക് മാറാൻ കഴിയും, ഫയലുകൾ നിയന്ത്രിത മോഡുകളോടെ അതിന്റെ ഉടമസ്ഥതയിലാണ്. user=-നൊപ്പം ~ അല്ലെങ്കിൽ ഹോം വേരിയബിൾ പാത ഉപയോഗിക്കരുത്, പാത പ്രവർത്തിക്കാൻ മൊഡ്യൂളിന്റെ ഉടമസ്ഥാവകാശ പരിശോധനകൾ അപ്രാപ്തമാക്കരുത്. പാസ്വേഡ് ഘട്ടവും ബാക്കി സ്റ്റാക്കും അക്ഷതമായി സൂക്ഷിക്കുക.

ഓപ്ഷൻ B: ഫയൽ വിട്ട് ഒരു പാത തുറക്കുക

രഹസ്യം ഉപയോക്താവിന്റെ ഹോമിൽ തന്നെ നിലനിൽക്കണമെങ്കിൽ, ഹോസ്റ്റിലെ എല്ലാ ഹോമുകളും വെളിപ്പെടുത്താതെ ആ ഒരു ഡയറക്ടറി ഉൾപ്പെടുത്തുന്ന കാഴ്ച യൂണിറ്റിന് വേണം. drop-in സാൻഡ്ബോക്സ് ചെയ്ത ഹോമിന് കീഴിൽ ഇടുങ്ങിയ പരിധിയിലുള്ള ബൈൻഡ് മൗണ്ട് ചേർക്കാം.

ഇത് ഉപയോക്താവിനനുസരിച്ചുള്ള ഉടമസ്ഥതയെ മാതൃകയായി നിലനിർത്തുന്നു, എന്നാൽ സാൻഡ്ബോക്സ് മാറുമ്പോഴെല്ലാം അവലോകനം ചെയ്യേണ്ട യൂണിറ്റ് മാറ്റത്തിന്റെ ചെലവിൽ.

രണ്ട് പരിധികൾ എളുപ്പത്തിൽ വിട്ടുപോകാം. സാൻഡ്ബോക്സ് മറയ്ക്കുന്ന ഡയറക്ടറിക്ക് കീഴിൽ ചേർക്കുന്ന വായന-മാത്ര പാത അത് വെളിപ്പെടുത്തുന്നില്ല, കാരണം മാതൃ ഡയറക്ടറി അവിടെ ഇല്ല. മൊഡ്യൂൾ അവസ്ഥ പുതുക്കേണ്ടതുണ്ടെങ്കിൽ മൗണ്ട് എഴുതാവുന്നതായിരിക്കണം, അത് അടുത്ത ഓപ്ഷനെ കളത്തിലിറക്കുന്നു. /usr/lib-ന് കീഴിലുള്ള പാക്കേജ് ചെയ്ത യൂണിറ്റ് തിരുത്തുന്നതിന് പകരം drop-in ഒരു പ്രത്യേക ഫയലായി എഴുതുക, പാക്കേജ് അപ്ഗ്രേഡ് അത് നിശ്ശബ്ദമായി റദ്ദാക്കാതിരിക്കാൻ.

ഓപ്ഷൻ C: സാൻഡ്ബോക്സ് നിലനിർത്തി അവസ്ഥാ എഴുത്തുകൾ ശരിയാക്കുക

രഹസ്യം വായിക്കുന്നത് ഓതന്റിക്കേഷന്റെ പകുതി മാത്രം. സമയ വ്യതിയാന വിവരങ്ങൾ, റീപ്ലേ സംരക്ഷണം അല്ലെങ്കിൽ ഒരു കൗണ്ടർ മൊഡ്യൂൾ വീണ്ടും എഴുതാം, വായന പരിശോധന കടന്ന ഫയൽ എഴുത്തിൽ ഇപ്പോഴും പരാജയപ്പെടാം.

ആ പരാജയം ഈ ശ്രമത്തിലല്ല, അടുത്ത ശ്രമത്തിൽ മോശം സംകേതം പോലെ തോന്നുന്നു, അതിനാലാണ് അതിനെ ക്ലോക്ക് ഡ്രിഫ്റ്റായി തെറ്റിദ്ധരിക്കുന്നത്.

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

നിങ്ങളായല്ല, സേവനമായി പരിശോധിക്കുക

പ്രധാനപ്പെട്ട ഓരോ പരിശോധനയും യൂണിറ്റിന്റെ സാൻഡ്ബോക്സിനുള്ളിൽ യൂണിറ്റിന്റെ ഐഡന്റിറ്റിയോടെ പ്രവർത്തിക്കണം.

root ആയി വിജയിക്കുന്ന കമാൻഡ് ഫയൽ നിലവിലുണ്ടെന്ന് മാത്രം പറയുന്നു. യഥാർത്ഥ സേവനത്തിലൂടെയുള്ള ലോഗിൻ മൊഡ്യൂളിന് രഹസ്യം വായിക്കാമോ, ഉപയോഗിക്കാമോ, ആവശ്യമുള്ളത് തിരികെ എഴുതാമോ എന്ന് പറയുന്നു.

അവസാനമായി, ആവശ്യകത അക്ഷതമായി നിലനിർത്തുക. പൂജ്യ-പാസ്വേഡ് ഓപ്ഷൻ ചേർക്കുക, വായന-മാത്ര പരാജയങ്ങൾ സ്വീകരിക്കുക അല്ലെങ്കിൽ സാൻഡ്ബോക്സ് നീക്കുക — ഇവയെല്ലാം നയം മാറ്റി ലക്ഷണം അപ്രത്യക്ഷമാക്കും. സംകേതം അവതരിപ്പിക്കേണ്ട ഉപയോക്താവിനെ രഹസ്യം ലഭ്യമല്ലാത്തപ്പോഴും നിരസിക്കണം.