FTP സർവറിലേക്കുള്ള വഴിയിൽ VPN സംരക്ഷണം അവസാനിക്കുന്നത് എവിടെ
VPN അതിന്റെ ഗേറ്റ്‌വേ വരെയുള്ള വഴി മാത്രം ഉൾക്കൊള്ളുന്നു, അതിനപ്പുറമുള്ള ഭാഗമല്ല. സാധാരണ FTP, FTPS, SFTP എന്നിവ വേർതിരിച്ച്, പിന്നീട് ഡാറ്റാ ചാനലും എതിർവശത്തെ ഐഡന്റിറ്റിയും പരിശോധിക്കുക.
VPN ഒരു വഴിയെ സംരക്ഷിക്കുന്നു, ഓരോ വഴിക്കും ഒരു അവസാനമുണ്ട്. ടണൽ ഒരു കമ്പനിയുടെ ഗേറ്റ്‌വേയിൽ അവസാനിക്കുമ്പോൾ, ഫയൽ കൈമാറ്റം അവിടെ നിന്ന് അതിന്റെ സ്വന്തം പ്രോട്ടോക്കോൾ നൽകുന്ന സംരക്ഷണത്തിൽ തുടരുന്നു. ഈ വ്യത്യാസമാണ് കൈമാറ്റം ആദ്യം മുതൽ അവസാനം വരെ സംരക്ഷിതമാണോ, അതോ ഗേറ്റ്‌വേ വരെ മാത്രമാണോ എന്ന് തീരുമാനിക്കുന്നത്. Connected സൂചകം ഇവ രണ്ടിനെക്കുറിച്ചും ഒന്നും പറയുന്നില്ല.
രണ്ട് സ്ഥാനങ്ങൾ, രണ്ട് ശേഷിക്കുന്ന വഴികൾ
കമ്പനിയുടെ VPN-ലേക്ക് ചേരുകയും പിന്നീട് വേറെ ഒരു ആന്തരിക സർവറിലേക്ക് FTP സെഷൻ തുറക്കുകയും ചെയ്യുന്ന ഒരു ലാപ്‌ടോപ്പ് എടുക്കുക. ടണൽ ഗേറ്റ്‌വേയിൽ നിൽക്കുന്നു, ഗേറ്റ്‌വേയിൽ നിന്ന് ആ സർവർ വരെയുള്ള ഭാഗം അതിന് പുറത്താണ്.
സാധാരണ FTP-യുടെ പാക്കറ്റുകൾ ഒരു ടണലിലൂടെ വന്നു എന്ന കാരണത്താൽ അതിന് എൻക്രിപ്ഷൻ ലഭിക്കുന്നില്ല. ആ ശേഷിക്കുന്ന ഭാഗത്ത്, കമാൻഡുകളും ക്രെഡൻഷ്യലുകളും ഫയലിന്റെ ഉള്ളടക്കവും പ്രോട്ടോക്കോൾ നിർവചിക്കുന്നത് പോലെ തന്നെ, അതായത് തുറന്ന രീതിയിൽ സഞ്ചരിക്കുന്നു. അത് പ്രധാനമാണോ എന്നത് ടോപ്പോളജിയെയും ആ ഭാഗത്തെ മറ്റെന്ത് സംരക്ഷിക്കുന്നു എന്നതിനെയും ആശ്രയിച്ചിരിക്കുന്നു, വിലാസത്തെ സ്വകാര്യം എന്ന് വിളിക്കുന്നത് ചോദ്യത്തിന് ഉത്തരം നൽകുന്നില്ല. ഗേറ്റ്‌വേ മറ്റൊരു കുതിപ്പിലൂടെ എത്തുന്ന ഒരു ക്ലൗഡ് നെറ്റ്‌വർക്കിലാണ് സർവർ എങ്കിൽ അതേ യുക്തി വിപരീത ദിശയിലും ബാധകമാണ്.
VPN അന്ത്യബിന്ദുവും FTP സേവനവും ഒരേ യന്ത്രത്തിൽ വയ്ക്കുക, എങ്കിൽ ആശങ്കപ്പെടാനുള്ള അടുത്ത ഭാഗം ഒന്നും ബാക്കിയില്ല. അത് മറ്റൊരു സ്ഥാനമാണ്, ഹോസ്റ്റിന്റെ പ്രോസസുകളും ഫയലുകളും ക്രെഡൻഷ്യലുകളും സുരക്ഷിതമാണെന്ന തെളിവല്ല.
സാധാരണ FTP, FTPS, SFTP എന്നിവ മൂന്ന് തീരുമാനങ്ങളാണ്
സാധാരണ FTP പാസ്‌വേഡ് ഉൾപ്പെടെ ഒന്നും എൻക്രിപ്റ്റ് ചെയ്യുന്നില്ല. FTPS, FTP-യിലേക്ക് TLS ചേർക്കുന്നു, അതിനാൽ നിയന്ത്രണ ചാനലും ചർച്ച ചെയ്യപ്പെട്ടാൽ ഡാറ്റാ ചാനലും സംരക്ഷിതമാണ്. SFTP എന്നത് SSH-യ്ക്കുള്ളിൽ കൊണ്ടുപോകുന്ന മറ്റൊരു പ്രോട്ടോക്കോളാണ്, അത് FTPS-ന്റെ മറ്റൊരു അക്ഷരവിന്യാസമല്ല.
സർവർ ഈ തിരഞ്ഞെടുപ്പിനെ പിന്തുണയ്ക്കണം, കാരണം ക്ലയന്റിന് ഇല്ലാത്ത ഒരു ശ്രോതാവിനെ സൃഷ്ടിക്കാനാവില്ല. SFTP തിരഞ്ഞെടുക്കുന്നത് FTP മാത്രമുള്ള ഒരു സേവനത്തെ SSH അന്ത്യബിന്ദുവാക്കി മാറ്റുന്നില്ല, ഒരു ബുക്ക്‌മാർക്ക് പേരുമാറ്റുന്നതോ പോർട്ട് മാറ്റുന്നതോ ചർച്ച ചെയ്ത കാര്യത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ക്ലയന്റിനൊപ്പം സർവറിന്റെ ഭാഗത്തുനിന്നും പ്രോട്ടോക്കോൾ സ്ഥിരീകരിക്കുക. ഫയൽ മാനേജറിലെ പൂട്ട് സെഷനെക്കുറിച്ചുള്ള ഒരു വാദമാണ്, അതിന് പിന്നിലെ ശ്രോതാവിനെക്കുറിച്ചല്ല.
| Protocol | Usual port | What it protects | Identity check |
|---|---|---|---|
| FTP | 21 | Nothing on the wire | None beyond the login |
| FTPS | 21 or 990 | Control channel, data channel when required | TLS server certificate |
| SFTP | 22 | The whole session inside SSH | SSH host key |
കൈമാറ്റം പ്രധാനമാകുമ്പോൾ അവസാന നിര വായിക്കുക, കാരണം പ്രതീക്ഷിക്കാത്ത ഐഡന്റിറ്റി മാറ്റം അവിടെയാണ് പ്രത്യക്ഷപ്പെടുന്നത്.
ഡാറ്റാ കണക്ഷൻ രണ്ടാമത്തെ കണക്ഷനാണ്
FTP ഒരു നിയന്ത്രണ കണക്ഷൻ തുറക്കുന്നു, പിന്നീട് ലിസ്റ്റിംഗുകൾക്കും കൈമാറ്റങ്ങൾക്കും വേറെ ഡാറ്റാ കണക്ഷനുകൾ തുറക്കുന്നു. സംരക്ഷിത ലോഗിൻ ആ പിന്നീടുള്ള കണക്ഷനുകളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, വിന്യാസം അവയ്ക്കും സംരക്ഷണം ആവശ്യപ്പെടുന്നില്ലെങ്കിൽ.
FTPS-ൽ ക്ലയന്റ് ഒരു പ്രത്യേക കമാൻഡിലൂടെ സംരക്ഷിത ഡാറ്റാ ചാനൽ ആവശ്യപ്പെടുന്നു, സർവർ നയത്തിന് തുറന്ന ബദൽ നിരസിക്കാം. ക്ലയന്റിന്റെ സ്വതവേയുള്ള മൂല്യം മതിയെന്ന് കരുതുന്നതിന് പകരം നയം അത് ആവശ്യപ്പെടുന്നുണ്ടെന്ന് പരിശോധിക്കുക. പാസീവ് മോഡ് രണ്ടാമത്തെ സങ്കീർണത ചേർക്കുന്നു, കാരണം സർവർ ഡാറ്റാ കണക്ഷനായി ഒരു വിലാസവും പോർട്ടും പ്രഖ്യാപിക്കുന്നു. ആ പ്രഖ്യാപനം മാറ്റിയെഴുതുന്നതോ തടയുന്നതോ ആയ ഒരു ഫയർവാൾ അല്ലെങ്കിൽ NAT ഉപകരണം, പ്രാമാണീകരണം കടന്ന് പിന്നീട് ആദ്യ ലിസ്റ്റിൽ കുടുങ്ങുന്ന ഒരു സെഷൻ സൃഷ്ടിക്കുന്നു.
curl -vk ftps://files.corp.example/ --user alice --ftp-ssl-control
openssl s_client -connect files.corp.example:21 -starttls ftp
ss -tnp | grep -E ':21|:990'രണ്ടാമത്തെ കമാൻഡ് ഏതെങ്കിലും ഫയലിൽ സ്പർശിക്കുന്നതിന് മുമ്പ് സർവർ നിയന്ത്രണ ചാനലിൽ എന്ത് അവതരിപ്പിക്കുന്നു എന്ന് കാണിക്കുന്നു. മൂന്നാമത്തേത് ഡാറ്റാ കണക്ഷൻ എങ്ങാനും സ്ഥാപിക്കപ്പെട്ടുവോ എന്ന് കാണിക്കുന്നു, അതാണ് പ്രാമാണീകരണ പരാജയവും പാസീവ് മോഡ് പരാജയവും തമ്മിലുള്ള വ്യത്യാസം.
ഐഡന്റിറ്റി പരിശോധനകൾ ടണലിനെ അതിജീവിക്കുന്നു
FTPS ക്ലയന്റ് TLS സർവറിന്റെ ഐഡന്റിറ്റി സാധൂകരിക്കുന്നു, SFTP ക്ലയന്റ് SSH ഹോസ്റ്റ് കീ സാധൂകരിക്കുന്നു. രണ്ട് പരിശോധനകളും ഫയൽ കൈമാറ്റ പ്രോട്ടോക്കോളിന്റേതാണ്, ഒന്നും VPN നിർവഹിക്കുന്നില്ല.
ഇടയിൽ എന്തെങ്കിലും സെഷൻ പരിശോധിക്കാൻ ആഗ്രഹിക്കുമ്പോൾ ഈ വേർതിരിവ് പ്രധാനമാണ്. നെറ്റ്‌വർക്ക് ഉപകരണത്തിന് കമാൻഡുകൾ വായിക്കാനായി TLS ഓഫ് ചെയ്യുന്നത് സംരക്ഷണ മാതൃക പൂർത്തിയാക്കുന്നതിന് പകരം മാറ്റുന്നു, ടണൽ ഉയർന്നതിനാൽ വിശദീകരിക്കാത്ത ഹോസ്റ്റ് കീ സ്വീകരിക്കുന്നതിനും അതേ കാര്യം തന്നെ. ഉദ്ദേശിച്ച വിശ്വാസ ക്രമീകരണം നിലനിർത്തുക, ശരിയായ വസ്തുവകകൾ ഓപ്പറേറ്ററിൽ നിന്ന് നേടുക. പ്രാമാണീകരണം നടത്തുന്ന ടണൽ അതിന്റെ ദൂരെ അറ്റത്തുള്ള സർവറിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
ഈ പ്രോട്ടോക്കോളുകൾക്കുള്ള സ്വകാര്യ കീയും സർട്ടിഫിക്കറ്റ് വസ്തുവകകളും VPN ക്രെഡൻഷ്യലിൽ നിന്ന് വേറിട്ട മറ്റൊരു, മൂന്നാമത്തെ രഹസ്യമാണ്.
യഥാർത്ഥത്തിൽ എന്താണ് പരിശോധിച്ചതെന്ന് രേഖപ്പെടുത്തുക
നീക്കാൻ അനുവാദമുള്ള ഒരു നിരുപദ്രവകരമായ ഫയൽ തിരഞ്ഞെടുക്കുക, ശ്രമത്തെക്കുറിച്ച് നാല് വസ്തുതകൾ രേഖപ്പെടുത്തുക: ഏത് പ്രോട്ടോക്കോൾ പ്രവർത്തിച്ചു, എതിർവശത്തെ ഏത് ഐഡന്റിറ്റി പരിശോധിച്ചു, ഏത് വഴിയാണ് ഉദ്ദേശിച്ചത്, കൈമാറ്റം പൂർത്തിയായോ.
lftp -u alice -e "set ftp:ssl-protect-data true; ls; bye" ftps://files.corp.example
sftp -v [email protected]ഡയറക്ടറി ലിസ്റ്റിംഗ്, ടണലിലേക്കുള്ള ലോഗിൻ, പൂർത്തിയായ കൈമാറ്റം എന്നിവ മൂന്ന് വേറിട്ട നിരീക്ഷണങ്ങളാണ്, വഴി ഫയലുകൾക്ക് പ്രവർത്തിക്കുന്നു എന്ന് അവസാനത്തേത് മാത്രം പറയുന്നു. ശേഷിക്കുന്ന കുതിപ്പിലെ രഹസ്യതയ്ക്ക് ഡിസൈൻ VPN-യെ മാത്രം ആശ്രയിക്കുന്നെങ്കിൽ, അത് അതായ ഒരു തീരുമാനമായി തന്നെ എഴുതുക. കുതിപ്പിനെയും അതിന്റെ വിശ്വാസ അനുമാനത്തെയും പേരെടുത്ത് പറയുന്ന സ്വീകരണ കുറിപ്പ്, ബന്ധിപ്പിച്ച ക്ലയന്റിന്റെ സ്ക്രീൻഷോട്ടിനേക്കാൾ മൂല്യമുള്ളതാണ്.