VPN ഗേറ്റ്വേയിലേക്ക് രണ്ടാമതൊരു പ്രാമാണീകരണ ബാക്കെൻഡ് ചേർക്കുന്നത് രണ്ടാം ഘടകം ചേർക്കുന്നതുപോലെ തോന്നുന്നു. സാധാരണയായി അത് ഒരു രണ്ടാം പരിശോധന ചേർക്കുന്നു, അത് വ്യത്യസ്ത പരാജയ രീതികളുള്ള വ്യത്യസ്ത വസ്തുവാണ്. രണ്ടും വിജയിക്കണമോ, ഓരോന്നും എന്ത് തെളിയിക്കുന്നു, ഒന്ന് ലഭ്യമല്ലാത്തപ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്നത് മൂന്ന് വെവ്വേറെ തീരുമാനങ്ങളാണ്. തെറ്റിച്ചാൽ ഗേറ്റ്വേ പ്രദർശനത്തിൽ കർശനവും തടസ്സസമയത്ത് ദുർബലവുമാകും.

രണ്ടാം ബാക്കെൻഡ് യഥാർത്ഥത്തിൽ എന്ത് തെളിയിക്കുന്നു

പ്രാദേശിക അക്കൗണ്ട് തിരച്ചിൽ ഒരു പേര് ഡാറ്റാബേസിൽ ഉണ്ടെന്നും പാസ്വേഡ് അതിനോട് പൊരുത്തപ്പെട്ടുവെന്നും തെളിയിക്കുന്നു. RADIUS കൈമാറ്റം RADIUS സർവർ ലഭിച്ച ആട്രിബ്യൂട്ടുകൾക്ക് Access-Accept നൽകിയെന്ന് തെളിയിക്കുന്നു. രണ്ട് പ്രസ്താവനകളും ഘടക തരം പരാമർശിക്കുന്നില്ല, കാരണം രണ്ടും അറിവ് സ്ഥിരീകരിക്കുന്നു. കൂടാതെ NIST-ന്റെ ഡിജിറ്റൽ ഐഡന്റിറ്റി മാർഗ്ഗനിർദ്ദേശം വ്യത്യസ്ത ഘടക തരങ്ങളും അവയുടെ പ്രാമാണീകരണികളും എണ്ണുന്നു, സർവറുകളോ സൂചനകളോ അല്ല.

രണ്ട് സംവിധാനങ്ങളും പങ്കെടുക്കുന്ന സാധുവായ ഒരു രൂപകൽപ്പനയുണ്ട്. ഒരു കേന്ദ്ര സേവനത്തിന് വ്യക്തിയെ പ്രാമാണീകരിക്കാം, അതേസമയം ഗേറ്റ്വേ ആ അക്കൗണ്ടിന് ഈ ടണലിനുള്ള അവകാശമുണ്ടോയെന്ന് സ്വതന്ത്രമായി പരിശോധിക്കുന്നു. അത് പ്രാമാണീകരണത്തിനൊപ്പമുള്ള അധികാരമാണ്, അതിനെ രണ്ട് ഘടകം എന്ന് വിളിക്കുന്നത് നയ പരിശോധനയെ ഉടമസ്ഥാവകാശ തെളിവുമായി കലർത്തുന്നു.

ഒരു കാര്യം സ്ഥിരീകരിക്കുന്നതിന് മുന്നിൽ നിൽക്കുമ്പോൾ RADIUS യഥാർത്ഥ രണ്ടാം ഘടകം വഹിക്കാം, ഉദാഹരണത്തിന് പുഷ് അനുമതി അല്ലെങ്കിൽ ഹാർഡ്വെയർ ടോക്കൺ. ഉപയോക്താവ് ഏത് പ്രാമാണീകരണികൾ കാണിച്ചുവെന്ന് എൻവലപ്പ് പറയുന്നില്ല, അതിനാൽ ഗേറ്റ്വേ ലേബലല്ല, ബാക്കെൻഡ് നയം വായിക്കുക.

AND, OR, ഫാൾബാക്ക് വ്യത്യസ്ത ഉൽപ്പന്നങ്ങളാണ്

നടപ്പാക്കലുകൾ താരതമ്യം ചെയ്യുന്നതിന് മുൻപ് നിങ്ങളുടെ ആവശ്യകതയിൽ രണ്ടും എന്താണ് അർത്ഥമാക്കുന്നതെന്ന് തീരുമാനിക്കുക. AND നയം ഓരോ പേരിട്ട പരിശോധനയും കടക്കണമെന്ന് ആവശ്യപ്പെടുന്നു, OR നയം വിജയിക്കുന്നത് സ്വീകരിക്കുന്നു, ഫാൾബാക്ക് പ്രഖ്യാപിത പരാജയ വ്യവസ്ഥകളിൽ മാത്രം രണ്ടാമത്തേത് പരീക്ഷിക്കുന്നു. ഈ മൂന്നും തടസ്സസമയത്ത് വിപരീതമായി പെരുമാറുന്നു, സാധാരണയായി അവയിൽ ഒന്ന് മാത്രമാണ് അവലോകനം ഉദ്ദേശിച്ചത്.

