OpenVPN-ൽ RAND_bytes പരാജയപ്പെട്ടു: ലൈബ്രറി പിശക് അല്ലെങ്കിൽ കാണാത്ത നോഡ്

RAND_bytes() failed ഒരു പ്രാദേശിക പ്രിമിറ്റീവിനെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്, അക്കൗണ്ട്, മുൻകൂട്ടി പങ്കിട്ട കീ അല്ലെങ്കിൽ ദൂര പോർട്ടിനെക്കുറിച്ചല്ല. രണ്ട് വളരെ വ്യത്യസ്തമായ തകരാറുകൾ അതേ വരി ഉൽപ്പാദിപ്പിക്കുകയും വ്യത്യസ്ത തെളിവുകൾ അവശേഷിപ്പിക്കുകയും ചെയ്യുന്നു. ഒന്ന് ബൈറ്റുകൾ നൽകാൻ വിസമ്മതിക്കുന്ന ക്രിപ്റ്റോഗ്രാഫിക് ബാക്കെൻഡ്; മറ്റൊന്ന് അതിന്റെ കോഡ് നിർമ്മിച്ച എൻട്രോപി ഉറവിടത്തിലേക്ക് എത്താത്ത പ്രോസസ്. അവയെ വേർതിരിക്കാൻ ഒരു പിശക് നിര വായനയും ജയിലിനുള്ളിലെ പ്രോസസിന്റെ ഫയൽ സിസ്റ്റം കാഴ്ചയിലേക്ക് ഒരു നോട്ടവും ആവശ്യമാണ്, ഈ പരിശോധന /dev-ന് കീഴിൽ എന്തെങ്കിലും സൃഷ്ടിക്കുന്നതിന് മുമ്പ് ഉണ്ടായിരിക്കണം.

തിരികെ നൽകുന്ന മൂല്യം എന്ത് വേർതിരിക്കുന്നു

രേഖപ്പെടുത്തിയ കരാർ മൂന്ന് ഫലങ്ങൾ വേർതിരിക്കുന്നു, രണ്ടല്ല: വിജയത്തിന് 1, ലോഡ് ചെയ്ത RAND രീതി അഭ്യർത്ഥന പിന്തുണയ്ക്കാത്തപ്പോൾ -1, മറ്റ് പരാജയങ്ങൾക്ക് 0, വിശദീകരണം പിശക് നിരയിൽ തുടരുന്നു. RAND_bytes റഫറൻസ് എളുപ്പത്തിൽ വിട്ടുപോകാവുന്ന ഒരു പോയിന്റ് ചേർക്കുന്നു: സ്ഥിരസ്ഥിതി ജനറേറ്റർ പിന്തുണയുള്ള പ്ലാറ്റ്ഫോമുകളിൽ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൽ നിന്ന് വിത്ത് എടുക്കുന്നു, ആ വിത്തിടൽ പരാജയപ്പെട്ടാൽ അത് പ്രവചനീയമായ ബൈറ്റുകൾ തിരികെ നൽകുന്നതിനുപകരം പിശക് അവസ്ഥയിൽ തുടരുന്നു.

ആ സംഖ്യകളിൽ ഒന്ന് മാത്രമാണ് പരിസ്ഥിതിയെ വിവരിക്കുന്നത്. -1 എന്നത് ബിൽഡ്, ദാതാവ് അല്ലെങ്കിൽ ഫീച്ചർ എന്നിവയുടെ ചോദ്യമാണ്, കാരണം സജീവ നടപ്പാക്കൽ നൽകാത്ത എന്തോ കോഡ് ആവശ്യപ്പെട്ടു. വിത്തിടലിനെക്കുറിച്ചുള്ള പരാതിയോടെ 0 പരിസ്ഥിതി ചോദ്യമാണ്, കാരണം ജനറേറ്ററിന് എൻട്രോപി ലഭിക്കാൻ കഴിഞ്ഞില്ല. സംഖ്യ തന്നെ ഒരിക്കലും ഏതെന്ന് പറയുന്നില്ല, ഫംഗ്ഷന്റെ പേരും പറയുന്നില്ല.

