OpenVPN-ലേക്ക് RADIUS ചേർക്കൽ: പ്ലഗിൻ അതോ സ്ക്രിപ്റ്റ് ഹുക്കോ?

നിലവിലെ ബിൽഡുകളേക്കാൾ പഴയ ത്രെഡുകളിൽ പ്ലഗിൻ ഇപ്പോഴും ശുപാർശ ചെയ്യപ്പെടുന്നു, ഇന്നലെ കമ്പൈൽ ചെയ്ത സെർവറിൽ അത് ലോഡ് ചെയ്യുമ്പോൾ പരാജയപ്പെടുന്നു. ഒരു പാത്ത് കൊണ്ട് പരിഹരിക്കാവുന്ന കോൺഫിഗറേഷൻ പിശകല്ല ഇത്. പ്ലഗിനും സ്ക്രിപ്റ്റ് ഹുക്കും ഒരേ പ്രശ്നം വ്യത്യസ്ത പാളികളിൽ പരിഹരിക്കുന്നു, ഒന്നിൽ നിന്ന് മറ്റൊന്നിലേക്ക് മാറുന്നത് എന്ത് ഇൻസ്റ്റാൾ ചെയ്യണം, എന്ത് സെർവർ അനുമതികളോടെ പ്രവർത്തിക്കുന്നു, പരാജയപ്പെട്ട ലോഗിൻ യഥാർത്ഥത്തിൽ എന്ത് പറയുന്നു എന്നിവ മാറ്റുന്നു.

മിത്ത്: പ്ലഗിനാണ് പിന്തുണയ്ക്കുന്ന വഴി

പ്ലഗിൻ എന്നത് OpenVPN പ്രോസസ്സിലേക്ക് ലോഡ് ചെയ്യുന്ന പങ്കിട്ട ഒബ്ജക്ടാണ്, അതിനാൽ ആ പ്രോസസ്സ് നൽകുന്ന ഇന്റർഫേസുമായി അത് പൊരുത്തപ്പെടണം. ബിൽഡുകൾ മാറുന്നു, പാക്കേജിംഗ് മാറുന്നു, പഴയ ഇന്റർഫേസിനായി കമ്പൈൽ ചെയ്ത ലൈബ്രറി ലോഡ് ചെയ്യാൻ വിസമ്മതിക്കുന്നു. സെർവർ കോൺഫിഗറേഷനിൽ ഒന്നിനും ആ വിടവ് നികത്താനാവില്ല, അതിനാൽ "radiusplugin ഇൻസ്റ്റാൾ ചെയ്താൽ മതി" എന്ന ഉപദേശം ആരംഭിക്കാത്ത സെർവറിൽ അവസാനിക്കുന്നു.

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

ഒരു സമീപനവും നിർമ്മാണപരമായി കൂടുതൽ സുരക്ഷിതമല്ല. ഒന്ന് ഡീമണിനുള്ളിൽ വിദേശ കോഡ് പ്രവർത്തിപ്പിക്കുന്നു; മറ്റൊന്ന് ക്രെഡൻഷ്യലുകൾ കൈയിൽ പിടിച്ച് നിങ്ങളുടെ കോഡ് അതിനൊപ്പം പ്രവർത്തിപ്പിക്കുന്നു. ഈ രണ്ട് അപകടങ്ങളിൽ ഏതാണ് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ കൈകാര്യം ചെയ്യാനാകുന്നത് എന്നതാണ് ശരിയായ ചോദ്യം.

പ്ലഗിൻ എന്താണ് ഒരുമിച്ച് ബന്ധിച്ചത്

RADIUS ഹോസ്റ്റ്, പങ്കിട്ട രഹസ്യം, വീണ്ടും ശ്രമങ്ങളുടെ എണ്ണം, സമയപരിധി എന്നിവയുള്ള സ്വന്തം കോൺഫിഗറേഷൻ ഫയൽ പ്ലഗിനിനുണ്ടായിരുന്നു, സെർവർ കോൺഫിഗറേഷൻ ഒരു വരിയിൽ അതിനെ പരാമർശിച്ചു. ക്രെഡൻഷ്യൽ കൈകാര്യം ചെയ്യൽ സെർവർ പ്രോസസ്സിനുള്ളിൽ തുടർന്നു, അതായത് പാസ്വേഡ് അഡ്മിനിസ്ട്രേറ്റർ സുരക്ഷിതമാക്കേണ്ട ഒരു പ്രോസസ്സ് അതിർത്തിയും ഒരിക്കലും കടന്നില്ല.

