SECLEVEL=0 ലക്ഷണം ശമിപ്പിക്കുന്നു, സർട്ടിഫിക്കറ്റിനെയല്ല

OpenVPN കണക്ഷൻ പരാജയപ്പെടുന്നു, ആരോ SECLEVEL=0 ചേർക്കുന്ന ഒരു വരി പരിഹാരം കണ്ടെത്തുന്നു, ടണൽ ഉയരുന്നു. മാറിയത് സർട്ടിഫിക്കറ്റോ സൈഫർ സ്യൂട്ടോ അല്ല; ലൈബ്രറി മുഴുവൻ നിലവിലുള്ള സ്വീകാര്യതാ പരിധി നീങ്ങി, തുടർന്ന് പ്രക്രിയ ചെയ്യുന്നതെല്ലാം പുതിയ പരിധി പാരമ്പര്യമായി സ്വീകരിക്കുന്നു. അതേ വരി പരിസരത്തിലെ ഓരോ പ്രൊഫൈലിലേക്കും പകർത്തുന്നതിന് മുൻപ് ഇത് മനസ്സിലാക്കുന്നത് വിലപ്പെട്ടതാണ്.

ഏത് ലൈബ്രറിയും ഏത് നയവുമാണ് പ്രാബല്യത്തിലെന്ന് നിർണ്ണയിക്കുക

SECLEVEL ഒരു OpenSSL ആശയമാണ്, അതിനാൽ ആദ്യ ചോദ്യം നിങ്ങളുടെ ബിൽഡ് OpenSSL ഉപയോഗിക്കുന്നുണ്ടോ എന്നതാണ്. OpenVPN ഒന്നിലധികം ക്രിപ്റ്റോഗ്രഫി ലൈബ്രറികളുമായി ലിങ്ക് ചെയ്യാം, അവയിലൊന്നിന് ബാധകമായ ക്രമീകരണം മറ്റുള്ളവയ്ക്ക് അർത്ഥശൂന്യമാണ്. ബൈനറിയോട് എന്തുകൊണ്ട് നിർമ്മിച്ചുവെന്ന് ചോദിക്കുക, പിന്നീട് ലൈബ്രറിയോട് ഏത് പതിപ്പും കോൺഫിഗറേഷനും ലോഡ് ചെയ്തുവെന്ന് ചോദിക്കുക:

openvpn --version | head -3
openssl version -a

പതിപ്പിന്റെ ഔട്ട്പുട്ട് ശ്രദ്ധയോടെ വായിക്കുക, കാരണം വിതരണങ്ങൾ സ്ഥിരസ്ഥിതികൾ പാച്ച് ചെയ്യുന്നു. ചിലത് കുറഞ്ഞ നിലവാരം upstream സ്ഥിരസ്ഥിതിക്ക് മുകളിലേക്ക് ഉയർത്തുന്ന സിസ്റ്റം കോൺഫിഗറേഷൻ നൽകുന്നു, അതിനാൽ ഒരേ OpenVPN പാക്കേജുകളുള്ള രണ്ട് മെഷീനുകളിൽ ഒരേ പ്രൊഫൈൽ വ്യത്യസ്തമായി പെരുമാറുന്നു. ഫലപ്രദമായ നയം പ്രവർത്തിക്കുന്ന പ്രക്രിയ ലോഡ് ചെയ്തതാണ്, upstream കൈപ്പുസ്തകത്തിലുള്ളതല്ല.

