VPN پتے پر مقفل NFS ایکسپورٹ: یہ کیا ثابت نہیں کرتا
ایکسپورٹ قاعدہ دیکھتا ہے کہ پیکٹ کہاں سے آیا; AUTH_SYS مقامی UID کا دعویٰ کرتا ہے اور Kerberos صارف کی تصدیق کرتا ہے۔ طے کریں کہ آپ کی فائل سروس کو کون سا درکار ہے۔
ایک میزبان کسی ڈائریکٹری کو VPN پتے پر ایکسپورٹ کرتا ہے، ماؤنٹ کامیاب ہوتا ہے، اور ڈیزائن تصدیق شدہ کے طور پر درج ہو جاتا ہے۔ یہ قاعدہ درحقیقت صرف یہ محدود کرتا ہے کہ پیکٹ کہاں سے آتے دکھتے ہیں۔ یہ کہ فائل آپریشن چلانے والا شخص واقعی وہی ہے جس کا وہ دعویٰ کرتا ہے، NFS سیکیورٹی فلیور پر منحصر ہے، اور اس قسم کے بیشتر ایکسپورٹس میں کسی نے اسے ڈیفالٹ سے تبدیل نہیں کیا۔
ایک درخواست میں تین شناختیں آ سکتی ہیں
VPN ساتھی کلائنٹ سرٹیفکیٹ یا ساتھی کلید جیسی رجسٹرڈ شناخت رکھتا ہے۔ اندرونی IP پیکٹ ماخذ پتہ رکھتا ہے۔ فائل آپریشن وہ صارف اسناد رکھتا ہے جو اس کا NFS میکانزم فراہم کرتا ہے۔ جو ڈیزائن پتے کو تینوں کا متبادل سمجھتا ہے اس نے خاموشی سے وہی حصہ فرض کر لیا جو تصدیق کرنا تھا۔
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
ان تین سطروں کا لکھنا ہی پورا مشق ہے۔ یہ بحث کہ ایکسپورٹ محفوظ ہے یا نہیں، اس وقت زیادہ تر ڈھیر ہو جاتی ہے جب واضح ہو کہ کون سا کنٹرول کس سطر میں رہتا ہے۔
پتے کی ملکیت نفاذ کی تفصیل ہے
گیٹ وے قبول شدہ ساتھی کو ٹنل پتہ دے سکتا ہے، یا اس کے لیے روٹ شدہ سب نیٹ مجاز کر سکتا ہے۔ یہ کہ نفاذ پھر ایسا پیکٹ مسترد کرتا ہے جس کا اندرونی ماخذ کسی دوسرے کلائنٹ کا ہو، اس نفاذ کی خصوصیت ہے، اور فرض کرنے کے بجائے اسے جانچنا بہتر ہے۔
روایتی Community OpenVPN صارف فضا سرور کوڈ، مثلاً، TUN ڈیوائس کے ذریعے پیکٹ پہنچنے سے پہلے کسی دوسرے کلائنٹ سے منسلک ماخذ کو مسترد کر سکتا ہے۔ یہ حقیقی قدر والی پتہ ملکیت کی جانچ ہے، اور یہ اب بھی NFS صارف کی تصدیق نہیں ہے، کیونکہ یہ نہیں بتاتی کہ کون سا اکاؤنٹ یہ عمل کر رہا ہے۔
ماخذ کی ترجمانی اسے بھی کھا جاتی ہے۔ NAT گیٹ وے ہر کلائنٹ کو ایک ہی پتے کے طور پر پیش کر سکتا ہے، اور پھر ایکسپورٹ قاعدہ اس کے پیچھے کے لوگوں میں امتیاز نہیں کر سکتا۔ قاعدے کی ظاہری درستگی پھر خاکے کے ذریعے قائم رکھی گئی افسانہ بن جاتی ہے۔ اگر ایکسپورٹ اہم ہے تو پتہ بندی واضح رکھیں، مترجم کو یہ فیصلہ کرنے نہ دیں کہ کون کس کے بدلے گنا جاتا ہے۔
ایکسپورٹ پر بھروسہ کرنے سے پہلے سیکیورٹی فلیور پڑھیں
Red Hat کی NFS رہنمائی sec=sys، جو AUTH_SYS کے ذریعے مقامی UNIX UID اور GID استعمال کرتا ہے، کو Kerberos طریقوں سے الگ کرتی ہے۔ krb5 صارف کی تصدیق شامل کرتا ہے، krb5i سالمیت کا تحفظ شامل کرتا ہے، اور krb5p ٹریفک کے لیے رازداری کا تحفظ شامل کرتا ہے۔
AUTH_SYS اسناد میں کال کرنے والے کا UID اور گروپ شناخت کنندہ جیسے میدان ہوتے ہیں، اور RFC 5531 صریحاً خبردار کرتا ہے کہ یہ فلیور بذات خود کوئی سیکیورٹی فراہم نہیں کرتا اور بیرونی تحفظ پر منحصر ہے۔ اسے VPN کے اندر چلانا نقل و حمل کے لیے تحفظ دیتا ہے اور پیکٹ کے اندر کے دعوے میں کچھ نہیں بدلتا۔
exportfs -v
showmount -e nfs.example.internalکلائنٹ فہرست پڑھنے سے پہلے اس آؤٹ پٹ میں فلیور پڑھیں۔ محدود دکھنے والا ایکسپورٹ صرف پتے سے محدود ہو سکتا ہے جبکہ ہر کال کرنے والا پھر بھی کوئی بھی UID دعویٰ کرتا ہے۔
ماڈل منتخب کریں، پھر اجازتیں برقرار رکھیں
وہ فائل سروس تصدیق ماڈل منتخب کریں جو ان کلائنٹس کے لیے موزوں ہو جنہیں آپ واقعی منتظم کرتے ہیں۔ Kerberos کو پیچھے شناخت اور سروس کی تعیناتی درکار ہے، اس لیے ایک ماؤنٹ اختیار بدلنا ہجرت نہیں ہے اور Kerberos ڈومین، پرنسپل اور keytab موجود ہونے تک وہ محض ناکام ہوگا۔
دونوں ماڈلز میں، ایکسپورٹ اجازتیں اور فائل سسٹم کی اجازت رکھیں جو تصدیق شدہ پرنسپل کی حدود طے کرتی ہیں۔ تصدیق بتاتی ہے کون پوچھ رہا ہے؛ اجازت طے کرتی ہے کہ جواب ہاں ہونا چاہیے یا نہیں۔ ان دونوں کو ایک ترتیب میں یکجا کرنا ہی وہ طریقہ ہے جس سے ہجرت بالآخر پرانی تشکیل سے زیادہ اختیار دینے لگتی ہے۔
پتہ قاعدے کو اس کے اصل مقصد کے لیے استعمال کریں
سروس کو منظور شدہ راستے اور ماخذوں تک محدود رکھنا اب بھی مفید ہے، بشمول میزبان کا اندراجی نظریہ جب VPN اختتامی نقطہ اور NFS سرور ایک ہی مشین شیئر کرتے ہیں۔ ٹریفک آگے بھیجنے والے قواعد ان درخواستوں کو کنٹرول نہیں کرتے جو اسی میزبان پر مقامی طور پر چلنے والی سروس کی طرف نشانہ ہوں۔ یہ خلا حیران کن تعداد میں ان ایکسپورٹس کی وضاحت کرتا ہے جو نجی ہونے چاہیے تھے۔ ٹنل قواعد اسے ڈھانپتے ہیں یہ ماننے کے بجائے مقامی اندراجی نظریہ واضح طور پر جانچیں۔
جانچیں کہ کوئی دوسرا انٹرفیس یا ماخذ کی ترجمانی کرنے والا گیٹ وے غیر متوقع طور پر قاعدہ پورا نہیں کر سکتا، اور اسے پتہ جعلی بنانے سے کام کرنے والے ماؤنٹ کی ضمانت ہونے کے دعوے کے بجائے اصل ثابت کرنے کی وجہ سمجھیں۔
ایک کے بجائے تین قبولیت کے کیس چلائیں۔ منظور شدہ کلائنٹ کے ساتھ منظور شدہ صارف کے طور پر شروع کریں، پھر کبھی منظور نہ ہونے والے ساتھی سے دہرائیں، پھر کوئی ایسی چیز آزمائیں جو منظور شدہ صارف کو اب بھی اجازت نہیں۔ پھر پوچھیں کہ اگر مجاز کلائنٹ سے سمجھوتہ ہو جائے تو کیا بدلتا ہے، کیونکہ نقل و حمل کی تصدیق اس مشین کے ہر عمل کو قابل اعتماد نہیں بناتی۔ چوری شدہ سرٹیفکیٹ اور متجسس مقامی اکاؤنٹ مختلف کنٹرولز والے مختلف مسائل ہیں۔