വില ബന്ധനമായിരുന്നു. ഓരോ OpenVPN അപ്ഗ്രേഡും പൊരുത്തപ്പെടാത്ത ഇന്റർഫേസ് അപകടത്തിലാക്കി, പാക്കേജ് പുനർനിർമ്മിക്കുന്ന ഓരോ വിതരണവും ഇനി പൊരുത്തപ്പെടാത്ത ലൈബ്രറി നിർമ്മിക്കാനുള്ള അപകടത്തിലായിരുന്നു. അത് സംഭവിക്കുമ്പോൾ പരാജയം ഉച്ചത്തിലും തൽക്ഷണവുമാണ്, അതാണ് ഡിസൈനിന്റെ ഏക കരുണ.

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

സ്ക്രിപ്റ്റ് ഹുക്ക് യഥാർത്ഥത്തിൽ എന്തിൽ വിശ്വസിക്കുന്നു

auth-user-pass-verify ഉം ഒരു ഡെലിവറി മെക്കാനിസവും ഉപയോഗിച്ചാണ് ഹുക്ക് കോൺഫിഗർ ചെയ്യുന്നത്: എൻവയൺമെന്റ് വേരിയബിളുകൾ അല്ലെങ്കിൽ ഒരു താൽക്കാലിക ഫയൽ. എൻവയൺമെന്റ് രൂപത്തിൽ OpenVPN-ന് script-security 3 ആവശ്യമാണ്, സ്ക്രിപ്റ്റുകൾക്ക് പാസ്വേഡ് വെളിപ്പെടുത്താൻ അനുവദിക്കുന്ന രേഖപ്പെടുത്തിയ നില. ആ നില ഡിഫോൾട്ടിന്റെ ബോധപൂർവമായ ദുർബലതയാണ്, ന്യായീകരണം ചേർത്ത അനുമതിയായി അതിനെ കാണണം.

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

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

ഫയൽ ഡെലിവറി രൂപം പരിസ്ഥിതി പാരമ്പര്യ പ്രശ്നം ഒഴിവാക്കുന്നു, പരിമിത അനുമതികളുള്ള താൽക്കാലിക ഫയലിലൂടെ സ്ക്രിപ്റ്റിന് ക്രെഡൻഷ്യലുകൾ നൽകുന്നു. നിങ്ങളുടെ ക്ലയന്റ് അത് പിന്തുണയ്ക്കുന്നുവെങ്കിൽ, അത് സാധാരണയായി മികച്ച ഡിഫോൾട്ടാണ്, പരാജയത്തിൽ വൃത്തിയാക്കാൻ ഒരു ഒബ്ജക്ട് കൂടി ചേർക്കുന്നുവെങ്കിലും.

എക്സിറ്റ് കോഡുകൾ തുറന്ന് പരാജയപ്പെടുമോ എന്ന് തീരുമാനിക്കുന്നു

സ്ക്രിപ്റ്റിന്റെ എക്സിറ്റ് നിലയാണ് വിധി: പൂജ്യം സ്വീകരിക്കുന്നു, പൂജ്യമല്ലാത്തത് നിരസിക്കുന്നു. പ്രശ്നമുണ്ടാക്കുന്ന മാതൃക RADIUS മറുപടിയിൽ ഒരു നിർദ്ദിഷ്ട സ്വീകാര്യ ടോക്കൺ ഉള്ളപ്പോൾ മാത്രം സ്വീകരിച്ച് ബാക്കിയെല്ലാത്തിനും പരാജയം നൽകുന്ന ഷെൽ സ്ക്രിപ്റ്റാണ്, കാരണം അത് മൂന്ന് വ്യത്യസ്ത സംഭവങ്ങളെ ഒരു ഉത്തരത്തിൽ ലയിപ്പിക്കുന്നു. തെറ്റായ പാസ്വേഡ്, എത്തിച്ചേരാനാകാത്ത സെർവർ, വികലമായ മറുപടി എന്നിവയെല്ലാം ഒരേ നിരസിക്കലായി മാറുന്നു.

ഹുക്കിന് സ്വീകാര്യതയോ നിരസിക്കലോ മാത്രം നൽകാനാകുമെങ്കിലും ആ കേസുകൾ സ്ക്രിപ്റ്റിൽ വേർതിരിക്കുക. ബാക്ക്എൻഡ് ഫലം പ്രത്യേകം രേഖപ്പെടുത്തുക, സമയപരിധികളിലും ഗതാഗത പിശകുകളിലും മുന്നറിയിപ്പ് നൽകുക, സേവനം തകർന്നതിനാലാണോ ഉപയോക്താക്കൾ തെറ്റായി ടൈപ്പ് ചെയ്യുന്നതിനാലാണോ പ്രാമാണീകരണം പരാജയപ്പെടുന്നതെന്ന് മോണിറ്ററിംഗിൽ വ്യക്തമാക്കുക.

