VPN വിലാസത്തിൽ ബന്ധിപ്പിച്ച NFS എക്സ്പോർട്ട്: അത് എന്താണ് തെളിയിക്കാത്തത്
എക്സ്പോർട്ട് നിയമം പാക്കറ്റ് എവിടെ നിന്ന് വന്നു എന്ന് പരിശോധിക്കുന്നു; AUTH_SYS പ്രാദേശിക UID പ്രഖ്യാപിക്കുന്നു, Kerberos ഉപയോക്താവിനെ പ്രാമാണീകരിക്കുന്നു. നിങ്ങളുടെ ഫയൽ സേവനത്തിന് ഏതാണ് വേണ്ടതെന്ന് തീരുമാനിക്കുക.
ഒരു ഹോസ്റ്റ് ഡയറക്ടറി ഒരു VPN വിലാസത്തിലേക്ക് എക്സ്പോർട്ട് ചെയ്യുന്നു, മൗണ്ട് വിജയിക്കുന്നു, ഡിസൈൻ പ്രാമാണീകരിച്ചതായി രേഖപ്പെടുത്തുന്നു. ആ നിയമം യഥാർത്ഥത്തിൽ പരിമിതപ്പെടുത്തുന്നത് പാക്കറ്റുകൾ എവിടെ നിന്ന് വരുന്നതായി തോന്നുന്നു എന്നത് മാത്രമാണ്. ഫയൽ പ്രവർത്തനം നയിക്കുന്ന വ്യക്തി താൻ അവകാശപ്പെടുന്ന ആളാണോ എന്നത് NFS സുരക്ഷാ ഫ്ലേവറിനെ ആശ്രയിച്ചിരിക്കുന്നു, ഇത്തരം മിക്ക എക്സ്പോർട്ടുകളിലും ആരും അത് സ്ഥിരസ്ഥിതിയിൽ നിന്ന് മാറ്റിയിട്ടില്ല.
ഒരു അഭ്യർത്ഥനയിൽ മൂന്ന് ഐഡന്റിറ്റികൾ പ്രത്യക്ഷപ്പെടാം
VPN പിയർ ക്ലൈന്റ് സർട്ടിഫിക്കറ്റ് അല്ലെങ്കിൽ പിയർ കീ പോലുള്ള രജിസ്റ്റർ ചെയ്ത ഐഡന്റിറ്റി വഹിക്കുന്നു. ഉള്ളിലെ IP പാക്കറ്റ് ഒരു ഉറവിട വിലാസം വഹിക്കുന്നു. ഫയൽ പ്രവർത്തനം അതിന്റെ NFS സംവിധാനം നൽകുന്ന ഉപയോക്തൃ ക്രെഡൻഷ്യലുകൾ വഹിക്കുന്നു. വിലാസത്തെ മൂന്നിന്റെയും പ്രതിനിധിയായി കണക്കാക്കുന്ന ഡിസൈൻ പരിശോധിക്കേണ്ട ഭാഗം തന്നെ നിശ്ശബ്ദമായി അനുമാനിച്ചു.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
ആ മൂന്ന് വരികൾ എഴുതുന്നതാണ് മുഴുവൻ അഭ്യാസം. എക്സ്പോർട്ട് സുരക്ഷിതമാണോ എന്ന ചർച്ചയുടെ ഭൂരിഭാഗവും ഏത് നിയന്ത്രണം ഏത് വരിയിൽ ജീവിക്കുന്നു എന്ന് വ്യക്തമാകുമ്പോൾ തകരുന്നു.
വിലാസ ഉടമസ്ഥത ഒരു നടപ്പാക്കൽ വിശദാംശമാണ്
ഒരു ഗേറ്റ്വേ സ്വീകരിച്ച പിയറിന് ഒരു ടണൽ വിലാസം അനുവദിക്കാം, അല്ലെങ്കിൽ അതിന് ഒരു റൂട്ട് ചെയ്ത സബ്നെറ്റ് അനുവദിക്കാം. ഉള്ളിലെ ഉറവിടം മറ്റൊരു ക്ലൈന്റിന്റേതാണ് എന്ന പാക്കറ്റ് നടപ്പാക്കൽ നിരസിക്കുന്നുണ്ടോ എന്നത് ആ നടപ്പാക്കലിന്റെ സ്വഭാവമാണ്, അനുമാനിക്കുന്നതിനേക്കാൾ അത് പരിശോധിക്കേണ്ടതാണ്.
പരമ്പരാഗത Community OpenVPN ഉപയോക്തൃ സ്ഥല സർവർ കോഡിന്, ഉദാഹരണത്തിന്, പാക്കറ്റ് TUN ഉപകരണത്തിലൂടെ എത്തിക്കുന്നതിന് മുമ്പ് മറ്റൊരു ക്ലൈന്റുമായി ബന്ധപ്പെട്ട ഉറവിടം നിരസിക്കാം. അത് യഥാർത്ഥ മൂല്യമുള്ള വിലാസ ഉടമസ്ഥത പരിശോധനയാണ്, ഏത് അക്കൗണ്ടാണ് പ്രവർത്തനം നടത്തുന്നത് എന്നതിനെക്കുറിച്ച് ഒന്നും പറയാത്തതിനാൽ ഇത് ഇപ്പോഴും NFS ഉപയോക്തൃ പ്രാമാണീകരണമല്ല.
ഉറവിട വിവർത്തനം അതിനെപ്പോലും ക്ഷയിപ്പിക്കുന്നു. ഒരു NAT ഗേറ്റ്വേ എല്ലാ ക്ലൈന്റിനെയും ഒരു വിലാസമായി അവതരിപ്പിക്കാം, അപ്പോൾ എക്സ്പോർട്ട് നിയമത്തിന് അതിന് പിന്നിലുള്ള ആളുകളെ വേർതിരിക്കാൻ കഴിയില്ല. നിയമത്തിന്റെ പ്രത്യക്ഷമായ കൃത്യത അപ്പോൾ ഡയഗ്രം നിലനിർത്തുന്ന ഒരു കൽപ്പിതകഥയായി മാറുന്നു. എക്സ്പോർട്ട് പ്രധാനമാണെങ്കിൽ, ആരു ആരുടെ പകരമായി കണക്കാക്കപ്പെടുന്നു എന്ന് വിവർത്തകനെ തീരുമാനിക്കാൻ അനുവദിക്കാതെ വിലാസനിർണ്ണയം വ്യക്തമായി നിലനിർത്തുക.
എക്സ്പോർട്ട് വിശ്വസിക്കുന്നതിന് മുമ്പ് സുരക്ഷാ ഫ്ലേവർ വായിക്കുക
Red Hat-ന്റെ NFS മാർഗ്ഗനിർദ്ദേശം AUTH_SYS വഴി പ്രാദേശിക UNIX UID-കളും GID-കളും ഉപയോഗിക്കുന്ന sec=sys എന്നതിനെ Kerberos മോഡുകളിൽ നിന്ന് വേർതിരിക്കുന്നു. krb5 ഉപയോക്തൃ പ്രാമാണീകരണം ചേർക്കുന്നു, krb5i അഖണ്ഡത സംരക്ഷണം ചേർക്കുന്നു, krb5p ട്രാഫിക്കിന് സ്വകാര്യത സംരക്ഷണം ചേർക്കുന്നു.
AUTH_SYS ക്രെഡൻഷ്യലിൽ വിളിക്കുന്നയാളുടെ UID, ഗ്രൂപ്പ് ഐഡന്റിഫയറുകൾ തുടങ്ങിയ ഫീൽഡുകൾ അടങ്ങിയിരിക്കുന്നു, ഈ ഫ്ലേവർ സ്വയം സുരക്ഷ നൽകുന്നില്ലെന്നും പുറം സംരക്ഷണത്തെ ആശ്രയിക്കുന്നുവെന്നും RFC 5531 വ്യക്തമായി മുന്നറിയിപ്പ് നൽകുന്നു. ഇത് VPN-നുള്ളിൽ പ്രവർത്തിപ്പിക്കുന്നത് ഗതാഗതത്തിന് സംരക്ഷണം നൽകുന്നു, പാക്കറ്റിനുള്ളിലെ അവകാശവാദത്തിൽ ഒന്നും മാറ്റുന്നില്ല.
exportfs -v
showmount -e nfs.example.internalക്ലൈന്റ് പട്ടിക വായിക്കുന്നതിന് മുമ്പ് ആ ഔട്ട്പുട്ടിലെ ഫ്ലേവർ വായിക്കുക. പരിമിതമായി തോന്നുന്ന ഒരു എക്സ്പോർട്ട് വിലാസം കൊണ്ട് മാത്രം പരിമിതമായിരിക്കാം, അതേസമയം ഓരോ വിളിക്കുന്നയാളും താൻ ആഗ്രഹിക്കുന്ന UID പ്രഖ്യാപിക്കുന്നു.
മോഡൽ തിരഞ്ഞെടുക്കുക, പിന്നീട് അനുമതികൾ നിലനിർത്തുക
നിങ്ങൾ യഥാർത്ഥത്തിൽ കൈകാര്യം ചെയ്യുന്ന ക്ലൈന്റുകൾക്ക് അനുയോജ്യമായ ഫയൽ-സേവന പ്രാമാണീകരണ മോഡൽ തിരഞ്ഞെടുക്കുക. Kerberos-ന് പിന്നിൽ ഒരു ഐഡന്റിറ്റിയും സേവന വിന്യാസവും ആവശ്യമാണ്, അതിനാൽ ഒരു മൗണ്ട് ഓപ്ഷൻ മാറ്റുന്നത് കുടിയേറ്റമല്ല, Kerberos ഡൊമെയിൻ, പ്രിൻസിപ്പലുകൾ, keytab-കൾ എന്നിവ നിലവിലുണ്ടാകുന്നതുവരെ അത് പരാജയപ്പെടും.
രണ്ട് മോഡലുകളിലും, പ്രാമാണീകരിച്ച പ്രിൻസിപ്പലിന് എന്ത് ചെയ്യാമെന്ന് പരിമിതപ്പെടുത്തുന്ന എക്സ്പോർട്ട് അനുമതികളും ഫയൽസിസ്റ്റം അധികാരവും നിലനിർത്തുക. പ്രാമാണീകരണം ആരാണ് ചോദിക്കുന്നതെന്ന് പറയുന്നു; അധികാരം ഉത്തരം അതെ ആയിരിക്കണമോ എന്ന് തീരുമാനിക്കുന്നു. ഇവ രണ്ടും ഒരു ക്രമീകരണത്തിൽ ലയിപ്പിക്കുന്നതാണ് കുടിയേറ്റം പഴയ കോൺഫിഗറേഷനേക്കാൾ കൂടുതൽ നൽകുന്ന രീതി.
വിലാസ നിയമം അതിന്റെ യഥാർത്ഥ ഉദ്ദേശ്യത്തിന് ഉപയോഗിക്കുക
സേവനത്തെ അംഗീകൃത പാതയിലേക്കും ഉറവിടങ്ങളിലേക്കും പരിമിതപ്പെടുത്തുന്നത് ഇപ്പോഴും മൂല്യവത്താണ്, VPN എൻഡ്പോയിന്റും NFS സർവറും ഒരേ യന്ത്രം പങ്കിടുമ്പോൾ ഹോസ്റ്റ് ഇൻപുട്ട് നയവും ഉൾപ്പെടെ. ട്രാഫിക് കൈമാറുന്ന നിയമങ്ങൾ ഇനിപ്പറയുന്നവയിലേക്ക് ലക്ഷ്യമിട്ടുള്ള അഭ്യർത്ഥനകളെ നിയന്ത്രിക്കുന്നില്ല: അതേ ഹോസ്റ്റിൽ പ്രാദേശികമായി പ്രവർത്തിക്കുന്ന സേവനം. ഈ വിടവ് സ്വകാര്യമായിരിക്കേണ്ടിയിരുന്ന എക്സ്പോർട്ടുകളുടെ ആശ്ചര്യകരമായ എണ്ണം വിശദീകരിക്കുന്നു. ടണൽ നിയമങ്ങൾ അത് ഉൾക്കൊള്ളുന്നു എന്ന് അനുമാനിക്കാതെ പ്രാദേശിക ഇൻപുട്ട് നയം വ്യക്തമായി പരിശോധിക്കുക.
മറ്റൊരു ഇന്റർഫേസിനോ ഉറവിട വിവർത്തനം ചെയ്യുന്ന ഗേറ്റ്വേയ്ക്കോ നിയമം അപ്രതീക്ഷിതമായി പാലിക്കാൻ കഴിയില്ലെന്ന് പരിശോധിക്കുക, അതിനെ വിലാസം വ്യാജമാക്കുന്നത് പ്രവർത്തിക്കുന്ന മൗണ്ട് ഉറപ്പാക്കുന്നു എന്ന അവകാശവാദമല്ല, ഉത്ഭവം സ്ഥാപിക്കാനുള്ള കാരണമായി കാണുക.
ഒന്നിന് പകരം മൂന്ന് സ്വീകാര്യതാ കേസുകൾ പ്രവർത്തിപ്പിക്കുക. അംഗീകൃത ക്ലൈന്റ് അംഗീകൃത ഉപയോക്താവായി പ്രവർത്തിക്കുന്നതിൽ നിന്ന് ആരംഭിക്കുക, തുടർന്ന് ഒരിക്കലും അംഗീകരിക്കാത്ത പിയറിൽ നിന്ന് ആവർത്തിക്കുക, പിന്നീട് അംഗീകൃത ഉപയോക്താവിന് ഇപ്പോഴും അനുവദിക്കാത്ത എന്തെങ്കിലും ശ്രമിക്കുക. അതിനുശേഷം അധികാരമുള്ള ക്ലൈന്റ് വിട്ടുവീഴ്ച ചെയ്യപ്പെട്ടാൽ എന്ത് മാറുമെന്ന് ചോദിക്കുക, കാരണം ഗതാഗത പ്രാമാണീകരണം ആ യന്ത്രത്തിലെ എല്ലാ പ്രോസസ്സിനെയും വിശ്വസനീയമാക്കുന്നില്ല. മോഷ്ടിക്കപ്പെട്ട സർട്ടിഫിക്കറ്റും ജിജ്ഞാസുവായ പ്രാദേശിക അക്കൗണ്ടും വ്യത്യസ്ത നിയന്ത്രണങ്ങളുള്ള വ്യത്യസ്ത പ്രശ്നങ്ങളാണ്.