പിന്നീട് ആളുകൾ കൂട്ടിക്കലർത്തുന്ന രണ്ട് പാളികൾ വേർതിരിക്കുക. OpenVPN-ന് സ്വന്തം TLS നിയന്ത്രണങ്ങളുണ്ട്, അവയിൽ സർട്ടിഫിക്കറ്റ് പ്രൊഫൈൽ ക്രമീകരണവും വ്യക്തമായ സൈഫർ പട്ടികകളും ഉൾപ്പെടുന്നു, അവ ലൈബ്രറി അടിച്ചേൽപ്പിക്കുന്നതെല്ലാത്തിനും മുകളിലാണ്. ലൈബ്രറിയുടെ നില താഴ്ത്തുന്നത് നിങ്ങളുടെ OpenVPN കോൺഫിഗറേഷൻ ഏത് സൈഫറുകൾ പട്ടികപ്പെടുത്തുന്നു എന്നത് മാറ്റുന്നില്ല, OpenVPN പട്ടിക ചുരുക്കുന്നത് ലൈബ്രറിയുടെ പരിധി ഉയർത്തുന്നില്ല. ഏത് പാളി നിങ്ങളെ നിരസിച്ചുവെന്ന് അറിയുന്നതാണ് പരിഹാരം ഊഹമായി തുടരാതിരിക്കാൻ സഹായിക്കുന്നത്.

നിരസിക്കപ്പെടാവുന്ന മൂന്ന് കാര്യങ്ങൾ വേർതിരിക്കുക

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

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

നില താഴ്ത്തുന്നത് മൂന്ന് ഇൻപുട്ടുകൾക്കും ഒരുമിച്ച് സ്വീകാര്യത വിപുലീകരിക്കുന്നു. ഇതാണ് ആളുകൾ വിട്ടുകളയുന്ന ഭാഗം: പഴയ സർട്ടിഫിക്കറ്റ് അനുവദിക്കുന്ന പരിഹാരം ദുർബലമായ ഗ്രൂപ്പും നിങ്ങൾ അനുവദിക്കാൻ ഉദ്ദേശിക്കാത്ത സ്യൂട്ടും അനുവദിക്കുന്നു. ഒരു പിശകാണ് മാറ്റത്തിന് കാരണമായത്, മാറ്റം പിശകിനേക്കാൾ വിശാലമാണ്. ഈ അസമമിതിയാണ് പരിമിതമായ ഒഴിവാക്കൽ മുഴുവൻ പരിസരത്തിന്റെ സ്ഥിരസ്ഥിതിയേക്കാൾ നല്ലതാക്കുന്നത്.

ഇൻപുട്ട് മാറ്റുക, പരിധിയല്ല

കോൺഫിഗറേഷൻ തൊടുന്നതിന് മുൻപ് കൃത്യമായ പിശക് സൂക്ഷിക്കുക, അത് റിപ്പോർട്ട് ചെയ്ത ഘട്ടവും അത് പേരിട്ട വസ്തുവും ഉൾപ്പെടെ. സർട്ടിഫിക്കറ്റ് പ്രശ്നം നിലവിലെ നയം സ്വീകരിക്കുന്ന എന്തെങ്കിലും കൊണ്ട് സർട്ടിഫിക്കറ്റ് മാറ്റിസ്ഥാപിച്ച് പരിഹരിക്കുന്നു, അതായത് സാധാരണയായി അതേ ഫയൽ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് പകരം അധികാരിയിൽ നിന്ന് വീണ്ടും പുറപ്പെടുവിക്കുക എന്നാണ്.

നിരസിച്ച ഇൻപുട്ട് നിങ്ങൾ നിയന്ത്രിക്കാത്ത ഒരു പിയറിന്റേതാണെങ്കിൽ, സംഭാഷണം ആ പിയറിന്റെ ഉടമയുമായി പിന്തുണയുള്ള പകരം വസ്തുവിനെക്കുറിച്ചാണ്. ആരും പരിപാലിക്കാത്ത ഒരു സിസ്റ്റത്തെ ഉൾക്കൊള്ളാൻ സ്വന്തം പരിധി താഴ്ത്തുന്നത് ചെലവ് അവരിൽ നിന്ന് അവർക്ക് ശേഷം ബന്ധിപ്പിക്കുന്ന എല്ലാവരിലേക്കും മാറ്റുന്നു.