കോൺഫിഗറേഷൻ സ്ക്രീനിൽ രണ്ട് ബാക്കെൻഡ് എൻട്രികൾ ചേർക്കുന്നത് ഉൽപ്പന്നം ഏത് നയം നടപ്പാക്കുന്നു എന്ന് വെളിപ്പെടുത്തുന്നില്ല. ചില ഗേറ്റ്വേകൾ പ്ലഗിനുകൾ ക്രമത്തിൽ ശൃംഖലബദ്ധമാക്കി ആദ്യ നിരസനത്തിൽ നിർത്തുന്നു, അത് ഓരോ പ്ലഗിനും നിർബന്ധമാകുമ്പോൾ മാത്രം AND ആണ്. മറ്റുള്ളവ പ്രാദേശിക അക്കൗണ്ടിനെ ഓവർറൈഡായി കണക്കാക്കുന്നു, അത് കേന്ദ്ര തടസ്സത്തെ ബൈപാസാക്കി മാറ്റുന്നു. വിശ്വസനീയമായ ഉത്തരം ഓരോ പാതയ്ക്കും നിങ്ങൾ വിന്യസിക്കുന്ന build-നെതിരെ പ്രവർത്തിപ്പിക്കുന്ന രേഖപ്പെടുത്തിയ നെഗറ്റീവ് പരിശോധനയാണ്.

ഫാൾബാക്ക് ഏറ്റവും സംശയത്തിന് അർഹമാണ്, കാരണം എന്തെങ്കിലും തകർന്നാൽ പ്രവർത്തനം തുടരാൻ അത് നിലനിൽക്കുന്നു. RADIUS ലഭ്യമല്ലാത്തപ്പോഴെല്ലാം പ്രാദേശിക പാസ്വേഡ് സ്വീകരിക്കുന്ന ഫാൾബാക്ക് കേന്ദ്ര നയത്തെ രണ്ടാമത്തെ, ദുർബലമായ വാതിലാക്കി മാറ്റിയിരിക്കുന്നു.

OpenVPN-ന്റെ ഇരട്ട പരിശോധന ഒരു നിർദ്ദിഷ്ട കേസാണ്

കമ്മ്യൂണിറ്റി OpenVPN 2.6 രണ്ടും പ്രവർത്തനക്ഷമമാകുമ്പോൾ ക്ലയന്റ് സർട്ടിഫിക്കറ്റും ക്രമീകരിച്ച auth-user-pass-verify സ്ക്രിപ്റ്റും ആവശ്യപ്പെടുന്നു. അത് സർട്ടിഫിക്കറ്റ് പരിശോധനയും ക്രെഡൻഷ്യൽ സ്ക്രിപ്റ്റും തമ്മിലുള്ള രേഖപ്പെടുത്തിയ AND ആണ്, അത് യഥാർത്ഥത്തിൽ രണ്ട് പരിശോധനകളാണ്. എന്നിട്ടും സ്വയമേവ രണ്ട് തരം ഘടകങ്ങളല്ല, കാരണം സ്ക്രിപ്റ്റ് പാസ്വേഡ് മാത്രം സാധൂകരിച്ചേക്കാം.

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

സർട്ടിഫിക്കറ്റ്-മാത്രം മോഡ് ഒരു പരിശോധനയാണ്, PIN കൊണ്ട് സംരക്ഷിക്കപ്പെട്ടേക്കാം അല്ലായിരിക്കാം എന്ന കീയാൽ പിന്തുണയ്ക്കപ്പെടുന്നു. PIN അതേ ക്രെഡൻഷ്യലിനെ അറിവും കൈവശവുമാക്കി മാറ്റുന്നത് കീ അതില്ലാതെ ഉപയോഗിക്കാനാകാത്തപ്പോൾ മാത്രമാണ്. കീ ഡിസ്കിൽ എൻക്രിപ്റ്റ് ചെയ്യാതെ വിടുന്നത് രണ്ടാം ഭാഗത്തെ ഫയൽ അനുമതിയായി ചുരുക്കുന്നു.

