دو لاگ اِن جانچیں دو عوامل نہیں: VPN اور RADIUS

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

دوسرا بیک اینڈ دراصل کیا ثابت کرتا ہے

مقامی اکاؤنٹ کی تلاش ثابت کرتی ہے کہ کوئی نام ڈیٹا بیس میں موجود ہے اور کوئی پاس ورڈ اس سے مماثل تھا۔ RADIUS تبادلہ ثابت کرتا ہے کہ RADIUS سرور نے موصول شدہ خصوصیات کے لیے Access-Accept واپس کیا۔ دونوں میں سے کوئی بیان عامل کی قسم کا ذکر نہیں کرتا، کیونکہ دونوں علم کی تصدیق کرتے ہیں۔ اور NIST کی ڈیجیٹل شناخت کی رہنمائی مختلف عامل اقسام اور ان کے تصدیق کنندگان گنتی ہے، سرور یا اشارے نہیں۔

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

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

AND، OR اور بیک اپ الگ مصنوعات ہیں

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

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

بیک اپ سب سے زیادہ شک کا حقدار ہے، کیونکہ کچھ ٹوٹنے پر کام جاری رکھنے کے لیے اس کا وجود ہے۔ جب بھی RADIUS ناقابل رسائی ہو مقامی پاس ورڈ قبول کرنے والا بیک اپ مرکزی پالیسی کو دوسرے، کمزور دروازے میں بدل چکا ہے۔

OpenVPN کی دوہری جانچ ایک ٹھوس معاملہ ہے

کمیونٹی OpenVPN 2.6 دونوں فعال ہونے پر کلائنٹ سرٹیفکیٹ اور کنفیگر شدہ auth-user-pass-verify اسکرپٹ دونوں کا تقاضا کرتا ہے۔ یہ سرٹیفکیٹ کی تصدیق اور اسناد کی اسکرپٹ کے درمیان دستاویزی AND ہے، اور یہ واقعی دو جانچیں ہیں۔ پھر بھی یہ خود بخود دو قسم کے عوامل نہیں، کیونکہ اسکرپٹ صرف پاس ورڈ کی توثیق کر سکتی ہے۔

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

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

آلہ ساز اپنی پلمبنگ بناتے ہیں، اکثر ویب کنسول کے پیچھے PAM ماڈیول یا RADIUS پلگ اِن۔ کمیونٹی کا رویہ اس بات کا حوالہ ہے کہ دوہری جانچیں کیسی دکھتی ہیں، نہ کہ آلہ انہیں کیسے جوڑتا ہے۔

اپنے گیٹ وے پر امتزاج کی جانچ کریں

کنسول کے خلاصے پر بھروسا کرنے سے پہلے کنفیگریشن پڑھیں۔ پالیسی طے کرنے والی سطریں سرٹیفکیٹ موڈ، اسناد کی اسکرپٹ اور پلگ اِن ترتیب ہیں۔

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep ظاہر کرتا ہے کہ سرٹیفکیٹ درکار ہے یا نہیں اور اس کے بعد کون سی اسکرپٹ چلتی ہے، اور ترتیب ناموں کے اشارے سے زیادہ اہم ہے۔ سرٹیفکیٹ ڈمپ وہ شناخت دیتا ہے جو گیٹ وے دیکھے گا، جس میں وابستگی کے نقشے کے لیے درکار CN اور سیریل نمبر شامل ہیں۔ RADIUS جانچ منفی معاملہ ہے: غلط پاس ورڈ Access-Reject اور درست Access-Accept دے۔ اگر مسترد شدہ اسناد پھر بھی سیشن دے، تو اسکرپٹ تصدیق کے راستے پر ہی نہیں۔

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

ضرورت کو منفی معاملات کے طور پر لکھیں

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

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

کسی بھی پلگ اِن یا فرم ویئر تبدیلی کے بعد چاروں تردیدیں دوبارہ چلائیں۔ وہ سستی ہیں، اور جن پالیسی کی وہ حفاظت کرتی ہیں وہی حملہ آور پہلے جانچتا ہے۔