ഒളിച്ചിരിക്കുന്ന ഉപകരണ നോഡ് യഥാർത്ഥ കാരണമാകുമ്പോൾ

നിയന്ത്രിത സേവനം നിങ്ങൾ ടൈപ്പ് ചെയ്യുന്ന ഷെല്ലിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു മരം കാണുന്നു. chroot ജയിലുകൾ, കണ്ടെയ്നർ ഇമേജുകൾ, കഠിനീകരിച്ച unit ഫയലുകൾ എന്നിവ സാധാരണയായി ഹോസ്റ്റിനെക്കാൾ കുറഞ്ഞ നോഡുകൾ ഉള്ള /dev അവതരിപ്പിക്കുന്നു. പരാജയപ്പെടുന്ന നടപ്പാക്കൽ /dev/urandom പാത്ത് നാമത്തിലൂടെ തുറക്കുകയാണെങ്കിൽ, ഹോസ്റ്റ് തന്നെ തികച്ചും ആരോഗ്യകരമായി കാണപ്പെടുമ്പോൾ ആ വ്യത്യാസം തുടക്കം തകർക്കാൻ മതിയാകും. ജയിലിന് പുറത്തുള്ള ഉപകരണം ജയിലിലെ പ്രോസസിന് എന്ത് തുറക്കാൻ അനുവാദമുണ്ടെന്നതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

എന്നിരുന്നാലും ഓരോ റാൻഡം ഇന്റർഫേസിനും പാത്ത് ആവശ്യമില്ല. ലിനക്സിലെ getrandom സിസ്റ്റം കോൾ ഫയൽ നാമമോ ഫയൽ ഡിസ്ക്രിപ്റ്ററോ സ്വീകരിക്കുന്നില്ല, അതിന്റെ മാനുവൽ പേജ് chroot ഉപകരണ പാത്തുകൾ ഒളിക്കുന്നിടത്ത് തന്നെ ഈ സ്വഭാവം ഉപയോഗപ്രദമാണെന്ന് കുറിക്കുന്നു.

അതിനാൽ കാണാത്ത നോഡിന്റെ വിശദീകരണം കോഡിന്റെ ഒരു ശാഖയെക്കുറിച്ചുള്ള സിദ്ധാന്തമാണ്, റാൻഡം സംഖ്യകളെക്കുറിച്ചുള്ള പൊതു നിയമമല്ല. തെളിവുകൾ പാത്ത് പേരിടുമ്പോൾ അത് നിലനിൽക്കുന്നു, തെളിവുകൾ മറ്റെന്തെങ്കിലും പേരിടുമ്പോൾ അത് ഊഹമാണ്.

ആദ്യം പിശക് നിര വായിക്കുക, പിന്നെ പ്രോസസ് കാഴ്ച

ചോദ്യം തീർപ്പാക്കാനുള്ള വേഗതയേറിയ മാർഗം ലൈബ്രറി ഇതിനകം രേഖപ്പെടുത്തിയത് വായിക്കുക, തുടർന്ന് ജയിലിനുള്ളിലെ കാഴ്ച നേരിട്ട് നോക്കുക എന്നതാണ്. സേവനം യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്ത OpenSSL ബിൽഡിൽ നിന്ന് ആരംഭിക്കുക, കാരണം ദാതാവ് സ്റ്റാക്കുകൾ പ്രധാന പതിപ്പുകൾക്കും വിതരണങ്ങൾക്കും ഇടയിൽ വ്യത്യാസപ്പെടുന്നു. പിന്നെ systemd-യോട് ഏത് പ്രോസസ് പ്രവർത്തിക്കുന്നു, അതിന് ഏത് നിയന്ത്രണങ്ങൾ ബാധകമാണ് എന്ന് ചോദിക്കുക. രണ്ട് വസ്തുതകളും മേശപ്പുറത്ത് വന്നതിന് ശേഷം മാത്രമാണ് ആ പ്രോസസ് കാണുന്ന നോഡുകൾ പട്ടികപ്പെടുത്തുന്നത് അർത്ഥവത്താകുന്നത്.