ഉപകരണ നിർമ്മാതാക്കൾ സ്വന്തം പ്ലംബിംഗ് നിർമ്മിക്കുന്നു, പലപ്പോഴും വെബ് കൺസോളിന് പിന്നിൽ PAM മൊഡ്യൂളോ RADIUS പ്ലഗിനോ. കമ്മ്യൂണിറ്റി സ്വഭാവം ഇരട്ട പരിശോധനകൾ എങ്ങനെയിരിക്കുമെന്നതിന് ഒരു സൂചനയാണ്, ഉപകരണം അവ എങ്ങനെ സംയോജിപ്പിക്കുന്നു എന്ന വിവരണമല്ല.

നിങ്ങളുടെ ഗേറ്റ്വേയിൽ സംയോജനം പരിശോധിക്കുക

കൺസോൾ സംഗ്രഹം വിശ്വസിക്കുന്നതിന് മുൻപ് കോൺഫിഗറേഷൻ വായിക്കുക. നയം നിർണ്ണയിക്കുന്ന വരികൾ സർട്ടിഫിക്കറ്റ് മോഡ്, ക്രെഡൻഷ്യൽ സ്ക്രിപ്റ്റ്, പ്ലഗിൻ ക്രമം എന്നിവയാണ്.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

സർട്ടിഫിക്കറ്റ് ആവശ്യമാണോ, അതിന് ശേഷം ഏത് സ്ക്രിപ്റ്റ് പ്രവർത്തിക്കുന്നു എന്ന് grep കാണിക്കുന്നു, ക്രമം പേരുകൾ സൂചിപ്പിക്കുന്നതിനേക്കാൾ പ്രധാനമാണ്. സർട്ടിഫിക്കറ്റ് ഡംപ് ഗേറ്റ്വേ കാണുന്ന ഐഡന്റിറ്റി നൽകുന്നു, ബന്ധിപ്പിക്കൽ മാപ്പിന് ആവശ്യമായ CN-ഉം സീരിയൽ നമ്പറും ഉൾപ്പെടെ. RADIUS പരിശോധന നെഗറ്റീവ് കേസാണ്: തെറ്റായ പാസ്വേഡ് Access-Reject-ഉം ശരിയായത് Access-Accept-ഉം നൽകണം. നിരസിച്ച ക്രെഡൻഷ്യൽ ഇപ്പോഴും സെഷൻ നൽകുന്നുവെങ്കിൽ, സ്ക്രിപ്റ്റ് പ്രാമാണീകരണ പാതയിൽ ഒട്ടുമില്ല.

തുടർന്ന് ലബോറട്ടറി ഇൻസ്റ്റൻസിൽ തടസ്സ കേസ് പ്രവർത്തിപ്പിക്കുക: നിർബന്ധിത ബാക്കെൻഡ് നിർത്തി സാധുവായ ക്രെഡൻഷ്യലുകളുമായി ബന്ധിപ്പിക്കുക. പ്രതീക്ഷിത ഫലം നിരസനമാണ്, മറ്റെന്തും ആരും രേഖപ്പെടുത്താത്ത ഫാൾബാക്ക് നയമാണ്.

ആവശ്യകത നെഗറ്റീവ് കേസുകളായി എഴുതുക

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

സ്വീകാര്യതയിൽ നാല് നിരസനങ്ങൾ ഉൾക്കൊള്ളണം: അയോഗ്യമായ പ്രാദേശിക അക്കൗണ്ട്, കാണാതായ നിർബന്ധിത തെളിവ്, അസാധുവായ രണ്ടാം ഘടകം, എത്തിച്ചേരാനാകാത്ത നിർബന്ധിത ബാക്കെൻഡ്. ഓരോ നിരസനത്തിനും മറ്റുള്ളവയിൽ നിന്ന് വേർതിരിക്കുന്ന ഒരു ലോഗ് വരി വേണം, അല്ലെങ്കിൽ അടുത്ത സംഭവം ഊഹങ്ങളോടെ തുടങ്ങും. ഗേറ്റ്വേ, RADIUS സർവർ, ഡയറക്ടറി എന്നിവ പരസ്പരം കുറ്റപ്പെടുത്തുമെന്നതിനാൽ ഏത് ഘടകമാണ് ഓരോ തീരുമാനവും എടുത്തതെന്ന് രേഖപ്പെടുത്തുക.

ഏതെങ്കിലും പ്ലഗിൻ അല്ലെങ്കിൽ ഫേംവെയർ മാറ്റത്തിന് ശേഷം നാല് നിരസനങ്ങൾ വീണ്ടും പ്രവർത്തിപ്പിക്കുക. അവ വിലകുറഞ്ഞവയാണ്, അവ സംരക്ഷിക്കുന്ന നയമാണ് ആക്രമണകാരി ആദ്യം പരിശോധിക്കുന്ന ഭാഗം.

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