സർവർ നയം നടപ്പാക്കുന്നിടത്ത്, ലൈബ്രറിയെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് OpenVPN തലത്തിലുള്ള ക്രമീകരണമാണോ യഥാർത്ഥ കാരണം എന്ന് പരിശോധിക്കുക. വിന്യസിച്ച സർട്ടിഫിക്കറ്റിന് തൃപ്തിപ്പെടുത്താനാവാത്ത കർശനമായ ക്ലാസ് ആവശ്യപ്പെടുന്ന സർട്ടിഫിക്കറ്റ് പ്രൊഫൈൽ സുരക്ഷാ നില എന്തായാലും പരാജയപ്പെടും, ആ പ്രൊഫൈൽ നീക്കം ചെയ്യുന്നത് ലൈബ്രറിയുടെ പരിശോധനകൾ അണയ്ക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയ മാറ്റമാണ്.

താഴ്ത്തേണ്ടിവന്നാൽ, പരിധി നിശ്ചയിച്ച് രേഖപ്പെടുത്തുക

ചിലപ്പോൾ അംഗീകരിച്ച അനുയോജ്യതാ ഒഴിവാക്കലാണ് ശരിയായ ഉത്തരം, പ്രത്യേകിച്ച് തീയതിയുള്ള വിരമിക്കൽ പദ്ധതിയുള്ള പഴയ പിയറിന്. മുഴുവൻ ഹോസ്റ്റിനും പകരം അത് ആവശ്യമുള്ള സേവനത്തിലേക്ക് പരിമിതപ്പെടുത്തുക: സേവനാധിഷ്ഠിത കോൺഫിഗറേഷൻ ഫയലോ സമർപ്പിത OpenSSL കോൺഫിഗറേഷനോ ആഗോള പ്രൊഫൈലിലെ എക്സ്പോർട്ടിനേക്കാൾ ചെറിയ സ്വാധീന പരിധിയുണ്ട്.

ഒഴിവാക്കലിനൊപ്പം നാല് കാര്യങ്ങൾ എഴുതുക: കൃത്യമായ ക്രമീകരണം, അത് അംഗീകരിച്ച ഉടമ, ബാധിക്കുന്ന ക്ലയന്റുകൾ, അത് നീക്കം ചെയ്യുന്ന വ്യവസ്ഥ. വിരമിക്കൽ വ്യവസ്ഥയില്ലാത്ത ഒഴിവാക്കൽ താൽക്കാലിക ന്യായീകരണം ചേർത്ത സ്ഥിരമായ ദുർബലതയാണ്.

റോൾബാക്ക് നിങ്ങൾ ഇതിനകം പരീക്ഷിച്ച ഒരു ഘട്ടമായിരിക്കണം. മുൻ കോൺഫിഗറേഷൻ സൂക്ഷിക്കുക, മാറ്റം പ്രയോഗിക്കുക, സേവനം ആരംഭിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, അടുത്ത കണക്ഷൻ പ്രതീക്ഷിച്ചതിൽ നിന്ന് വ്യത്യസ്തമായി പെരുമാറിയാൽ ഏത് ഫയൽ പുനഃസ്ഥാപിക്കണമെന്ന് കൃത്യമായി അറിയുക.

പിന്നീട് ഐഡന്റിറ്റിയും സംരക്ഷണവും പരിശോധിക്കുക

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

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

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

ഓഡിറ്റിനെ അതിജീവിക്കുന്ന കൈമാറ്റം ഏത് നയം ഏത് ഇൻപുട്ട് നിരസിച്ചു, എന്ത് മാറി, ഫലമായി എന്ത് സ്വീകാര്യമായി തുടരുന്നു എന്ന് പറയുന്നു. „ഇത് SECLEVEL=0-നൊപ്പം പ്രവർത്തിക്കുന്നു“ ഒരു കണക്ഷനെക്കുറിച്ചുള്ള നിരീക്ഷണമാണ്, വിന്യാസത്തിന്റെ സുരക്ഷാ വിലയിരുത്തലല്ല.