openssl version -a
systemctl show openvpn-server@lab -p MainPID -p PrivateDevices -p DevicePolicy
pid=$(systemctl show -p MainPID --value openvpn-server@lab)
sudo ls -l /proc/"$pid"/root/dev/urandom /proc/"$pid"/root/dev/random

ഈ വായനകൾ അതേ പ്രോസസിൽ തന്നെ ചെയ്യുക, യാദൃച്ഛികമായി തുറന്നിരിക്കുന്ന ഷെല്ലിൽ അല്ല. ഹോസ്റ്റിന്റെ /dev അസംബന്ധമായ ഒരു പ്രോസസിന്റെ കാഴ്ചയുമായി താരതമ്യം ചെയ്യുന്നതാണ് തെറ്റായ ആശ്രിതത്വം രണ്ടുതവണ നന്നാക്കപ്പെടുന്ന വഴി.

ആശ്രിതത്വം അതിന്റെ പേര് പറയാൻ കഴിയുമ്പോൾ മാത്രം ചേർക്കുക

തെളിവുകൾ യഥാർത്ഥത്തിൽ ഒരു പാത്ത് പേരിടുമ്പോൾ, അറ്റകുറ്റപ്പണി ചെറുതാണ്: ആ ഒരു പാത്ത് ജയിലിനുള്ളിൽ ലഭ്യമാക്കുക, ബാക്കിയെല്ലാം വിടുക. ഒരു നോഡിന്റെ bind mount സാധാരണയായി മതിയാകും, കൂടാതെ mknod നോഡിന്റെ സാധാരണ major, minor നമ്പറുകളോടെ mount ഓപ്ഷനല്ലാത്ത ഇൻസ്റ്റാളേഷനുകളിൽ അതേ ഫലം നൽകുന്നു. സാൻഡ്ബോക്സ് വിപുലീകരിക്കുന്നതോ ഓരോ പ്രതീക ഉപകരണത്തിനും പ്രവേശനം നൽകുന്നതോ PrivateDevices ഓഫാക്കുന്നതോ ലക്ഷ്യബദ്ധമായ തിരുത്തലിന് പകരം സ്ഥിരമായ സുരക്ഷാ പിന്നോട്ടുപോക്ക് നൽകുന്നു.

എൻട്രോപി ഡീമൺ ആ അറ്റകുറ്റപ്പണിക്ക് പകരമല്ല. haveged പോലുള്ള പാക്കേജുകൾ കെർണൽ പൂൾ എങ്ങനെ പോഷിപ്പിക്കപ്പെടുന്നു എന്ന് മാറ്റുന്നു; ജയിലിലെ പ്രോസസിന് തുറക്കാൻ അനുവാദമുള്ള ഒരു പാത്ത് അവയ്ക്ക് സൃഷ്ടിക്കാൻ കഴിയില്ല. ഒന്ന് ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ആരോഗ്യ ഗ്രാഫ് മെച്ചമായി കാണിക്കാം, പക്ഷേ തുറക്കൽ കോൾ ഇപ്പോഴും പരാജയപ്പെടുന്നു. രണ്ട് പ്രശ്നങ്ങളും വേർതിരിച്ച് സൂക്ഷിക്കുക, അല്ലെങ്കിൽ അടുത്ത പരാജയം വീണ്ടും തെറ്റായ പാളിക്ക് ആരോപിക്കപ്പെടും.

ജനറേറ്ററും ടണലും വെവ്വേറെ പരിശോധിക്കുക

പുനരാരംഭം മാത്രമാണ് പരാജയം സൃഷ്ടിച്ച അതേ കോൺഫിഗറേഷൻ, അതേ unit ഫയൽ, അതേ വേർതിരിവ് എന്നിവ വീണ്ടും ഉപയോഗിക്കുന്ന പരീക്ഷണം. അത് പ്രവർത്തിപ്പിക്കുക, പിന്നെ മുൻ ബൂട്ടിൽ നിന്നുള്ള സാമ്പിളിന് പകരം ജേണലിലെ ഏറ്റവും പുതിയ എൻട്രികൾ വായിക്കുക.

sudo systemctl restart openvpn-server@lab
sudo journalctl -u openvpn-server@lab --since -5min --no-pager | grep -iE 'rand|entropy|Initialization Sequence'

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