രണ്ട് ശീലങ്ങൾ ബാക്കിയുള്ളതിനെ വിവേകത്തോടെ നിർത്തുന്നു. RADIUS അധികാരമാണെങ്കിൽ, പാസ്വേഡ് പരിശോധിക്കുന്ന ഏക സ്ഥലം അതായിരിക്കണം, കാരണം നിഴൽ പട്ടിക ഒരേ ചോദ്യത്തിന് രണ്ട് ഉത്തരങ്ങൾ സൃഷ്ടിക്കുന്നു, രണ്ടാമത്തേത് ആരും നിരീക്ഷിക്കാത്ത ആക്രമണ ഉപരിതലമാണ്. കൂടാതെ ഓരോ വീണ്ടും ശ്രമത്തിലും ഹുക്ക് വീണ്ടും വിളിക്കപ്പെടുന്നു എന്ന് ഓർക്കുക, അതിനാൽ സാവധാനമുള്ള സ്ക്രിപ്റ്റും അക്ഷമയുള്ള ക്ലയന്റും ചേർന്നാൽ RADIUS വശത്ത് കാലതാമസമോ നയമോ ചേർക്കാത്ത പക്ഷം പാസ്വേഡ് ഊഹിക്കലിനുള്ള ആംപ്ലിഫയറായി മാറുന്നു.

സർട്ടിഫിക്കറ്റ് പോകുമ്പോൾ നിങ്ങൾ എന്ത് ഉപേക്ഷിക്കുന്നു

ഈ രൂപത്തിലുള്ള പല വിന്യാസങ്ങളും ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് പരിശോധന പൂർണ്ണമായി ഓഫ് ചെയ്യുന്നു, ഉപയോക്തൃനാമവും പാസ്വേഡും ക്ലയന്റിന്റെ മുഴുവൻ അവകാശവാദമായി വിടുന്നു. ആ ക്രമീകരണത്തോടെ അപ്രത്യക്ഷമാകുന്നത് സർട്ടിഫിക്കറ്റ് അടിസ്ഥാനമാക്കിയ ഐഡന്റിറ്റിയാണ്. ചാനൽ എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നു, പക്ഷേ ക്ലയന്റിനെ പേരിടുന്ന ഏക കാര്യം RADIUS വിധിയാണ്. മുമ്പ് സർട്ടിഫിക്കറ്റ് വിഷയത്തെ ആശ്രയിച്ചിരുന്ന എല്ലാ ഡൗൺസ്ട്രീം കാര്യങ്ങളും ഇപ്പോൾ ഉപയോക്തൃനാമത്തെ ആശ്രയിക്കണം.

നിയന്ത്രണ ചാനൽ സംരക്ഷണം നിലനിർത്തുക, പ്രാമാണീകരിക്കപ്പെടാത്ത സഹപ്രവർത്തകന് ഹാൻഡ്ഷേക്ക് പരിശോധിക്കാനോ വെള്ളപ്പൊക്കമാക്കാനോ കഴിയരുത്, ഓരോ ഉപയോക്താവിന്റെയും കോൺഫിഗറേഷൻ പൊതുനാമത്തെ ആശ്രയിക്കുമ്പോൾ username-as-common-name ഉപയോഗിക്കുക. മാനേജ്ഡ് ഗേറ്റ്‌വേകൾ ഇത് പലപ്പോഴും വ്യത്യസ്തമായി പരിഹരിക്കുന്നു, RADIUS-നോട് EAP-TLS സംസാരിക്കുന്ന ഗേറ്റ്‌വേയിൽ സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണം അവസാനിപ്പിക്കുന്നു, അങ്ങനെയെങ്കിൽ ഈ സെർവർ നിർദ്ദേശങ്ങളിൽ ഒന്നും ബാധകമല്ല. അയൽ ഉൽപ്പന്നത്തിന്റേതല്ല, നിങ്ങളുടെ സ്വന്തം പ്ലാറ്റ്ഫോം രേഖപ്പെടുത്തുന്ന മാതൃക പകർത്തുക. പ്രധാനപ്പെട്ട നിർദ്ദേശങ്ങൾ വേർതിരിച്ചറിയാൻ മാത്രം വ്യത്യസ്തമാണ്, അവ കലർത്തിയാൽ പാഴ്സ് ചെയ്യപ്പെടുകയും പിന്നീട് ആരെയും പ്രാമാണീകരിക്കാതിരിക്കുകയും ചെയ്യുന്ന ഒരു കോൺഫിഗറേഷൻ ഉണ്ടാകും.