يصدر مضيف دليلًا إلى عنوان VPN، فتنجح عملية التركيب، فيُكتب التصميم على أنه موثَّق. لكن ما تقيّده تلك القاعدة فعليًا هو المكان الذي تبدو الحزم قادمة منه. أما ما إذا كان الشخص الذي يقود عملية الملف هو من يدّعي أنه هو، فيعتمد على نمط أمان NFS، وفي معظم عمليات التصدير من هذا النوع لم يغيّره أحد عن الوضع الافتراضي.

ثلاث هويات يمكن أن تظهر في طلب واحد

يحمل نظير VPN هوية مسجَّلة مثل شهادة عميل أو مفتاح نظير. وتحمل حزمة IP الداخلية عنوان مصدر. وتحمل عملية الملف أي بيانات اعتماد مستخدم توفّرها آلية NFS الخاصة بها. والتصميم الذي يعامل العنوان كبديل عن الثلاثة يفترض بهدوء الجزء الذي كان يحتاج إلى التحقق منه.

IdentityWhat it provesWhat it does not
VPN peerWhich peer was accepted by the tunnelWhich user runs on that machine
Inner source addressWhere the packet appears to originateThat only the intended client can use it
NFS credentialWhat the file service believes about the callerAnything, if the flavour only asserts local IDs

كتابة تلك الصفوف الثلاثة هي التمرين كله. معظم الجدل حول ما إذا كان التصدير آمنًا ينهار بمجرد وضوح الصف الذي يقيم فيه كل ضابط.

ملكية العنوان تفصيل تنفيذي

يمكن لبوابة أن تخصّص عنوان نفق لنظير مقبول، أو أن تأذن بشبكة فرعية موجّهة له. أما ما إذا كانت التنفيذ يرفض بعد ذلك حزمة يعود مصدرها الداخلي إلى عميل آخر، فهذه خاصية لذلك التنفيذ، ويستحق الأمر التحقق منها بدل افتراضها.

يمكن لكود خادم Community التقليدي في فضاء المستخدم الخاص بـ OpenVPN أن يرفض، على سبيل المثال، مصدرًا مرتبطًا بعميل آخر قبل تسليم الحزمة عبر جهاز TUN. وهذا فحص لملكية العنوان له قيمة حقيقية، ومع ذلك ليس مصادقة مستخدم NFS، لأنه لا يقول شيئًا عن الحساب الذي ينفّذ العملية.

إن ترجمة المصدر تآكل حتى ذلك. يمكن لبوابة NAT أن تُظهر كل عميل بعنوان واحد، وعندها لا تستطيع قاعدة التصدير التمييز بين الأشخاص الذين يقفون خلفه. فتصبح دقة القاعدة الظاهرة رواية يحافظ عليها المخطط. إن كان التصدير مهمًا، فأبقِ العنونة صريحة بدل أن تدع مترجمًا يقرر من يُحسب من.

اقرأ نمط الأمان قبل أن تثق بالتصدير

يفصل إرشاد Red Hat الخاص بـ NFS بين sec=sys، الذي يستخدم معرّفات UID وGID المحلية في UNIX عبر AUTH_SYS، وأنماط Kerberos. يضيف krb5 مصادقة المستخدم، ويضيف krb5i حماية السلامة، ويضيف krb5p حماية الخصوصية للحركة.

تحتوي بيانات اعتماد AUTH_SYS على حقول مثل UID المتصل ومعرّفات المجموعات، ويحذّر RFC 5531 صراحة من أن هذا النمط لا يوفّر أمانًا بحد ذاته ويعتمد على حماية خارجية. وتشغيله داخل VPN يوفّر حماية للنقل ولا يغيّر شيئًا في الادعاء داخل الحزمة.

exportfs -v
showmount -e nfs.example.internal

اقرأ النمط في ذلك المخرَج قبل أن تقرأ قائمة العملاء. فالتصدير الذي يبدو مقيّدًا قد يكون مقيّدًا بالعنوان فقط بينما كل متصل ما زال يعلن أي UID يريد.

اختر النموذج ثم أبقِ الأذونات

اختر نموذج مصادقة خدمة الملفات المناسب للعملاء الذين تديرهم فعليًا. يتطلب Kerberos هوية ونشر خدمة خلفه، لذا فإن تغيير خيار تركيب واحد ليس ترحيلًا وسيفشل ببساطة حتى يوجد نطاق Kerberos والـ principals والـ keytabs.

تحت أي من النموذجين، أبقِ أذونات التصدير وتفويض نظام الملفات الذي يقيّد ما يجوز للـ principal الموثَّق فعله. المصادقة تخبرك من يسأل؛ والتفويض يقرر هل ينبغي أن تكون الإجابة نعم. ودمج هذين في إعداد واحد هو كيف ينتهي الترحيل إلى منح أكثر مما منحته التهيئة القديمة.

استخدم قاعدة العنوان لغرضها الحقيقي

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

تحقق من أن واجهة أخرى أو بوابة بترجمة مصدر لا يمكنها تلبية القاعدة بشكل غير متوقع، واعتبر ذلك سببًا لإثبات المنشأ لا ادعاءً بأن تزوير عنوان يضمن تركيبًا ناجحًا.

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

مقالات ذات صلة