حفاظت VPN در مسیر رسیدن به سرور FTP کجا پایان می‌یابد
یک VPN مسیر تا دروازهٔ خود را پوشش می‌دهد، نه بخش پس از آن را. FTP ساده، FTPS و SFTP را از هم جدا کنید، سپس کانال داده و هویت طرف مقابل را بررسی کنید.
یک VPN مسیری را محافظت می‌کند، و هر مسیری پایانی دارد. وقتی تونل در دروازهٔ یک شرکت پایان می‌یابد، انتقال فایل از همان‌جا زیر حفاظتی ادامه می‌یابد که پروتکل خودش فراهم می‌کند. همین تمایز تعیین می‌کند که آیا انتقال از ابتدا تا انتها محافظت می‌شود یا فقط تا دروازه. نشانگر Connected درباره هیچ‌کدام از این دو چیزی نمی‌گوید.
دو جایگاه، دو مسیر باقی‌مانده
لپ‌تاپی را در نظر بگیرید که به VPN شرکت می‌پیوندد و سپس نشست FTP را به یک سرور داخلی جداگانه باز می‌کند. تونل در دروازه متوقف می‌شود، و بخش میان دروازه و آن سرور بیرون از آن قرار دارد.
FTP ساده به این دلیل که بسته‌هایش از تونل گذشته‌اند رمزنگاری پیدا نمی‌کند. در آن بخش باقی‌مانده، فرمان‌ها، اعتبارنامه‌ها و محتوای فایل دقیقاً همان‌گونه که پروتکل تعریف می‌کند، یعنی آشکار، جابه‌جا می‌شوند. اینکه این موضوع مهم است یا نه به توپولوژی و به اینکه چه چیز دیگری از آن بخش محافظت می‌کند بستگی دارد، و خصوصی نامیدن نشانی به پرسش پاسخ نمی‌دهد. همین استدلال به‌طور معکوس هم صادق است وقتی سرور در شبکهٔ ابری قرار دارد که دروازه با یک پرش دیگر به آن می‌رسد.
نقطهٔ پایانی VPN و سرویس FTP را روی یک ماشین بگذارید تا بخش بعدی‌ای برای نگرانی نماند. این جایگاه دیگری است، نه دلیلی بر اینکه فرایندها، فایل‌ها و اعتبارنامه‌های میزبان امن هستند.
FTP ساده، FTPS و SFTP سه تصمیم‌اند
FTP ساده هیچ چیز را رمزنگاری نمی‌کند، حتی گذرواژه را. FTPS لایهٔ TLS را به FTP می‌افزاید، بنابراین کانال کنترل و در صورت توافق کانال داده محافظت می‌شوند. 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 تکیه کند، آن را همان‌گونه که هست به‌عنوان تصمیم بنویسید. یادداشت پذیرشی که پرش و فرض اعتمادش را نام می‌برد ارزشمندتر از تصویر صفحهٔ یک کلاینت متصل است.