FTPS

الموسوعة الحرة

FTPS (المعروف أيضًا باسم FTP-SSL و FTP Secure ) هو امتداد لبروتوكول نقل الملفات (FTP) المستخدم بشكل شائع والذي يضيف دعمًا لبروتوكول أمان طبقة النقل (TLS) وبروتوكول طبقة المقابس الآمنة (SSL) سابقًا، والذي تم حظره الآن بموجب RFC7568 ) بروتوكولات التشفير.

يجب عدم الخلط بين بروتوكول نقل الملفات الآمن عبر بروتوكول FTPS وبروتوكول نقل الملفات الآمن عبر بروتوكول SSH (SFTP)، وهو نظام فرعي لنقل الملفات الآمن ضمن بروتوكول SSH، ولا يتوافق معه. كما يختلف بروتوكول FTPS عن بروتوكول نقل الملفات عبر SSH ، الذي يُتيح نقل بيانات FTP عبر اتصال SSH.

خلفية

تم وضع بروتوكول نقل الملفات في عام 1971 لاستخدامه مع شبكة البحث العلمي، أربانت . [ 1 ] كان الوصول إلى أربانت خلال هذا الوقت محدودًا لعدد قليل من المواقع العسكرية والجامعات ومجموعة ضيقة من المستخدمين الذين يمكنهم العمل دون متطلبات أمن البيانات والخصوصية ضمن البروتوكول.

مع تحول شبكة أربانت إلى شبكة NSFNET ثم إلى الإنترنت ، أصبح بإمكان شريحة أوسع من السكان الوصول إلى البيانات التي تنتقل عبر مسارات أطول فأطول من العميل إلى الخادم. وبالتالي، ازدادت فرص الأطراف الثالثة غير المصرح لها بالتنصت على عمليات نقل البيانات بشكل متناسب.

في عام ١٩٩٤، طورت شركة نتسكيب، مطورة متصفحات الإنترنت، وأصدرت بروتوكول طبقة المقابس الآمنة (SSL) . [ ٢ ] مكّن هذا البروتوكول التطبيقات من التواصل عبر الشبكة بشكل خاص وآمن، مما يحدّ من التنصت والتلاعب وتزوير الرسائل. ورغم إمكانية استخدامه لتعزيز أمان أي بروتوكول يستخدم اتصالات موثوقة، مثل TCP ، إلا أن نتسكيب استخدمته بشكل شائع مع HTTP لتكوين HTTPS.

تم تطبيق بروتوكول SSL لاحقًا على بروتوكول نقل الملفات (FTP)، ونُشرت مسودة طلب التعليقات (RFC) في أواخر عام 1996. [ 3 ] وسُجّل منفذ رسمي لدى هيئة IANA بعد ذلك بوقت قصير. ومع ذلك، لم يُعتمد طلب التعليقات (RFC) نهائيًا حتى عام 2005. [ 4 ]

أساليب استدعاء الأمن

طُوِّرت طريقتان منفصلتان لتفعيل أمان العميل لاستخدامه مع عملاء بروتوكول نقل الملفات (FTP): الطريقة الضمنية والطريقة الصريحة . تتطلب الطريقة الضمنية إنشاء طبقة أمان النقل (TLS) منذ بداية الاتصال، مما يؤدي بدوره إلى عدم التوافق مع العملاء والخوادم غير المتوافقة مع بروتوكول FTPS. أما الطريقة الصريحة فتستخدم أوامر وردود بروتوكول FTP القياسية لترقية اتصال النص العادي إلى اتصال مشفر، مما يسمح باستخدام منفذ تحكم واحد لخدمة كل من العملاء المتوافقين مع بروتوكول FTPS وغير المتوافقين معه.

ضمني

لا يدعم بروتوكول FTPS الضمني عملية التفاوض. يُتوقع من العميل إرسال رسالة TLS ClientHello إلى خادم FTPS فورًا . إذا لم يستلم خادم FTPS هذه الرسالة، فعليه قطع الاتصال.

للحفاظ على التوافق مع العملاء الحاليين غير المتوافقين مع بروتوكول FTPS، كان من المتوقع أن يستمع بروتوكول FTPS الضمني على المنفذ 990/TCP المعروف لدى هيئة IANA لقناة التحكم في FTPS، والمنفذ 989/TCP لقناة البيانات في FTPS. [ 5 ] وقد سمح هذا للمسؤولين بالاحتفاظ بالخدمات المتوافقة مع الأنظمة القديمة على قناة التحكم الأصلية لبروتوكول FTP (21/TCP).

تجدر الإشارة إلى أن التفاوض الضمني لم يُعرّف في RFC 4217. ولذلك، يُعتبر طريقةً قديمةً ومهملةً للتفاوض على TLS/SSL لبروتوكول نقل الملفات (FTP). [ 6 ]

