OpenVPN میں RADIUS جوڑنا: پلگ اِن یا اسکرپٹ ہک؟

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

افسانہ: پلگ اِن ہی معاون راستہ ہے

پلگ اِن ایک مشترک آبجیکٹ ہے جو OpenVPN کے عمل میں لوڈ ہوتا ہے، اس لیے اسے اُس انٹرفیس سے مطابقت رکھنی چاہیے جو وہ عمل فراہم کرتا ہے۔ بلڈز بدلتے ہیں، پیکجنگ بدلتی ہے، اور پرانے انٹرفیس کے لیے کمپائل شدہ لائبریری لوڈ ہونے سے انکار کر دیتی ہے۔ سرور کنفیگریشن میں کوئی چیز اُس خلا کو نہیں بھر سکتی، اسی لیے "صرف radiusplugin نصب کریں" کا مشورہ ایسے سرور پر ختم ہوتا ہے جو شروع نہیں ہوتا۔

اسکرپٹ ہک اس کے برعکس عمل سے باہر کھڑا ہوتا ہے۔ OpenVPN ایک پروگرام چلاتا ہے، اسے اسناد دیتا ہے اور فیصلہ پڑھتا ہے۔ یہی علیحدگی اسے اپ گریڈز سے گزرنے دیتی ہے، اور یہی اسے اُس طرح آپ کی ذمہ داری بناتی ہے جس طرح پلگ اِن کبھی نہ تھا۔

کوئی بھی طریقہ اپنی ساخت کے لحاظ سے زیادہ محفوظ نہیں۔ ایک ڈیمان کے اندر غیر ملکی کوڈ چلاتا ہے؛ دوسرا اسناد ہاتھ میں رکھ کر آپ کا کوڈ اس کے ساتھ چلاتا ہے۔ صحیح سوال یہ ہے کہ ان دو خطرات میں سے کون سا آپ واقعی سنبھال سکتے ہیں۔

پلگ اِن نے کیا باندھا تھا

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

قیمت جوڑ تھی۔ ہر OpenVPN اپ گریڈ غیر مطابق انٹرفیس کا خطرہ رکھتا تھا، اور پیکج دوبارہ بنانے والی ہر تقسیم ایسی لائبریری بنانے کا خطرہ رکھتی تھی جو اب مطابقت نہیں رکھتی۔ جب ایسا ہوتا ہے، ناکامی بلند اور فوری ہوتی ہے، اور یہی اس ڈیزائن کی واحد رحمت ہے۔

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

اسکرپٹ ہک واقعی کس پر بھروسہ کرتا ہے

ہک auth-user-pass-verify اور ترسیل کے طریقہ کار کے ساتھ ترتیب دیا جاتا ہے: ماحول کے متغیرات یا عارضی فائل۔ ماحول کی شکل میں OpenVPN کو script-security 3 درکار ہے، وہ دستاویزی سطح جو اسکرپٹس کو پاس ورڈ ظاہر کرنے کی اجازت دیتی ہے۔ یہ سطح طے شدہ کی جان بوجھ کر کمزوری ہے، اور اسے وجہ کے ساتھ منسلک اجازت سمجھنا چاہیے۔

اسکرپٹ جسے بھی چھوتی ہے وہ اُس اعتماد کا وارث ہوتا ہے۔ اسے root کی ملکیت ہونا چاہیے، گروہ یا دیگر کے لیے قابلِ تحریر نہ ہو، مکمل راستے سے حوالہ دیا جائے، اور ایسی کسی جگہ سے پاک ہو جہاں غیر معتبر قدر shell تک پہنچے۔ ہر متغیر کو اقتباس میں رکھیں، غیر متوقع حروف مسترد کریں، اور فراہم کردہ صارف نام سے کبھی حکم نہ بنائیں۔ ہر لاگ اِن کوشش پر root کے طور پر چلنے والی اسکرپٹ انہی چار خصوصیات کی بنا پر ایک بار جائزہ لینے کے قابل ہے۔

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

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

اخراجی کوڈ طے کرتے ہیں کہ آپ کھلے طور پر ناکام ہوں گے یا نہیں

اسکرپٹ کی اخراجی حالت ہی فیصلہ ہے: صفر قبول کرتا ہے، غیر صفر مسترد کرتا ہے۔ دشواری پیدا کرنے والا نمونہ وہ shell اسکرپٹ ہے جو صرف اُس وقت قبول کرتی ہے جب RADIUS جواب میں کوئی مخصوص قبولیت ٹوکن ہو اور باقی سب کے لیے ناکامی واپس کرتی ہے، کیونکہ یہ تین مختلف واقعات کو ایک جواب میں یکجا کر دیتی ہے۔ غلط پاس ورڈ، ناقابلِ رسائی سرور اور بگڑا ہوا جواب سب ایک ہی مسترد ہو جاتے ہیں۔

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

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

سرٹیفکیٹ جانے پر آپ کیا چھوڑتے ہیں

اس شکل کی بہت سی تعیناتیاں کلائنٹ سرٹیفکیٹ کی جانچ مکمل طور پر بند کر دیتی ہیں، اور صارف نام اور پاس ورڈ کو کلائنٹ کا پورا دعویٰ بنا دیتی ہیں۔ اُس ترتیب کے ساتھ جو غائب ہوتا ہے وہ سرٹیفکیٹ پر مبنی شناخت ہے۔ چینل خفیہ رہتا ہے، لیکن کلائنٹ کا نام لینے والی واحد چیز RADIUS کا فیصلہ ہے۔ پہلے سرٹیفکیٹ کے موضوع پر منحصر کوئی بھی نیچے کی چیز اب صارف نام پر منحصر ہونی چاہیے۔

کنٹرول چینل کا تحفظ برقرار رکھیں تاکہ غیر تصدیق شدہ ساتھی ہینڈ شیک کی جانچ یا سیلاب نہ کر سکے، اور username-as-common-name استعمال کریں جب فی صارف کنفیگریشن عام نام پر منحصر ہو۔ منظم گیٹ ویز اسے اکثر مختلف طریقے سے حل کرتے ہیں، سرٹیفکیٹ کی تصدیق اُس گیٹ وے پر ختم کرتے ہیں جو RADIUS سے EAP-TLS بولتا ہے، اور اُس صورت میں یہ سرور ہدایات میں سے کوئی بھی لاگو نہیں ہوتی۔ ہمسایہ مصنوع کی نقل نہیں، اپنے پلیٹ فارم کا دستاویزی نمونہ کاپی کریں۔ اہم ہدایات اتنی مختلف ہیں کہ انہیں ملانا ایسی کنفیگریشن بناتا ہے جو پارس ہوتی ہے اور پھر کسی کی تصدیق نہیں کرتی۔