Windows VPN کو مضبوط بنانا: سرنگ سے پہلے تصدیق درست کریں

آپ کا Windows VPN سرور صارف نام اور پاس ورڈ مانگتا ہے، اور وہی ایک مکالمہ تین غیر متعلق فرائض چھپاتا ہے۔ ایک ثابت کرتا ہے کہ شخص کون ہے، ایک روکتا ہے کہ تار پر نظر رکھنے والا کوئی وہ ثبوت دوبارہ استعمال کرے، اور ایک طے کرتا ہے کہ بعد میں کون سے پتوں تک پہنچ سکتا ہے۔ زیادہ تر چھوٹی تعیناتیاں پہلے سرنگ مضبوط کرتی ہیں اور پہلے دو فرائض کو ان کی طے شدہ قدروں پر چھوڑ دیتی ہیں، جو غلط ترتیب ہے۔

اسی ترتیب سے کام کریں جس ترتیب سے حملہ آور کرتا ہے۔ پہلے وہ جو تار سے پکڑا جا سکتا ہے۔ پھر وہ جو اس ریکارڈنگ کے ساتھ بعد میں دوبارہ چلایا جا سکتا ہے۔ آخر میں، وہ جہاں تصدیق شدہ حملہ آور اندر پہنچ کر پہنچ سکتا ہے۔

تین فرائض، ایک مکالمہ

شناخت وہ حصہ ہے جس کے بارے میں لوگ سوچتے ہیں، اور یہ مسئلے کا صرف ایک تہائی ہے۔ شناخت کا ثبوت ایسے ناظر کا سامنا کرے جو تبادلہ ریکارڈ کرتا ہے اور بعد میں دوبارہ کوشش کرتا ہے۔ اور اجازت ایک الگ فیصلہ ہے جو سرور شناخت طے ہونے کے بعد کرتا ہے، اور Windows اسے اس خدمت سے الگ خدمت میں رکھتا ہے جو اسناد کی تصدیق کرتی ہے۔

جب تینوں ایک ہی ذہنی بالٹی میں رہتے ہیں، تو عام نتیجہ وہ سرور ہوتا ہے جو مضبوطی سے تصدیق کرتا ہے اور پھر صارف کو ہر چیز تک پہنچنے دیتا ہے۔ اسے بعد میں درست کرنا ابھی پالیسی طے کرنے سے مشکل ہے، کیونکہ تب تک فائر وال پروفائل، پتوں کا تالاب اور راستے سب پرانی مفروضے کو کوڈ کر چکے ہوتے ہیں۔

کسی بھی ترتیب کو چھونے سے پہلے تینوں کو اپنے نوٹوں میں الگ کریں، پھر انہیں سب سے کمزور کڑی سے اوپر درست کریں۔

MS-CHAPv2 دوبارہ چلانے کا امتحان کیوں نہیں جھیل سکتا

اگر سرور اب بھی MS-CHAPv2 کے ساتھ PPTP قبول کرتا ہے، تو سرنگ پاس ورڈ کو کسی بامعنی معنی میں محفوظ نہیں رکھتی۔ چیلنج اور جواب پکڑے جا سکتے ہیں اور آف لائن حملہ کیا جا سکتا ہے، اور 2012 میں ایک عوامی کریکنگ سروس نے عام پاس ورڈ کے لیے ایسی مصافحہ سے تقریباً ایک دن میں بحالی دکھائی۔ لمبا اور پیچیدہ پاس ورڈ لاگت بڑھاتا ہے؛ یہ وہ مواد نہیں ہٹاتا جو حملہ آور کو نیٹ ورک سے درکار ہوتا ہے۔

آپ کو جو خاصیت چاہیے وہ ایسی اسناد ہے جو دوبارہ نہ چلائی جا سکے۔ کلائنٹ سرٹیفکیٹ کے ساتھ EAP-TLS ہر آلے کو اس کی اپنی شناخت دیتا ہے اور آپ کو بالکل ایک آلہ منسوخ کرنے دیتا ہے۔

سرٹیفکیٹ کی تعیناتی حقیقی کام ہے: نجی CA، منسوخی کا راستہ جسے کلائنٹ جانچیں، اور تجدید کا منصوبہ جو عملے کی تبدیلی برداشت کرے۔ اس کام کو منصوبہ سمجھیں، اپنے اور چلتی سرنگ کے درمیان رکاوٹ نہیں۔ فائر وال کی تبدیلی کے لیے بجٹ رکھتے ہیں ویسے ہی اس کے لیے رکھیں۔ مشترکہ پاس ورڈ صرف پہلی منسوخی تک سستا ہے۔

پیشگی مشترک چابی جوڑی کی تصدیق کرتی ہے، شخص کی نہیں