صريح

في الوضع الصريح (المعروف أيضًا باسم FTPES)، يجب على عميل FTPS أن يطلب صراحةً تفعيل الأمان من خادم FTPS، ثم الانتقال إلى طريقة تشفير متفق عليها بين الطرفين. إذا لم يطلب العميل تفعيل الأمان، فيمكن لخادم FTPS إما السماح للعميل بالاستمرار في الوضع غير الآمن أو رفض الاتصال.

أُضيفت آلية التفاوض على المصادقة والأمان مع بروتوكول نقل الملفات (FTP) بموجب RFC 2228، والتي تضمنت أمر FTP الجديد AUTH. مع أن هذا RFC لا يُحدد صراحةً أي آليات أمان مطلوبة، مثل SSL أو TLS، إلا أنه يُلزم عميل FTPS بتحدي خادم FTPS بآلية معروفة للطرفين. إذا تحدى عميل FTPS خادم FTPS بآلية أمان غير معروفة، فسيرد خادم FTPS على أمر AUTH برمز الخطأ 504 (غير مدعوم) . يمكن للعملاء تحديد الآليات المدعومة عن طريق الاستعلام من خادم FTPS باستخدام أمر FEAT، مع العلم أن الخوادم ليست مُلزمة بالضرورة بالإفصاح عن مستويات الأمان التي تدعمها. من الطرق الشائعة لتفعيل أمان FTPS: AUTH TLS و AUTH SSL.

تم تعريف الطريقة الصريحة في RFC 4217. في الإصدارات اللاحقة من الوثيقة، تطلب الامتثال لـ FTPS أن يتفاوض العملاء دائمًا باستخدام طريقة AUTH TLS.

أمان طبقة النقل (TLS) / طبقة المقابس الآمنة (SSL)

الدعم العام

يدعم بروتوكول FTPS بشكل كامل بروتوكولات التشفير TLS وSSL، بما في ذلك استخدام شهادات مصادقة المفتاح العام من جانب الخادم وشهادات التفويض من جانب العميل. كما يدعم خوارزميات التشفير المتوافقة، مثل AES و RC4 و RC2 و Triple DES و DES . بالإضافة إلى ذلك، يدعم دوال التجزئة SHA و MD5 و MD4 و MD2 .

نطاق الاستخدام

في الوضع الضمني، تُشفّر جلسة FTPS بالكامل. أما في الوضع الصريح، فيتمتع العميل بالتحكم الكامل في أجزاء الاتصال التي تُشفّر. ويمكن تفعيل أو تعطيل التشفير لقناة التحكم وقناة البيانات في أي وقت. والقيد الوحيد هو من خادم FTPS، الذي يملك صلاحية رفض الأوامر بناءً على سياسة التشفير الخاصة به.

قناة أوامر آمنة

يمكن تفعيل وضع قناة الأوامر الآمنة عبر إصدار أوامر AUTH TLS أو AUTH SSL. بعد ذلك، يُفترض تشفير جميع عمليات التحكم في الأوامر بين عميل وخادم FTPS. يُنصح عمومًا بتفعيل هذا الوضع قبل مصادقة المستخدم وتفويضه لتجنب تنصت جهات خارجية على بيانات اسم المستخدم وكلمة المرور.

قناة بيانات آمنة

يمكن الدخول إلى قناة البيانات الآمنة باستخدام أمر PROT. وهي غير مُفعّلة افتراضيًا عند استخدام أمر AUTH TLS. بعد ذلك، يُفترض أن جميع اتصالات قناة البيانات بين عميل FTPS والخادم مُشفّرة.

يمكن لعميل FTPS الخروج من وضع قناة البيانات الآمنة في أي وقت عن طريق إصدار أمر CDC (مسح قناة البيانات).

أسباب تعطيل التشفير

قد لا يكون من المفيد استخدام تشفير قناة البيانات عند إجراء عمليات النقل في الحالات التالية:

  • الملفات المنقولة ذات طبيعة غير حساسة، مما يجعل التشفير غير ضروري.
  • الملفات التي يتم نقلها مشفرة بالفعل على مستوى الملف أو تمر عبر شبكة VPN مشفرة ، مما يجعل التشفير غير ضروري.
  • لا تفي أوضاع التشفير المتاحة من نوع TLS أو SSL بمستوى التشفير المطلوب. وهذا شائع مع عملاء أو خوادم FTPS القديمة التي ربما كانت محدودة بتشفير SSL ذي 40 بت بسبب قوانين التصدير الأمريكية السابقة التي كانت تفرض تشفيرًا عاليًا.

