VPN گیٹ وے پر Fail2ban: کیا ٹھیک کرتا ہے اور کیا نہیں

ہر کھلی سروس کو وہی مشورہ ملتا ہے: اس پر fail2ban لگائیں۔ VPN گیٹ وے کے لیے یہ مشورہ نہ غلط ہے نہ کافی، اور اسی کو ہارڈننگ کی ٹک سمجھنا وہ طریقہ ہے جس سے لوگ ایسے jail کے ساتھ رہ جاتے ہیں جو کوئی مفید چیز بلاک نہیں کرتا۔ Fail2ban ان ناکامی کے ریکارڈز کو پڑھتا ہے جن کی طرف آپ اسے اشارہ کرتے ہیں اور نافذ کرنے والے backend سے مماثل ذرائع بلاک کرنے کو کہتا ہے۔ اس کی پوری قدر اس پر ہے کہ کس تصدیقی سطح نے ریکارڈ بنایا، اس میں دیا گیا پتہ اصل کلائنٹ ہے یا نہیں، اور اس پتے کے پیچھے باقی سب کے ساتھ کیا ہوتا ہے۔

میکانکی طور پر fail2ban کیا ہے

فلٹر لاگ کی سطروں سے مماثلت پیدا کرتا ہے، jail فی ماخذ مماثلتیں گنتا ہے، اور عمل فائر وال backend کے ذریعے پابندی لگاتا ہے۔ تین متحرک حصے، اور ہر ایک آزادانہ طور پر غلط ہو سکتا ہے۔

تینوں میں سے کوئی تصدیقی راستے کو نہیں چھوتا: fail2ban واقعے کے بعد شہادتوں پر ردِعمل دیتا ہے اور کبھی خود کسی اسناد کی تصدیق نہیں کرتا۔ اس لیے jail صاف چل سکتا ہے جبکہ جس سطح کا وہ نام لیتا ہے وہ پہلے کی طرح کھلی رہتی ہے۔

ٹنل کا سننے والا لاگ اِن فارم نہیں ہے

OpenVPN سننے والا اگر tls-auth یا tls-crypt سے محفوظ ہو، تو عام TLS پروسیسنگ شروع ہونے سے پہلے کنٹرول چینل کی حفاظت کے بغیر پیکٹ پھینک دیتا ہے۔ جس اسکینر کے پاس کبھی چابی نہ ہو وہ ایسا کچھ پیدا نہیں کرتا جو آپ کا فلٹر گن سکے۔ سرٹیفکیٹ تصدیق ایک اور دروازہ شامل کرتی ہے، کیونکہ اندازہ لگانے کے لیے کوئی پاس ورڈ نہیں۔ Fail2ban منصوبہ ایک عام لاگ پر مبنی ماڈل کی دستاویز کرتا ہے، اور عام VPN فلٹر غیر تصدیق شدہ پیکٹ کو بامعنی ناکامی کا واقعہ نہیں بناتا۔

اگر گیٹ وے صرف سرٹیفکیٹ قبول کرتا ہے، تو جس بروٹ فورس کہانی سے آپ بچاؤ کر رہے ہیں وہ اس پورٹ پر بالکل نہیں ہو سکتی۔

تو آپ کس سطح کی حفاظت کر رہے ہیں؟

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

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

ماخذ کی نسبت کمزور کڑی ہے

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

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

پہلو کا خرچ دوسرے لوگ ہیں

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

مختصر پابندیاں اور معتدل حدیں اسے کم کرتی ہیں، اور دستاویزی اَن بین راستہ پھر بھی ایسا ہونے پر معاونت کا بوجھ کم کرتا ہے۔ پتہ ایک موٹا اشارہ، شناخت نہیں ہے، اور ٹکٹ کھولنے والا حد نہیں، رکاوٹ بیان کرے گا۔

کب اپنائیں، اور کب کوئی اور چیز درست کریں

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

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