L2TP/IPsec پیشگی مشترک چابی کے ساتھ ثابت کرتا ہے کہ دو گیٹ وے ایک ہی راز جانتے ہیں۔ یہ نہیں بتاتا کہ کون سا انسان جڑ رہا ہے، اور اس سطح پر ایک ملازم کو دوسرے سے الگ نہیں کر سکتا۔ لمبی بے ترتیب قدر استعمال کریں، کچھ رہنما کتابوں کے تجویز کردہ دس حروف سے بہت آگے، کیونکہ جو مصافحہ پکڑ لے وہ چابی پر آف لائن حملہ کر سکتا ہے۔

اس پروفائل کا ہر کلائنٹ راز مشترک کرتا ہے، اس لیے ایک شخص کو ہٹانے کا مطلب ہے اسے باقی سب میں دوبارہ تقسیم کرنا۔ مشین سطح کے راز کے اوپر صارف کی تصدیق کا الگ مرحلہ رکھیں، اور کلائنٹ تعداد بڑھنے کے ساتھ سرٹیفکیٹ کی طرف جائیں۔ پیشگی مشترک چابی MS-CHAPv2 کے ساتھ دو کمزور تہیں ہیں، اور دوسری پہلی کو بے اثر کر دیتی ہے۔

اجازت Network Policy Server میں ہے

Windows پر NPS طے کرتا ہے کہ کون جڑ سکتا ہے، اور یہ تصدیق پہلے ہی کامیاب ہونے کے بعد کرتا ہے۔ وہ علیحدگی مصنوع میں سب سے مفید مضبوطی کا کنٹرول ہے، اور کئی تعیناتیاں اسے اچھوتا چھوڑ دیتی ہیں۔

ایسی پالیسی شرائط استعمال کریں جو حقیقی پابندیاں ظاہر کریں: گروہ کی رکنیت، وہ وقت کی کھڑکی جب معاونت میں عملہ ہو، اور صحت کی جانچ سے آلے کی حالت۔ جہاں ڈیٹا رگڑ کو جائز ٹھہرائے وہاں دوسرا عنصر شامل کریں، اور یاد رکھیں کہ پالیسی ہر کنکشن کوشش پر جانچی جاتی ہے، جو اسے دستاویز کے بجائے زندہ کنٹرول بناتی ہے۔

RADIUS حساب کتاب آپ کو ایک ریکارڈ بھی دیتا ہے کہ کون اور کب جڑا۔ وہ لاگ واقعہ جائزے اور اندازے کے درمیان فرق ہے، اور رہتا ہے چاہے کوئی اسے پڑھے یا نہ پڑھے۔

محدود کریں کہ کامیاب لاگ ان کہاں پہنچ سکتا ہے

VPN اڈاپٹر کو پورے ذیلی نیٹ کے بجائے اپنے کردار کے لیے درکار خدمات کی اجازت دینے والے فائر وال پروفائل میں اترنا چاہیے۔ راستے کا سوال فلٹرنگ سے الگ ہے۔ مکمل سرنگ کلائنٹ آلے کی حفاظت کرتی ہے اور ہر بائٹ آپ کے اوپری لنک سے گزارتی ہے، جبکہ منقسم سرنگ مقامی ٹریفک کو مقامی رکھتی ہے اور آلے کو جس بھی نیٹ ورک پر ہو اس کے سامنے لاتی ہے۔

دونوں میں سے کوئی بھی انتخاب سیکیورٹی کی طے شدہ قدر نہیں ہے۔ دونوں کو اس فائر وال پروفائل کے ساتھ لکھنا ہوگا جس کا وہ تصور کرتے ہیں۔

ناکامی کے راستے جانچیں

جانچیں کہ کیا ٹوٹنا چاہیے: غلط پاس ورڈ، میعاد ختم سرٹیفکیٹ، منسوخ شدہ آلہ، گروہ سے باہر صارف۔ ہر ایک مختلف مقام پر ناکام ہونا چاہیے، اور لاگ کو بتانا چاہیے کہ کون سا تھا۔ سیٹ پہلے جانچ کے اکاؤنٹ پر چلائیں، پھر حقیقی صارف کے لیے دہرائیں۔ بلا سبب واقعہ لاگ میں پہنچنے والی مستردگی اس ریکارڈ کی ضرورت سے بہت پہلے درست کرنے کے قابل ہے۔

پھر تصدیق کریں کہ کون سے پورٹ شائع ہیں اور کیوں۔ PPTP کو TCP 1723 اور پورٹ کے بجائے IP پروٹوکول کے طور پر GRE چاہیے، IKEv2 کو UDP 500 اور 4500 چاہیے، اور L2TP کو UDP 1701 کے ساتھ IPsec چاہیے۔ کلائنٹ کے جڑنے کے لیے انتظامی انٹرفیس کھولنا مرمت نہیں ہے، یہ دریافت ہونے کے منتظر دوسرا واقعہ ہے۔

آخر میں طے کریں کہ سرور کیا اور کتنی دیر ریکارڈ کرتا ہے۔ تصدیق کی تاریخ کے بغیر آخری نقطہ واقعے کے بعد پہلے سوال کا جواب نہیں دے سکتا، یعنی کیا وہ کوشش کبھی مجاز تھی۔