قد لا يكون من المفيد استخدام تشفير قناة التحكم في الحالات التالية:

  • استخدام بروتوكول FTPS عندما يكون العميل أو الخادم موجودًا خلف جدار حماية الشبكة أو جهاز ترجمة عناوين الشبكة (NAT). (انظر قسم عدم توافق جدار الحماية أدناه).
  • تكرار استخدام أوامر AUTH و CCC/CDC من قِبل عملاء FTP مجهولين خلال نفس الجلسة. يمكن استغلال هذا السلوك كهجوم حجب خدمة قائم على استنزاف موارد النظام، حيث يجب إعادة إنشاء جلسة TLS/SSL في كل مرة، مما يستهلك وقت معالج الخادم.

شهادات SSL

على غرار بروتوكول HTTPS ، يجب على خوادم FTPS توفير شهادة مفتاح عام . ويمكن طلب هذه الشهادات وإنشاؤها باستخدام أدوات مثل OpenSSL .

عندما تُوقَّع هذه الشهادات من قِبَل جهة إصدار شهادات موثوقة ، فإن ذلك يضمن اتصال العميل بالخادم المطلوب، مما يقي من هجمات الوسيط . أما إذا لم تُوقَّع الشهادة من قِبَل جهة إصدار شهادات موثوقة ( شهادة موقعة ذاتيًا )، فقد يُصدر عميل بروتوكول أمان ملفات FTPS تحذيرًا يفيد بأن الشهادة غير صالحة. ويمكن للعميل حينها قبول الشهادة أو رفض الاتصال.

وهذا على النقيض من بروتوكول نقل الملفات SSH (SFTP)، الذي لا يقدم شهادات موقعة، ولكنه يعتمد بدلاً من ذلك على المصادقة خارج النطاق للمفاتيح العامة.

عدم توافق جدار الحماية

نظرًا لأن بروتوكول نقل الملفات (FTP) يستخدم منفذًا ثانويًا ديناميكيًا (لقنوات البيانات)، فقد صُممت العديد من جدران الحماية لمراقبة رسائل التحكم في بروتوكول FTP لتحديد اتصالات البيانات الثانوية التي يجب السماح بها. مع ذلك، إذا كان اتصال التحكم في FTP مُشفّرًا باستخدام TLS/SSL، فلن يتمكن جدار الحماية من تحديد رقم منفذ TCP لاتصال البيانات المُتفاوض عليه بين العميل وخادم FTP. لذلك، في العديد من الشبكات المحمية بجدران الحماية، سيفشل نشر FTPS بينما يعمل نشر FTP غير المُشفّر. يُمكن حل هذه المشكلة باستخدام نطاق محدود من المنافذ للبيانات وتكوين جدار الحماية لفتح هذه المنافذ.

انظر أيضاً

ملحوظات

  1. ↑ أباي بهوشان؛ بوب برادن ؛ ويل كروثر؛ إريك نارسلم؛ جون هيفنر؛ أليكس ماكنزي؛ جون ملفين؛ بوب سوندبيرغ؛ ديك واتسون؛ جيم وايت (17 نوفمبر 1971). بروتوكول نقل الملفات . مجموعة عمل الشبكة. doi : 10.17487/RFC0265 . RFC 265 .الحالة غير معروفة. NIC 781. تم إلغاؤه بموجب RFC 354. تم تحديثه بموجب RFC 281 و 294 و 310 . يلغي RFC 172 .   
  2. ↑ "بروتوكول SSL 0.2" . mozilla.org . 9 فبراير 1995. مؤرشف من الأصل في 14 يونيو 2001.
  3. ↑ بول فورد-هاتشينسون؛ تيم هدسون؛ إريك موراي (26-11-1996). بروتوكول نقل الملفات الآمن عبر SSL . IETF . المعرف: draft-murray-auth-ftp-ssl-00.
  4. ↑ ب. فورد-هاتشينسون (أكتوبر 2005). تأمين بروتوكول نقل الملفات باستخدام بروتوكول أمان طبقة النقل (TLS ). مجموعة عمل الشبكة. doi : 10.17487/RFC4217 . RFC 4217 .المعيار المقترح. تم تحديثه بواسطة RFC 8996 . 
  5. ↑ "سجل اسم الخدمة ورقم منفذ بروتوكول النقل" . هيئة أرقام الإنترنت المخصصة . تم الاطلاع عليه بتاريخ 9 أكتوبر 2015 .
  6. ↑ "آليات التفاوض على بروتوكول SSL المهملة" . تأمين بروتوكول نقل الملفات (FTP) باستخدام بروتوكول أمان طبقة النقل (TLS) . فريق هندسة الإنترنت (IETF) . 5 أبريل 2001. القسم أ. المعرف: draft-murray-auth-ftp-ssl-07 . تاريخ الاسترجاع: 9 أكتوبر 2015 .