أين تنتهي حماية 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 وحده للسرية على القفزة المتبقية، فاكتب ذلك كقرار. وملاحظة قبول تسمّي القفزة وافتراض الثقة فيها أثمن من لقطة شاشة لعميل متصل.